Jorge I am certainly making some assumptions based on the fact that design/development is not completed.
Perhaps “must” was too strong, but in that example of club member names I would either have to leave them at level 1 OR put them in a hierarchy. Leaving them at level 1 would be unwieldy, so I would consider it a must to use the hierarchy if we lost the document distinction entirely. One of my assumptions is that if I personally wish to distinguish clubname.clubmember.personname in categories because it would be unwieldy for ME to to have them at the first level… then that will impose my hierarchy on any other users of that document.
The answer to that question might be linked to the following - it has to be considered if the tag shows in its entirety at the document level in the text - DOES it always show #france.paris ?
- If yes, that’s going to blow out the length of my task and project names. Yuck - that leads to way more wrapping and less readable lists.
- If no, then how do I make sure that the tags for #france.paris and #idaho.paris EXIST?
Currently, the app creates the list of tags within the document automatically. For that to happen, I think the document would always have to show the full tag name. The only alternative I could see was that we had to now manage tags in some separate tag management list. If it requires such a management screen, then for your example we would have to create four #paris tags - one under each of france, texas, idaho and illinois. that’s 8 tags instead of 5 and that issue would be exponential.
But I agree with you (and I think all others in this conversation do too) that we should be able to associate tags to a given node level if we want to make sure that they are local to a particular node (document).
I’m really glad to hear this and I hope it’s the ultimate solution. I did my best to pick up where things were at from this long conversation and was just left with some pretty big alarm bells I felt I had to raise.
