Polishing the Overlay: From Functional to Professional

The Sync Works. Now Make It Beautiful.

After fixing the GPS temporal gaps in episode 7, the synchronization between video and telemetry data is solid. The speed matches what you see in the video. The map follows the route correctly. When I stop at a traffic light, the speed drops to zero. When I accelerate, it climbs smoothly.

But "functional" isn't enough for a landing page demo. The overlay needs to look like something people would actually want on their cycling videos — not developer debug output. This session was about closing that gap.

Redesigning the Gauges

The original telemetry overlay was basic CSS spans: white text floating over the video with speed, elevation, and heart rate. Functional, but forgettable. The target was the Safa Brian aesthetic — clean, modern, with a sense of speed and data richness.

I created a reference mockup in Photoshop with the exact layout I wanted: speed prominently at the bottom in large numbers, heart rate and cadence on the upper left, a gradient bar showing progress, and the SportsSync logo in the corner. Then I uploaded this image to Lovable with a simple prompt: "Style the telemetry gauges to match this design."

Lovable nailed it on the first try. The gauges shifted from plain text to a professional overlay with proper typography, positioning, and opacity. The speed numbers got larger and more prominent. Heart rate moved to the expected position. The SportsSync logo appeared in the corner with a CSS brightness filter to make it white.

Small refinements followed: moving the speed display up to avoid overlapping YouTube's built-in controls, adjusting opacity so the gauges don't compete with the video content, and adding subtle dot indicators for the speed bar.

The Missing Metrics: Cadence and Power

Two important cycling metrics were absent from the overlay: cadence (pedaling RPM) and power (watts). Both exist in the GPX file but weren't appearing in the UI.

The investigation revealed a layered problem. First, the GPX parser was extracting these values correctly for recorded points, but the gap-filling algorithm from episode 7 wasn't copying cadence and power to the interpolated points. So during any period where the GPS had dropped data (stops, coasting), these metrics showed as undefined rather than zero.

Second, I had previously told Lovable to hide metrics with zero values — thinking it would look cleaner. But cadence and power legitimately start at zero when you're stopped. Hiding zeros meant the metrics would appear and disappear as you started and stopped pedaling, creating a distracting flicker.

The fix was two-part: ensure the interpolation algorithm copies ALL metrics (not just position and heart rate) to generated points, and display metrics whenever they exist in the GPX data, even when zero. If a metric genuinely doesn't exist in the file (some GPS devices don't record power), don't show it at all.

Smooth Value Transitions

A subtle but important detail: how quickly the numbers update. The original implementation refreshed once per second, creating a robotic stepping effect — speed would jump from 14.1 to 17.3 in a single frame. Real cycling computers show smooth transitions.

I adjusted the refresh interval to 100 milliseconds with interpolated intermediate values. The difference is dramatic. Speed now flows naturally, accelerations feel organic, and the whole overlay gains a sense of real-time data rather than sampled snapshots.

The Wizard Problem

The current demo uses a four-step wizard: load video, upload GPX, review data, view result. Steps one and two should be a single screen — two upload boxes side by side. Step three (data review) adds nothing for the user experience. Step four (visualization) is the only screen that matters.

The ideal flow: one page with video and GPX upload areas at the top, and the synchronized visualization below. Upload both files, pick your sync point, and the overlay appears. No navigation, no "next" buttons, no context switching.

I started this refactor but it's more complex than a single prompt — the state management spans multiple components, and Lovable's changes kept breaking the existing synchronization logic. This gets pushed to the next session.

Planning the Product Transition

With the demo nearly complete, I mapped out the remaining work before transitioning from "building the landing page" to "building the product":

Immediate (episode 9): Analytics integration (Google Analytics or similar) to understand visitor behavior. Domain warming for email deliverability. Finalize the wizard UX. Consider replacing the hero image with an auto-playing video of the overlay in action.

Summary video (episode 10): A 10-minute recap of the entire journey so far, created by feeding YouTube's auto-generated subtitles to an AI and asking it to identify the most important moments from each episode. Repurposed content, minimal new recording.

User research (episode 11): Two 15-minute conversations with real cyclists. Edu — my cycling coach who trains athletes and has a YouTube channel. And Marc — a cycling content creator who's essentially a semi-pro cyclist and journalist. The goal: show them the demo, ask if they'd use it, identify what's missing.

Marketing phase: Create Instagram and Twitter accounts for SportsSync. Produce short-form content showing the overlay in action. Start with my own cycling footage, then expand if the user research validates the concept.

The Video Format Question

An important product decision emerged: the overlay currently renders in 16:9 (landscape, standard YouTube). But Instagram Reels, TikTok, and YouTube Shorts use 9:16 (portrait). The gauges need to reflow for vertical video — speed and heart rate repositioned for a tall frame instead of a wide one.

This isn't just a CSS media query. It changes the entire composition. In landscape, you have wide horizontal space for speed at the bottom and metrics on the side. In portrait, everything competes for vertical real estate. The gauge positions, sizes, and hierarchy all need rethinking for 9:16.

The solution I'm considering: the MVP renders the video with overlays server-side (using ffmpeg or a similar tool), and the user chooses the output format before rendering. The client-side demo stays 16:9 for now.

YouTube Analytics Reality Check

A candid look at the numbers: episode 1 was shown to 82,000 people with a 3.5% click-through rate — 4,200 views. By episode 5, impressions dropped to roughly 8,000. The series is losing reach with each episode.

This is typical for serialized content on YouTube. New viewers find episode 1, watch it, but don't necessarily continue to episode 5. The algorithm shows later episodes to fewer people because the audience is smaller and more niche.

The plan: create that summary video to give new viewers a faster entry point, and start producing standalone content (tool comparisons, cycling tech) that can attract viewers independently of the series.

Where Things Stand

The telemetry overlay is visually professional. The sync is accurate. Cadence and power are rendering. The update rate is smooth. What remains is UX polish — collapsing the wizard, integrating the demo into the landing page, and adding the analytics layer.

After that, the building phase pauses and the selling phase begins. The product can't stay a landing page demo forever. Real users need to tell me what they actually want before I invest months building a server-side rendering pipeline.