Screen recording annotations: what breaks when the page scrolls
The arrow lands perfectly on the toggle. Then the recording scrolls, the toggle rides up out of frame, and the arrow keeps pointing at a blank strip of sidebar for the next four seconds.
Quick Answer: Screen recording annotations are the arrows, boxes and brackets laid over a screen capture to direct attention. An annotation that holds a fixed position on the frame comes loose the moment the interface underneath it moves. Either the annotation follows the element, or the capture holds the target still.
What are screen recording annotations actually pinned to?
An annotation is pinned to a position on the frame, with an X, a Y, and an in and out point.
Nothing in that description mentions the button. The annotation knows a rectangle and a span of time, and it will sit there with total confidence while the page underneath it scrolls or opens a modal.
The same is true of the highlight box, the rounded rectangle around a form field, and the bracket with a label hanging off it, all of which end up on a product demo video.
Why do screen recording annotations break when the page scrolls?
Because scrolling moves the target and leaves the annotation behind. Four common approaches produce four different outcomes.
| Approach | What holds the annotation | What happens on scroll | What it costs you |
|---|---|---|---|
| Pinned to the frame | Fixed X and Y for a set duration | Target slides away, annotation stays put | Nothing at first, then a reshoot when someone notices |
| Stacked along the scroll | Several annotations, each hand timed | Roughly tracks, drifts at the ends of each segment | Manual timing work, and a full redo if the recording changes |
| Following the element | The annotation is bound to the target | Annotation moves with the target | Depends on tooling that can track the element |
| Target held still at capture | A recording planned so nothing moves | No scroll to survive | Planning time, and less freedom in the take |
The second row is the one people build by hand.
What does the stacked workaround for screen recording annotations cost?
It is a feature request wearing a costume. When someone splits one arrow into four arrows and hand times each one to a scroll, they are describing an annotation that should have followed the element, and paying for its absence in keyframes.
Capsule's published figures put 30% of creative time into tedious tasks. Timing four arrows so that one arrow appears to work is that 30% in miniature, on a Tuesday afternoon.
The cost compounds with volume. One walkthrough is an afternoon, and a library covering the types of product demo video teams actually ship is that afternoon repeated by whoever is holding the timeline that week.
How do screen recording annotations fail in a settings page walkthrough?
A product marketer records a settings page. The field she needs to explain sits about two thirds down, below the fold.
The recording
- She opens settings, lands at the top of the page, and starts talking.
- She scrolls for roughly two seconds to reach the notification section.
- She stops on the row she cares about and keeps narrating for eight seconds.
- She scrolls a little further by accident while gesturing at the trackpad.
The annotation pass
- Arrow one points at the row's final resting place, right for the last eight seconds and wrong for everything before it.
- Arrow two covers the top of the scroll, placed where the row starts.
- Arrow three covers the middle of the scroll, eyeballed halfway between.
- Arrow four cleans up after the accidental nudge.
That is four annotations to keep one arrow on one row. Then the product team ships a redesign of the notification section and all four are garbage, because the row now sits 60 pixels higher and the scroll is shorter.
What should screen recording annotations follow instead of the frame?
The element. An annotation bound to a target moves when the target moves, which is what the four arrow stack was imitating.
Where the tooling cannot do that, the fix moves earlier, into the capture. Set the browser to a window height that puts the target on screen without scrolling. Collapse the sections above it. Use a deep link to land straight on the field. Record the scroll and the explanation as separate takes so the arrow only has to survive a still frame.
Both routes sit alongside the rest of the decisions you make at capture. Setting the window height before you hit record costs a minute. Handling it afterwards costs four annotations, plus a redo the next time the page changes.
FAQ
What are screen recording annotations?
Screen recording annotations are the arrows, boxes, brackets and highlights placed over a screen capture to direct attention to part of the interface. An annotation positioned on the frame for a set duration has no link to the element it points at.
Why do my screen recording annotations drift when the page scrolls?
The annotation is holding still while the interface underneath it moves. An annotation fixed to the frame has no relationship to the button or row it appears to indicate, so any scroll separates the two.
How do you keep an arrow on a moving element in a screen recording?
Use a tool that binds the annotation to the target so it tracks automatically, or plan the capture so the target never moves: a shorter page, collapsed sections, a deep link straight to the field, or the scroll recorded as its own take.
Is it better to fix screen recording annotations in the edit or at capture?
At capture, when you have the choice. An edit can time a stack of annotations to a scroll, but every one of those keyframes has to be redone when the product changes or the recording is replaced.