when the folder name contains "i", move to xxx again / copy to xxx again accesskey/shortcut "i" appears in folder name

NEW
Unassigned

Status

Thunderbird
Folder and Message Lists
--
minor
9 years ago
6 years ago

People

(Reporter: wsmwk, Unassigned)

Tracking

(Depends on: 2 bugs, Blocks: 1 bug, {polish, uiwanted})

Trunk
x86
Windows Vista
polish, uiwanted
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

9 years ago
current trunk

when the folder name contains "i", move to xxx again / copy to xxx again shortcut "i" appears in folder name rather than in the word "again"
(Reporter)

Comment 1

9 years ago
p.s it's really a trivial issue, but I filed this because some people may think it confusing, and strange when they see the underline for the accesskey move out of "again".

One possible solution is to change wording to 
  move again to xxx or 
  copy again to xxx
Summary: when the folder name contains "i", move to xxx again / copy to xxx again shortcut "i" appears in folder name → when the folder name contains "i", move to xxx again / copy to xxx again accesskey/shortcut "i" appears in folder name

Comment 2

6 years ago
According to https://developer.mozilla.org/en/XUL_Accesskey_FAQ_and_Policies, 'i' isn't a good accesskey.

So what is the UX decision here?
Keywords: polish, uiwanted
(Reporter)

Comment 3

6 years ago
(In reply to :aceman from comment #2)
> According to
> https://developer.mozilla.org/en/XUL_Accesskey_FAQ_and_Policies, 'i' isn't a
> good accesskey.
> 
> So what is the UX decision here?

In an ideal world, one might not use "i". However, look at the Message menu and the folder pane context menu, and I think you'll see we don't we have much choice.  And if Bug 512661 is done - Move to/ Copy to "xxx" again doesn't mean what it says!  Remove the word "again" - we won't have even that choice.  I am therefore not in favor of that bug.

The accesskey policies are wonderful.  However, once you have over 12 or so menu items that require accesskeys, then you get into the territory of needing to give ground on some of the guidelines. And I submit that the items under "Make it easy to see" are probably least important of the guidelines.

Comment 4

6 years ago
(In reply to Wayne Mery (:wsmwk) from comment #3)

I agree with Wayne that "make acceskeys easy to see" is probably the least important of our guidelines, given the high number of commands that we need to cover.

The good news is, if done correctly, we can solve/avoid several problems at a time with the following suggestion:

1) Unify "Open" commands in their flavors between Message Menu and Message Context Menu: The main menu is supposed to contain the complete set of commands, there is absolutely no reason why "Open In A New Tab" and "Open In A New Window" are not differentiated in the main Message Menu (on the contrary, it's much more likely somebody might use the main menu for the *non*-default opening methods).

2) Then, unify access keys between main and context message menu:
- t for opening in a _t_ab
- w for opening in a _w_indow
- probably v for opening in con_v_ersation

3) Now we have a better access key available for Copy|Move to [afolder]:
- o for C_o_py|M_o_ve to [afolder]
Thus, we'll solve both problems of this bug:
- new accesskey will never be applied to the foldername, AND
- new accesskey avoids problem letters like i, l, or g.

4) Concerning accesskeys, we are now free to remove the word "Again" from the "Copy|Move to [afolder] Again" caption (Bug 512661):
-> "C_o_py|M_o_ve to [afolder]"

Wayne, how is that? :)

Updated

6 years ago
Blocks: 586097
(Reporter)

Comment 5

6 years ago
seems to make sense. although I still have a fondness for keeping the word "again", mostly because uniqueness of function names is helpful in support situations.

Updated

6 years ago
Depends on: 512661

Comment 6

6 years ago
So maybe some other wording could work.
Like:
"_C_opy to Folder"
"_M_ove to Folder"
"C_o_py to [aFolder]"

Comment 7

6 years ago
(In reply to :aceman from comment #6)
> So maybe some other wording could work.
> Like:
> "_C_opy to Folder"
> "_M_ove to Folder"
> "C_o_py to [aFolder]"

I don't understand. Are you now talking about adding the word "Folder" to the existing "Copy To >" and "Move To >" commands? If yes, it's not exactly the topic of this bug, which is about finding a better access key for the "Copy to [lastfolder] again" command...

(In reply to Thomas D. from comment #4)
> 3) Now we have a better access key available for Copy|Move to [afolder]:
> - o for C_o_py|M_o_ve to [afolder]
> Thus, we'll solve both problems of this bug:

Of course, in 3) I am talking about the "Copy|Move to [lastfolder] again" command (as opposed to "Copy to >" and "Move to >"), and I anticipated the removal of "Again" suggested by bug 512661, which Wayne wants to keep...

Comment 8

6 years ago
(In reply to Thomas D. from comment #7)
> (In reply to :aceman from comment #6)
> > So maybe some other wording could work.
> > Like:
> > "_C_opy to Folder"
> > "_M_ove to Folder"
> > "C_o_py to [aFolder]"
> 
> I don't understand. Are you now talking about adding the word "Folder" to
> the existing "Copy To >" and "Move To >" commands? If yes, it's not exactly
> the topic of this bug, which is about finding a better access key for the
> "Copy to [lastfolder] again" command...

Yes, that is what I am proposing. It would solve removal of the "again", make the items different (for Wayne), and have good accesskeys (your point 3).

Comment 9

6 years ago
If bug 491309 is implemented, those 2 commands would need different keys.
Depends on: 491309
You need to log in before you can comment on or make changes to this bug.