Why viewers pause tutorials, and how on-screen keys stop it
Viewers pause a tutorial when something changes on screen and they cannot see why. Most often that is a keyboard shortcut: you press Command-Shift-N, a new folder appears, and the video shows no cause at all. Putting the keys you press, the clicks you make and the name of each shortcut on screen gives viewers the cause in the same frame as the result, so they keep watching instead of scrubbing back.
Below: the moments that send people to the pause button, what you can fix in how you record, how to caption shortcuts, and what an on-screen key display adds.
The moments that make people pause
Watch one of your own tutorials the way a beginner does, with the app open in another window, trying to follow along. The pauses cluster around a handful of moments.
A shortcut with no visible cause. A panel opens, a window disappears, a file is duplicated. You pressed a key; the viewer saw nothing. They scrub back, see nothing again, and start hunting through the menus.
A click too fast to see. The pointer darts across the screen, lands, and a menu opens and closes before anyone has read it. On a large display shrunk down to a phone, the pointer is a few pixels wide.
A modifier on a click or drag. Option-dragging a file in Finder copies it instead of moving it. Command-clicking adds to a selection. On video, a modified drag looks exactly like a plain one, and the viewer who copies it gets a different result.
A right click. A context menu appears, and the viewer cannot tell whether you right-clicked, Control-clicked or pressed something on the keyboard.
A jump. Command-Tab to another app, a swipe to another Space, Mission Control. The screen is suddenly somewhere else, and the viewer has to work out where and how.
Typing they need to copy. A command in Terminal, a formula, a search term. If they cannot read it, they cannot follow.
None of these are mistakes. They are how people who know an app use it. The trouble is only that the video does not show them.
Fix what you can while you record
Before adding anything to the screen, a few habits cover a lot of ground.
- Say the shortcut as you press it. “Command-Shift-N, new folder.” Use the names printed on Mac keys: Command, Option, Control, Shift, Return, Delete. Viewers coming from Windows will not have to translate Alt and Backspace.
- Show the long way first. The first time you use a command, choose it from the menu, so viewers see where it lives and see its shortcut printed beside it. After that, use the shortcut.
- Pause a beat after each step. Let the result sit on screen for a second before you move on. It costs you very little and saves the viewer a rewind.
- Point, then click. Move the pointer to the thing you are about to click, stop, then click it.
- Make the pointer bigger. In System Settings, open Accessibility, then Display, and raise Pointer size a notch or two. It reads much better once the video is shrunk.
- Turn on Show Mouse Clicks. If you record with Command-Shift-5 (⇧⌘5), or with New Screen Recording in QuickTime Player, the Options menu in the screenshot toolbar has Show Mouse Clicks, which draws a circle around the pointer each time you click.
Show Mouse Clicks covers clicks only. Neither the screenshot toolbar nor QuickTime Player has an option for the keys you press, and macOS has no setting for it. How to show keystrokes in a screen recording on a Mac covers the ways to add them.
Captions and on-screen text
Narration helps, but plenty of people watch with the sound off, in a second language, or with one ear on something else. Text on screen reaches them too.
Some practices that hold up:
- Write shortcuts the same way every time. Pick one style, such as “Command-Shift-4” or “⇧⌘4”, and keep to it in the video and the description. Mixing styles makes viewers wonder whether they are different shortcuts.
- Name the result, not just the keys. “⇧⌘4” tells a viewer what to press. “⇧⌘4 Screenshot Selection” also tells them what it does.
- List the shortcuts in the description or chapters. Someone who wants to try one later should not have to scrub back to find the frame.
- Keep captions clear of the action. If the important part of the screen is at the bottom, move your text to the top for that section. Where to put a keystroke overlay so it never covers the action has more on placement.
Adding all of this by hand in an editor works, but it is slow. Every shortcut is a title to type, place and time, and it is easy to miss one, which is usually the one somebody pauses on.
What on-screen keys add
A key display puts the cause on screen at the moment it happens, with no work in the edit. Typebar is one: every key you press lights up on an on-screen keyboard, and a keystroke pill shows what you pressed as keycaps, with the name the shortcut has in the app you are using, such as “⇧⌘4 Screenshot Selection” or “⌘K Insert Link”. The names come from the app’s own menus, so they match what your viewers find when they go looking.
Back to the moments that cause pauses:
| Moment | What the viewer sees |
|---|---|
| A shortcut with no visible cause | The keys light up and the pill names the action |
| A fast click | A ripple where the click landed, and Click in the pill |
| A modifier on a click or drag | The modifier lit on the board; a Command-click reads as ⌘ Click |
| A right click | A ripple with its own shape, and Right Click in the pill |
| The same shortcut several times | One chip that counts up: ×2, ×3 |
| Typing | The letters gathered into one chip, not a blur of single keys |
Clicks appear in the pill when Show clicks in the pill is on, in the Mouse settings. For the pointer that darts across the screen, a cursor halo puts a circle around it wherever it goes, and a drag trail shows the path of a drag. All of these show while the overlay shows, and they appear in the recording.
You choose how much the pill shows. For a tutorial about shortcuts, show everything. For one where you type a lot of ordinary text, set it to show only shortcuts, with or without keys like Return and Tab, so it does not fill up with sentences. Show clicks and keystrokes together so viewers see the whole action goes further into combining the two.
What on-screen keys do not fix
A key display shows what you did. It does not explain why, and it does not slow you down. Keep the habits from earlier: say what you are doing, pause after each step, and show the menu the first time. The overlay covers the moments you forget to narrate, and in a long recording there are many of those.
It also has to be in the frame. Typebar’s keyboard and pill appear in screen recordings like any other window, so record the whole display or an area that includes them. A recorder set to capture one other app’s window will leave them out.
If the tutorial involves signing in to something, typing in fields that macOS marks as secure never shows; the pill says “Typing hidden in a password field” instead.
Typebar is $9 once, and the first 24 hours are free with everything on.
Questions
Why do viewers pause screen recording tutorials so often?
Mostly because something changes on screen with no visible cause: a keyboard shortcut, a quick click, a modifier on a drag, or a jump to another app. They pause to work out what happened.
Does macOS show keystrokes in a screen recording?
No. The screenshot toolbar can show mouse clicks, through Show Mouse Clicks in its Options menu, but macOS has no setting that shows the keys you press.
Should I still narrate if the keys are on screen?
Yes. On-screen keys show what you pressed; narration says why. Together they work for viewers with the sound on and with it off.