Nested Tags / Hierarchy for tags

After 4 years I just noticed that this got 1649 upvotes lol.
At this point i'm using Anytype with 0 issues :/

What does "open" status mean? Hopefully you're finally working on it, after 4 years!

The status of this feature request has changed from "planned" to "open".
What is that supposed to mean? 🤔

Is it actually being un-planned?!

Just build it already!
1600 people want to use it.

Some people don't want to use it, but they can just... not use it.
Even if it's part of Capacities and works perfectly for a lot of other folks. 🙏

If people like their tags and collections - that is wonderful. I love Capacities enough to have tried to adapt to this 'different' way of organizing myself. I get that some people may have 'hierarchy-trauma' - fine. Don't use hierarchy-reminiscent features if they are introduced. To me, not having these options is a burden to how my brain functions - so I would welcome them. (As in: pretty, pretty PLEASE). I think this can be done without corrupting the spirit of Capacities.

Capacities is flexible, with many ways to connect objects. Nested/hierarchical tags seem like they would suit the spirit of the app: another way to relate objects, additive flexibility for those who want to use the feature, and no downside for those who prefer to keep a flat single-level tag list.

The Things app from Cultured Code makes filtering by nested tags remarkably intuitive, if you are looking for UX ideas.

A quick stream-of-consciousness summary of how tag filtering works in Things: When viewing a list, tags assigned to items in the list are shown as one-click filters at the top of the view. Tags with nested/child tags present are shown with an ellipsis; clicking that tag applies its filter, and also expands to offer a list of its child tags to further refine the filter if needed. Clicking a selected tag toggles its filter off. An (All) option is always present at the start of the list of tags, which effectively clears any current tag filter.

Edit: Things documentation reference for tags - https://culturedcode.com/things/support/articles/2803581/#ayskc

Any rate, I'm sure your implementation will be thoughtful, considered, and fitting for the Capacities design, as you consistently achieve with your feature development. Looking forward to seeing how it goes. Thanks for your continued improvements of the app!

I think this is a great idea. Glad it is planned. The point is we don't have to use them but for something I am doing right now, that would have been perfect. Collections isn't working for me and sometimes you need a tag and for different types it makes it tidier.

I think this would undermine what makes Capacities great and unique: A strong and consistent positioning against any kind of hierarchical structure.

The moment we get nested tags, we will start having the same headache people usually have with folders.

I understand where the OP author comes from. I'm also used to nested tags and did try using them in Capacities initially. Such things serve us well in other tools like GMail. But in Capacities, we can do even better without such!

For the OP's example, I'd use a Recipe object type. The "breakfast" vs. "dinner" distinction could be a multi-select property on that type, e.g. Category = {Breakfast, Lunch, Dinner, Snack, Drink, Dessert, ...}.

This gives a plethora of benefits over nested recipe tags, e.g.:

• No accidental recipe tagging of objects which are not recipes (tags can be applied to any objects)
• No noise from "recipe related" tagging, e.g. a "get groceries" task may seem related to a particular recipe I want to try. And so is the friend who recommended me that recipe. But when I want to try that recipe, I don't want to see a big list with tasks and friends. I only want to see a list of recipes.
• Powerful modeling which would help me decide what to buy when I'm in the grocery store or what to make when I'm in the kitchen, e.g. a separate Ingredient object type, with a multi-select relation from Recipe to Ingredient. This would allow Capacities queries like "I have these ingredients, which recipes could I make right now?" or "I want to make these recipes over the next week; which ingredients do I need?".
• To distinguish between ingredients I have and the ones I should buy, we could add a multi-select Stock = {Empty, Low, Plenty} property to the Ingredient object.
• With the above, I could plan my cooking week by listing Recipe objects on corresponding Dailye Note pages for the upcoming week.
• Having that, I can create a query like "Shopping List", showing all Ingredient objects linked to Recipe objects which are linked to Daily Note objects for the upcoming week, where the Ingredient.Stock property is not Plenty.
• Bonus: With the above, I can also check which recipes I haven't made for a while.
• Extension possibilities are endless: Add an Allergens property to Ingredients and an Allergies property to Person, and suddenly I can filter my recipes for things which I can serve to particular guests ...

I don't think this is a good idea. If what you want is #recipe/breakfast, why not use collections?

I’m not convinced that introducing nested tags (e.g., #recipe/breakfast) is the right direction for Capacities.

From my understanding, Capacities is intentionally built around object types and properties to model structured relationships. A hierarchy like this seems to duplicate exactly that purpose, just in a less structured and more error-prone way.

Yes please! Especially needed b/c Capacities requires that tags are used to simulate a hierarchical folder structure. This IS useful to organize content of various types that relates to specific topics or more general areas of work).

You have my support mate 👍🏻👍🏻 100%

I wouldn't use nested tags for everything, but there are useful uses cases for this feature.

Like when I collect medical information, I want to organize them under a main tag like "Medical", then add sub-tags for medical specialties (such as urology, neurology, gastroenterology, etc.), and finally tag specific topics or diseases under each specialty.

No, having an Object or Property will not solve this, it would be a work around type of solving; because I have "Posts" object and "Questions" object and "Writing" object, if the information is from a post online or a general website it would be in Posts because it is not a good source, but useful to store and visit later or fact check it, if it is a question I had that would be in Questions, if it is a full research I will draft it in Writings and tag it with "Draft" until I finish writing it. And each one of those objects has different genres of information (not all medical of course, that was just an example but I have many other useful use cases), so creating a property for each object is not as general and clean as tags.

I personally started to forget my tags and create similar ones by mistake, having a general tag that I can always remember and go to is useful.

Nested collections would also be nice (while you're at it) and not very hard to do I suppose because of how collection works. For exemple collection 1/subcollection 1... if an item is in subcollection 1 It also appear in collection 1, but if an item is in collection 1 It does not appear in subcollection 1.

This would essentially be folders on steroids, and very very useful for many users in order to declutter certain collections, and organise some not that rare data. Music genre comes to mind for exemple. We can already do it (technically), and they are other way to achieve the same result with labels and such. But in some areas I think that nested tags and nested collections would be a more elegant a less complicated solution for many users.

Tagstudio is a very interesting open source app that have a very robust tagging system, and his creator is pretty deep into note taking (obsidian user tho). I'm sure he would be glad to help, since he is trying to developpe a universal tagging format from what I understood.

I would also welcome if the nested tag inherited it's paretnt's colour at the time of creation - I like my colrelated tags (e. g. all topic tags, all source type tags etc.) share the same colour and this would avoid the need for setting the proper colour after creating a new tag manually.

For my knowledge base, I basically need tags for two categories: a main category and a subcategory, whereby each tag in a main category would be assigned to specific tags in a specific subcategory.

Currently, I have created a custom object type called “Article” with two custom properties of the type “Label” (one for the main category and one for the subcategory).

Now when I create a new “Article” object, I first select a main category tag.

But when I select a suitable subcategory tag, I currently see all existing subcategory tags, even though only a few would be relevant to the selected main category tag.

As the number of subcategories grows, the list of subcategory tags becomes quite confusing.

What I would therefore like to see is a kind of “conditional tagging,” i.e., the option to set up a dependency between the display of the available subcategories and the previously selected main category, so that the selection of a tag of the main category determines the subcategories tags available for selection.

I don't know if and how this problem will be solved with the introduction of nested tags in the UI, but I hope so.

I found a workflow that works great without the need for nested tags folks. I know that this task is being planned, but should it?

I've used nested tags in the past in Evernote, and it caused me to organise my notes in a "folder" management sort of way, which Capacities wasn't designed for

Hopefully my post here helps solves your queries, and if not (this feature is coming anyway)

https://feedback.capacities.io/b/1v35e680/feature-ideas/nested-tags-hierarchy-for-tags#comment_vz5967pv

Please, as the unique way to not have tag objects too crowded!

Can I downvote this? This sounds like objects or properties being used as tags. I would create a recipe object, and have a 'meal' property.

can I downvote this? keep it simple!

yes yes