The steps will sit on the screenshot, not beside it.
Building a walkthrough of your own is coming. The player below is not a picture of one: it is the component the product ships, playing a walkthrough of the app itself.
Five things the board does, marked on one screenshot
Press a dot, press Next, or use the left and right arrow keys. The rail fills in as you go, the counter keeps its place, and Chapters jumps straight to a slide.
That screenshot is the desktop app itself, so the tour is worth taking on its own.
A walkthrough of the SnapBuddy board
Five hotspots over one screenshot of the desktop app. Take them with the dots, with Next, or with the arrow keys.
A walkthrough of the SnapBuddy board
Chapters
A walkthrough of the SnapBuddy board
Five hotspots over one screenshot of the desktop app. Take them with the dots, with Next, or with the arrow keys.
Capture screen takes the whole display. Region drags a rectangle over anything on screen, and Window picks one window that is already open.
Annotate opens the editor over the shot. On a screenshot, redaction removes the pixels underneath rather than covering them over.
Type what went wrong here. The note stays attached to the card and travels with it wherever the card goes.
The environment line is filled in for you. It is read off the machine that took the capture rather than typed by whoever files the bug.
Save card writes it to the board, and to your save folder when auto-save is on. What you capture is written to this computer and stays there.
That was the player, and the player is the part that is built
Making a walkthrough of your own is what is coming. Everything you just used already ships.
That is the player itself and not a picture of one. The walkthrough it is playing is written into this page, nothing is uploaded, no walkthrough is stored, and there is no control here that starts one, because authoring is not switched on yet.
Back goes where you have been, not one row up the list
A Next button stores a sentinel, not a step. It is resolved at the moment somebody plays the walkthrough, so reordering the steps never quietly repoints a link at yesterday’s order.
Back walks the history of what this viewer has actually seen, not the step before the current one in the list. After a jump from step two to step seven, the step before is one they have never laid eyes on.
Focus never moves. Changing step announces itself in a polite live region and leaves the cursor exactly where the reader put it, because yanking focus into a tooltip on every advance is hostile to anybody driving with a switch or a screen reader.
No blur is ever painted over a picture here. A redaction is baked into the bytes on every export path, and a rectangle drawn over an original that can still be saved out of the page hides nothing while looking as though it does.
The numbered list under the frame is not a caption. It is every step of the walkthrough as plain text, in the first byte the server sends, which is what makes one readable with JavaScript switched off, quotable into a bug ticket, and crawlable. Turn the engine off and reload this page: the walkthrough is still all there.
Interactive demos · coming soon
Walkthroughs
you will build
by pointing.
Hotspots will land on the frames you already captured, branches will go wherever you send them, and reordering a step will not repoint anything at the wrong target.
- Branching
- Chapters
- Reachability check
The tooltip copy in the picture is a suggestion the builder will offer. Nothing in SnapBuddy writes tooltip copy today.
Half of the words describe where a button is. The other half go stale.
A written set of steps asks the reader to rebuild your screen in their head before they can follow you, and it asks again every time they lose their place.
A walkthrough will put the pointing back in. Hotspots will land on the frames you already captured, each one will carry the sentence that belongs to it, and the person following will move at their own pace instead of scrubbing a video for the second where you clicked the thing.
It will branch, because the honest answer to half of these questions is “it depends”. A step will be able to offer two ways on and send each of them somewhere different, and a chapter slide will do the same at the level above. That is a directed graph rather than a list, which is why reordering will stay safe and why the builder will be able to tell you, before you publish, that every step can still be reached.
And the thing you send will be a link. The same link that already works the moment it is created, and dies the moment you delete what is behind it.
Something you can use before any of that
The annotation editor runs on the web. No account, no install, no upload: it is the same engine the desktop app and the extension run, loaded unmodified in a frame, and it opens whatever image you hand it.
Nothing is stored. The picture you open never leaves the tab, there is nowhere for it to be saved to, and the page tells you so when you press Save.
The frames are already on your board
The frames. Capture, region and window shots go to the board today, a recording goes beside them, and those are the pictures a walkthrough will be assembled from rather than a second set you have to go and take.
The desktop recorder already writes an interaction track beside a take, and the markdown export turns it into numbered repro steps. That is mechanical, it reads mouse positions, clicks and window focus changes, and it ships today.
A walkthrough you build yourself
Dropping hotspots on your own frames, branching them, and publishing the result as a link is what is coming. The player it will publish to is the one further up this page.
Every walkthrough will start with a capture. Those ship today.
The desktop app is the part that takes them, and it is built, shipping and Windows only.
The privacy notice names everything that ever leaves your computer.