Hover states for PiP playback controls
Categories
(Toolkit :: Picture-in-Picture, task, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox105 | --- | fixed |
People
(Reporter: asafko, Assigned: janvi01)
References
(Blocks 1 open bug)
Details
Attachments
(9 files)
close hover.png
User Story
As a user, I want to know that PiP playback controls are clickable with a mouse and what keyword shortcuts I can use instead of clicking them.
Acceptance Criteria
- Hover states are displayed upon hovering over the currently available controls in PiP.
- Hover state text includes a brief description of the control action.
Close button
macOS: Close (⌘W)
Windows and Linux: Close (Ctrl+W) - made the change here since Linux/Windows have different shortcuts display standards.
Video Play / Pause button
Pause (Spacebar)
Play (Spacebar)
The hover state changes according to the button state.
Subtitles button
Subtitles
Volume on/ off
macOS
Mute (⌘↓)
Unmute (⌘↑)
Windows and Linux
Mute (Ctrl+↓)
Unmute (Ctrl+↑) - made the change here since Linux/Windows have different shortcuts display standards.
UnPiP button
Back to tab
This is just a reminder for the future PiP controls hover states
Fullscreen
Fullscreen (double click)
Seek forward
Forward (→)
Seek backward
Backward (←)
|
||
Updated•2 years ago
|
|
Assignee | |
Comment 3•2 years ago
|
||
Hi team,
Quick summary of my thoughts after reviewing the comments and a few more sources:
-
System (macOS) conventions and our internal guidelines for menu items suggest using capitalized letters in shortcuts.
I think it's appropriate in the menus, however, with PiP we are not dealing with a menu and shortcuts in the exact same way. -
When we use hover states with shortcuts in Firefox, we go for sentence case, no pluses, and parentheses, e.g. "Display the progress of ongoing downloads (⌘J)"
-
System macOS applications use the following convention for hover states (a combination of sentence case, capitalized letters in shortcuts, and - as a separator instead of parentheses), e.g. "Play full screen - ↑⌘F"
I'm going to need info Jules on this, but I feel there's a strong case to either:
- Use sentence case and treat text in hover states as one sentence, e.g.: "Mute (ctrl↓)" - only the first letter is capitalized:
Mute (ctrl↓)
Unmute (⌘↑)
Forward (→)
Fullscreen (double-click)
Play (space bar)
or
- Use sentence case and treat the shortcut part as a sentence separate from the description of the button:
Mute (Ctrl↓)
Unmute (⌘↑)
Forward (→)
Fullscreen (Double-click)
Play (Space bar)
Please see attached files for mentioned Firefox and macOS system examples.
|
||
Comment 10•2 years ago
|
||
Hey Ania,
Thanks for sharing your research and proposed approaches.
I did some research on guidelines around displaying keyboard shortcuts that may inform you on making a decision here.
I ran into a pretty good argument around capitalization:
"...the letter key in the shortcut (if there is a letter) is always presented as a capital, even when the Shift key isn’t used... When entering a keyboard shortcut, you’re not typing a letter, you’re pressing a set of physical keys on the keyboard in front of you. The symbols on the letter keys are capitals, so that’s the appropriate way to identify those keys."
https://leancrew.com/all-this/2017/11/modifier-key-order/
I also figured out why modifier keys (e.g. Control, Command, Shift, Win) are capitalized. Modifiers have a specific role, and are different from other keys, so it makes sense they're treated as a proper noun. This Wikipedia article https://en.wikipedia.org/wiki/Modifier_key (although not a reliable source, this article does a good job summarizing and listing common modifiers) lists common modifiers.
With all of that in mind, I would:
- Leave single letters capitalized
- Capitalize only modifier keys
- Like the rest of Firefox, continue using parenthesis instead of a "-" (when I saw the screenshot that had "Play - Space Bar" I myself was really confused as to what those words meant all together due to them all being capitalized and only divided up by the separator)
This would produce the following:
Mute (Ctrl↓)
Unmute (⌘↑)
Forward (→)
Fullscreen (double-click)
Play (space bar)
|
|
||
Comment 11•2 years ago
|
||
I have some more feedback - I hope it's not too late!
I would capitalize any time a key's proper name is used. Example: Tab, Page Up, Enter, Escape, F1, etc. I know I recommended capitalizing modifiers, but it dawned on me that these too are all unique keys.
Whenever a key is described in plain text (tabulator key, down arrow key) I wouldn't capitalize it anymore since it is no longer their proper name / a proper noun.
I know the latter won't be really happening in this feature since you are going for the actual key names, but I wanted to explain the strategy around capitalization.
https://developer.mozilla.org/en-US/docs/Web/API/UI_Events/Keyboard_event_key_values
|
Reporter | |
Comment 12•2 years ago
•
|
||
Jules, thank you so much for looking into this and doing the research, I'm really glad we'll be going for this nuanced approach.
One last question - so "Space Bar" is a proper name, right? Hence we will capitalize it in a hover state:
Here's our final state if that's correct:
Close button
macOS: Close (⌘W)
Windows and Linux: Close (CtrlW)
Video Play / Pause button
Pause (Spacebar)
Play (Spacebar)
The hover state changes according to the button state.
Subtitles button
Subtitles
Volume on/ off
macOS
Mute (⌘↓)
Unmute (⌘↑)
Windows and Linux
Mute (Ctrl↓)
Unmute (Ctrl↑)
UnPiP button
Back to tab
This is just a reminder for the future PiP controls hover states
Fullscreen
Fullscreen (double click)
Seek forward
Forward (→)
Seek backward
Backward (←)
|
|
||
Comment 13•2 years ago
•
|
||
Hey Ania!
Based on what we discussed, the final states you listed look good to me.
I was wondering why you added the plus in this version. The previous version you listed didn't include it. As you mentioned above, the existing Firefox pattern of displaying shortcuts doesn't include the plus. Any reasoning behind the plus?
The "Space Bar" spelling is an interesting one. I did a ton of reading around that, and I have run into these three variations:
Space bar
Spacebar
Space Bar
I think as long as we capitalize the beginning, either spelling would be OK. FWIW, in MDN I see both "Space Bar" and "Spacebar" spellings.
|
|
Reporter | |
Comment 14•2 years ago
|
||
Jules, very sorry about this, the "+" is the unfortunate copy-paste. Fixed it, and updated the first comment.
I feel like "Spacebar" looks nicer in the context of a hover (one less capitalization), so we're going to stick to it.
I'm going to compile all of this wealth of knowledge into a google doc as it's definitely something useful for desktop PMs. Please let me know, if it's helpful share in the Fx design systems too.
|
|
||
Comment 15•2 years ago
|
||
Hey Ania, don't be sorry! Just wanted to gather some context around that plus :-)
"Spacebar" definitely makes things easier on the capitalization front - if you're cool with it, that's cool! Brent could probably give some opinion around it too, if he already hasn't.
I think this is a great guide to compile into a small guideline. I don't see this becoming longer than a 1-pager.
We can absolutely host this in our docs, and you could link your PM docs to our docs if you'd like. Let me know!
|
|
Reporter | |
Comment 16•2 years ago
|
||
|
||
Comment 17•2 years ago
|
||
|
||
Comment 18•2 years ago
|
||
Backed out for causing failures at browser_keyboardShortcut.js.
Backout link: https://hg.mozilla.org/integration/autoland/rev/d3c802f1a2276053da5196692c7689638a8d18bb
Failure log: https://treeherder.mozilla.org/logviewer?job_id=384508594&repo=autoland&lineNumber=17204
| Comment hidden (off-topic) |
|
||
Comment 20•2 years ago
|
||
The patch is still being worked on by the original assignee.
|
|
||
Comment 21•2 years ago
|
||
|
||
Comment 22•2 years ago
|
||
| bugherder | ||
Description
•