User-Agent: Opera/9.01 (X11; Linux i686; U; en) Build Identifier: version 2 alpha 1 (20060724) Tags are commonly used to sort messages according to their content. For example, I might have "home", and "work" tags. I might also apply the "red project", "blue project", and "green project" tags to some work e-mail. If the various project tags could be designated children of the work tag, the following beneficial effect would come about: - The colour of the message as rendered would always be that of the most specific tag in a hierarchy - The need to manually apply the work tag as well as the project tag would be removed - The 'tags' list would be more meaningful (because it wouldn't be as cluttered) - Searching for the work tag would be guaranteed to find all messages tagged 'work' as well as those tagged with any descendant of 'work' - The tags paradigm would generally become more flexible and usable - No incompatibility with the 'flat' tags model would be introduced Reproducible: Always

I'm using tb2 beta 2 now and I already got over 50 tags. whenever I want to apply or remove tags from messages using the drop down menu I constantly have to scroll all the time to get to the right tag which starts to get annoying very soon. in combination with hierarchical tags a cascading menu would make sense, just like for example when moving messages which has a "move here" and below the subfolders are listed. you could name it "use this tag" and below list the subtags.

(In reply to comment #0) > Tags are commonly used to sort messages according to their content. For > example, I might have "home", and "work" tags. I might also apply the "red > project", "blue project", and "green project" tags to some work e-mail. > > If the various project tags could be designated children of the work tag, the > following beneficial effect would come about: > > - The colour of the message as rendered would always be that of the most > specific tag in a hierarchy This one I agree, while it conflicts with the today sys based on tag order > > - The need to manually apply the work tag as well as the project tag would be > removed That is not such a burden, I would prefer TB to consider the order in which you specify tags. And that to just be enough for hierarchy and color. [so that 1 msg is tagged work/than../john while other may be john/ personal etc] > > - The 'tags' list would be more meaningful (because it wouldn't be as > cluttered) Tag toolbar extension, very visual, allows grouping and search also.. > > - Searching for the work tag would be guaranteed to find all messages tagged > 'work' as well as those tagged with any descendant of 'work' Tag toolbar, grouping .. > > - The tags paradigm would generally become more flexible and usable > > - No incompatibility with the 'flat' tags model would be introduced But duplicate tags should not be possible, for compatibility, and also to avoid confusion. Which creates a problem. Is this rather a matter of views management? Cause the point would be that - tag toolbar solves some of the tag management/visualization issues - view/ tags /home and then selector is by tags or - search tag1 + tag2 should bring some similar structure Only that is still important the order of the tags in tag list Pov of colors and

> For example, I might have "home", and "work" tags. I might also > apply the "red project", "blue project" No, you might have a *folder* "home" and "work", and a subfolder "project A". Tags and folders have different purposes and uses. Tags are good for orthogonal classification like "important" and "todo". They are not suited for categorisation, that's what folders are good for.

I don't see this ever happening for tags. Perhaps for some other categorization tool. but as written, agree with comment 3. Bryan - extension fodder or wontfix? (same difference)

Folders and tags can be easily extended beyond their natural usage. Folders are great if the things you are storing can easily map into a strict hierarchy; something that information doesn't often lend to. I do think hierarchical tags can create a better system of information management, though they can also create the same problem of information no mapping correctly to the hierarchy. In the end much of this really has to do with the presentation / user interface which makes either of these systems efficient or difficult. We don't have time for tb3 to make a usable system of hierarchical tags so if it's ever done it will have to be pushed to an extension or a future release. In the meantime people might want to check out wikipedia's discussion on the use of subpages. If you're interested in information management wrt systems like categorization vs. hierarchy you'll want to read over the long debate they had. Start here: http://en.wikipedia.org/wiki/Wikipedia:Do_not_use_subpages

From previous comments, the general sentiment seems to be that this is addon fodder and in that sense, wontfix (and if that addon does something really cool & useful, we could consider taking it into core). Otherwise and for the meantime, I agree with Wayne's comment 4: > I don't see this ever happening for tags... ...in the foreseeable future. We'd also probably want to see more obviously beneficial tag stuff happen first. Feel free to reopen if you feel this was done in error.

I'd keep this open, though it may not happen very soon. E.g. gmail tags (labels) are always hierarchal. I don't agree with comment 3, and indeed i think comment 5 is saying don't use folders (subpages), use categories (tags!). Ideally you would only ever have tags, not folders at all (again, google realized this). But that's an historical limitation we have to live with.

(In reply to Magnus Melin from comment #7) > I'd keep this open, though it may not happen very soon. FTR: I'm fine with reopening this. I've tried to indicate in my comment 6 that I wontfixed this only for pragmatic reasons (like effort/time/priorities) rather than conceptual reasons. > E.g. gmail tags (labels) are always hierarchal. Thanks for adding that aspect in support of this bug. Perhaps we can even add some more detail to inspire this bug conceptionally. > I don't agree with comment 3, and indeed i think comment 5 is saying don't > use folders (subpages), use categories (tags!). Ideally you would only ever > have tags, not folders at all (again, google realized this). But that's an > historical limitation we have to live with. I'm not against folders as such, I'd still consider them intuitive UI depending on user's purposes. But I'm open to rethinking folders under the new paradigm of tags, which is clearly superior over the less flexible and less scalable paradigm of folders. So I don't agree with comment 3 either; in fact I think tags are an excellent means of categorisation, and that potential has been criminally neglected and clipped by the current historically limited design which is no longer feasible for the large amounts of diverse information we need to handle in our inboxes today. That's why I am advocating to unlock the full potential of tags along the lines of Bug 370076 - Create/apply tags for messages by typing with the keyboard / Port Firefox tagging UI to Thunderbird (implement new way of tagging which is more flexible and scalable; applying tags currently too complicated). From Magnus' comment 7, I get the feeling that Bug 370076 and this bug 348128 might actually be converging in their general intention of using tags for categorisation in much more versatile and scalable ways than now. I also feel that Bug 370076 might be a better starting point than this bug, but perhaps it's just two sides of the same coin.

(In reply to Bryan Clark [:clarkbw] from comment #5) > Folders and tags can be easily extended beyond their natural usage. > ... > In the meantime people might want to check out wikipedia's discussion on the > use of subpages. If you're interested in information management wrt systems > like categorization vs. hierarchy you'll want to read over the long debate > they had. Start here: > http://en.wikipedia.org/wiki/Wikipedia:Do_not_use_subpages That page is now redirecting to the general article on Subpages, which has a small but nifty paragraph on the issue at hand: (Source: http://en.wikipedia.org/wiki/Wikipedia:Subpages#History_of_subpages) > History of subpages > > Subpages were originally used on Wikipedia to differentiate between subjects > to create topical hierarchies of articles, but this proved unworkable because > articles tend to belong in more than one hierarchy. The present system of > disambiguation was adopted instead, and the {Wikipedia:Do not use subpages} > policy had to be rigorously enforced, as well as being retroactively applied. > Since 2004, the category system has supported hierarchical organization while > still allowing an article to belong to multiple categories. Replace "Articles" with "Messages" and this applies to TB very well: A new system of tags in TB can support hierarchical organization while still allowing for a message to belong to multiple categories (even multiple "folders"). - Creating new tags and applying existing tags "on the fly" the FF way (Bug 370076) imo forms an essential part of such a new tagging system. The discussion Bryan was probably referring to has been archived here: http://en.wikipedia.org/w/index.php?title=Wikipedia:Do_not_use_subpages&oldid=2836167

you could use the message filters to use different tags on one special email... hierarchical tags would be a nice solution for thunderbird.