998312 - Contacts sidebar: Implement Alt+Enter keyboard shortcut to edit the properties of selected AND focused contact (ux-consistency with TB address book and Windows/Linux default shortcut for "Properties")

Status: RESOLVED FIXED

(Thunderbird :: Message Compose Window, defect)

Description

[Thomas D. (:thomas8)]

+++ This bug was initially created as a clone of Bug #650745 +++

(In reply to Wayne Mery (:wsmwk) from Bug #650745 comment #9)
> I'm an avid keyboard user who will be glad to see this fixed.
> In case it hasn't been already stated, this does no harm to people
> who don't use keyboard :)
+1

STR
1 Compose message.
2 F9 to show contacts sidebar.
3 Single-left-click on one contact to select and focus that contact.
4 Press Alt+Enter with an intention of editing the properties of that contact (which works in TB AB, and is the *default shortcut for "Properties" in Windows and Linux* on all eligible objects e.g. files, folders, printers, etc.).

Actual Result
- nothing

Expected Result
- Alt+Enter should open the "Edit Contact" dialogue

Reasons in favor of implementing Alt+Enter keyboard shortcut per this bug:

1a) internal ux-consistency:  In TB's main AB, Alt+Enter on selected and focussed contact will also trigger the "Edit contact" dialogue. Contacts side bar is nothing but a miniature version of AB, so the behaviour should be as consistent as possible; unnecessary deviations violate internal ux-consistency.

1b) internal/external ux-consistency: In contacts sidebar, we already allow much more delicate "DEL" keyboard shortcut to delete selected AND focussed contacts (after confirmation), because our users rightly expect such universally recognized shortcuts to work (Bug 343973). Btw Bug 343973 got ui-r+ from bwinton at the time for essentially the same reasons laid out here, see Bug 343973 Comment 12.

2) external ux-consistency: Both for Windows and Linux, ALT+Enter is a well-known default keyboard shortcut for opening the "Properties" dialog of eligible items like files, folders, printers, etc. (and "Edit Contact" is de facto a properties dialogue; we even still have "Properties" on the context menu). Unnecessary deviations in TB violate external ux-consistency and interrupts users habitual workflows.

3) ux-efficiency: Editing/verifiying properties of a contact is a a common and likely scenario for contacts side bar. Especially for keyboard users including the disabled, just Alt+Enter from muscle memory is much more efficient than the only keyboard-only alternative: Context menu key (not found on all keyboards!), parse and navigate context menu, select "Properties".

4) ux-discovery: Alt+Enter, due to its wide-spread applicability in- and outside of TB, is easily discoverable and intuitive for keyboard users, at least on Windows and Linux ("muscle memory"). In that sense, doing something useful for a well-known and un-ambiguous keyboard shortcut is certainly better than doing nothing...


Discussion of potential problems ("What happens if...")

5) Alt+Enter keyboard shortcut is not currently used for anything else anywhere in composition; nor is it likely to be used for anything else here in the future. With a selected and focused contact, due to habit formation and internal/external ux-consistency, it can never be used for anything but "Edit Contact" as proposed here (see 1) and 2) above).

6) Alt+Enter is unlikely to be hit accidentally, because the keys are far apart and both *selection AND focus must be on the contact* for this trick to work. After this bug, hitting Alt+Enter accidentially, even multiple times, will still be completely inconsequential: 
Alt+Enter (1st time) will open the "Edit contacts" dialogue (and unaware user will probably be happy to discover that shortcut)
Alt+Enter (2nd time), or just plain Enter, will just close the "Edit contacts" dialogue again without any errors nor harm done. 

7) Users who use *Ctrl*+Enter to send their messages are not affected by this in any way; even if they accidentally hit *Alt*+Enter instead, nothing sinister will happen to them (see 6). Besides, keyboard users who are advanced enough to know and use such shortcuts are probably the same users who can tell them apart.

8) Reverse case: Users who intend to use *Alt*+Enter (habit formation from TB AB and OS environment) but accidentally hit *Ctrl*+Enter instead will get a confirmation alert "Are you sure you are ready to send this message?" (unless they have deliberately disabled confirmation, which means they are already familiar with the send shortcut hence unlikely to get it wrong); this occurs with or without the keyboard shortcut suggested here so it's a non-argument for this bug.

9) In case it hasn't been already stated, allowing your cat on your keyboard or pressing random key combinations without observing current focus is not recommended as a modus operandi for any software application - do so at your own risk, or return to ink and paper if the problem persists. The good news being, the keyboard shortcut suggested here will not do any harm even if hit accidentally (see 5)... :)

Tia on behalf of all avid keyboard users or users who depend on keyboard access.

Feedback welcome, pls comment if this sounds right to you.
(If not, please be specific and refer to each argument presented.) Thanks.

Comment 1

[Thomas D. (:thomas8)]

This bug seeks to provide a clean and neutral start for a small subset extracted from Bug 650745 which failed to take off because I didn't conform strictly enough to "one-issue per bug" and it ended up in misunderstandings and emotional cul-de-sacs which hindered objective analysis and progress. Mixing up Enter and Alt+Enter as I did in Bug 650745 was a truly bad idea for which I apologize because Enter in contacts side bar is an entirely different story, a can of worms indeed given the broken design for default action in contacts side bar (see Bug 650745 Comment 17 by :mconley). So this is a fresh start which leaves out the entire complex discussion about plain Enter and so I think it will be much easier to reach a consensus here.

Comment 2

[Thomas D. (:thomas8)]

(In reply to Thomas D. from comment #0)
> 7) Users who use *Ctrl*+Enter to send their messages are not affected by
> this in any way; even if they accidentally hit *Alt*+Enter instead, nothing
> sinister will happen to them (see 6). Besides, keyboard users who are
> advanced enough to know and use such shortcuts are probably the same users
> who can tell them apart.

Getting into "Edit Contacts" dialog (Alt+Enter) accidentally when you really wanted "Send Message" (Ctrl+Enter) is even more unlikely than described because it also requires *selection AND focus* to be on a contact in contacts side bar. So for the biggest part of composition UI, accidental Alt+Enter will still do nothing as before, and otherwise, it doesn't hurt at all even if you get it wrong, which is unlikely for the type of user we are talking about.

Comment 3

[Thomas D. (:thomas8)]

Apart from commenting, votes are also helpful - pls use (vote) link on the right of Importance field above, or the following link:
https://bugzilla.mozilla.org/page.cgi?id=voting/user.html&bug_id=998312#vote_998312

Comment 4

[Thomas D. (:thomas8)]

Wrt ux-consistency of this proposal, here's another interesting piece which fits seamlessly into the puzzle:

Ever wondered why in main address book (on Win/Linux), we offer both ALT+Enter *and* Ctrl+I to access contact's properties?

Here's the answer:

> Mac OS and Windows Keyboard Equivalents [1]
>
> Let's look at some of the common Mac vs. Windows keyboard equivalents.
>
> General Keyboard Shortcuts
>
> Function                  | MAC         | Windows            
> --------------------------+-------------+-------------
> Item's Info or Properties | Command + I | Alt + Enter

So ALT+Enter on Windows/Linux is the official equivalent of Command+I on MAC.
And as seen on [1], both of them are in the same general category of universal /swiss-knife/ one-for-all keyboard shortcuts along with e.g. plain ENTER, ESC, DEL, or Ctrl/Command+A. These general keyboard shortcuts are so powerful because they work everywhere the same way (accross the entire OS; cross-application); so keyboard users including the handicapped who depend on keyboard access remember them easily and rely on them heavily.

(As a sidenote, Ctrl+I per above and Alt+Double-Click per below would complement this proposal nicely, but let's focus (pun intended) on ALT+Enter first...).

UX-consistency reloaded:

If any further proof was needed that ALT modifier while "opening" eligible items on Windows is a *deliberate and deeply-rooted general UX design* to get to the *properties* of those items, here's more:

* UX-consistent with ALT+Enter, *ALT+Double-Click* also does the trick of opening the properties of any eligible item (hold ALT modifier while double-clicking eligible items e.g. files); cf.[2]).
* ALT modifier for opening item properties applies to a lot of different items across the OS like files, printer, network connection, "My Computer" (-> system properties), *Outlook contacts* etc.
* ALT+Enter masterkey for item properties works on all windows versions since time immemorial (already on Windows 3.11, see [3], all the way through to Windows 8, see [4]).
* Windows even anticipates that users might use Alt+Enter or Alt+Double-Click on /uneligible/ items like Control Panel's collective "Printers and Faxes" or "Network Connections" and presents the following error-message in that case: "The properties for this item are not available"...

The point being that because ALT modifier works *everyhwere* across windows and its applications to open the properties of a selected and focused item (and also in TB's main AB), TB users have all reason to expect the same universal shortcut to do the trick for contacts in contact side bar. And we already offer several siblings like DEL or Ctrl+A on the sidebar...

Users love it:

The user comments on Lifehacker's dedicated "Shortcut of the day" page featuring ALT modifier for "faster access to properties in Windows" [2] also reflect how happy users are about such shortcuts to make their daily routines easier / work more efficiently / save time. And they start to worry whenever/whereever it *doesn't* work; for anecdotal evidence, see [5].

(In reply to Thomas D. from comment #0)
> Reasons in favor of implementing Alt+Enter keyboard shortcut per this bug:
> 1a) internal ux-consistency:  In TB's main AB, Alt+Enter on selected and
> focussed contact will also trigger the "Edit contact" dialogue...
> 2) external ux-consistency: Both for Windows and Linux, ALT+Enter is a
> well-known default keyboard shortcut for opening the "Properties" dialog of
> eligible items like files, folders, printers, etc.

[1] http://www.mtholyoke.edu/lits/labs/docs/MacWinKBeq.htm
[2] http://lifehacker.com/5819914/hold-the-alt-key-while-double-clicking-for-faster-access-to-properties-in-windows
[3] http://aggedor.freeshell.org/win31key.html
[4] http://www.shortcutworld.com/en/win/Windows_8.html#link_8
[5] http://social.msdn.microsoft.com/Forums/vstudio/en-US/82e6c88d-422b-43ec-9c28-ae449c40a2b2/alt-enter-does-not-display-property-sheet-in-vs2013-ide?forum=visualstudiogeneral

Comment 5

[Thomas D. (:thomas8)]

Attachment: Patch v. 1 - Alt+Enter for properties of selected AND focused contact (as in main AB)

So let's fix it...

Hi Jim, ALT+Enter on a single, selected AND focused contact in contacts side bar should just show the "Edit Contact..." *properties* dialogue (as it does in the main AB, and anywhere else in the entire Windows and Linux universe). As you are somebody who has made great contributions wrt keyboard accessibility and focus respect (e.g. in attachments pane), would you kindly confirm with your ui-review that this is the right thing to do in terms of ux-consistency and ux-efficiency.

Comment 6

[Thomas D. (:thomas8)]

Attachment: Patch v. 1.1 - Alt+Enter for properties of selected AND focused contact (as in main AB)

Same patch with linebreaks sorted out (unix LF only)

> Hi Jim, ALT+Enter on a single, selected AND focused contact in contacts side
> bar should just show the "Edit Contact..." *properties* dialogue (as it does
> in the main AB, and anywhere else in the entire Windows and Linux universe).
> As you are somebody who has made great contributions wrt keyboard
> accessibility and focus respect (e.g. in attachments pane), would you kindly
> confirm with your ui-review that this is the right thing to do in terms of
> ux-consistency and ux-efficiency.

Comment 7

[Magnus Melin [:mkmelin]]

Comment on attachment 8654594 [details] [diff] [review]
Patch v. 1.1 - Alt+Enter for properties of selected AND focused contact (as in main AB)

Review of attachment 8654594 [details] [diff] [review]:
-----------------------------------------------------------------

::: mail/components/addrbook/content/abContactsPanel.js
@@ +39,5 @@
>  
> +function contactsListOnKeyPress(aEvent)
> +{
> +  switch (aEvent.key) {
> +    case "Enter":

while this works, it should better be

switch (aEvent.keyCode) {
  case KeyEvent.DOM_VK_RETURN:

Comment 8

[Thomas D. (:thomas8)]

(In reply to Magnus Melin from comment #7)
> Comment on attachment 8654594 [details] [diff] [review]
> Patch v. 1.1 - Alt+Enter for properties of selected AND focused contact (as
> in main AB)
> 
> Review of attachment 8654594 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: mail/components/addrbook/content/abContactsPanel.js
> @@ +39,5 @@
> >  
> > +function contactsListOnKeyPress(aEvent)
> > +{
> > +  switch (aEvent.key) {
> > +    case "Enter":
> 
> while this works, it should better be
> 
> switch (aEvent.keyCode) {
>   case KeyEvent.DOM_VK_RETURN:

Hmmm, but documentation clearly states .keyCode is deprecated and should be replaced by .key which is not only cross-platform but also makes a more natural reading, avoiding the old confusions between VK_ENTER and VK_RETURN, the former of which has been dumped. .key=="Enter" catches both the main Enter (Return) key and Enter on numeric keypad.

https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/keyCode

Comment 9

[Magnus Melin [:mkmelin]]

Ok, but please use the "VK_RETURN" constant instead of "Enter".

Comment 10

[Thomas D. (:thomas8)]

(In reply to Magnus Melin from comment #9)
> Ok, but please use the "VK_RETURN" constant instead of "Enter".

??? Hmmm, no, that doesn't work either.

As explained above, we shouldn't use .keycode because it's deprecated.
So we can't use the .keycode return values either.
DOM_VK_RETURN is a .keycode return value = 0x0D (13) = Return/enter key on the main keyboard.
(Even if it technically worked, it would be insufficient because we want to check for both enter keys.)

So we must use .key return value, which is identical for both main keyboard's Return key and numpad's Enter key. Per documentation, the correct and only .key return value for these keys is "Enter" [sic] (not 0x0D (13)), as seen in the list of return values AND the event.key Example here:

> switch (event.key) {
>    case "Enter":
>      // Do something for "enter" or "return" key press.
>      break;

https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/key#Key_values
https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/key#Example

I conclude that current patch code does exactly what it should and is technically correct per current documentation. So think it's right as it is.

Comment 11

[Magnus Melin [:mkmelin]]

Ok. Strange though that there's not a single other usage of that in the codebase.

Comment 12

[Thomas D. (:thomas8)]

Comment on attachment 8654594 [details] [diff] [review]
Patch v. 1.1 - Alt+Enter for properties of selected AND focused contact (as in main AB)

This has undergone painstaking ui-review in my comment 0, beyond which there's certainly nothing to add or subtract. ui-r=ThomasD

Comment 13

[Thomas D. (:thomas8)]

(In reply to Magnus Melin from comment #11)
> Ok. Strange though that there's not a single other usage of that in the
> codebase.

Probably because:
- .key implementation is recent wip both on W3C and Gecko side, most recent changes require Gecko 37 (although "Enter" is not one of them). Iow, consumers simply haven't updated to .key instead of .keycode yet.
- "Enter" does not usually require special handling at all because it's the default action
- Modifier+Enter, more so ALT+Enter has very limited scenarios where it can apply (the only wide-spread uses of Alt+Enter I'm aware of are Properties, or Page Break in word processing applications)
- In XUL, Modifier+Enter will usually be handled by <key...> which also doesn't require .keycode or .key. Contacts side bar is exceptional because it's an extra scope apart from the main editor, so we hand-crafted this using onkeypress event in contacts side bar, which looks like a safe thing to do.

Comment 14

[aleth [:aleth]]

https://hg.mozilla.org/comm-central/rev/14ee2aab83e72f9170da008f23324b357b71e4f3
Bug 998312 - Contacts sidebar: Alt+Enter keyboard shortcut for properties of selected AND focused contact. r=mkmelin

Comment 15

[Thomas D. (:thomas8)]

Thanks everyone. Wow. Sanity prevailed. TB just got better in a small everyday detail. Simple and straightforward, more efficiency, no side effects. Love it. Keyboard users will appreciate this. And we're even helping with discovery, by advertising the shortcut on the context menu.

Comment 17

[Thomas D. (:thomas8)]

I improved the implementation of this in bug 1322032, now using <key>.

https://hg.mozilla.org/comm-central/diff/8f2f953f2ed3/mail/components/addrbook/content/abContactsPanel.xul#l1.49

+  <keyset id="keyset_abContactsPanel">
+    <!-- This key (key_delete) does not trigger any command, but it is used
+         only to show the hotkey on the corresponding menuitem. -->
+    <key id="key_delete" keycode="VK_DELETE"/>
+#ifdef XP_MACOSX
+    <key id="key_properties" modifiers="accel" key="&propertiesCmd.key;" command="cmd_properties"/>
+#else
+    <key id="key_properties" modifiers="alt" keycode="VK_RETURN" command="cmd_properties"/>            <!--Alt+Enter-->
+    <key id="key_properties2" modifiers="accel" key="&propertiesCmd.key;" command="cmd_properties"/>
+#endif
+  </keyset>