video notes design iteration 001

[joelhooks]

The egghead player notes UX Design Figma is doing a great job at visual tackling and explaining the UX we are working to achieve. It breaks down the original screen share with Greg Róg and gives us a clear-ish vision of where we want to be.

It describes a lot of ambitious work!

This player is an infinite game, and to achieve the vision of an enriched video-based learning environment it's essential that we get there incrementally in a way that consistently improves the learning experience

Current Iteration:

The current iteration can be found at https://egghead.io/video-test.

This version is a technical proof of concept that has passed and:

• uses mock data in the WebVTT format
• implements a "cue bar" within the video frame that displays "ticks" where notes are available in the context of the video with a "tooltip" when the video reaches the matching timecode
• implements a "side panel" for notes corresponding to the "ticks" in the cue bar. when that note's time has reached the note is highlighted in the side panel

Next iteration:

• create a structural visual design that matches the default theme for the cue bar and the side panel
• implement visual design in React components

Global Considerations

These components need to take a11y as a primary design focus with keyboard and screen reader access considered essential to the initial iteration and deployment to learners.

Cue Bar

The cue bar is a component that rests on top of the player controls and presents "ticks" at certain places across the bottom of the video. Each of these ticks represents a resource related to the video. Currently, we are only presenting static notes that were created by egghead staff.

There is no ability to author notes in the UI with this iteration.

Some things to consider:

• unlike the player controls, the notes are useful visually throughout the duration of the video so what happens when the controls auto-hide?
• notes can have just a start time or a start and end time. How does that affect the behavior?
• if we auto display notes when they are entered (start time is reached) it's critical to make muting obvious and quick.
• if we don't auto display, we can make a "flourish" or other indication to highlight notes as they are activated in time

Side Panel

The current production side panel makes a sensible base since we will want to display the lesson outline for a course as we do currently, but add a notes tab:

The side panel will have two tabs, lessons and notes with an understanding that additional tabs will be created in future iterations.

Some things to consider:

• horizontal space is at a premium in the side panel and we want to maximize the width of the notes and keep the metadata compact
• the notes are static so no flagging, editing or individual attribution is required.
• the initial notes are "staff notes"
• notes scroll into view along with video
• notes are highlighted when active (start and end / enter and exit)

[joelhooks]

In Slack, we were discussing where cues are displayed and how to associate them with the timeline.

@vojtaholik proposed this:

This proposal is a step in the right direction because it's critical that the current time and the cues are closely associated and not detached.

The issue with this approach for me is that it "compresses" the display of the notes and limits the capacity of the control bar. It is also less critical for the controls to be closely associated with time, so detaching the progress bar and relocating it on top of the control bar frees up valuable room for controls and gives the cue track full width of player for display.

Youtube, as an example of a well implemented play head above the control bar:

One essential aspect of this work is that we don't reinvent the video player UX. It's my opinion that sticking close to youtube as far as core controls go is a very reasonable approach.

Play head progress bar rests on top of the control bar.

YouTube also has some very cool interactions when you "pull" the play head that might be worth noting for future iterations.

Cue Tracks

We currently have 1 cue track. It is a literal track in the player architecture. For this interaction, I am considering professional non-linear video editing and annotation software.

Here's an example from Adobe Premiere, but if you look at all modern software that deals with tracks and video, these similar patterns emerge:

Our use case is thankfully much less complex, so we can take these ideas and simplify them considerably:

Three primary components (bars) are represented:

• play head progress - stacked on top of tracks and controls is the play head timeline controller. This orients the user and displays the current location in the video and allows them to interact with the timeline to move the video to the desired location by pressing and dragging the play head. Time "flags" appear when dragging to give feedback on the current location. Clicking a location in the progress bar will snap the playhead to the location.
• cue bar (optional) - if present, metadata tracks are displayed directly underneath the play head progress bar. Individual cues can be interacted with on hover and click. Clicking a cue will snap the playhead to that time. Clicking empty space between cues will snap playhead to the location clicked.
• control bar - standard video controls play, pause, jump forward, jump back, volume, time, subtitles, download, speed, fullscreen, etc

Control Visibility

In the default implementation, the control bar autohides and is overlaid on the video itself. Taking a cue (hah!) from YouTube we should consider an "always on" approach for all controls and tracks as initial default under )not over) the video

Multiple Cue Tracks

This approach allows flexibility in how we handle multiple tracks in the future. It's important to show constraint in the number of tracks, and again video editing software has made this well-trodden ground so we should consider these tracks in that context. Typically tracks can be collapsed and expanded for the progressive display of information to the user. We could (in the future) offer a configuration menu that allows users to customize their preferences (always hide public tracks, for instance).

Also recorded this loom with some extended thoughts.