Firefox/Projects/Video Controls
Contents
Next steps
Tasks for 3.6
- Fullscreen mode
- bug 453063
Currently assigned to Dao- Patch landed, needs UI & dev review (dolske & Boriss)
- Depends on
bug 370857, bug 476371, bug 502440, bug 506826,bug 513144(fixed)
- bug 453063
- Video error messages
- bug 518168
- Currently assigned to Dolske & Boriss
- Most is front-end controlled, so there’s 3-4 kinds of error
- Need a list of what errors we can catch & what to show the user (e.g. codec vs non-code errors)
- Requires strings
- Play button/click area
- bug 518008
- Currently assigned to Boriss & (?)
- For video with autoplay off (and possibly poster off), have a play button in the center and have the whole video clickable to play
- If the user clicks anywhere on the screen while the video is playing, pause and show pause button in the center of the screen
- Small size handling (phase 1)
- For 3.6 chose what elements disappear in what order at small sizes
- Change icon for volume when video is muted, on different volume levels
- End time in the video should count down to how much time is left (?)
Tasks for 3.7
- Small size handling (phase 2)
- Optimization of what video should do at different sizes
- Possible expanding menus
- Ability to link to a particular time in the video
Current design
Wanted features
Streaming UI controls
Our current video controls follow conventions of digital playback: a horizontal timeline with a slider that marks the current play point.
Current implementations of live video feed tend to be variations on video controls, but with non-interactive elements such as stationary or removed timelines. These indicate to the user what they can't do, but don't give any additional functionality. They also do not allow video to be buffered for playback.
We'd like to give the added functionality of playback in live video: the ability the keep an amount of video buffered so that users can 1. leave the live feed, replay what they've just seen, and jump back to live or 2. pause the feed and pick up watching where they left off. However, this presents a few design challenges:
- How to visually represent when the user is "live" vs. viewing buffered video
- How to visually represent the amount of video in the buffer (past & future)
- How to make it easy for the user to jump between live and buffered video
- How to visually distinguish between past (buffered video), present (what the user is currently viewing), future (video buffered after the user paused), and live
Below is a design we've been considering to handle these issue. By default, the user is in a visually marked "live" mode - the box on the right of the timeline. As the user watches the live video, the timeline to the left of live fills up with how much video is buffered. So, after one minute the timeline represents one minute in length, and after two minutes it represents two. To give an indication of how much time the bar represents, tick marks marking minutes will scroll left as the video plays. Clicking the live mode button or moving the slider back to the live point (which will "snap") brings the video back to live mode.
However, eventually the video will reach the maximum that can be buffered. For the purposes of these mockups, we'll say that 10MB and 10minutes is the limit. After the video plays for 10 minutes, the beginning of the video is dropped and no longer accessible. The user sees this as the 0:00 mark disappearing from the timeline, and higher time markers continuing to scroll left.
If the user pauses the video, he exits live mode and the slider moves off of the live mode box. A visual indication will show that the video is no longer live - perhaps by fading the live mode and/or changing the shape and color of the slider. As the video is paused, new live video will be buffered and old video will continue to be dropped, moving the paused slider and the timeline left.
Once the slider has moved back 10 minutes, the new video is no longer buffered: only the ten minutes immediately after the pause is stored. This is so that when the user returns, the video will play from the point they left off and not the somewhat arbitrary 10 minutes before the live video. At this point, the buffered 10 minutes and the live point are no longer connected - a visual indication such as a break of the timeline will indicate this.
Accessibility
- Improve default shortcut keys
Audio controls
- Audio controls currently just use the video ones
- Uses too much screen real estate
- Slightly different use case, since it doesn't require you to pay attention to what's on the screen
Fullscreen implementation + UI
- Implement full-screen support for video
- Make larger controls for this mode, probably floating
Feedback
Streaming UI
Feedback for the Streaming UI concept above has been mostly positive. A blog post was made about the original concept here, and a dev post was made here.
Feedback notes:
- Dynamically degrading video over time can allow for more content to be buffered (gerv)
- There are instances that the user may want to save as much video as possible and should have this option (faaborg)
- Different uses of live video benefit from different ways of displaying the current time. James uses the example of watching a live football game, where knowing what quarter the game is in is more useful than knowing the actual time. In other cases, knowing the actual time (”4:30pm”) rather than the relative time (”you’ve watched for 4 minutes”) is more useful. Here’s some examples of uses for live video that could require different time displays:
Optimals time display for live video
Possible ways to address this include allowing developers to specify display time or toggle between them with a click. (james heaver)
Other
- Giant play button when paused (e.g. YouTube)
- Volume adjustment button could use degrees of volume states (eg more obvious when muted)
- Adjust text (currently too high and thin on marker)
- Be able to overlay text / other content onto video
- Determine what events to be able to consume / produce
- Ability to link to a direct moment in the video
Error messages
- Currently, there's no proper handling of errors
Meetings
- Contact people at YouTube + DailyMotion to make sure we give them what they need when it comes to controls
- Meet with the accessibility people to figure out what the best approach for keyboard shortcuts is
