Open Bug 1383627 Opened 2 years ago Updated 2 years ago
Display keyboard shortcuts in tooltip
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0 Build ID: 20170713134507 Steps to reproduce: Example: Hover with the mouse over the archive button Actual results: It shows the text "Archive this message" Expected results: It should show the text "Archive this message (press A on your keyboard)" or equivalent to help the user learn and remember important keyboard shortcuts. Attached screenshot to give context.
I don't think we want to advertise the keyboard shortcuts in the tooltips since that would cause an unwanted dependency between those strings. When changing a shortcut, we'd also have to change the tooltip. For me this is a WONTFIX. Richard?
Severity: normal → enhancement
Summary: Display keyboard shortcuts in mouse-over help bubble → Display keyboard shortcuts in tooltip
> When changing a shortcut, we'd also have to change the tooltip. How often do the shortcuts change?
We reshuffle them if there is a conflict. The tooltip is really only to explain the icon, not give a full-blown summary of everything you need to know ;-)
Fair point, Jorg. :-) Let's wait for Richard to comment.
We can leave it as an enhancement. We have already the shortcuts in the menus, but add this to the tooltip could help to learn them. I checked Outlook (eek) and it has the shortcuts in the button tooltips. I'm okay with this bug as an enhancement request, but with our limited developer resources you need to have patience until this will be fixed.
I want to help changing the tooltip text to include the keyboard shortcuts. How can I contribute?
I'm not a friend of this idea. - We'd have to visit a lot of strings causing all of them to be re-translated since we'd have give all these strings new IDs. We'd have to check that those string IDs are not referenced in JS or C++ code. - We need to get this right in one go, otherwise we get bugs "Shortcut key of command XX not shown in tooltip". - We create the unwanted dependency between tooltip and shortcut key. - And we'd need to answer this question upfront: If we ever change a shortcut key that shows up in a tooltip, do we have to change the string ID of the tooltip? Currently we can change shortcut/accelerator keys without changing string IDs. I think it's a lot of pain for little gain. IMHO there are users who prefer to click and those who prefer to use the keyboard. For the first class, it makes no sense to show the keyboard shortcut in the tooltip, and the users in the second class are already using the keyboard shortcut and will not hover the icon to see the tooltip. That said, after decades of using Firefox, I've just hovered the download manager icon, the little down-arrow, and lo and behold, it says "(Ctrl+J)" at the end. I've never seen this before. (In reply to Robert Orzanna from comment #6) > How can I contribute? Build Thunderbird and attach a patch: https://wiki.mozilla.org/Thunderbird:Home#Contributing https://wiki.mozilla.org/Thunderbird/Contributing_patches
Jorg, I agree with you. If it indeed involves that much complexity and added work, the limited development time should not be spend on this minor enhancement. I believe that's up to you to decide eventually...
Then it's best to close it.
Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX
There is a core Bug 53309, which leads to Bug 341656 - Tie shortcuts, tooltips, etc. together for UI automation purposes - which could accomplish without imposing string translation complexity. So going out on a limb here and reopening.
As Thunderbird's master of keyboard shortcuts ;), I'm amazed, to say the least, how a great idea of improving our UX almost ended up in the dustbin for all the wrong reasons if it wasn't for Wayne to pay attention. So let's get this straight. TL;DR: Keyboard shortcuts in tooltips are an excellent way of promoting their UX-discovery. M$ Word as world's largest word processor has had them forever. TB needs this more than FF because we have more commands. Ways of making keyboard shortcuts discoverable are limited, more so as our main menu, only in-app reference of shortcuts, is hidden. ------- (In reply to Jorg K (GMT+2) from comment #7) > - We'd have to visit a lot of strings causing all of them to be re-translated > since we'd have give all these strings new IDs. > - We create the unwanted dependency between tooltip and shortcut key. Hell NO! I'm not sure how anyone could even think of hard-coding keyboard shortcuts into tooltips. As Jörg correctly points out, that implementation would be 100% wontfix because it's not maintainable. Obviously, this must and can be implemented *without* re-translating even a single tooltip, and hence *without* creating any dependency between the tooltip and the shortcut key. UI automization is the magic word. So we shouldn't dump the idea based on a wrong model of implementation! In fact, in our current XUL structures, I imagine that this might be relatively straight-forward for a talented programmer like Jörg, by exploiting the existing connections between tooltips and shortcuts. <button command="cmd_foo" tooltip="foo-tip"> <command id="cmd_foo" key="key_foo"> <key command="cmd_foo" key="O" modifiers="Shift"> All of these have the command name as a common attribute. So using that attribute, I believe it must be possible to have iteration code which for any given element with tooltip, via its command attribute, and the key attribute of the respective command, gets at the shortcut key from the <key> and manipulates the DOM tree to programmatically append the shortcut key to the tooltip... So for a large number of commands, we're probably covered after suffering just once to get the iteration code right and efficient. Special cases need special attention; my guess is that where this doesn't work because we're not using that XUL system, our code layout is probably wrong. See e.g. Bug 1322032 where I converted a non-standard implementation of shortcut keys into the XUL standard implementation (Ctrl+Enter, Ctrl+I for cmd_properties). > I think it's a lot of pain for little gain. So now that we've massively reduced the pain, let's look at the gain. > IMHO there are users who prefer > to click and those who prefer to use the keyboard. Maybe, but still that's too simplistic. The truth is, most of us will never know *all* the shortcuts, and there aren't shortcuts for everything, so even keyboard-affined users are de facto using keyboard and mouse. Plus there's a learning curve of gradual conversion from one type to the other... > For the first class [prefers mouse], it > makes no sense to show the keyboard shortcut in the tooltip Huh??? How would a mouse user ever learn about a shortcut if not when he's using his mouse? We're not born as keyboard users; we learn over time. UX-discoverability is key... And as others have commented, given that the main menu is the only place in TB to discover keyboard shortcuts, but *hidden* by default, on wonders where users should ever learn about keyboard shortcuts if not on tooltips and (possibly) context menus (keyboard on context menus would be helpful, but should be optional). > and the users in the second class are already using the keyboard shortcut > and will not hover the icon to see the tooltip. Huh??? You're not really saying that a keyboard-preferring user must know all the shortcuts all the time, starting right after installing our software? There's a learning curve here, isn't it? We pick up shortcuts gradually and as needed for our personal workflows. Frequent workflows with lots of or complicated clicks first. After editing 100 contacts from contacts side bar, you might find that having a keyboard shortcut for that would just come in handy (Bug 998312), to save a couple of delicate and error-prone clicks every time. If you're never touching your contacts or have few, or maybe aren't currently using contacts side bar, you won't learn that shortcut. Until that day when you discover that contacts side bar might actually make your workflows easier, and allow you to fix contacts while composing... So again, UX-discoverability is key! Having the keyboard shortcut in the tooltip is an *offer* to the mouse user that look, there's a more efficient way of doing this when you're ready for that. And it's pretty ideal in terms of ux-discoverability, to get that education exactly when you click around. > That said, after decades of using Firefox, I've just hovered the download > manager icon, the little down-arrow, and lo and behold, it says "(Ctrl+J)" > at the end. I've never seen this before. So you've just discovered a keyboard shortcut from a tooltip! :p And it's not the only one (try hovering bookmark buttons, new tab button) ... Jokes aside, that's exactly how it should work. You've never seen this before but one day you'll see it. Firefox UI is a bad example because their ux-minimalism has reduced the UI to bare bones, and web browsers don't have a lot of functions requiring keyboard shortcuts anyway, because most of the action happens on the content, not the UI. In comparison, Thunderbird has a lot more commands which are regularly used (e.g. new message, reply, forward, archive etc.). I'm still surprised that the concept of keyboard shortcuts in tooltips is presented here as if it was something alien or unusual. The world's most popular Word processor, M$ Word (95% market share as of 2000 according to Wikipedia), has had shortcut keys on tooltips forever! (Although I must admit I'm not sure if they're activated by default, I think they weren't in earlier versions, but are now). And tooltips have been radically changed and expanded in later versions of Word (I'm on 2010), but the keyboard shortcuts are still there, so that's certainly intentional because it's sound and proven for UX-discovery. > (In reply to Robert Orzanna from comment #6) > > How can I contribute? > Build Thunderbird and attach a patch: > https://wiki.mozilla.org/Thunderbird:Home#Contributing > https://wiki.mozilla.org/Thunderbird/Contributing_patches I think Robert wanted to assist on translations, which unfortunately is the wrong implementation... No offense meant, but I'm still worried and somewhat speechless about the casual style in which we arrive at significant UX decisions...
(In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #11) > TL;DR: Keyboard shortcuts in tooltips are an excellent way of promoting > their UX-discovery. M$ Word as world's largest word processor has had them > forever. TB needs this more than FF because we have more commands. Ways of > making keyboard shortcuts discoverable are limited, more so as our main > menu, only in-app reference of shortcuts, is hidden. In the excitement of the moment (sorry for somewhat lengthy comment 11), I forgot the main point in TL;DR: Implementation of this feature does *not* require hardcoding keyboard shortcuts in tooltips, so there'll be no unmaintainable dependency between tooltips and shortcut keys (which was correctly considered wontfix). Instead, we need to extract shortcut keys in an automated fashion and append them to tooltips at runtime, e.g. using common denominator cmd_name to link from a given UI element, via the <command>, to the <key>.
More thoughts on automated implementation Another way of doing this (Jörg knows this much better than me) might be this: Have a general listener for mouse-over event. If we hover an UI element with tooltip, go back the command chain of that single element as I explained in comment 10 (element -> associated command -> associated key), and dynamically append the shortcut to the tooltip before it gets shown. This approach looks more efficient, because we'll only do one element at a time exactly when needed. Also safer/more correct than doing all tooltips beforehand, because they can be changed by addons.
Thank you, Thomas! Appreciate your openness. Cannot really add anything to the technical discussion. Just wanted to mentioned that I worked around the issue to help myself remember: http://i.imgur.com/9jeSiOO.png
The button that takes you to the download manager says: Display the progress of ongoing downloads (Ctrl+J) https://dxr.mozilla.org/mozilla-central/rev/52285ea5e54c73d3ed824544cef2ee3f195f05e6/browser/base/content/browser.xul#1053 <toolbarbutton id="downloads-button" ... tooltip="dynamic-shortcut-tooltip"/> There seem to be some smarts here to do the dynamic tooltip: https://dxr.mozilla.org/mozilla-central/rev/52285ea5e54c73d3ed824544cef2ee3f195f05e6/browser/base/content/browser.js#5706 And in the end, all the tooltips have a %S that inserts the shortcut, like: https://dxr.mozilla.org/mozilla-central/rev/52285ea5e54c73d3ed824544cef2ee3f195f05e6/browser/locales/en-US/chrome/browser/browser.properties#426 # Downloads button tooltip # LOCALIZATION NOTE (downloads.tooltip): # %S is the keyboard shortcut for "Downloads" downloads.tooltip=Display the progress of ongoing downloads (%S) We could follow that scheme in TB. P.S.: I hope the project has other talented developers than myself since I'm stretched to the limit with other tasks.
(In reply to Robert Orzanna from comment #14) > http://i.imgur.com/9jeSiOO.png Please remember that the behaviour of Ctrl+R has changed under some circumstances when replying to a mailing list post.
You need to log in before you can comment on or make changes to this bug.