VISUAL PERSPECTIVE
Three situations come to my mind when thinking about sub-items:
- Sub-items in a grid (collection or set)
- Sub-items in the object’s contents
- Sub-items in the sidebar widget
Grid (1) visualization can be referenced from Notion. They did it pretty well and support a bunch of nice options.
(2) Sub-items in the object’s contents are not supported by Notion, and I miss it. It would be really useful. Some additional questions here:
2.a) Will AnyType also support nesting of sub-items in the object’s contents? (hierarchy of sub-items of sub-items) For example, if one links a task on a page and than adds another task as a sub-task of the first one, and then adds a third one as a sub-task of the second one. This would be cool. But adds complexity and ambiguity, because in some cases users might want to see only immediate children (sub-items) and in other cases the whole hierarchy: this option is similar to option in sidebar widgets when choosing list vs tree. It might be challenging to make a clean UI for this.
2.b) If user drag&drops sub-items in a grid or in a sidebar, this should change the order of sub-items in the object’s contents as well. Generally this is supported by Notion when user changes the order of pages in the Notion’s sidebar, their order also changes in the page contents. So Notion can be used as a reference here.
(3) Sidebar widget should display sub-items and allow changing their order and their hierarchy by drag & drop.
MODELLING PERSPECTIVE
Generally, I see two main approaches for modelling sub-items:
- Notion-like approach by using a dedicated relation for that (e.g. sub-items or parent — can be unidirectional for beginning until bidirectional relations are supported)
- The opposite approach of using object’s contents links for definition of sub-items.
I like the 2nd. From my experience Notion’s approach is inconvenient. But 2nd approach is not so easy.
If AT decides to go 1st approach — it would be straightforward as you could use Notion for reference. But this approach feels weird because naturally one would expect that objects from the object’s contents links are sub-items. Having two separate relations complicates user’s thinking.
For the 2nd approach, AnyType would need to redesign their object linking capabilities. Currently AnyType supports only one type of linking between objects. While Notion supports two types of linking: association and composition.
I will give examples. Let’s say we define a project consisting of a tree of tasks. We want to define this tree of tasks in the project’s description (contents of the AnyType page).
So we write down project description and put some tasks in it, which are considered tasks of this project. This is a composition (or can be also aggregation: I will explain the difference later). But at the same time often we would refer to some tasks (mention them) without defining them as project’s tasks. They can be like “see also” category or referring to some preceding projects and tasks. This is association. These tasks are associated with the project but do not belong to it! This is a very important distinction and Notion models this well:
- If user presses
/ — this creates a composition
- If user presses
@ — this creates an association (like shortcut), and it will have special icon (try doing this in Notion)
AnyType does not model this now. Both @ and / would always create link.
I think AnyType should redesign this and follow Notion’s approach. @ for light associations, and objects linked in such way should not be considered sub-items and included in hierarchies. / for compositions or aggregations, and objects linked in such way should be considered sub-items and included in hierarchies.
What is the difference between aggregation and composition? (simplified)
Composition means that when project is removed, all its tasks are removed as well. AT does not support this now.
Aggregation means that when project is removed, all its tasks are not removed. This is how AT works today. But aggregation still has a semantics that tasks belong to the project. The difference is whether the removal of parent removes its children or not. Like in real life removal of university department, does not remove its students.
I’m fine with both options. Although I like composition more for its cleanliness.
EDGE CASE
Imagine such hierarchy:
[+]- Project
|
[+]- Task 1
|
[+] Page
|
[+] Task 2
Is task 2 a sub-item of task 1?
From my perspective — no. Page is a sub-item of Task 1. And Task 2 is a sub-item of a page. But it is still a question how to render this in a grid of tasks? Will Task 2 come underneath of Task 1? A cool approach would be to output this whole hierarchy starting from Task 1 in a grid of tasks. And when user clicks Page under Task 1, there can be an empty row for it in the grid. However since even objects of different types can have same relations in AT, this makes hierarchical grids super powerful.
