436017 - Thunderbird should sort by tags in a more meaningful way

Status: NEW

(Thunderbird :: Mail Window Front End, defect)

Description

[Boying Lu]

re-produce steps:

1. Thunderbird provides standard labels and colors for their tags.
      Important  (red)
      Work  (orange)
      Personal  (green)
      To Do  (blue)
      Later  (violet)
2. I assign a lab for my emails.
3. I then sort the mails by tag.
4. PROBLEM:  mails are sorted in tag alphabetical order (not as they are 
listed), this means that mails are sorted in the following order:
      Important
      Later
      Personal
      To Do
      Work
5. If I want to change order I can go edit them by putting a number (in 
front of the tag) as well as different colors such as:
      1 Important  (blue)
      2 Work  (green)
      3 Personal  (orange)
      4 To Do  (yellow)
      5 Later  (red)
6. PROBLEM:  when I assign the edited tag to my emails and sort by tag, 
SOME of the tags (on their own) revert back to the original names and 
colors, and then sort by number then alphabetic order.  So my mails are 
sorted in the following order and into two different groups and two 
different colors:
      1 Important  (blue)
      2 Work  (green)
      3 Personal  (orange)
      4 To Do  (yellow)
      5 Later  (red)
      Important  (red)
      Later  (violet)
      Personal  (green)
      To Do  (blue)
      Work  (orange)

Comment 1

[benc]

I have the same problem in Mac OS X 10.4, Thunderbird 2.0.0.14.

NOTE: We should probably break the two problems mentioned (sort order and updating the value of the tags) separately...

Comment 2

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #0)
> 5. If I want to change order I can go edit them by putting a number (in 
> front of the tag) as well as different colors such as:
>       1 Important  (blue)
>       2 Work  (green)
>       3 Personal  (orange)
>       4 To Do  (yellow)
>       5 Later  (red)

Your editing means change of string text for the tag(displayed in UI) only. 
> user_pref("mailnews.tags.$label1.tag", "Important" => "1 Important");
> user_pref("mailnews.tags.$label2.tag", "Work"      => "2 Work"     );
> user_pref("mailnews.tags.$label3.tag", "Personal"  => "3 Personal" );
> user_pref("mailnews.tags.$label4.tag", "To Do"        "4 To Do"    );
> user_pref("mailnews.tags.$label5.tag", "Later"        "5 Later"    );
Tag data for a mail saved in X-Mozilla-Keys: is still "$labelX", even after string text change of a tags. This is intentional, in order to avoid replacing work of already put tag data in X-Mozilla-Keys: for all mails upon string text change for a tag. (Local mail folder case. When IMAP, situation is far worse.)
And, AFAIK, sorting by tag is based on $labelX part instead of "1 Important".
(Sorry but I don't know sort order when multiple tags are set in mails.)
(simply ordered by character data of "X-Mozilla-Keys: tagX tagY tagZ ..." ?)

Workaround:
In your case, at least next 2 steps are required.
(1) Add entries in prefs.js.
(Or define tags of "$_X_label" via UI, then change string to "Important" etc.) 
> user_pref("mailnews.tags.$_1_label.tag", "Important");
>                            |
> user_pref("mailnews.tags.$_5_label.tag", "Later"    );
>or
> user_pref("mailnews.tags._1_important.tag", "Important");
>                           |
> user_pref("mailnews.tags._5_later.tag",     "Later"    );
(2) Change already added tags(in X-Mozilla-Keys:) from $labelX to $_X_label.
    - Create search folder for $labelX, add tag for $_X_label to mails,
      and remove tag for $labelX from mails.
(3) If you use "add tag" in filter or "tags contains" in search folder or view, they should also be changed.

Current implementation is very confusing for users, and sort order is unpredictable/unbelievable for users, if string for tags are altered after initial tag definition. 
What is best way for users, do you think?

Comment 3

[Karsten Düsterloh]

Thunderbird sorts tags by importance.
See bug 368084 comment 12 for details - basically TB needs a more advanced pref pane like SeaMonkey has.

Comment 4

[Thomas D. (:thomas8)]

Sorting tags by importance makes sense when there's only 10 or 20 tags to prioritize; it might not make so much sense any more when TB will eventually get a useful tagging UI (as proposed in Bug 370076 -  create tags for messages by typing with the keyboard, like Firefox). With a firefox-style tagging UI, users will finally be able to apply as many user-defined tags on the fly as they please, and the tags can be about anything: importance, content, assigned-to, suggested action,... For many of those, sorting by importance doesn't make sense. How do you sort 100+ content tags by importance?

What we need to make TB tags useful is a new concept that is similar to the firefox concept of tags (if only because users are used to that concept, because it's great!). I believe when trying to find a new tags (sorting UI) approach for TB, it will be important to get away in our thinking from the ancient 10-labels approach of TB. For a start, I agree with WADA that alphabetical order of the visible tag strings would be a good idea (and not some mysterious internal definition strings order the average user has no idea of). Any other options should be considered additions:

- If you think that user should be able to sort by importance, fine. But the idea is to assign importance ranking as another property of the tag, without affecting the option to sort alphabetically.
- If some tags should be accessable via shortcut number keys as we all love it, fine. But the conceptual idea must be assigning the shortcut keys to the tags, and not "ordering" tags in a way that they happen to be the first 10 who happen to have a shortcut. By the way: assigning one of the rare shortcuts to a tag doesn't necessarily say anything about the "importance" of a tag. Rather, it says something about the frequency with which I am expecting to use that tag, which might be completely opposed to its importance.

Comment 5

[Thomas D. (:thomas8)]

(In reply to comment #3)
> Thunderbird sorts tags by importance.
> See bug 368084 comment 12 for details - basically TB needs a more advanced pref
> pane like SeaMonkey has.

There's a kinda lengthy comment of mine (Bug 368084 comment #15) trying to explain why SeaMonkey's tag pref pane might not be a good template (tag order of lists to apply tags should be independent of shortcut assignment)
Within that comment, there are also some suggestions with respect to sorting tags (e.g. default alphabetical order, optional allow user-defined sort order, optional MRU tags list on top of normal list, optional sort by keyboard shortcut).

Overview: Bug 432710 - [Meta] Thunderbird Tag Bugs Tracker

Comment 6

[Karsten Düsterloh]

Basically I think you don't understand "importance".

(In reply to comment #4)
> Sorting tags by importance makes sense when there's only 10 or 20 tags to
> prioritize; it might not make so much sense any more when TB will eventually
> get a useful tagging UI

Huh?!

> For many of those, sorting by importance doesn't make sense.
> How do you sort 100+ content tags by importance?

If I want to *sort* something, I need to define a sort *order* - iow, I need to define the *importance* of each element in the set.

> get away in our thinking from the ancient 10-labels approach of TB.

There never were 10 labels. Just five.

> alphabetical order of the visible tag strings would be a good idea

I disagree. Why should my tag order depend upon a tag's name?
That'd be like sorting the pages of a book by their first word, just because you don't understand those strange numbers at the bottom.

Of course, you _can_ derive your tags' importance from their name, but that shouldn't be default or a requirement. It might be worth exploring to enhance the tag addition algorithm to support automatically setting a tag's importance as defined by the lexical order, but I doubt it's very useful.

> some mysterious internal definition strings order the average user has no
> idea of).

Again, that's not a problem of the sort algorithm, but of TB's limited tags pref panel.

> - If some tags should be accessable via shortcut number keys as we all love
> it, fine. But the conceptual idea must be assigning the shortcut keys to the
> tags, and not "ordering" tags in a way that they happen to be the first 10
> who happen to have a shortcut.

That might be a useful enhancement indeed.

(On a greater scheme, this is "just" the result of our general problem to let users assign custom keys for menus and actions.)

Comment 7

[WADA:World Anti-bad-Duping Agency]

Setting dependency of some bugs(sort&tag or sort&order in bug summary), for ease of tracking.

Comment 8

[Daniel Kabs, reporting bugs since 2002]

I think it is important that a user can control and change the priority of his tags. See bug #528034.

Comment 9

[Daniel Kabs, reporting bugs since 2002]

Why can't we just say that sort order of tags is done according to priority of tags? So that priority equals sort order equals priority. 

Then, of course, user has to be able to define the order of bugs, see bug 528034.

For the use case "semantical tagging" (i.e. describing the content of a mail using tags) the priority/sort order might just be the lexical order.

For the use case of "project management" (i.e. using tags to assign mails to projects, work queues, etc.) the priority/sort order might be completely up to the user.

Comment 10

[Pander]

Attachment: Proposal for improving UI to fix several tag related bugs.

Comment 11

[Pander]

Which tags are available and how these should be sorted should be completely up to the individual Thunderbird users but should be offered with well thought defaults settings.

The proposed changes to the UI in submitted attachment, when accompanied with proper changes to tag related software, will allow solving many tag related bugs such as:
- easily and transparently managing tags with respect to numeric keys 1, 2, ..., 9 and setting tag name and tag color
- allowing historic tags (backwards compatibility)
- sorting meaningfully on numeric key and historic tags, key 1 = highest priority, etc.
- optionally allowing only one tag
- supporting Getting THings Done (GTD), see bug 721901

Comment 12

[Thomas D. (:thomas8)]

Comment on attachment 596473 [details]
Proposal for improving UI to fix several tag related bugs.

Pander, thank you for your efforts to help improve the tags UI, something which is much needed.

When you suggest a new UI by attaching a screenshot, pls ensure to use the right flags:
- start with asking for feedback: set "feedback?" and pick an appropriate person for feedback. If you don't know who is appropriate for feedback, pls ask.
- at a more advanced stage, usually after some agreement/feedback etc., you can ask for ui-review: set "ui-review?" and pick an appropriate reviewer (or ask for one).
- for actual patches with code, after you get "ui-review+" from reviewer, you can then set "review?" and pick an appropriate reviewer for the code (or ask for one)

I'll take feedback / ui-review for this one in subsequent comment, because it's an obvious case.

Comment 13

[Thomas D. (:thomas8)]

Comment on attachment 596473 [details]
Proposal for improving UI to fix several tag related bugs.

Pander, thank you for providing the mockup UI proposal.
I appreciate the general intention of making editing of tags simpler (less steps). However, there are a number of problems with the proposed UI:

1) No way to edit user-defined tags for number of tags > 9
This UI isn't scalable. We need something like a list that can handle large numbers of tags, so that semantic tagging becomes possible, as in FF.

2) No way to assign a different keyboard shortcut to existing tags.
This UI will mislead the user into renaming tag captions in order to "assign" a new keyboard shortcut. Due to the current internal nature of tags, the result will be disastrous, a total mess-up of various tags (dataloss).
And even if dragging of tags into the keyboard shortcut slots were possible, it would still the wrong concept, and it would still be dangerously misleading.

3) No way to assign colors to user-defined tags > 9
And duplicating the color buttons for > 9 tags isn't scalable - e.g. for heavy use of semantic tagging, we don't want 100+ color buttons in our UI.

4) "Tags...which are not in this list [of first 9 tags]...will be sorted alphabetically after the 9 and before the 0"
- No way! Again, there could be a potentially unlimited number of user-defined tags, and to have "Remove all tags" at the end of the list really doesn't help.
- Apart from that, we need to provide for various sorting alternatives (e.g. alphabetical vs. importance ranking), and we need cater for various parts of the ui where different sort orders might be required (e.g. tag application UI vs. tag administration UI). I believe I have already commented on this elsewhere. For semantic tagging, we need options for alphabetical sorting. For "importance" tagging, we need options for creating importance rankings. So we need to provide both.
- And as I have said before, assigning of keyboard shortcuts must be independent of sorting, because neither importance ranking nor alphabetical order necessarily coincide with the need for keyboard shortcuts.

5) "Restore Defaults" button
- That button doesn't work because it's entirely not clear what exactly this is going to restore. Even as a power user, I would never click that button, fearing that it might erase my user-defined tags, because they are not part of the defaults.
- Furthermore, even resetting all the keyboard shortcuts or colors doesn't make sense because we have no idea if these first 9 tags still serve the original purpose, or even have the original captions, or if they are still existing at all.

6) Option to "[ ] Remove all other tags when setting new tag"
- This might be an interesting idea to explore, but it's a new feature, so it needs a new bug.
- This cannot be the default option, because a lot of use cases like complex workflows or semantic tagging require multiple tags on single message.
- Even for mutually exclusive tags like those for "Getting things done" (as suggested by Pander in Bug 721901), users might still want an additional layer of tags for different projects, different users, etc.

In conclusion, the proposed UI doesn't work, mainly because it's not scalable, but designed only for the "traditional" tagging approach with a small, static, and limited set of tags. -> ui-review-

Comment 14

[Pander]

(In reply to Thomas D. from comment #13)
> Comment on attachment 596473 [details]
> Proposal for improving UI to fix several tag related bugs.

Thomas, thank you for setting the correct tags and explaining how they work.

> Pander, thank you for providing the mockup UI proposal.
> I appreciate the general intention of making editing of tags simpler (less
> steps). However, there are a number of problems with the proposed UI:

Thanks for the constructive feedback, see my comments and questions below.

> 1) No way to edit user-defined tags for number of tags > 9
> This UI isn't scalable. We need something like a list that can handle large
> numbers of tags, so that semantic tagging becomes possible, as in FF.

What if this proposal is extended with a second column of tags for '!', '@', ..., ')' (i.e. SHIFT+1, SHIFT+2, ..., SHIFT+0) This would allow for a total of 19 tags. If also '`', '~', '-', '_', '=' and '+' are added that would allow for 25 tags. These ranges keep clear for the shortcuts that are assigned to normal keys a, b, ..., z for bindings such as star, message forward, message backwards, archive message, etc. (Note it is 19 and 25 and not 20 and 26 because the 0 is reserved to clean tags.)

> 2) No way to assign a different keyboard shortcut to existing tags.
> This UI will mislead the user into renaming tag captions in order to
> "assign" a new keyboard shortcut. Due to the current internal nature of
> tags, the result will be disastrous, a total mess-up of various tags
> (dataloss).
> And even if dragging of tags into the keyboard shortcut slots were possible,
> it would still the wrong concept, and it would still be dangerously
> misleading.

How about disabling 1, 2, 3, 4, and 5 by default and offering a setting in http://about:config for power users to disable this lock?

> 3) No way to assign colors to user-defined tags > 9
> And duplicating the color buttons for > 9 tags isn't scalable - e.g. for
> heavy use of semantic tagging, we don't want 100+ color buttons in our UI.

Not sure what you mean by this. My comments above would limit to a maximum of 19, 21, 23 or 25 different tags.

> 4) "Tags...which are not in this list [of first 9 tags]...will be sorted
> alphabetically after the 9 and before the 0"
> - No way! Again, there could be a potentially unlimited number of
> user-defined tags, and to have "Remove all tags" at the end of the list
> really doesn't help.
> - Apart from that, we need to provide for various sorting alternatives (e.g.
> alphabetical vs. importance ranking), and we need cater for various parts of
> the ui where different sort orders might be required (e.g. tag application
> UI vs. tag administration UI). I believe I have already commented on this
> elsewhere. For semantic tagging, we need options for alphabetical sorting.
> For "importance" tagging, we need options for creating importance rankings.
> So we need to provide both.
> - And as I have said before, assigning of keyboard shortcuts must be
> independent of sorting, because neither importance ranking nor alphabetical
> order necessarily coincide with the need for keyboard shortcuts.

What if each key-tagname-color should also get a sort order number? Or each key-tagname-color is in a user sortable list? This would of course complicate the UI a bit but allow for separation of sort order and tag definition.

Next to that some options could be provided for where to put the 'no tags' and 'unknown tags' in the final sort.

> 5) "Restore Defaults" button
> - That button doesn't work because it's entirely not clear what exactly this
> is going to restore. Even as a power user, I would never click that button,
> fearing that it might erase my user-defined tags, because they are not part
> of the defaults.

Factory defaults, ergo removing your custom tag definitions. I understand this is dangerous so I agree to remove that.

> - Furthermore, even resetting all the keyboard shortcuts or colors doesn't
> make sense because we have no idea if these first 9 tags still serve the
> original purpose, or even have the original captions, or if they are still
> existing at all.

Agree.

> 6) Option to "[ ] Remove all other tags when setting new tag"
> - This might be an interesting idea to explore, but it's a new feature, so
> it needs a new bug.

Agree. OK to leave it in the UI proposal fow now?

> - This cannot be the default option, because a lot of use cases like complex
> workflows or semantic tagging require multiple tags on single message.

Agree, hence it was unchecked in the proposal.

> - Even for mutually exclusive tags like those for "Getting things done" (as
> suggested by Pander in Bug 721901), users might still want an additional
> layer of tags for different projects, different users, etc.

Personally I use Star for that so offering this options leaves it to the user to decide.

> In conclusion, the proposed UI doesn't work, mainly because it's not
> scalable, but designed only for the "traditional" tagging approach with a
> small, static, and limited set of tags. -> ui-review-

Two main questions from my side:
- are 25 tags enough?
- what do you prefer, sort-order-number per key-tagname-color or a list of key-tagname-colors in which each item can be pushed up or down?

With answers to this and taking all your comments into consideration I would like to make anther sketch so we can see if that matches the requirements better.

Comment 15

[Thomas D. (:thomas8)]

(In reply to Pander from comment #14)

Pander, I've read your considerate response. I don't have enough time for all the details right now, so here's an answer to your main questions:

> (In reply to Thomas D. from comment #13)
> > Comment on attachment 596473 [details]
> > Proposal for improving UI to fix several tag related bugs.
> Two main questions from my side:
> - are 25 tags enough?

No. :) 25 keyboard shortcuts for tags would certainly be an improvement over the status quo. However, from my pov and experience, that definitely needs a new bug.
An administrative UI for only 25 tags is not enough, because there is no limit on the number of tags a user can create. And we need to allow the user to edit all of his tags from the tags options UI.

When I say scalability, I'm thinking of Bug 370076 Comment 5, Bug 368084 Comment 17, and Bug 368084 Comment 15 (where you can find a more detailed explanation). So the goal is to allow unlimited semantic tagging, like in Firefox. But even for traditional closed-set tagging (with a limited number / fixed set of tags), we can't tell how many tags are needed for different types of users.

> - what do you prefer, sort-order-number per key-tagname-color or a list of
> key-tagname-colors in which each item can be pushed up or down?

I don't fully understand that question. Tabular list sounds right (see example below), but "pushing up & down", if at all, might make sense only for setting priority, not for assigning keyboard shortcuts. Priority ranking and Keyboard shortcut should be two independent properties of any tag, because we can't tell if they coincide (and I've explained elsewhere that on the contrary, some most important tags might be less frequent, so they might not even need a keyboard shortcut). More so if you want to increase the no of keyboard shortcuts: IMO we really want to assign one out of many keyboard shortcuts to any one given tag, not vice versa (assign one out of many tags to one keyboard shortcut, e.g. by moving the tag into fixed keyboard shortcut slots). Imagine you have tag_x with keyboard shortcut 25 (where it doesn't matter which key that is). But you want to assign keyboard shortcut 1 to tag_x. So you'd have to click 24 times "move up" to push up tag_x into the appropriate keyboard shortcut slot 1. For tag_y, ranking on position 100 out of 200 tags, you might have to click 100 times "move up" to do the same. Hence, pushing up and down seems simple, but isn't scalable for setting keyboard shortcuts (apart from other ux problems).

> With answers to this and taking all your comments into consideration I would
> like to make anther sketch so we can see if that matches the requirements
> better.

I envision something like the following UI (an example of scalable UI):

* A grid control (XUL <tree>), i. e. a tabular structure with following columns:

|Tag name |Ranking | Color | Keyboard shortcut|
+---------+--------+-------+------------------+
|Important| 1      | #red# | 1                |

So user can sort the tag administration list (in tools > options) by any of these 4 characteristics of a tag, and it's scalable as a list with a scrollbar (which I didn't draw).

* We might want to enable simple editing directly from the grid (similar to Pander's original idea, but using different UI elements):
- Tag name can be edited directly with F2 or clicking on the tag name caption.
- Clicking on color icon in grid pops up color picker
- perhaps more (but that's probably more complex)

* A <frame> element where the details of the currently selected tag are shown for editing (editing panel):

+--Edit Tag: Importance----------+
| Tag name:          [Importance]|
| Ranking:           [1 ⇓⇑]      |
| Color              [#red#]     |
| Keyboard Shortcut: [1 |v]²     |
+--------------------------------+

²: (with a dropdown of all available shortcuts as long as we prescribe them and their no. is small)

N.B. I wonder if we should show or even let edit the internal name here, too, as long as we use that.

Comment 16

[Thomas D. (:thomas8)]

Pander, I suppose you *do* know that there's a Tag button in the main UI from which you can create a "New tag...", and even tags without a keyboard shortcut can currently be applied by using the tag button (which is about to become an endangered species for message tabs because of bug 644169 and bug 456169).

Comment 17

[Thomas D. (:thomas8)]

(In reply to Thomas D. from comment #15)
> (In reply to Pander from comment #14)
> I envision something like the following UI (an example of scalable UI):

A good live example of the envisioned scalable UI (Tree-Grid + Details Pane for selected item) is FF bookmark manager: When you select one out of many bookmarks, you can edit the details in the properties pane at the lower right.

Comment 18

[Pander]

Attachment: Proposal new tags dialogue

Comment 19

[Pander]

Attachment: Proposal new tags dialogue - add/edit

Comment 20

[Pander]

I have added two new proposals based on your feedback from yesterday. These require minimal changes to existing dialogues while catering to all the requirements discussed.

Comment 21

[Thomas D. (:thomas8)]

Comment on attachment 597327 [details]
Proposal new tags dialogue

Thank you, Pander!
This is going the right direction, so feedback+
Some of the details in the text may not work. Pls file a copy of your descriptive text for both attachments as a comment so that others can reply citing you. When filing the text, pls add attachment # so that there's a link to the respective attachments.

Comment 22

[Thomas D. (:thomas8)]

Comment on attachment 597328 [details]
Proposal new tags dialogue - add/edit

This is also going the right way, although some of the details may not work.

This would be the minimal change using current UI (add/edit dialogue for the tag). I'm inclined to think that since we are changing both the main administrative tag dialogue and the tag add/edit dialogue, it's probably only a little more work to combine them into a single flat dialogue, as proposed in my comment 15, similar to the bookmarks manager example in comment 17.

I don't understand your details of rank, e.g. "outside of range". Can you illustrate with an example of 7 tags, which rank values are possible?

I would definitely deal with allowing extra shortcut keys in a separate bug. That's a lot more work, and needs a lot more thought. It's not required to fix this bug (and btw, I'm not sure if we are fixing *this* bug, I think we are fixing Bug 368084).

Pander, do you want to eliminate/change the use of internal tag order? I.e., do you want to change the whole backend code for tags, which are currently saved as prefs (not well scalable)? See Bug 368084 Comment 12 for details. I've lost track of the details, but they are currently complex and confusing (this bug, and others). I don't have a good understanding of IMAP tags, but we need to consider these, too.

Again, it might be better to do one thing at a time. If we can fix bug 368084 about assigning the current keyboard shortcuts to any given tag (which is the main effect of the new UI you propose here), that would be a great step forward already.

I'm setting feedback+ for the general direction, but not all of the details will work.

Comment 23

[Thomas D. (:thomas8)]

About the color column I proposed for the grid, I meant to display a square with the actual color there, not the color code. Clicking the icon will trigger the color picker. Benefit: Sort by colors to see which colors are assigned for which tags. I haven't checked which xul elements or techniques could be used for that UI. The Seamonkey tag administration UI is better than ours, but the design is wrong about assigning keyboard shortcuts, and it's not getting various aspects of ranking/order etc. right. Not that I have the perfect plan for those, either...
I recorded some general first thoughts about ranking/order in Bug 368084 Comment 15.

Comment 24

[Blake Winton (:bwinton) (:☕️)]

(In reply to Thomas D. from comment #21)
> Comment on attachment 597327 [details]
> Thank you, Pander!
> This is going the right direction, so feedback+

So, I know that Thomas likes the idea of separating the keyboard shortcuts from the ordering, but I'm not convinced that that is a common enough use-case to force all our users to deal with the added complexity that it brings…

So given that, I much prefer your first proposal to your second one.

(I also strongly disagree that SeaMonkey's tag administration UI is better than Thunderbird's.  More powerful, perhaps, but also more confusing and less usable, and that doesn't seem like the right trade-off for Thunderbird's user-base.)

Thanks,
Blake.

Comment 25

[Pander]

Tomorrow I'll send an improved design in text only which keeps it simple and robust.

Comment 26

[Pander]

Preconditions:
- current 5 default tags should remain default tags, however they can be edited by the user
- tags may never be removed from messages when tag definitions are removed
- new tag interface should be compatible with existing tag definitions from before
- 0 will remain the key to remove all tags for a message

Upcoming Functionality:
- Tags should be created and edited to have a name*, color*, unique key and rank (* required).
- Any free key (also in combination with SHIFT) should be possible to assign to a label.
- Rank is an integer > 0
- Sorting emails on tag should sort on tags with highest rank first, for identical rank, look at rank of next tag. Next to rank, sort order is alphabetically on tag name. Emails with unknown tags are next, also alphabetically, and emails without any tags are last.
- Messages in overviews get the color of the tag with the highest rank.
- Labels are shown in message header sorted in the same way as described above

Questions:
- Does this sketch the outlines of the new design before going into the details?
- Is it really necessary to be able to set more then one key per tag? (I don't think so, especially when we want access to *more* keys for different tags.)
- Is a Java/C++ short enough for rank?
- Should rank be unique? (I think so, because when rank is always set, sorting is very quick.)