Display Only Current Range in Progress Bar

[joncameron]

Description

As as user, I want a progress bar to represent the duration of the current track/segment, rather than the duration of the entire file. Rather than changing the UI, for Ramp in Avalon 7.8 the existing functionality will be copied.

This issue revives #12, replacing "lil' scrub.", which showed the duration of the current track within a separate progress bar that appeared below the original media player. This is for a "track view" that displays the duration of the current track to fit the entirety of the progress bar in the media player, allowing for easier seeking and presentation of tracks present in a single AV stream. This is particularly relevant for audio CDs which have been extracted as a single stream but are meant to be navigated using track metadata.

For this ticket, segment/track/chapter can be used interchangeable to refer to labeled time ranges that define named areas of content within a recording.

Done Looks Like

• The media player includes a zoom button that toggles the display of the secondary, segment-level progress bar
• The zoom button does not appear if there are no tracks (no structure except the sections themselves)

When zoomed out (default):

• Clicking the zoom button toggles the presence of the track-level progress bar

When zoomed in:

• A short panel opens below the player with a separate progress bar showing the duration of the currently active track
• The start of the zoomed in progress bar is 0:00 and the end is the duration of the currently active track (rather than the timestamp within the broader media item)
• When autoplay advances from one track immediately to the next track, the zoomed in progress bar reloads to displa
• When the user clicks on a track and the zoomed in progress bar is open, the new duration should reload in the zoomed in progress bar
• When autoplay advances past the end of a track and the content continues but there is no track covering it, the zoomed in progress bar displays the duration of the entire file, instead of the track-level view (matching Avalon 7.6)

Current Functionality in Avalon 7.6

Notes

• Implementing as a custom component would most likely be easier than trying to create a video.js plug

[joncameron]

• Context is a concern (how will users know which zoom level they're at?)
  • progress bar could be thicker when zoomed in to match styling in current Avalon
  • header text could be updated to include which zoom level the player is showing (section or segment/track)
• How will timespans outside of structure data be handled?
• What happens when the next timespan/section begins?
• Previous/next buttons being section level - could also be track level (buttons through video.js?)

[joncameron]

From implementation perspective, it would be good to have this on the Ramp side because it is a player event that goes through across state for all of the components. Everything with Video.js within Ramp is current handled on initialization and this would happen after that step, so this could be more complicated.

Progress bar in Ramp is a video.js component we've written, so it would probably be easier to put the customization here.

For creating a copy of our current UI with a slide-out panel, we could possibly use the video.js panel library. This would require some research into the use of the component so we could use them well.

This can be rewritten to match the UI for the existing functionality, where a panel appears underneath the player showing a progress bar only scoped to the current structure segment.

[elynema]

@joncameron I took a stab at starting to update done looks like, but I didn't delete anything that was already there, which still needs to be done. I wanted to make sure we covered all the functional cases in Done Looks Like for QA purposes.

[elynema]

@joncameron If this is a custom component, does that mean Ramp users decide if they want it to display? I didn't know if some users might not want this component.I didn't see anything about that in the StyleGuidist docs.

[joncameron]

Yes, it should display or not based on values passed in. It's currently suppressed as expected on the /embed page for example.

@Dananji could you update the docs with the new value? Thanks!

[elynema]

Li'l Scrub is not working properly in the iPad environment in either Chrome or Safari. That seems to be part of a larger issue in Ramp #354 (#354) and Ramp #338. It's not available on iPhone mobile device (since the native player doesn't include Li'l scrub).

On Android, Li'l scrub is not working in Firefox. It works fine in Chrome. Here's a video of it in Firefox:

Private Zenhub Video

@joncameron Have you tested this in computer browsers? Should we pull this back to in progress for the Firefox Android issue, or is that one that doesn't need to be resolved for 7.7 release?

[joncameron]

I tested all desktop browsers and it worked without issue in Safari, Chrome and Firefox so this seems to be mobile platforms only. I'm comfortable closing this issue because it does seem like part of #354 and #338 and will get resolved on those issues.

I'll create a separate issue for it not working in Firefox on Android, since that seems to me like a reasonable "known issue" bug that shouldn't hold back release.