When right-clicking a tree widget row (the widget’s root object or any nested row) the context menu should include a “Create object inside” (create child/nested object) action. Today the context menu offers navigation and widget management (Open in New Tab, Favorite, Pin/Unpin, etc.) but no way to add content, leaving the hover “+” as the only way to add a nested item (which only currently is allowed on the root/parent widget object).
HOW COULD IT BE DONE?
Add a menu entry that performs the same action as the root row’s “+” button: create a new object and append a link block to the right-clicked object’s body, so it appears as that row’s child in the tree. Use the default object type, or expose a submenu listing types (matching the sidebar’s “+” arrow behavior). The entry should appear only on rows whose object layout supports body content; file-layout rows (images, PDFs, etc.) omit it, since there’s no body to link into.
REAL WORLD USE CASES
Right-click → create-inside is muscle memory from every hierarchical tool: Confluence (“Create child page”), Notion (“Add a page inside”), file managers (“New folder”), IDEs (“New file”). Users building page hierarchies reflexively right-click the parent node in the sidebar. That natural reflex currently hits a wall and adding a child requires opening the object and using /link from the editor.
A context menu entry makes hierarchy building possible entirely from the sidebar, is more discoverable than a hover-only icon, and works better with touchpads/long-press (mobile) where hover affordances are unreliable.
RECOMMENDED ALTERNATIVES
Hover “+” button on every row (submitted as a separate FR) (complementary, not competing with this request): the button serves rapid repeated creation, the menu entry serves discoverability and contexts where hover is awkward. Most reference implementations (Notion, file managers) provide both.
Current workflow: open object → /link → create. Functional but slow, and breaks the sidebar-driven flow.
ADDITIONAL CONTEXT
Companion to my FR for a “+” create-child button on nested tree rows:
Both follow the same rule — create actions available wherever a row represents a body-bearing object — and together bring tree widgets to parity with the page-tree interactions of Confluence and Notion that incoming migrants expect.
I’m a little bit on the fence here. To be fair, it’s a spectrum of how ‘familiar’ do we make Anytype to users who are used to tree hierarchies. And how much do we guide them towards object-based workflows.
My worry of simulating too much tree-hierarchy structures is that users will expect the system behaves in that way, which it does not.
That’s a fair concern, and I think it actually narrows what I’m asking for rather than arguing against it.
I’m not necessarily suggesting for Anytype to become or even emulate a tree-hierarchy system. The action I’m describing already exists and already implements the object model. /link in an editor creates an object and links it. That’s a link-graph operation, not a folder operation. A root widget has a + hover option which does the same thing.
“Child” objects can be linked from multiple nodes and live independently in their type. None of that changes. All this request does is expose that same link-creation action from a second entry point (the widget context menu) instead of only from inside the editor.
So the mental model I’d want it to reinforce isn’t “this row contains that row” but rather “this object links to that object.” Perhaps to make sure that idea/model doesn’t get lost in translation, menu text can be Link new object rather than Create child. This could be a lever that reinforces that mental model of object links.
Also, right now the hover “+” exists on the root row and does exactly this already. So users already encounter the create-and-link action in widgets, just via a hover-only interaction with no menu equivalent. Making the action uniform (every row that has content/a body allowing context menu + hover) reads as “links work the same everywhere”.
I understand the logic of your proposal, the issue more lies with user habits. That user pattern (+ symbol in a sidebar) is typically used to ‘adding something to something’ with some level of inherent relationship. This makes sense for Types because it is a real ‘container-like’ relationship. When you click + next to the Task Type, it’s clear you’re creating a new Task object.
This gets more murky when you start doing it all over the place. For somebody who understands the object-based model, it’s not an issue. But for somebody who doesn’t (virtually all new users), they will get caught with a surprise later.
To be fair, we haven’t been super consistent with it either. But I don’t think the answer is necessarily is to just lean super heavily into a user pattern that simulates an experience that is not part of the system. We’d need to think more on this.
Ah, I understand where you are coming from! Since the issue is about user habits, then perhaps anytype can instead allow objects to “opt-in” to the kind of “nested linking” I’m proposing at the type level.
The way I imagine this is that by default, nothing changes from how anytype widgets currently function. By default, only ‘Type’ widgets show the + symbol. A user can, however, modify/create a new type wherein the configuration options expose a new configuration parameter. This could be something like a toggle/checkbox option named Allow creating linked objects from widget rows.
In your example, for instance, this can be incredibly useful for Tasks because then you can allow users to create subtasks inline right in the widget if the Tasks type allows you to create linked objects.
I think in this way, anytype can continue intrinsically avoid suggesting hirrarchy everywhere. At the same time, it gives more affordance to users who do understand what they’re choosing.
Understood. It’s a possibility but I can’t say we feel confident about this one. We typically try to avoid having too many user options for different behaviours. Thanks for your suggestion nonetheless, we will consider.