1683223 - Implement keyboard shortcuts offering quick access to primary addressing fields

Status: RESOLVED WORKSFORME

(Thunderbird :: Message Compose Window, enhancement)

Description

[Alessandro Castellani [:aleca]]

The new compose window already brings some great usability and accessibility improvements to the whole writing experience, but there are some areas that need more improvements.

Bug 1616514, highlights the necessity for some users to make the extra addressing fields easier to reach, activate, and interact with without the necessity of using a mouse.

I think we can find an easily discoverable and elegant solution to boost the keyboard usability of the whole area, and mitigate user's frustration without adding extra prefs.

CTRL+ALT+"key" for the main fields
The CTRL+ALT combination seems agnostic enough to not interfere with any preexisting or OS specific shortcuts.
It also feels kind of like a natural progression of our implemented paradigms, as we have CTRL+key for actions like save and send, and ALT+key for the access keys in the menu items.

Here's a possible mapping proposal:

• CTRL+ALT+I: Focus on the From field.
• CTRL+ALT+T: Move cursor on the To field.
• CTRL+ALT+C: Move cursor on the Cc field, and open it if closed.
• CTRL+ALT+B: Move cursor on the Bcc field, and open it if closed.
• CTRL+ALT+R: Move cursor on the Reply To field, and open it if closed.
• CTRL+ALT+E: Open the extra recipients popup panel and focus on the first item.
• CTRL+ALT+S: Move cursor on the Subject field.
• CTRL+ALT+M: Move cursor on the Message Body.

These shortcuts can be added as tooltips to each of the clickable elements we have in the dialog, making them easily discoverable after a few uses.

Thoughts?

Comment 1

[Magnus Melin [:mkmelin]]

I'm not too thrilled about it. In general moving around with tab is enough IMHO. Finding some solution to opening a field not visible is a different issue.

I also think Ctrl+Alt+things are often OS reserved, or used by various third party key automation tools.

Comment 2

[Thomas D. (:thomas8)]

Attachment: Screenshot 1: Windows 10 enforces Ctrl+Alt+[key] for customized application shortcut keys

(In reply to Alessandro Castellani (:aleca) from comment #0)

TL;DR:

• The current proposal conflicts with Ctrl+Alt+[key] which Windows enforces for customized application shortcut keys; hijacking that is a no-go imho.

• If we want to be competitive, I think we should make it easy for users of other wide-spread systems (like gmail webmail) to migrate - see my existing bug 1667692 which covers a high-relevance subset of this bug:

  Bug 1667692 - Explore implementing keyboard shortcuts to show and focus important address rows (To, CC, BCC): Ctrl+Shift+T, Ctrl+Shift+C, Ctrl+Shift+B (like gmail)

The new compose window already brings some great usability and accessibility improvements to the whole writing experience

Indeed! Good job!!!

Bug 1616514 highlights the necessity for some users to make the extra addressing fields easier to reach, activate, and interact with without the necessity of using a mouse.

Yes. If the amount of user feedback on different channels is anything to go by, it looks like a significant number of users with that type of request, especially, but not only, enterprise users.

In fact, while dedicated keyboard access (as proposed here and in Bug 1667692) would certainly mitigate the issue, it's still an extra step for a highly frequent scenario, whereas many users have requested a customizable setting which eliminates that needless step for good.

I think we can find an easily discoverable and elegant solution to boost the keyboard usability of the whole area, and mitigate user's frustration without adding extra prefs.

Thank you very much Alex for looking into ways of boosting keyboard usability! This is crucial. As user stories around Bug 1616514 have shown beyond doubt, ux-efficiency matters (especially to enterprise users), and keyboard efficiency is an important part of that. Dedicated keyboard shortcuts (as opposed to just tabbing around) provide the highest degree of keyboard efficiency for repetitive workflows.
Imho ux-efficiency including keyboard efficiency are part of the brand core of Thunderbird - so far typically you don't get that from web mailers (although they are catching up).

Your proposal:
(+) I like your systematic, unifying, intuitive and energetic approach.
(-) However, the devil in the detail unfortunately spoils the fun. Also note the above considerations about matching the gmail shortcuts.

CTRL+ALT+"key" for the main fields
The CTRL+ALT combination seems agnostic enough to not interfere with any preexisting or OS specific shortcuts.

(In reply to Magnus Melin [:mkmelin] from comment #1)

I also think Ctrl+Alt+things are often OS reserved, or used by various third party key automation tools.

Magnus is right: As seen in the attached screenshot, Windows 10 enforces Ctrl+Alt+[key] for customized application shortcut keys (from time immemorial). In view of that, hijacking lots of potential application shortcut keys does not look like a good idea to me (which unfortunately makes the entire current proposal a no-go imho).

It also feels kind of like a natural progression of our implemented paradigms, as we have CTRL+key for actions like save and send, and ALT+key for the access keys in the menu items.

We need to figure out a consistent way forward between the traditional OS access keys on Windows (Alt+key) and the new web-style access key implementation which defaults to Alt+Shift+key.

Access keys vs. Shortcut keys

While the conceptual difference between shortcut keys and access keys might be subtle, please note:

• The classic notion of access keys is just that: providing direct access to (visible) UI elements.
• Whereas shortcut keys are more action oriented and not necessarily tied to primary UI elements, i.e. they can also provide shortcuts to covert actions.
• More importantly, access keys are localizable (as they are linked to localized UI captions).
• Whereas our shortcut keys are international (which may or may not be an advantage depending on perspective; other applications like MS Office also have some localized shortcut keys).

Here's a possible mapping proposal:

• CTRL+ALT+I: Focus on the From field.
• CTRL+ALT+T: Move cursor on the To field.
• CTRL+ALT+C: Move cursor on the Cc field, and open it if closed.
• CTRL+ALT+B: Move cursor on the Bcc field, and open it if closed.
• CTRL+ALT+R: Move cursor on the Reply To field, and open it if closed.
• CTRL+ALT+E: Open the extra recipients popup panel and focus on the first item.
• CTRL+ALT+S: Move cursor on the Subject field.
• CTRL+ALT+M: Move cursor on the Message Body.

These shortcuts can be added as tooltips to each of the clickable elements we have in the dialog, making them easily discoverable after a few uses.

This would be pretty nice if it wasn't for the big BUT... :-/

Comment 3

[Alessandro Castellani [:aleca]]

(In reply to Magnus Melin [:mkmelin] from comment #1)

I'm not too thrilled about it. In general moving around with tab is enough IMHO. Finding some solution to opening a field not visible is a different issue.

The TAB focus is definitely a great implementation but is not the perfect solution.
I think we should definitely implement shortcuts to give quick access to important areas of every section, without exclusively relying on the TAB focus, which works well in a list context but is not an optimal solution when outside of a linear interaction pattern.

I also think Ctrl+Alt+things are often OS reserved, or used by various third party key automation tools.

True, and they seem to be also primarily used on Windows.
What about a Ctrl+Shift+... combination like proposed by Thomas in bug 1667692?

(In reply to Thomas D. [:thomas8] from comment #2)

Whereas our shortcut keys are international (which may or may not be an advantage depending on perspective; other applications like MS Office also have some localized shortcut keys).

That's where we should use this bug to prototype a localized (and maybe even customizable?) shortcut implementation.
Something similar to what I did in bug 1675721, which doesn't use a <key> element but a standard event listener with a localized key.

Comment 4

[Thomas D. (:thomas8)]

Anything left to do here after my bug 1667692?

Most shortcuts and access keys are all taken... Perhaps with the most important fields now easily accessible (Ctrl/Cmd+Shift+T/C/B for To/CC/BCC), we shouldn't volunteer for the squaring of the circle...

Comment 5

[Alessandro Castellani [:aleca]]

I think we're pretty good with this, we can close it.