If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

[Meta] Message menu and Message context menu access key alignment and other nits

NEW
Assigned to

Status

Thunderbird
Mail Window Front End
--
minor
7 years ago
3 years ago

People

(Reporter: wsmwk, Assigned: aceman)

Tracking

(Depends on: 3 bugs, {meta})

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments)

Created attachment 464606 [details]
command and context menus for Message

Message menu and Message context menu access key and other nits. 

While looking at bug 512661 it hit me that the Message menu looks unpolished. I know this bug breaks the rule of one bug per issue, but I don't see an alternative to a holistic look at the menus. If this doesn't make sense in the end, then so be it. Also, it will certainly be appropriate to have discussion outside this bug.

Mentioned last night irc with ewong. Screen shot has markup comparing the two menus 

a) consistency and brevity - Open, New and Edit don't need the word Message. (boxed in red)

b) access key conflict - most notable is "a", archive and Create Filter (in pink)

c) context menu has some different access keys (in green)

d) Reply is missing "to Sender Only (red+white box)

e) (for completeness - bug query http://bit.ly/9VaPHE )
e1) Move to (or Copy to) again - Bug 493499 may be some core keyboard issue?  (boxed in blue) 
e2) Bug 349986 - Accesskeys 'g' ... Tb menus are sub-optimal (The progress in the bug seems to suggest there is no room for improvment


Complete alignment of the two menus is beyond my intentions and the scope of this bug - not everything must be in both context menu and message menu. But more symmetry than what we have seems warranted.  Note: there was an access key discussion about some of our menus in the run up to version 3 (I no longer remeber the context) and died for various reasonable concerns at the time - localization, coder resources, access keys not important, aligning keys assignments in multiple menus not worth the time and future conflicts always arise anyway, limited availability of letters, add-ons create unplanned conflicts - plus "UI is hard". But we have more volunteers now and slightly more time on our hands, so this may be worth a quick look.

Proposal idea next...
Created attachment 464623 [details]
proposal idea 1 (RTF)

I did not intended to provide a proposal, but I started playing and perhaps fell into a reasonable starting point for discussion, with I hope minimal change. Reasonable people can disagree. If nothing else, that is to be expected because not everyone uses every function. Archive for example.

Attached is a quick and dirty ms-word RTF with previous attached image as background and accesskeys overlaid. It's pretty if you ignore the bottom of the document. Red letters represent changes from the current setting. No guarantees the RTF will display for you as I see it, so I'll attach a screen shot next.

Somewhat key to the proposal but by no means a killer, is remove Print Preview and Save as from the context menu. Rationale - likely a tiny % of users use them, they exist on the File menu, they free up scarce accesskey letters, and lastly the context menu is getting too long. (perhaps even Print should go away ... thinking GREEN)

Next is "Move again" and "Copy Again".  Perhaps not everyone uses this but I don't have a sense of whether it should or shouldn't get the axe (although I use it *a lot*). Possibilities:
* Does it need an accesskey?  (they have shortcuts after all)
* Add a start word from which a unique letter can be pulled - getting it from Move and Copy is hard. Idea - Repeat Move and Repeat Copy and use access key P. Bonus - works around bug 493499.
* Is there merit to bug 491309 - Move to again and copy to again are conflated?  I think it's worth considering. In which case Repeat Copy could get P, and Repeat Move could get V (if open in conversation is given S).  Or, perhaps smarter is give them both P and leave V free for future use or assign it to Conversation.

Next is what to assign Archive and Conversation. You don't find S much in the menu, so S is one possibility. V is the other.  For Archive I have no strong preference, but would note that using the uncommon H frees A for some future purpose.

Lastly, the problematic Create Filter From Message. Personally, I like picking letters from the KEY word of the action. How about using I?
Created attachment 464624 [details]
proposal idea 1 screen shot from RTF
(Reporter)

Updated

7 years ago
Attachment #464623 - Attachment mime type: text/plain → application/rtf

Comment 3

7 years ago
Wayne, are you aware that the menus are different in current Trunk? Both message and message context menu have been reordered and structurally assimilated by my patch for Bug 525987, which has landed on trunk.

a) to e) seem OK at first sight.

- Shortcuts cannot replace access keys, every menu item needs one (archive, and move/copy again too).
- re-labelling the menu just to change access keys does not seem right (move/copy again), although repeat might be ok
- Print Preview I personally don't care if it's on the context menu; we should file a bug that print preview needs to be accessible from a button on print dialogue
- before removing menus: is there a systematical approach? Is it possible that we currently have *all* message-related commands on the context? If yes, removing just one or two might not be good idea.
- no, Print should not go away from context
- save as - hmmm, r u sure that it's not needed on context?
- imho, having a long context menu doesn't hurt as long as it is well-structured
(In reply to comment #3)
> Wayne, are you aware that the menus are different in current Trunk? Both
> message and message context menu have been reordered and structurally
> assimilated by my patch for Bug 525987, which has landed on trunk.

No I wasn't - I don't follow UI components, and not actively using trunk. Those are welcome changes.

 
> a) to e) seem OK at first sight.
> 
> - Shortcuts cannot replace access keys, every menu item needs one (archive, and
> move/copy again too).
> - re-labelling the menu just to change access keys does not seem right
> (move/copy again), although repeat might be ok
> - Print Preview I personally don't care if it's on the context menu; we should
> file a bug that print preview needs to be accessible from a button on print
> dialogue
under "other options" of m essage header button is another possibility

> - before removing menus: is there a systematical approach? Is it possible that
> we currently have *all* message-related commands on the context? If yes,
> removing just one or two might not be good idea.
not sure I follow, unless you mean when removing we should ensure the functionality is properly exposed elsewhere if needed. absolutely

> - no, Print should not go away from context
> - save as - hmmm, r u sure that it's not needed on context?
It might be there because no one dared suggest removing it in the past. Note in the bug query of comment 0 I included WONTFIX bugs for that reason and no prior suggestions of that sort have been suggested and rejected in the past.

> - imho, having a long context menu doesn't hurt as long as it is
> well-structured


Agree with all your points. serendipitous that I cced you :)

Comment 5

7 years ago
(In reply to comment #0)
> 
> a) consistency and brevity - Open, New and Edit don't need the word Message.
> (boxed in red)

I would agree with this.  In the context, it would seem silly that it'd
be anything other than a message.  

> 
> b) access key conflict - most notable is "a", archive and Create Filter (in
> pink)
> 
> c) context menu has some different access keys (in green)
> 
> d) Reply is missing "to Sender Only (red+white box)
> 

Agree on all points.

> e) (for completeness - bug query http://bit.ly/9VaPHE )
> e1) Move to (or Copy to) again - Bug 493499 may be some core keyboard issue? 
> (boxed in blue) 

I didn't even know about the "again" part.  I normally just 
drag and drop the stuff I want to move.  

There was a point that I'm not entirely agreeing with and that's
the removal of Print Preview.  I don't know about anyone else,
but I normally print preview first before I print.  From there,
I can select the printer and what not.  Of course, one can always
File->Print Preview things also; but, it's less handy.
(Assignee)

Comment 6

6 years ago
Wayne, could you summarize which proposals still apply to TB11 ?
If these are just menu labels and access key changes, I can do this.
But who needs to ui-review this? Bwinton?
Assignee: nobody → acelists
(In reply to :aceman from comment #6)
> But who needs to ui-review this? Bwinton?

Yep.  I might pass it off to someone else, but starting by asking me is probably the easiest thing for you to do.  :)

Thanks,
Blake.
(Assignee)

Comment 8

6 years ago
So can you write your ideas about the proposal? Are there any parts you don't agree with? Which parts can we implement?

Comment 9

6 years ago
Notwithstanding the value of the holistic approach of comment 0, I suspect we'll eventually have to break this up in smaller pieces and keep this as a meta bug for coordination. Even just to get some of the minor changes ui-reviewed more easily, rather than the whole bunch of proposed changes. Otherwise, I don't mind to discuss some of the things here or even end up with a more comprehensive patch here, but I think we need to tag this as a "meta" bug.

Next steps:
1) need new screenshots of message menu and message context menu in current Trunk
2) discuss & decide string caption changes first, as they'll affect our choices for access keys (e.g., request ui-review for removing superfluous words, probably in separate bugs)
3) discuss & decide which commands should be added/removed/conflated (e.g. message context's Print and Print Preview being a likely candidate for a conflated Print dual menu button with submenu popup on hover offering Print, Print Preview, and Page Setup, like in the FF-Button which does this nicely)
Changing the sets of commands obviously influences our choices of accesskeys. However, we might want to do some of these things later.
4) discuss & decide accesskeys in a holistic manner (align message menu and message context menu accesskeys as much as possible)

Something like that... and somewhat proving the idea that we'll probably need to break this up into smaller units...
Depends on: 349986, 493499, 512661, 491309
Keywords: meta
Summary: Message menu and Message context menu access key alignment and other nits → [Meta] Message menu and Message context menu access key alignment and other nits

Comment 10

6 years ago
Do we have a meta bug for TB's access keys? Would make sense to co-ordinate some of them...
You need to log in before you can comment on or make changes to this bug.