368084 - Cannot assign keyboard shortcut keys 1-9 to user-defined tags (missing UI for changing tag number key association)

Status: NEW

(Thunderbird :: Preferences, defect)

Description

[Jason Airlie]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1
Build Identifier: version 2 beta 2 (20070116)

With the new tags interface, I am unable to sort the tags. This means that while I can easily apply the first 9 tags by simply pressing the number key associated with it, I can't change which tags are associated with a number.

Reproducible: Always

Steps to Reproduce:
1. Add a tag
2. Try to sort tags
3.


Expected Results:  
Give users the ability to change which tags are associated with the numbers. 

Perhaps make a shortcut key to start tagging 'mode' (t? , crtl+t?).
Ex:
ctrl+t work
To apply the work tag. Auto complete would be very helpful here.

Comment 1

[Magnus Melin [:mkmelin]]

Didn't find a dupe, confirming.

Comment 2

[Nathan R. Yergler]

A slight variation of this is that if you add a new tag, Thunderbird 2.0 beta 2 reorders your existing tags alphabetically so that the number key assignments *change*.  This was sort of frustrating for me, as it totally screws with my muscle memory for tagging.

Steps to reproduce:

1. Delete all tags
2. Create a tag "foo"
3. When tagging, "foo" is assigned to "1"
4. Create a tag "bar"
5. Now "bar" is "1" and "foo" is 2.

Comment 3

[Tristan Harward]

I second this, tags should be re-orderable, and never ordered alphabetically.

The standard interface for this are "Move up/Move down" buttons or arrows, and I think that's ideal for the tag window. A shortcut key such as mentioned above isn't consistent with other sorting interfaces in Thunderbird, such as in the Message Filters window.

Also, the keyboard shortcuts should not be linked with the order. The user should be able to re-order the tags in any manner they like for the menus, yet assign custom keys for applying them quickly. A simple select menu--beside each tag name in the tag options window--with all possible tag shortcuts would be perfect (I recommend making other unused keys available, even possibly letters).

I can do an interface mockup if anyone wants.

Comment 4

[Karsten Düsterloh]

SeaMonkey implemented this in bug 342560, you might want to give it a try and port it...

Comment 6

[Mike Cowperthwaite]

The Seamonkey interface is generally superior; see bug 369114.

Comment 7

[Tristan Harward]

The interface from Seamonkey should be used in Thunderbird, it looks good. Thunderbird 2 should NOT be released with the incomplete interface it currently has as of 2/10.

Comment 9

[Tristan Harward]

We're at RC1 and this STILL has not been addressed, is there any news or progress?

Comment 10

[Steve Nickels]

Another reason to do this - it appears that when a message is tagged with multiple tags, the message takes on the color of the first tag in the tag list. Being able to control which tag colors have priority would be nice.

Comment 11

[Steve Nickels]

Clarification: when a message is tagged with multiple tags, it takes on the color of the first of those tags to appear in the tag list.

Comment 12

[Karsten Düsterloh]

> Clarification: when a message is tagged with multiple tags, it takes on the
> color of the first of those tags to appear in the tag list.

Tags in threadpane and headerpane are listed in the order they got applied.
Colour and order in menues is based upon the tag's "importance", which is defined by the lexical order of the "internal tag key" and an optional "ordinal" string (as seen in about:config):

mailnews.tags.$label1.tag = 'Name1'
mailnews.tags.test.tag = 'Name2'
mailnews.tags.unknown.tag = 'Name3'
mailnews.tags.unknown.ordinal = 'higher'

will create an (decreasing) order of importance like

Name1
Name3
Name2

because in lexical order, $label1 < higher < test.
Thus a message tagged 'Name2 Name3' or 'Name3 Name2' will be coloured according to Name3.

Comment 13

[Tristan Harward]

@Karsten, I consider that to be a UI flaw, as it makes no sense from the user's standpoint. The order of the tags and which color takes precedence should be defined by the user's order, which they should be able to set.

2.0 was released with this incomplete tag options interface, I wasn't too happy... time to learn XUL I suppose.

Comment 14

[Karsten Düsterloh]

Well, that's what this bug is about: make the pref panel allow for rearranging the tags, eg like the in SeaMonkey does...

> time to learn XUL I suppose.

You're welcome. :)

(I need to rewrite parts of the SM UI when we switch to the new toolkit's <prefwindow> anyway, which will probably make porting that to TB easier then, but the transition is not quite ready yet.)

Comment 15

[Thomas D. (:thomas8)]

Current Summary of this bug (bug 368084):
> "Unable to reorder / sort tags to change number key association"

Please correct me if I am wrong: From what I understand, this bug as per its current summary and the comments so far suggests the following (sorry I can't check in seamonkey):
- To change the association of number shortcut keys (1-10), the user must reorder the administrative list of all tags (in tools-options-display-tags) in such a way that the tags that should have shortcuts are at the top of the list (list entries 1-10). This is done by moving up and down tag items in that list.
- The user-defined order of the list of tags should be used as default order for tags (e.g. when applying tags from the list in Message > tags), and alphabetical order should be abandoned (Comment #3)

I think that the logic behind the UI approach of this bug is very flawed and should be abandoned. "(User-defined) ordering of tags" and "shortcut key association" are two entirely different things that must be kept apart: from a conceptual point of view, they have nothing to do with each other.

The underlying concept goes back to the ancient 5-labels approach of TB, which is outdated and got messed up with the arrival of half-implemented user-defined tags in TB2. The underlying assumption is:

In a user-defined sort order:
first 9 tags in the list
= 9 most important tags
= 9 most frequent tags
= 9 tags that should get number shortcuts (1-9)

This is obviously nonsense for a modern tagging system:

1) Given that users can create as many different tags as they please (and they will as soon as there is a better UI, e.g. Bug 370076 - create tags for messages by typing with the keyboard, like in Firefox), might be 100+ different tags
2) Given that users can use tags for all sorts of descriptive content (importance, workflow, description of content, associated contacts...)
3) Assuming that the user may wish to order his tags in any possible way that we can't predict - alphabetically, hierarchically, by topic, newest tags first, etc...
4) Assuming that the tagging habits of a given user can change over time (tags that were used frequently before become infrequent --> new tags become frequent --> user wants to re-assign shortcuts --> does that automatically mean he wants to change sort order???)

You really can't tell under all these circumstances that the ordering of a list (for convenient overview or manual application of tags) will automatically concur with the association of shortcuts. So the concept of "ordering tags" to "change shortcut key association" messes up 2 if not 3 different aspects that should be realized independently of each other.

Here's what I'd recommend:
1.) by default, sort tag lists alphabetically (according to visible string) for both administrative list (settings) and tag application lists (currently only Message > tag)
2.) [optionally] allow the user to sort the tag application lists according to his own criteria (manual sort order, set via administrative list); new tags go at the end of that sort order as they are added
3.) for each tag, allow to assign a shortcut, e.g.
a) by providing a shortcut dropdown next to each tag in the administrative list
b) or by providing a separate dialogue where shortcuts can be assigned

4.) optionally show the currently assigned shortcut next to the respective tag in tag application lists
5.) optionally have a separate section of MRU tags at the top of the tag application lists (most recently used)
6.) optionally allow the tag application lists to be sorted by assigned shortcuts, where the reminder of tags without shortcut will be sorted according to whatever the default sort order is (alphabetical or user-defined)

Having said which, two final thoughts:
- When Bug 370076 gets implemented and we can actually create tags for messages by typing with the keyboard like in Firefox... not many users will bother sorting their daily-growing tags list /manually/ - how do you sort 100+ tags that you typed on the fly?
- When tag autocomplete gets implemented with/after implementation of bug 370076, the tiny set of 9 legacy shortcuts will become much less important as users will use autocomplete instead; besides, shortcut freaks will be able to number or otherwise label their tags and use autocomplete as a shortcut system that can handle an unlimited number of "shortcuts". Instead of just numbers 1-10, we can then use any combination of letters and numbers, and have tags like "P1 Priority 1", "P2 Priority 2".... "100 Print this" "100C print this in color" "AT1 Assign to Team 1" etc...

There's a related comment of mine in Bug 436017 comment #4 (Thunderbird should sort by tags in a more meaningful way).

See also Bug 432710 -  [Meta] Thunderbird Tag Bugs Tracker

Comment 16

[Karsten Düsterloh]

> Please correct me if I am wrong:

You are, sort of.

> I think that the logic behind the UI approach of this bug is very flawed and
> should be abandoned. "(User-defined) ordering of tags" and "shortcut key
> association" are two entirely different things that must be kept apart:

It's always a pleasure to meet someone who has absolute knowledge. :-P

Basically, the history of these key assignments is this:
- we had 5 labels, you could only use one at a time and you couldn't define new ones
- for convenience, using keys 1 to 5 set the label (and 0 deleted it)
- tags came in, allowing more than one
- the key assignments were kept and extended to use 0-9

There wasn't much thought about which key to assign to which tag, historically it's been the first ones (because there weren't any other!) and that has been kept.

This bug actually *not* about tag reordering.

The OP wants to redefine the shortcut assignment, and that's a valid wish.
And this here is the bug to fix it.

This has nothing to do with the algorithm we use to order tags, it's a completely different matter!

> from a conceptual point of view, they have nothing to do with each other.

Exactly.

> 1.) by default, sort tag lists alphabetically (according to visible string)
> for both administrative list (settings) and tag application lists (currently
> only Message > tag)

This is (a) nonsense and (b) not needed to fix this bug here.
(Also, see my bug 436017 comment #6.)

> - When Bug 370076 gets implemented and we can actually create tags for
> messages by typing with the keyboard like in Firefox... not many users will
> bother sorting their daily-growing tags list /manually/ - how do you sort
> 100+ tags that you typed on the fly?

Then why do want to sort them at all? That's kind of contradictory.
But I do agree that the usual sort notion of "natural -> \/ down -> /\ up -> natural" would be helpful here (as in "importance -> lexical down -> lexical up ").

Comment 17

[Tristan Harward]

For what it's worth, I think Thomas's comment was spot on and very well thought out, and regardless of how the tags are eventually ordered (which he clearly knows is not the key focus) his final recommendations are 100% what I would implement.

The key thing to realize is that the whole paradigm on which this bug was based (the idea that the number keys are associated with the pre-defined tag order) is now completely obsolete given a new tag system. It was originally flawed for the old implementation, but it is completely irrelevant to a new implementation which should start from the ground up with Thomas's comments in mind. 

I believe this bug's goal is still valid (essentially, to provide a good tag management UI with good shortcut capability), but the details are moot if we've got a new tag system coming. Start from scratch and do it right.

Comment 18

[Jay Moran (jaym/lazvon)]

I personally have just ended up going in and editing my prefs.js and inserting a number in front of the name of each Tag. Certainly not something is easy to explain to most end users, but it works for me.

The thought should be that the end users should be able to assign whatever number to each tag that they want, they can pick their color, let them pick their number as well.

Here is what I have:

user_pref("mailnews.tags.1to_do_-_24_hrs.color", "#FF0000");
user_pref("mailnews.tags.1to_do_-_24_hrs.tag", "To Do - 24 hrs");
user_pref("mailnews.tags.2to_do_-_week.color", "#FF9900");
user_pref("mailnews.tags.2to_do_-_week.tag", "To Do - Week");
user_pref("mailnews.tags.3useful_info.color", "#009900");
user_pref("mailnews.tags.3useful_info.tag", "To Do - Month");
user_pref("mailnews.tags.4useful_infoa.color", "#3333FF");
user_pref("mailnews.tags.4useful_infoa.tag", "Useful Info");
user_pref("mailnews.tags.5vendor.color", "#6600CC");
user_pref("mailnews.tags.5vendor.tag", "Vendor");
user_pref("mailnews.tags.6delagated.color", "#663333");
user_pref("mailnews.tags.6delagated.tag", "Delagated");

Comment 19

[Tristan Harward]

Jay - yes, that would be ideal for the current version, but is no longer relevant to a new implementation with many more tags.

Comment 20

[Jay Moran (jaym/lazvon)]

So, really, is there another option rather than what GMail does then? It seems to be incredibly well thought out and designed and be described very succinctly.

Press T for Tag (instead of L for Label as in GMail) which drops down the Tag listing, then start typing the name of the Tag you want which eliminates any non-matching tags until you either get to the specific one you want and press Enter, or click on the one you want in the list. Have as many Tags as you'd like. If you type something that has no potential matches, pop up an option to click on (or Tab to) that says "Create This Label".

And oh yeah, make sure you let folks assign numbers to those labels for even faster access than typing "L 1" which would choose my label that I called "1 To Do - 24 Hours"... because I really don't want to see my email Tag with a "1" in it.

Comment 21

[Thomas D. (:thomas8)]

Thanks, Tristan, you are getting my comment #15 right in your comment #17, that's exactly what I was trying to say.

Karsten (comment #16), I am aware that this bug is not about ordering tags. Yet the current summary of this bug ("Unable to reorder / sort tags to change number key association") suggests that the user should "reorder / sort" the administrative list of tags (Tools > options > display > tags). In the same line, I understand that /your/ approach towards fixing this bug is to implement "move up" and "move down" buttons for that list, so that moving a tag up into the first slot of the list would mean to assign the key "1" to that tag as a shortcut etc. What I am trying to say is exactly what Tristan has summarized in comment #17: I fully support the goal of this bug to provide a bug-free and better way of letting the user assign keyboard shortcuts, but moving tags around in a list to do that just doesn't seem the right UI approach for this any more (as it is based on an obsolete concept of having 5 pre-defined tags). I am glad that we also agree on the history of this, and I couldn't agree more to what you said in comment #16:

> There wasn't much thought about which key to assign to which tag,
> historically it's been the first ones (because there weren't any other!)
> and that has been kept.

Have a look at Firefox tagging UI (which now includes autocomplete!) to see that Thunderbird's current tagging UI is somewhat disadvantageous when it comes to extensive and efficient user-defined tagging (cf. bug 370076). Meta bug 432710 (TB Tag bugs tracker) has more... That's why I hope with some confidence that we will see some major changes of TB's tagging UI in the not-too-distant future. In that context, scalable UI choices will be crucial to handle a lot of tags. As you point out in the above quote, scalability wasn't an issue when the current administrative preference pane for tags was built. Moving tags up and down into a pre-defined number of shortcut slots isn't scalable.

I agree with your statement of bug 436017 comment #6 that this bug is part of a more "general problem to let users assign custom keys for menus and actions" in TB. In the same comment, you acknowledge that the UI concept of "assigning the shortcut keys to the tags" rather than vice versa (ordering tags in a way that they fall into the right shortcut slot), I quote, "might be a useful enhancement indeed".

So I think we can agree that it'll be a good idea to update the summary of this bug accordingly. Furthermore, this bug was originally posted as a bug, and the bug is still there (including the bug mentioned in comment #2!), so "bug" seems more appropriate than "enhancement", and will have more chances to get addressed.

Comment 22

[Daniel Kabs, reporting bugs since 2002]

Filed bug #528034: UI needed to allow user to order tags manually.

Comment 23

[Daniel Kabs, reporting bugs since 2002]

Thomas wrote:
> So I think we can agree that it'll be a good idea to update the summary of this
> bug accordingly. 

It was a very good idea to change the summary to reflect to current state of discussion. But please don't explicitly limit the shortcuts to *applying* tags. Please also think about the critical action of *removing* all tags. 

Currently the shortcut to remove all tags is key "0". This must be user configurable, too.

Reasoning:
Use makes intensive use of TB's tagging system. After selecting messages, user  accidentially hits "0". All tags are gone and there is no undo function (in contrast to "removing messages to trash")

Comment 24

[Thomas D. (:thomas8)]

Related user feedback:

http://getsatisfaction.com/mozilla_messaging/topics/how_to_reorder_my_tags
http://getsatisfaction.com/mozilla_messaging/topics/manage_tags_new_short_key