Tasks for 3.7

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.

fig 1

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.

fig 2

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.

fig 3

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.

fig 4

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.

fig 5

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.

fig 6

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: