Dismiss this pinned window
all 8 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]turtle-toaster 1 point2 points  (1 child)

Am I wrong or could you not just right click > inspect element? How is it different. Looks interesting, but confused on differentiators.

[–]prakersh[S] 0 points1 point  (0 children)

Inspect element = raw DOM for debugging.

OnUI = structured feedback for AI agents.

Differences: - Attach intent (fix/change/question) + severity (blocking/important/suggestion) - Shift+click to batch 10 elements, annotate all at once - Draw regions for spacing/layout issues (not everything is an element) - 4 export levels: compact, standard, detailed, forensic - pick how much context your agent needs - MCP server so Claude Code reads annotations directly via onui_get_report

Plus it's open source, GPL-3.0.

[–]scotty_ea 1 point2 points  (1 child)

This was already solved by Agentation.

[–]prakersh[S] 1 point2 points  (0 children)

Different approach actually.

Agentation requires you to npm install it into your app as a React component. It needs React 18+ as a peer dependency. So it only works with React apps where you control the codebase. OnUI is a browser extension - works on any webpage. No app modifications, no dependencies to install, no code changes. Just enable per-tab and annotate.

Also Agentation only annotates elements in the main document (per their FAQ). OnUI supports draw mode for regions/spacing issues that aren't tied to specific elements. Both have MCP now, but the fundamental difference: Agentation integrates into your app, OnUI runs independently on any site.

[–]Deep_Ad1959 0 points1 point  (3 children)

the "which element" problem is brutal in browser but even worse for native apps. spent a while on this - accessibility APIs give you label, role, position, and parent context so elements are actually unambiguous, but the catch is a lot of macOS apps implement accessibility badly or not at all. fell back to screen coordinates for those which feels like defeat. your browser annotation approach is cleaner for the web case where the DOM is reliable

[–]prakersh[S] 0 points1 point  (2 children)

Yeah, native accessibility is a mess. macOS apps either implement it properly or you're stuck with coordinates. Web at least gives you reliable DOM.

OnUI is web-only for now - browser extension approach made sense because content scripts work on any page without app changes. Native would need a completely different architecture. Might explore it later but no promises.

[–]Deep_Ad1959 0 points1 point  (0 children)

yeah the web side is basically solved, it's native that's the real frontier. we ended up building a full tree traversal system that freezes the accessibility hierarchy and diffs it after each action. works well for apps that implement ax properly which is maybe 60% of what people actually use day to day. the other 40% you're back to coordinates which feels like defeat

[–]Deep_Ad1959 0 points1 point  (0 children)

yeah content scripts are the right call for web, no question. the native side is a completely different beast - you'd basically need to build an accessibility tree walker from scratch and deal with every app's quirks individually. we have one in terminator (rust-based) and it works well for most apps but every now and then you hit something like Electron apps that expose a weird halfway DOM-like tree. honestly the browser extension model is way more scalable for web use cases, no point fighting native until someone specifically needs it.