User Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111107 Ubuntu/10.10 (maverick) Firefox/3.6.24 Build ID: 20111107175754 Steps to reproduce: Use tags Waiting and Reference. Actual results: These tags do not exist so they could not be added. Expected results: GTD or Getting Things Done is an organizational method developed by David Allen, see https://en.wikipedia.org/wiki/Getting_things_done for which Thunderbird can be used. In the book called Getting Things Done: The Art of Stress-Free Productivity in the diagram on page 36 certain categories are defined to be used in the GTD method. These are: a) Trash b) Someday/maybe (hold for review) c) Reference (retrievable when required) d) Projects (planning) e) Project plans (review for actions) f) Waiting (for someone else to do) g) Calendar (to do at a specific time) h) Next actions (to do as soon as I can) There are many different ways of using software in general and Thunderbird specifically to support GTD. One way is to use tags. Thunderbird currently offers five tags: 1) Important (red) 2) Work (orange) 3) Personal (green) 4) To Do (blue) 5) Later (purple) All tags highlight messages in the message list pane with the respective bright colors. GTD categories a), d), e) and g) are not very suitable to be used with tags but rather with Mail subfolders and Lightning calendar. GTD category b) can be tagged with 5) Later and category h) can be tagged with 4) To Do or even 1) Important. However for categories c) and f) not suitable tags exist. Therefore I would like to propose the following tags to be added: 6) Waiting (appropriate tint of cyan) 7) Reference (appropriate shade of gray) Which color to use exactly will be described next. Both colors have been tested for proper contrast for possible background colors in Thunderbird. The cyan to be used is RGB value 009999 and which follows the color scheme of the exiting color and has good contrast with the light gray background color of the odd lines in the message list pane. The gray to be used is RGB value B2B2B2 which is also used in the grayed out day numbers in the top left month overview in Lightning calendar. It has also good contrast with the light gray background color of the odd lines in the message list pane. Of course the end user can add new tags and edit existing tags. Nevertheless the current set of tags provided showed already too minimal for tagging messages at the moment and in the past, even before I ever heard of GTD. Especially a gray tag as an alternative archiving email is very welcome when message need to be kept together in the same Mail subfolder. Secondly, many work is deferred to others and one needs to be able to tag a message for which another person is doing the work and you only need to check if he or she did the work. Therefore tag for waiting is also justified. An patch file made with hg diff on trunk adding these tags as described is attached to this report. Implementing this feature will make Thunderbird more GTD compliant, at least more GTD friendly and for users that don't use GTD simply handy to have these two extra tags which can be of general use in processing emails.

Update: RGB #339999 (cyan) for Waiting and RGB #999999 (gray) for Reference since these are from the default pallet for tag colors. Also a new patch has been added which was made with hg commit and hg export.

Please see also https://bug436017.bugzilla.mozilla.org/attachment.cgi?id=596473 and comment number 10 and 11 on bug 436017

Comment on attachment 592415 [details] [diff] [review] Adding tags Waiting and Reference So, I'm having a tough time with this patch. I applied it to my source tree, and rebuilt, but I don't see the new tags show up in the preferences or the Tag menu, and hitting "6" or "7" doesn't tag the message. So, based on that, I think I have to clear out the review request until you can help me get it working. (The code seems okay, my only two complaints are that it doesn't do anything that I can see, and that there are no tests.) As for the UI-Review… 1) I'm not totally happy with the cyan, since it seems kind of close to both the blue and the green. The grey isn't too bad, though, I think. (I'll have to test it out to be sure.) 2) It seems to me that "Reference", like "Trash", would be better implemented with a folder. Specifically the "Archive" folder, which is easily fileable-in using the "a" key. "Waiting" does seem like a useful thing to add a tag for, though, and if it took the grey, then point #1 wouldn't be a problem. :) Now, I'm no GTD expert, so I might not really understand the concept behind "Reference". If that's so, and it's really not covered by the Archive functionality, please let me know, and maybe try to explain it a little more so that I can better understand. Based on those comments, and my need to see the patch in action, I think I'm going to say ui-r- for this version, and will test out the next one when it's posted. Thank you, Blake.

(In reply to Blake Winton (:bwinton - Thunderbird UX) from comment #4) > Comment on attachment 592415 [details] [diff] [review] > Adding tags Waiting and Reference > > So, I'm having a tough time with this patch. I applied it to my source > tree, and rebuilt, but I don't see the new tags show up in the preferences > or the Tag menu, and hitting "6" or "7" doesn't tag the message. So, based > on that, I think I have to clear out the review request until you can help > me get it working. (The code seems okay, my only two complaints are that it > doesn't do anything that I can see, and that there are no tests.) And if you use an account which doesn't have a Firefox profile? As for the technical support on this patch, please ask in the Mozilla developers community as I have only little experience patching Thunderbird. > As for the UI-Review… > > 1) I'm not totally happy with the cyan, since it seems kind of close to both > the blue and the green. The grey isn't too bad, though, I think. (I'll > have to test it out to be sure.) My idea behind it was that the "Waiting" still requires some action later on so the color is somewhere in between "To Do" and "Later". > 2) It seems to me that "Reference", like "Trash", would be better > implemented with a folder. Specifically the "Archive" folder, which is > easily fileable-in using the "a" key. "Waiting" does seem like a useful > thing to add a tag for, though, and if it took the grey, then point #1 > wouldn't be a problem. :) The idea of "Reference" is that you need to keep this message for possible reference material in the distant future but want to keep it in the same container as the other messages. This is similar to "Archive" however the "Archive" folder builds a tree bades on dates and moves a message there, separating it from its previous project folder in which should be kept (in this particular usage of GTD). Since there are many ways of organising your messages, this adds a way to archive your messages by tagging it "Reference" and on purpose not moving it to a special "Archive" folder. People who would like to use the "Archive" folder can still do that. The proposed patch offers simply an alternative way of archiving. > Now, I'm no GTD expert, so I might not really understand the concept behind > "Reference". If that's so, and it's really not covered by the Archive > functionality, please let me know, and maybe try to explain it a little more > so that I can better understand. See previous comment. :) > Based on those comments, and my need to see the patch in action, I think I'm > going to say ui-r- for this version, and will test out the next one when > it's posted. See my first comment. :S > Thank you, > Blake. Regards, Pander

I don't have many feelings about this, but here's something to consider: - This bug proposes to add 2 more default tags, increasing the number of default tags to 7. - Currently, 5 out of 9 available keyboard shortcuts are taken by default tags; after this bug, 7 out of 9 available keyboard shortcuts will be taken by default tags and thus practically no longer available for the user, due to the wrong/insufficient design of our tags administration UI (e.g. bug 368084) - So after this bug, by default, we would only leave 2 free slots for custom tags with a keyboard shortcut (and imo users will be shy to change the defaults for their own purposes); as a matter of fact, after this bug, they will run into the problems of bug 368084 even faster than now, even for very small sets of tags. - In the current design, that's also 2 more tags that ignore lexical sorting and always stay at the top of any tags list unless hacked otherwise. - We have no idea what kind of tags different types of users will actually need; it's hard to tell how much value "Waiting" or "Reference" tags will have for different types of users (of course one might say something similar about the existing 5 default tags, but I consider these more as a set of examples). - Users like Pander who need special tags, e.g. for GTD, can always create them themselves, currently with a default choice of 4 free slots for custom tags with a keyboard shortcut. I'm not saying this is a bad idea, but in the current wrong and non-customizable, non-scalable tags UI environment, I have some doubts if the uncertain benefits of this bug will outweigh the costs.

(In reply to Thomas D. from comment #6) > I don't have many feelings about this, but here's something to consider: > ... > I'm not saying this is a bad idea, but in the current wrong and > non-customizable, non-scalable tags UI environment, I have some doubts if > the uncertain benefits of this bug will outweigh the costs. I think that's a wontfix recommendation from my side, but why not make this an addon? In an addon, one could even provide the full set of GTD tags, and attempt to ensure that the available keyboard shortcuts get assigned to them as appropriate, by specifying an appropriate internal tag key that ends up at the top of the list (and don't forget an undo for that).

(In reply to Thomas D. from comment #6) > - So after this bug, by default, we would only leave 2 free slots for custom > tags with a keyboard shortcut (and imo users will be shy to change the > defaults for their own purposes); I would suspect that users who are savvy enough to add their own tags with keyboard shortcuts would also be savvy enough to replace the default shortcuts. But I also suspect that neither of us have any data one way or the other. > I'm not saying this is a bad idea, but in the current wrong and > non-customizable, non-scalable tags UI environment, I have some doubts if > the uncertain benefits of this bug will outweigh the costs. I have similar doubts, and am looking forward to Pander's reponse… Thanks, Blake.

Perhaps postpone/park this until bug 436017 is fixed. Then re-evaluate the desire among Thunderbird GTD users and possible defer it to "should be an add-on". Is that OK?

Sure, that would totally work for me. :) Thanks, Blake.