Wiki - nested view
Would like to see the nested view for Wiki pages, the way Widgets in Anytype had options to view the hierarchy
5 Comments
Sign in to comment
Same here.
I created a page inside a folder.
Then I created another page within that page.
I would have liked to see it appear below it in the miniapp's tree view, but it appeared separately (and not even in the folder where it was indirectly created).
Even though I understand that we need to handle some slightly complicated cases.
As for the loop, limiting the display to the immediate environment prevents any loops.
For example, the wiki tree structure could display 5 levels of nesting starting from the root? There’s no risk of a loop.
It’s still possible to see the same element multiple times, but that’s consistent (otherwise, we’d have to detect when an element is already displayed in the tree to ignore it afterward… doable, I think, but it wouldn’t fully reflect reality).
Otherwise, rather than a specific subpage type, why not add a configurable option for links (links or pages created within a page)? A toggle for “display as a child / display in the tree.”
·10 days ago(edited)Yeah, there are a lot of potential solutions for this. Those are some good suggestions, thank you!
"why not add a configurable option for links (links or pages created within a page)? A toggle for “display as a child / display in the tree.” — the other option I thought of is: if you create a /page while in the Wiki, it automatically populates it in the Wiki. The issue of course, is if you're viewing that page from a different mini app, then create a /page or /link and whether or not that should also be reflected in the Wiki.
Possibly the simple solution is the best, just display all forward links inside objects in the wiki in a nested dropdown by default. But I'm concerned this creates other weird behaviours in other edge cases.
·11 days agoThis is a little tricky, but I will try to explain.
- Anytwo and Anytype are both graph systems—there is no hierarchy for objects. There is technically no such thing as 'nested items'.
- In Anytype, when you see a dropdown of 'nested items', this is not actually a parent > child relationship like in true folders/files in a desktop (which nesting implies). It is actually just a list of all the forward links that exist on an object. That is, there is no real hierarchy. The dropdown simulates hierarchy when in fact none exists. The problem is that you can have a cycle of object links that point to each other in a never ending loop. Object A > Object B > Object C > Object A > and so on. This would be a 'nested dropdown' that cycles forever.
- In an app like Notion, when you create a page in another page, this automatically generates a nested page in the object because Notion is not a graph-based system. It's a true hierarchical system, which is why if you delete a page, it will delete all of the 'children' pages stored within it. That doesn't happen in Anytwo/Anytype.
- The problem is that many users still wanted some kind of hierarchy view within the knowledge graph. To solve this, we devised Mini-app: Wiki.
- The trade off is that the nesting/hierarchy that exists in the Wiki menu must be manually generated. You can use the + button to add a new page, or you can add an existing object that you created elsewhere.
What I will say is that I've been thinking a lot about how we could take the Wiki one step further, which would enable you to create an object (such as /page) and then have it automatically populate in the Wiki sidebar. The thought here is to create a special block type called /subpage that would automatically create the 'nesting' in the wiki. The big issue with this is that it's a behaviour that would only work inside the Wiki and nowhere else—which could create even more confusion.
I hope that makes sense.
I'd assume that, to simulate a hierarchy in a purely graph-based system, a "Parent" object "A" acts a bit like an implicit "Collection" in the sense that I can add or drag&drop another object "B" to the "Parent" object "A" (e.g. in the 'hierarchy' sidebar), and that would turn object "B" into a "Child" object of Parent "B".
Thus, the relation "B is child of A" would establish a hierarchical link.
Of course, as in Anytype today, the user could conceptually create a "Hierarchy" with loops, like "A->B->A" or maybe even "A->B->B" — but if they want so, I can't see a problem with that in a purely graph-based system.
What am I missing that would make this a challenge in Anytwo?
The problem is that it's too simple when only thinking about 3 objects—the area for confusion looks so insignificant it doesn't matter. But imagine you have an Project Object that links to hundreds of different objects; meetings, tasks, files, documentation, etc. Then imagine that each of those objects have many forward links that point to even more objects. If every forward link in an object is to show up in the Wiki automatically, you can see how it can create a huge tangled mess because they are inherently not hierarchal—there is no parent > child.
Also, people who work in graph structures love to create as many links as possible. But people who work in hierarchies don't. When you merge the two automatically, it's not just about object loops, it's just about organisational conflicts.
Thus, the current solution where we limit Wiki to explicit map creation, rather than auto generated, is a way to tame that mess. Indeed it puts more effort on the user side, but it's the trade off for spaces being object-based, not hierarchical.
Not saying this is the end/best solution, but it's where our thinking has landed today.