Tag nodes in Collection

[houshasen]

Feature Request

Allows users to optionally display tag entries as nodes within the collection.

Background

Collections in AFFiNE function essentially as powerful queries. Users can add individual documents and multiple rules, making collections adaptable to various needs. Some may use them as folders, while others may use them as Maps of Content (MOC) or object types.

Regardless of the use case, as the number of entries in a collection grows, it becomes necessary to create some type of organization within the collection. Currently, this can be achieved by creating a real MOC document. However, we already use tags to group and organize related content, which is often part of a large collection.

General workflow

When a user sets tags as one of the rule entries and enables the option "display tag" in a collection, the first level of the collection shows the tag with a "tag icon" and the tag name. The user can then expand the tag to view the entries that meet the criteria.

For example, if the rule is set to "Tags contains one of 'PKM, AFFiNE'," it creates two nodes, PKM and AFFiNE, at the top level. Each node can be expanded to display the search results corresponding to each tag.

Design consideration points

⬜ Enable "display tag" option

One option could be to include a simple checkbox in the collection edit window, next to the tag rule, allowing users to easily turn it on or off.
Another option might be to place it under the left navigation collection menu "...", with an option labeled "group tag rule"

⬜ Duplicate display
Some items may fall under multiple tags. Currently, I believe the collection properly handles this by not displaying duplicates. When the tag node is enabled, I think it would be most intuitive to show any document that has the tag under the node, even if it results in potential duplicates.

⬜ 🔥Nested tag
The true potential of this implementation will be realized when nested tags become available.

Let's say we have tags #PKM/AFFiNE, #PKM/Notion, and #PKM/Book.

If the rule uses the PKM tag without child tag, it should display the PKM tag node at top under the collection, with AFFiNE, Notion and Book tag nodes nested underneath.

Conversely, if I explicitly choose #PKM/AFFiNE and #PKM/Notion, these two tags will appear at the top node but not Book node or PKM node.

⬜ Consolidating more than tag rules
Currently, AFFiNE allows the creation of multiple tag-based filter rules, which appear to use "AND" logic between the rules. If one rule entry specifies "PKM" and another specifies "Food," without consolidation, this would result in two empty tag nodes, which is unintuitive to user when looking at nodes. Therefore, the rules should be combined into a single rule that requires the tags to "contain all PKM and Food," and then processed accordingly, which is discussed below.

⬜ ❓Contains all, Not filters
One design challenge I foresee is handling the "contain all" and "not" type filters. While these filters do not assist in separating "tags" into multiple nodes, AFFiNE's capability of adding individual document entries to the collection still makes this a useful grouping method. Therefore, I believe we can treat these filters similarly to the "contains one of" filter but always display just a single "tag" node.

A special modification would be necessary for the actual tag text. For the "contain all" filter, the tags could be too long to display in the left menu, and for the "not" filter, it might not make sense to show tag names. Thus, I propose showing these as a "tag rule" node. Upon hovering over the node, the actual rule of the tag filter would be displayed.

⬜ ❓To all rules
One interesting consideration is to apply these grouping under collection to any rule and not just tags. This may become particularly helpful if AFFiNE ends up supporting other commonly grouped rule entities such as properties, maybe object type etc.

Comparison to other similar concepts

Nested collection

While nested collections sound interesting, they can become confusing rather quickly. Essentially, it involves creating a query and then adding it to another set of queries.

Folder within collection

I believe that folders within collections have their own utility; however, this approach highlights the fundamental limitation of a folder structure compared to a network structure.

For instance, when a new atomic note is created, the user sets a tag to categorize it. Ideally, this tag places the note into the appropriate collection. However, if the note needs to be placed in a specific folder within that collection, the user must manually drag and drop it into the desired folder. This process becomes even more cumbersome if the user wants to place the note into multiple folders. What should they do in such cases?

[HeJiachen-PM]

Interesting suggestion!
Sub-structure under a collection has been considered. However, we are thinking about making the collections/pages nest-able or give better options to classify things in the collection -- a great path is to deal with tags first! This is essentially a part of "how to make the collection and databases more similar in terms of views and filters and eventually allow databases to open collections".

We will support a way of design to allow better organization under a collection. It's a matter of how are going to make better 'group by' or 'sort by' features/views to support tags and even more properties.

We also discussed nest tags internally. However, one questions is, for nested tags, do you want to have "unique paths" for tags, like "PKMs/Notion" and "Workspace/Notion" will be actually two tags, or do you want to have tags but not explicitly belong to a path, where Notion have 2 parents PKMs and Workspace?

[houshasen]

Thank you for sharing the current design concept and direction. I genuinely enjoy hearing about these developments; it feels like a gaming spoiler to me. The idea of making databases and collections similar sounds perfect. With proper implementation, when one evolves, the other can potentially benefit from it.

Although I am not an expert on nested tags, I believe we need to use unique path. As I think this is how nested tag can be by distinguishing from double tags i.e. #PKM/Notion vs. #PKM #Notion. If we parse them at the time of storing tag, rather than reading them, I believe the nested tag will lose its context and structural info and essentially becomes double or multiple separate tags.

To eliminate the confusion, I have updated the nested tag request with a bit more detail. So when other community member sees it, hopefully they can see where I am coming from.

I hope these explanation makes sense. Thank you for considering.