Have something to say?

Tell us how we could make the product more useful to you.

copy the original image to the system clipboard.

I would really appreciate a feature that allows users to copy the original image to the system clipboard. Currently, when an image is copied from the canvas, visualOS appears to place internal data on the clipboard for duplicating the element within visualOS. This works well for working inside visualOS, but it limits how easily images can be used with other applications. If there were a separate “Copy Original Image” option that copied the actual original image to the system clipboard—at its original resolution and quality—it would greatly expand what visualOS can be used for. For example, I could find an image visually on the canvas, copy it, and immediately paste it into Photoshop, Procreate, or another application. It would also work naturally with Apple’s Universal Clipboard, allowing an image copied on the Mac to be pasted directly into an app on the iPad. This feature would be especially valuable to me because it would turn visualOS into more than just an infinite canvas. It could become a kind of visual file-storage canvas: a place where I can organize and store large numbers of images spatially, then retrieve the original image whenever I need it. Instead of searching through folders and filenames, the workflow could simply be: Find visually on the canvas → select → copy original image → paste into another app. That would connect visual organization and actual production work into one seamless workflow. I think this relatively simple capability could significantly expand the usefulness of visualOS, turning it from an idea-organizing canvas into a powerful workspace for storing, organizing, and reusing visual assets. For my workflow, this would add tremendous long-term value to the application. Thabk you.

영철김 10 days ago

2

Planned

A Plugin Marketplace and Labs Section

I think the most useful addition would be a plugin system, maybe with a Labs section where people can easily browse, install, and enable community-made plugins. That would let users add features without making the core app feel bloated, while also showing you which ideas people actually want. If plugins are file-based, they should be fairly easy for users to install themselves, and the most popular, well-tested ones could eventually become official features. Some examples could be layers, grids and measurements, smarter diagrams, reusable objects, presentation mode, better drawing tools, tables, richer export options, widgets, Kanban boards, timelines, and 3D viewers, Scenes / saved canvas views, just to name a few.

mackm 10 days ago

4

UX Basics: Markdown filename vs H1

Right now markdown docs appear to save in the filesystem adding the doc name as an h1 at the top formatted as: “# My Heading“ However, the filename may not be what you want as an H1. This is why a famous editor Obsidian has settings for this: If I were you I would avoid all this confusion and never put the filename inside the text itself. It’s a typical issue in all markdown editors which is handled differently by each app. The fact is a filename is not the same as content and sometime you dont want the filename to be the same as your H1. Examples: 1) Sort order. You may deliberately prefix filenames to enforce a kind of sequence, without making that prefix part of the displayed title. People do this in markdown apps like Obsidian or Bear quite frequently because they don’t have manual sorting like Ulysses. 01-accessibility-audit-process.md Accessibility Audit Process 2) A filename might be a short internal label while the H1 is the clear public-facing title. a11y-ops.md Operating an Accessibility Practice as an Independent Consultant 3) You might refine the document’s title multiple times while wanting inbound links, URLs, sync references, or automation paths to remain stable. consulting-offer.md Accessibility Consulting: Initial Service Menu which may change to Accessibility Consulting Packages for Small Product Teams 4) File systems and publishing tools impose rules that a human title should not have to follow. This is a major gripe of mine. The H1 can retain the human-facing punctuation and typography a reader expects. wcag-2-2-criterion-1-4-3.md WCAG 2.2, Success Criterion 1.4.3: Contrast (Minimum) 5) A unique filename can distinguish documents that need the same—or nearly the same—visible H1. 2026-08-26-client-a-discovery.md Discovery Workshop 2026-08-27-client-b-discovery.md Discovery Workshop

AD 18 days ago

Rejected

UX Polish: Markdown docs are opaque

I don’t quite understand why markdown docs can’t be a resizable card just like a text element on the board. Obsidian, Heptabase and some others provide a fold/unfold icon so people can choose if they want the text visible or not for each document. I would rather write markdown on the board itself like a text element than be taken out of context unless I specifically want to open the document in a fullscreen view and I do that through a command. Taking people out of context should only be done with good reason and should generally not be the default. It would be helpful to have some options in this regard rather than assume that we all want the text of our markdown docs hidden all the time.

AD 18 days ago

1