759053 - [en] Change access key of Toolkit's "Don't Save" button from "D" to "N" for "Save changes?" type confirmation dialogue (ux-errorprevention on QWERTY keyboards)

Status: RESOLVED FIXED

(Toolkit :: UI Widgets, defect)

Description

[Thomas D. (:thomas8)]

+++ This bug was initially created as a clone of Bug #582949 +++
(In reply to Phil Lacy from comment #0)
> Not only is 's' and 'd' physically close on the keyboard...
(In reply to Bryan Clark [:clarkbw] from comment #2)
> if there is a suggestion to improve the keyboard shortcut used
> such that they aren't close to each other we could look into improving that.

STR

1 compose, type some words
2 close composition window

Actual

"Save message" confirmation dialogue with these buttons:
[_S_ave] [_D_on't save]
That's error prone because access keys S and D for "save" vs "don't save" are right next to each other on the keyboard, so it's easy for EN localizations to hit the wrong one.

Expected

[_S_ave] [Don_n_'t save]
+ That's less error-prone because access keys for opposite actions are no
  longer close to each other.
+ It's still memorable for EN: n = no
- It's a little less comfortable, but still possible as a one-handed shortcut.

Comment 1

[Thomas D. (:thomas8)]

Attachment: Request ui-review for safer access keys S and N for "Save" vs. "Don't save"

Blake, a tiny tweak for your ui-review. Affects only/mostly EN localization.
It was requested in bug 582949 and encouraged by Bryan (see comment 0 here).
I guess it's better in terms of ux-errorprevention, so we could do this in spite of minor drawbacks. Otherwise, no strong feelings about this.

Comment 2

[Thomas D. (:thomas8)]

Comment on attachment 627641 [details]
Request ui-review for safer access keys S and N for "Save" vs. "Don't save"

(In reply to Thomas D. from comment #1)
> Created attachment 627641 [details]
> Request ui-review for safer access keys S and N for "Save" vs. "Don't save"
> 
> Blake, a tiny tweak for your ui-review. Affects only/mostly EN localization.
> It was requested in bug 582949 and encouraged by Bryan (see comment 0 here).
> I guess it's better in terms of ux-errorprevention, so we could do this in
> spite of minor drawbacks. Otherwise, no strong feelings about this.

Comment 3

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

Comment on attachment 627641 [details]
Request ui-review for safer access keys S and N for "Save" vs. "Don't save"

Yeah, I'm not strongly for this change, but sure, I could accept it.

Maybe to ease the pain of transition, use both "N" and "D" for a release?

Comment 4

[Thomas D. (:thomas8)]

(In reply to Blake Winton (:bwinton - Thunderbird UX) from comment #3)
> Comment on attachment 627641 [details]
> Request ui-review for safer access keys S and N for "Save" vs. "Don't save"
> 
> Yeah, I'm not strongly for this change, but sure, I could accept it.

Me neither, but I think the dataloss argument in case of error weighs a bit more.

> Maybe to ease the pain of transition, use both "N" and "D" for a release?

I don't think that would ease the pain, because
- those with muscle memory for "N" will stick with "N" during transition, so it's just postponing the "pain"
- two access keys are a bit unusual (is it even technically possible?)

But I don't think it'll be very painful:
- imo not many users affected (even as a keyboard user, I click on such things if it's not immediately obvious what Enter or ESC will do)
- rare scenario: why or how often would you make changes to your composition and *not* save them?

So if we change it, which I think is reasonable, let's just change it.

Comment 5

[Thomas D. (:thomas8)]

Is this the place to change it?
http://mxr.mozilla.org/comm-central/source/mozilla/toolkit/locales/en-US/chrome/global/commonDialogs.properties#18

Comment 6

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

Since that's in mozilla/toolkit, I strongly suspect that's _not_ the right place to change it.  Unless you want to make the change for Firefox and SeaMonkey, too…

Comment 7

[Ian Neal]

It seems like it is done from here:
http://mxr.mozilla.org/comm-central/source/mail/components/compose/content/MsgComposeCommands.js#3375
so should be able to pass arguments that include the replacement button string, e.g.
http://mxr.mozilla.org/comm-central/source/mail/components/compose/content/MsgComposeCommands.js#2643

Comment 8

[:aceman]

So it would need to not use the standard button of "Don't save" but use a new string with a new accesskey. That's not great either.
Does Seamonkey want this?

Comment 9

[Ian Neal]

(In reply to :aceman from comment #8)
> So it would need to not use the standard button of "Don't save" but use a
> new string with a new accesskey. That's not great either.
If Firefox is okay with the change as well as SeaMonkey, then can do it within toolkit...

> Does Seamonkey want this?
I think it is something that SeaMonkey would want, best person to check with, as it is across the whole of SeaMonkey suite, is Neil (cc'd).

Comment 10

[:aceman]

Can we CC somebody from toolkit? However if changing such an accesskey app-wide it may need to go through all the dialogs where it appears an check if it does not collide with other buttons in any of them.

Comment 11

[[e-mail]]

(In reply to aceman from comment #8)
> Does Seamonkey want this?
Not a new string, no, but feel free to persuade Toolkit to change it.

Comment 12

[:aceman]

If I searched mxr correctly there are not many uses of this button. I've seen about 2 in Firefox and some in mail.

Comment 13

[:aceman]

Attachment: patch

I went through other users of this button and couldn't spot any collisions. Most of the time it was: _S_ave, Cancel, Do_n_'t save.

I don't know why Cancel does not have accesskey, but that would be a different bug.

Comment 14

[[e-mail]]

(In reply to aceman from comment #13)
> I don't know why Cancel does not have accesskey
ESC suffices.

Comment 15

[:Gavin Sharp [email: [e-mail]]]

(In reply to [e-mail] from comment #11)
> Not a new string, no, but feel free to persuade Toolkit to change it.

You're a toolkit peer, and I don't think there are any other toolkit peers better suited to make the call.

Comment 16

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/9ab3ac95813f

Sorry for the delay...

Comment 17

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/9ab3ac95813f

Comment 18

[Brian Jamison]

I was quite surprised to see this change pop up in a recent update.  While I (barely) see the potential UI issue with fat fingering en users, may I request a little more public discussion on keyboard shortcut changes?  My issues with this change:

1) This breaks a keyboard standard that's been in place for years in TB and decades in other apps (Libreoffice, for example)

2) The 'n' key requires two hands to execute, whereas the industry standard 'd' is one hand.  If you process a lot of emails like I do, having to take your other hand off the mouse or move your hand to hit 'n' is bothersome.  If a change really is called for, a more logical move IMO would be to keep 'd' for Don't save and move the 's' in Save to 'v', since 'd' is the default action.  This keeps it a one-handed action and preserves the default.

3) Because something /can/ be done better is not necessarily an argument for changing it.  Sometimes standards and accepted behaviors are much more important.  QWERTY keyboards, for example.

I'd wager that an actual discussion or a poll on this among your users would overwhelmingly come down on the side of keeping the 'd' key.  Please consider reverting this or implementing 'v.'  And thank you for a terrific project.

Comment 19

[Phil Lacy]

Clark probably has statistics on TB users that shine a light on the norm for that group and is fine with me but surely deleting the message isn't  the default. If i ht enter for default on a whim i don't want permanent unfixable surprises.

Comment 20

[Thomas D. (:thomas8)]

Can someone explain to me why this patch which landed in toolkit 2012 is not seen in current release version of TB (45.4.0, 20160928132736), where we still have "&Don't Save"? Are we overriding this somehow, or have we been late adopters of toolkit changes? Note that contrary to TB release, both TB Trunk and Toolkit correctly have "Do&n't Save".

https://dxr.mozilla.org/mozilla-central/search?q=dontsave%3D&redirect=false
https://dxr.mozilla.org/comm-central/search?q=dontsave%3D&redirect=false
https://dxr.mozilla.org/comm-central/source/mozilla/toolkit/locales/en-US/chrome/global/commonDialogs.properties#18
> DontSave=Do&n’t Save

Comment 22

[Thomas D. (:thomas8)]

Not only is this required per ux-error-prevention to avoid dataloss for keyboard layouts like QWERTZ or QWERTY, but also strongly supported per ux-consistency with the OS default on Windows and many Windows apps including Outlook.

From duplicate bug 633897, comment 5 (by myself):

"N" for "Do&n't Save" is default access key 
- on native Windows applications like Notepad, Paint, Write etc.
- on MS Office: Word 2010: &Save, Do&n't Save, Cancel. Notably also Outlook 2010: &Yes, &No, Cancel.
- non MS apps: e.g. GVim, Notepad++ (probably using the default yes-no-cancel dialogue)

Somewhat orthogonal, Open Office has "Discard" button which doesn't have "N", so it's "D" there.

Comment 23

[Thomas D. (:thomas8)]

(In reply to Brian Jamison from comment #18)
> I was quite surprised to see this change pop up in a recent update.  While I
> (barely) see the potential UI issue with fat fingering en users, may I
> request a little more public discussion on keyboard shortcut changes?  My
> issues with this change:
> 
> 1) This breaks a keyboard standard that's been in place for years in TB and
> decades in other apps (Libreoffice, for example)

UX-errorprevention, avoiding accidental dataloss in this case, clearly trumps tradition.
Access keys are more prone to change than shortcut keys, and they don't come with guarantees although we try to avoid changes. After this bug, if you continue to use "D", nothing will happen, so it's a safe change.
LibreOffice aka Open Office has "Discard" button which obviously can't have "N" as access key, so that's true but somewhat orthogonal.
The default access key for "Don't Save" for Windows and Windows apps is clearly "N", see list of apps in comment 22. Including MS Outlook which has "&Yes, &No, Cancel". It's more important to match these than Open Office.

> 2) The 'n' key requires two hands to execute, whereas the industry standard
> 'd' is one hand.  If you process a lot of emails like I do, having to take
> your other hand off the mouse or move your hand to hit 'n' is bothersome. 

Not true. Access key "N" does NOT require two hands, because
a) second-level access keys (inside menus or simple dialogues) work without ALT key, so you can just press "N" only with left Index Finger. With a bit of stretching, you can even maintain left hand default position on the keyboard.
b) even ALT+N would still be doable with one hand (left hand only): Baby finger + Index Finger or Thumb + Index Finger. If that's inconvenient, just use a), i.e. press "N" only with Index Finger.

> If a change really is called for, a more logical move IMO would be to keep
> 'd' for Don't save and move the 's' in Save to 'v', since 'd' is the default
> action.  This keeps it a one-handed action and preserves the default.

"V" for "Save" is not intuitive and violating standards when we can just have intuitive "S" from the beginning of the main action word.
"Don't Save" is definitely NOT the default action.
"D" is NOT the Windows default access key for "Don't Save" or "No" in this type of "Save Changes?" dialogues.
And if you think about it, in spite of being the first letter, "D" for "Don't Save" is not even very intuitive because between "Do" and "not", it's clearly the "NOT" which logically holds the intention.

> 3) Because something /can/ be done better is not necessarily an argument for
> changing it.  Sometimes standards and accepted behaviors are much more
> important.  QWERTY keyboards, for example.

In this case, "N" is better AND safer (more standards-conform, less error-prone), so there are strong arguments of ux-errorprevention and ux-consistency for the change as implemented by this bug, specifically on QWERTY keyboards.

> I'd wager that an actual discussion or a poll on this among your users would
> overwhelmingly come down on the side of keeping the 'd' key.  Please
> consider reverting this or implementing 'v.'

Discussion always welcome, polls are tricky (usually NOT the best way of solving UX problems), and in this case, the decision taken after careful consideration is required and supported by important ux principles, so after that there's nothing much to discuss or vote about.

> And thank you for a terrific project.
Thank you for the appreciation!

Comment 24

[:aceman]

I see the accesskey 'n' being used in TB trunk.