Notate
Annotate anything for humans and their agents
93 followers
Annotate anything for humans and their agents
93 followers
Notate is for anything where pointing beats describing: design and motion review, product walkthroughs, code review, and handoffs. Unlike screenshot tools, it freezes open menus, hover and focus states before they disappear, or records a flow so you can pin the exact frame where an animation breaks. Gesture-based annotation keeps the flow fast; smart crop and reopenable sessions preserve the image, comments, and context so feedback stays useful when it reaches a teammate or an agent.
Notate
@victor_aremu Do designers and developers end up using Notate differently, or is the workflow pretty similar?
Notate
@reda_roqai_chaoui The capture half is identical — freeze or record, point, comment; there are no tools to learn, so there's nothing to use differently. The split shows up at the export: developers mostly take the text side, numbered comments with coordinates that an agent or a ticket can act on, while designers take the image side — one picture with the comments joined on, ready to drop anywhere. Same session, two outputs; the file doesn't care who made it.
Honestly though, it's early — most of what I've watched closely is the developer loop, so if you're on the design side I'd genuinely like to hear where it falls short.
Notate
Thank you to everyone who supported Notate launch—whether you upvoted, tried the app, shared it, or sent feedback. I really appreciate it.
I’ve also opened a Discord community for anyone who wants to keep the conversation going, share feedback, or follow development more closely.
Notate is only getting started, so keep an eye out for Notate 1.0.
The capture half is solved here in a way I haven't seen elsewhere, so my question is about the other end of the loop. I annotate the frame where the easing breaks, the agent changes the code — and now I have to get back to that exact state to see whether it's fixed. Same hover, same interruption point in the animation, same window size. That reproduction step is manual, and it's the reason I stopped filing my own visual bugs properly: the before was cheap, the after was a chore, so I'd eyeball it and move on.
Does a .notate session carry enough to make the re-capture repeatable — app, window geometry, frame timestamp — so a second capture is comparable to the first frame by frame? A diffable before/after pair is what would turn this from a feedback tool into a regression check, and the typed manifest you described to Anand sounds like it's already most of the way there.
Notate
@narek_keshishyan You've reframed the product and I spent the afternoon designing against it, so here's the honest version. Today's archive carries part of what you'd need: canvas size, every frame's timestamp, duplicate markers, normalized annotations — so two same-rate recordings are already alignable in time. What it doesn't yet pin is the environment (app, window geometry, display scale, capture rate). Those are cheap, additive fields, and they're now first on the roadmap this question produced.
Where I landed after sitting with it: there are three primitives. The trace — each session becomes one truthful timeline: environment plus stimulus (cursor path, clicks, scroll — recorded as data alongside the frames, never keystroke contents), which agents can query ("where was the cursor at this frame?") and humans can watch as a cursor overlay in playback. The diff — two traces aligned on motion start rather than record-press (nobody triggers an animation at the same instant twice; the first changed frame is the honest zero), compared with the same perceptual-signature math the dedupe engine already runs. And a CLI, so the agent that made the fix can record and diff its own verification pass instead of only reading exports.
One limit I'm keeping on purpose: no replay guarantees. Your fix invalidates the recording by design — replaying old clicks against a moved button clicks the wrong thing — so Notate will never pretend to reproduce app state. It records what happened, verifies the second capture matches the first's geometry and rate, and tells you exactly which frames diverge. Getting the app back to the moment stays with you or your agent — but with the trace in hand, that's following instructions rather than remembering. And your bar is the one I'm building to: not CI-grade, just decisively cheaper than eyeballing.
Freezing transient UI states is the part that has always been missing. Regular screenshots lose hover states and animation frames at exactly the moment you need to point at them. The agent-readiness angle is the interesting differentiator here. How does Notate structure annotation metadata for agents? Is there a typed schema alongside the visual, or does the agent infer context from comments and pin positions?
Notate
@anand_thakkar1 Both, roughly — with the typed half about to get more visible. Today the export is a markdown manifest (frontmatter with the app and window, numbered comments, per-frame comments and timestamps for recordings) paired with the images, where the pins and arrows are drawn in with their numbers — so a multimodal agent grounds each comment by reading the number off the pixels rather than inferring position.
Underneath, every session is also a .notate archive with a fully typed manifest: shape kinds and normalized coordinates for every annotation. Surfacing that schema in the agent-facing export (coordinates alongside each numbered comment) is next on my list — it makes the export just as useful to agents without vision, and lets multimodal ones verify instead of guess.
Notate
@anand_thakkar1 Update: shipped in v0.1.10. There's now an Output Detail setting on the export — Standard adds a typed block to the frontmatter with each annotation's kind and normalized coordinates (a pin's point, an arrow's tip), and Detailed adds endpoints and bounding boxes. Coordinates are normalized to the exported image, so they stay correct even when the smart crop trims to a window, and recording manifests tag every entry with its frame.
"For humans and their agents" is the phrase doing the most work here. A human annotation is fundamentally positional — this thing, right here — and an agent has no pixels to point at, so the same note has to arrive as something structural instead.
What does the agent actually receive? Just the note text, or the note plus enough surrounding context to know what it was attached to? I'd guess "make this button smaller" is close to useless without the second part, and that's the piece that seems genuinely hard to get right.
Notate
@ark_y_k Today the note arrives with three layers. The images carry the pointer itself — pins and arrows drawn in and numbered, so a multimodal agent grounds "make this button smaller" the way a human does: by looking at what pin 2 sits on. As of v0.1.10, an Output Detail setting adds a typed layer to the frontmatter — each note's kind and normalized coordinates, arrow tips, bounding boxes — alongside the app and window it already names, with the export cropped to the focal window.
The layer you're describing — resolving the note to a UI element as structured data — is deliberately not Notate's job. Whatever consumes the export already holds better context than Notate could bake in: a coding agent has the source and finds the component itself, an automation agent has the live accessibility tree at action time, a human has the picture. Notate's job is to say where and what you meant, faithfully — your agent already knows, or can find, everything else. That's also what keeps the format small and stable: it has no opinions about what the pixels mean.
@victor_aremu The scope line is the interesting decision here, and I think it's the right one. A coding agent has the source, an automation agent has the live accessibility tree, a human has the picture — every consumer already holds better context than Notate could bake in, so resolving to a component would mean guessing on behalf of someone who doesn't need you to guess. Staying geometric is what keeps the format small enough to survive.
Which makes the reference frame the thing I'd want pinned down. Normalized coordinates and bounding boxes are only faithful relative to something, and the export is cropped to the focal window — so are those normalized against the crop, the full window, or the screen? A consumer re-resolving the note has to reconstruct the same frame to land on the right pixels, and that's the kind of detail that's invisible until two tools disagree about it.
The other gap I keep looking at is time. The accessibility tree an automation agent reads at action time isn't the one that existed when the note was made. Does the frontmatter carry anything about when it was captured — build, version, timestamp — so a consumer can at least tell the note is older than the thing it's pointing at? Not asking you to interpret it, just to date it.
Notate
@ark_y_k Normalized to the image you're holding — and the export says so itself: the frontmatter carries coordinates: normalized to the image, top-left origin, and the coordinates are computed against the same rect the crop produced. The picture and its numbers travel as one object; multiply by the image's pixel size and you land. There's no window or screen frame to reconstruct, which is the point — if a consumer has the pixels, it has the frame.
On time: the session archive already dates everything — a wall-clock capture time in the manifest, per-frame times as offsets — but you're right that the markdown export doesn't carry it, and it should. captured is going into the frontmatter as of your comment. Build and version of the app being captured is out of reach honestly — Notate sees pixels, not process internals — so dating the note without interpreting it is exactly the scope I can do faithfully.
@victor_aremu Self-describing is the answer that actually closes it. Two consumers can't quietly disagree about the frame if the file states which frame it used — the ambiguity I was worried about only exists when the convention lives in documentation instead of in the artifact.
That's my question fully answered, and the scope line makes more sense to me now than it did at the start. Notate records where and what you meant, faithfully, and refuses to guess at meaning — which is exactly why the format can stay small and stable. Most tools in this space would have been tempted to resolve to a component and inherit every redesign as a bug.
Thanks for going into this much depth. I'll be watching where it goes.
the honesty in this thread is what's selling me on it tbh. one thing I didn't see covered - since it's a full screen recording tool, what happens when a password field or some other sensitive text is visible in a frame that gets captured. is there any blur/redact step before the .notate file gets handed off to a teammate or an agent, or is it on the user to notice and re-record
Notate
@galdayan there's no redact step yet. What protects you today is structural — you annotate on the capture itself, so every pixel that will ship is in front of you before you deliver, and image exports crop to the window you annotated instead of your whole desktop. Keystrokes are never recorded, password fields are dots at the OS level, and a session is a local file that only goes where you send it. The gap is a handed-off session file, which carries the full frames. Two things are on the roadmap as of your comment: a redact shape that blacks out a region for good, and an automatic PII detector, on by default, that flags sensitive regions before you hand the file off.
@victor_aremu that's a genuinely solid answer, structural protection first and the redact shape/PII detector as a real roadmap item rather than a vague someday. the "dots at OS level" detail is the part that actually matters to me - a lot of tools claim they don't record passwords but still capture the frame around the field, so knowing it's blocked at capture time not just blurred after the fact is the difference between a real guarantee and a UX nicety. will keep an eye on the PII detector, that's the one that turns "you have to remember to check" into "the tool checks for you," which is the harder and more valuable of the two
Freezing hover states and pinning feedback to the exact frame solves a real gap in UI review. Can a teammate reopen a shared session and add or resolve annotations without needing the original capture environment?
Notate
@adityaharish2002 Yes! Just share the .notate file — it carries every frame and comment, and double-clicking it opens the full editor on their Mac. Nothing is needed from the original capture environment, not even the Screen Recording permission (that's only for capturing). Your teammate can add, edit, or delete annotations and send the file back — full sessions survive the round trip. There's no resolve workflow yet (today you resolve by editing or deleting a pin) — proper collaboration features are what I'm building next.
Shared annotations for humans and agents could provide valuable execution context. How does Notate keep annotations attached when the underlying webpage, design, or code changes substantially?
Notate
@russlan_ramdowar Deliberately, it doesn't — and that's the design. A Notate annotation is attached to a captured moment, its own pixels, not to the living page or codebase. So it can never drift or detach: the note stays true about what it pointed at forever, and it's dated, so anything consuming it can tell it predates what's on screen today. When the thing changes substantially, the move isn't migrating old notes — it's re-capturing and comparing: notate diff lines the old session up against a new one and names exactly where they diverge. Keeping a note pinned through a redesign would mean the capture tool guessing what "the same button" means after the change — the agent with the source, or the human with the picture, is better placed to make that call than I am.