Docking UX for video players #8088

Open
aghassemi opened this Issue Mar 13, 2017 · 9 comments

Comments

@aghassemi
Member

aghassemi commented Mar 13, 2017

Task breakdown for #7510

  • If video is playing, scrolling down the page minimizes the video to the corner.
  • When scrolling back to top, video is maximized again.
  • When video is minimized, swiping to the right dismisses the video (e.g. pause and moves it back to the top).
  • Minimized video should be 'movable' by the user.

Format for docking videos

  • Available only on video players that implement the video-interface.
  • dock=(when-playing|never)
  • Defaults to when-playing (this makes this an opt-out!)
  • Possibly to support when-playing-or-autoplaying later. We are not sure if we want to support this for auto playing videos.
  • Value will be ignored in A4A format

UX for docking videos

  • Videos that are played by the user are minimized and docked to the top corner when about to go out of viewport as user scrolls.
  • Player's builtin controls get hidden
  • Swipe to the left dismisses the video (i.e. pause and dock back to original place)
  • Tap expands the video to full width but (still docked to the top) and enables the player's builtin controls so user can take actions such as volume change, fullscreen, etc.
  • Playing another video will dismiss the existing docked video.

@aghassemi aghassemi referenced this issue Mar 13, 2017

Open

Hero mode for video players #7510

0 of 4 tasks complete

@aghassemi aghassemi self-assigned this Mar 13, 2017

@aghassemi aghassemi added this to the Sprint H2 March milestone Mar 13, 2017

@aghassemi aghassemi added this to In Progress in UI Mar 13, 2017

@aghassemi aghassemi moved this from In Progress to Sprint (committed) in UI Mar 13, 2017

@aghassemi aghassemi added this to In Progress in Video Mar 14, 2017

@dpetrieldn

This comment has been minimized.

Show comment
Hide comment
@dpetrieldn

dpetrieldn Mar 23, 2017

Would additional configuration options be in scope or relevant for this, such as initial docked/minimised position (top/bottom, left/right etc) or keeping the player in view but paused if another video is played until the user dismisses?

dpetrieldn commented Mar 23, 2017

Would additional configuration options be in scope or relevant for this, such as initial docked/minimised position (top/bottom, left/right etc) or keeping the player in view but paused if another video is played until the user dismisses?

@aghassemi

This comment has been minimized.

Show comment
Hide comment
@aghassemi

aghassemi Mar 23, 2017

Member

@dpetrieldn For the docking location, it is certainly possible to expose an option. Initially we are thinking not to expose that in the hopes of providing a unified UX across all AMP pages (always top-right) and allow the user to move it instead of publisher deciding where it docks.

Definitely open for discussion though. Is there a specific use-cases for you that must require docking somewhere other than top-right? (Of course for RTL pages, we would automatically flip to dock on top-left).

Another option we are exploring here is: instead of an option to pick where to dock, allowing authors to put a marker div whereever and having the video dock to the marker. This is more flexible for responsive design when docking to corners of viewport may not work great for desktop sites where docking to a sidebar or corner of main area may make more sense.

keeping the player in view but paused if another video is played until the user dismisses?

Could you elaborate on this design a bit more? (We haven't fully flushed out multiple video UX yet). Does something like the following cover the design you had in mind:
1- User plays video 1
2- User scroll, video 1 docks
3- User plays video 2, docked video 1 is paused but not dismissed yet.
4- User scrolls again, now video 2 docks and dismisses video 1 as it is docking.

Member

aghassemi commented Mar 23, 2017

@dpetrieldn For the docking location, it is certainly possible to expose an option. Initially we are thinking not to expose that in the hopes of providing a unified UX across all AMP pages (always top-right) and allow the user to move it instead of publisher deciding where it docks.

Definitely open for discussion though. Is there a specific use-cases for you that must require docking somewhere other than top-right? (Of course for RTL pages, we would automatically flip to dock on top-left).

Another option we are exploring here is: instead of an option to pick where to dock, allowing authors to put a marker div whereever and having the video dock to the marker. This is more flexible for responsive design when docking to corners of viewport may not work great for desktop sites where docking to a sidebar or corner of main area may make more sense.

keeping the player in view but paused if another video is played until the user dismisses?

Could you elaborate on this design a bit more? (We haven't fully flushed out multiple video UX yet). Does something like the following cover the design you had in mind:
1- User plays video 1
2- User scroll, video 1 docks
3- User plays video 2, docked video 1 is paused but not dismissed yet.
4- User scrolls again, now video 2 docks and dismisses video 1 as it is docking.

@dpetrieldn

This comment has been minimized.

Show comment
Hide comment
@dpetrieldn

dpetrieldn Mar 27, 2017

@aghassemi
Hopefully the below will help to clarify.

Multi video pages
As publishers we sometimes lead with videos, and would ideally only have these videos as the ones that are docked. We do however include additional video in video lead articles to support textual content, but would not want them to dock. So, if the user has the lead video docked, and then interacts with another video on the page, we wouldn't want to always dismiss the lead video, but would want to pause it and play the inline one. This would not only need to pause the video content, but also any pre-roll that is playing. I expect we would be able to identify these types of situations at our end and apply relevant controls to identify whether or not we would want a video to dock, but having the option to either undock or keep docked if another video was played would be useful.

Docking player in different locations
Use cases would be limited to differing viewport widths, extending beyond what would be typical. For example a landscape tablet view that was rendering a 2 column layout, the second column on the right could contain commercial content that we wouldn't want to have a player obscure, at least not at the top of the page, and would instead prefer it to be docked at the bottom.

Likewise we wouldn't ideally want the player to obscure content either (at least obscure anything as little as possible) but should the content column be on the right side we'd be into a similar issue, where we would want it docked to the bottom left.

In either case we would want to avoid the player covering any high value commercial elements, or to be able to at least limit this.

Some additional thoughts
It would be ideal to specify at what point the player becomes sticky. Viewability of pre-rolls is an increasingly important metric as you likely already know. If the destination position of the docked player is at the bottom of the page then we would want to identify a trigger point that still displays more than 50% of the player so that the inview counter during a pre-roll doesn't get reset. This is more of an issue on shorter pre-rolls than longer ones for obvious reasons, but to balance the commercial need of greater viewability Vs a positive UX from a shorter pre-roll this may be something to reflect upon.

Auto closing/dismiss
We've identified some use cases in a comments system, specifically where a player is docked at the top, a user then interacts with an element to insert text, and the keyboard covers the remaining content on the page fully without the ability to see the element into which they are typing. An auto-pause and close would be of benefit in this situation, perhaps coming back into view after the user has completed their interaction, but this may be a somewhat awkward UX.

Docking effect on pre-rolls
We've noticed that in some instances, when pre-rolls are playing and the user takes an action which causes a player to dock and change size (again this would be dependent on viewport widths), pre-rolls can sometimes pause. This is not ideal behaviour and may not be something we can alter, but may have a negative impact on UX.

Orientation restrictions/media queries
We may only want to dock the player at certain viewports or orientations, such as not docking on landscape mobile or even on landscape tablet. This would often cover too much content and restrict what was viewable depending on the size of the docked player.

Apologies for the long post, hopefully this answers some questions and prompts extra discussion on the UX.

@aghassemi
Hopefully the below will help to clarify.

Multi video pages
As publishers we sometimes lead with videos, and would ideally only have these videos as the ones that are docked. We do however include additional video in video lead articles to support textual content, but would not want them to dock. So, if the user has the lead video docked, and then interacts with another video on the page, we wouldn't want to always dismiss the lead video, but would want to pause it and play the inline one. This would not only need to pause the video content, but also any pre-roll that is playing. I expect we would be able to identify these types of situations at our end and apply relevant controls to identify whether or not we would want a video to dock, but having the option to either undock or keep docked if another video was played would be useful.

Docking player in different locations
Use cases would be limited to differing viewport widths, extending beyond what would be typical. For example a landscape tablet view that was rendering a 2 column layout, the second column on the right could contain commercial content that we wouldn't want to have a player obscure, at least not at the top of the page, and would instead prefer it to be docked at the bottom.

Likewise we wouldn't ideally want the player to obscure content either (at least obscure anything as little as possible) but should the content column be on the right side we'd be into a similar issue, where we would want it docked to the bottom left.

In either case we would want to avoid the player covering any high value commercial elements, or to be able to at least limit this.

Some additional thoughts
It would be ideal to specify at what point the player becomes sticky. Viewability of pre-rolls is an increasingly important metric as you likely already know. If the destination position of the docked player is at the bottom of the page then we would want to identify a trigger point that still displays more than 50% of the player so that the inview counter during a pre-roll doesn't get reset. This is more of an issue on shorter pre-rolls than longer ones for obvious reasons, but to balance the commercial need of greater viewability Vs a positive UX from a shorter pre-roll this may be something to reflect upon.

Auto closing/dismiss
We've identified some use cases in a comments system, specifically where a player is docked at the top, a user then interacts with an element to insert text, and the keyboard covers the remaining content on the page fully without the ability to see the element into which they are typing. An auto-pause and close would be of benefit in this situation, perhaps coming back into view after the user has completed their interaction, but this may be a somewhat awkward UX.

Docking effect on pre-rolls
We've noticed that in some instances, when pre-rolls are playing and the user takes an action which causes a player to dock and change size (again this would be dependent on viewport widths), pre-rolls can sometimes pause. This is not ideal behaviour and may not be something we can alter, but may have a negative impact on UX.

Orientation restrictions/media queries
We may only want to dock the player at certain viewports or orientations, such as not docking on landscape mobile or even on landscape tablet. This would often cover too much content and restrict what was viewable depending on the size of the docked player.

Apologies for the long post, hopefully this answers some questions and prompts extra discussion on the UX.

@aghassemi

This comment has been minimized.

Show comment
Hide comment
@aghassemi

aghassemi Mar 27, 2017

Member

Thanks for the details write-up @dpetrieldn! This is absolutely great that you are sharing your requirements with us before we implement a feature! 👍

I will keep these in mind as we work on the implementation. Everything looks reasonable to support. The API design for docking location and docking triggers might be the harder part to get right. For Docking effect on pre-rolls problem, I am hoping using CSS scale transformation would solve it as the player inside the iframe would not become aware of the resize. (We would be asking the player to hide UI controls when minimizing however)

I am also curious to know what video player you are using. Do you have a custom in-house solution and use amp-iframe to embed or do you use a commercial platform like Brightcove? (Reason I am asking is that only video players the implement AMP's video-interface can be supported for docking so I like to make sure we get whatever player you use to support it - assuming you are interested in the docking UX and like to be an early adopter so AMP can iterate on a solution with a partner)

/cc @spacedino

Member

aghassemi commented Mar 27, 2017

Thanks for the details write-up @dpetrieldn! This is absolutely great that you are sharing your requirements with us before we implement a feature! 👍

I will keep these in mind as we work on the implementation. Everything looks reasonable to support. The API design for docking location and docking triggers might be the harder part to get right. For Docking effect on pre-rolls problem, I am hoping using CSS scale transformation would solve it as the player inside the iframe would not become aware of the resize. (We would be asking the player to hide UI controls when minimizing however)

I am also curious to know what video player you are using. Do you have a custom in-house solution and use amp-iframe to embed or do you use a commercial platform like Brightcove? (Reason I am asking is that only video players the implement AMP's video-interface can be supported for docking so I like to make sure we get whatever player you use to support it - assuming you are interested in the docking UX and like to be an early adopter so AMP can iterate on a solution with a partner)

/cc @spacedino

@bjalford

This comment has been minimized.

Show comment
Hide comment
@bjalford

bjalford Mar 28, 2017

@aghassemi I'll leave Dan to feedback on the rest.

The player currently used is Brightcove and yes keen to implement as an early adopter.

@aghassemi I'll leave Dan to feedback on the rest.

The player currently used is Brightcove and yes keen to implement as an early adopter.

@ericlindley-g ericlindley-g moved this from Sprint (committed) to Sprint (candidate) in UI Mar 31, 2017

@ericlindley-g ericlindley-g moved this from Sprint (candidate) to Backlog (shortlist) in UI Mar 31, 2017

@dpetrieldn

This comment has been minimized.

Show comment
Hide comment
@dpetrieldn

dpetrieldn May 2, 2017

Hey @aghassemi, we tried using scale on non amp pages with the Brightcove player but it had an impact on the player controls that proved to be unworkable, however we didn't go into it in much depth past an initial attempt.

As per @bjalford 's comment, its a Brightcove player 99% of the time, but in very rare instances we have other players in use, typically across your standard embeds like youtube for example.

With our Brightcove player we would also actually love to have some form of end board, appreciate it may not have a place in this issue but may be something to consider.

Would love to be an early adopter for this, just to make that clear! So happy to answer any questions or provide more specific feedback if required.

Hey @aghassemi, we tried using scale on non amp pages with the Brightcove player but it had an impact on the player controls that proved to be unworkable, however we didn't go into it in much depth past an initial attempt.

As per @bjalford 's comment, its a Brightcove player 99% of the time, but in very rare instances we have other players in use, typically across your standard embeds like youtube for example.

With our Brightcove player we would also actually love to have some form of end board, appreciate it may not have a place in this issue but may be something to consider.

Would love to be an early adopter for this, just to make that clear! So happy to answer any questions or provide more specific feedback if required.

@bjalford

This comment has been minimized.

Show comment
Hide comment
@bjalford

bjalford May 2, 2017

+1 for early adopter and testing.

bjalford commented May 2, 2017

+1 for early adopter and testing.

@aghassemi

This comment has been minimized.

Show comment
Hide comment
@aghassemi

aghassemi May 2, 2017

Member

@bjalford @dpetrieldn Thanks for more info. Our initial design assumed we hide the player controls and instead put our own controls on top of the video (limited controls with large tap targets) when minimized.

Brightcove needs to fully implement the video-interface before it can be part of this UX. There has been some work done already by @mister-ben here: #7795

Just another note that work on this feature is on pause at the moment for higher priority tasks.
/cc @ericlindley-g for another look at prioritization.

Member

aghassemi commented May 2, 2017

@bjalford @dpetrieldn Thanks for more info. Our initial design assumed we hide the player controls and instead put our own controls on top of the video (limited controls with large tap targets) when minimized.

Brightcove needs to fully implement the video-interface before it can be part of this UX. There has been some work done already by @mister-ben here: #7795

Just another note that work on this feature is on pause at the moment for higher priority tasks.
/cc @ericlindley-g for another look at prioritization.

@ampprojectbot

This comment has been minimized.

Show comment
Hide comment
@ampprojectbot

ampprojectbot Nov 20, 2017

Collaborator

This issue hasn't been updated in awhile. @wassgha Do you have any updates?

Collaborator

ampprojectbot commented Nov 20, 2017

This issue hasn't been updated in awhile. @wassgha Do you have any updates?

@ericlindley-g ericlindley-g moved this from Backlog (shortlist) to Video in UI Jan 5, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment