Add autoplay mode for amp-story

[newmuis]

amp-story Autoplay Mode

Overview

We would like to have stories play inline in embedded contexts (e.g. feeds), automatically advancing through all pages in the story without any user interaction. If the user taps on the story, it can open full-screen, at which point the document is opened "normally", where the user can manually navigate between pages, and the story is most likely shown in a larger container.

Requirements

• The embedding context must be able to initialize the document in this state, so that there is no transition between the normal document state and the "autoplay" mode
• The embedding context must be able to subsequently toggle the document between states after it has been initialized

API Design

Option 1: New PREVIEW VisibilityState

We add a new generic enum value to VisibilityState, like PREVIEW, where each component can optionally change its logic depending on its value. By default, PREVIEW can be equivalent to VISIBLE, unless the component overrides this behavior. amp-story's autoplay mode then just becomes an implementation detail of how the amp-story component chooses to implement the PREVIEW VisibilityState.

The PREVIEW state can be defined as the document being visible to the user, but being passively consumed (whereas VISIBLE would mean the document is visible and actively consumed).

VISIBILITY_STATES = {
  HIDDEN: 'hidden',
  INACTIVE: 'inactive',
  PAUSED: 'paused',
  PRERENDER: 'prerender',
  PREVIEW: 'preview',
  VISIBLE: 'visible',
};

Option 2: New fragment parameter and request name

We can add autoplay mode as its own new fragment parameter and message/request name. For example we can append #autoplay=1 to the URL to initialize the state; to modify this state, the embedding context can send a message like autoplayMode with e.g. a boolean payload enabling/disabling the mode.
/cc @flaviori @christianbersch

[newmuis]

The feedback from the design review was to take option 2.

As a separate design consideration (not from the review), it may make sense to make this requirement go the other way as well: to disable automatic advancement in cases where it was explicitly specified. This will be useful to force determinism for testing in some cases. So, we at least want this construct to have three states (naming is temporary):

• As specified (i.e. if the publisher specified auto-advance, we advance automatically; if they did not, the user must advance manually)
• Always automatically advance (i.e. ignore what the publisher specified; always auto-advance on every page)
• Never automatically advance (i.e. ignore what the publisher specified; never auto-advance on any page)

[newmuis]

We have since added the embedMode construct, which will encapsulate this. We should add a new embed mode that enables this autoplay behavior. We will also need to add the ability to modify the embedMode via postMessage.

[newmuis]

Perhaps we can make the message toggleAutoplay, to match the amp-carousel toggleAutoplay action. Maybe this means that we allow autoplay in the same way that carousel does: an autoplay attribute and delay attribute. Then, the embedMode can append these, if they were absent from the original doc. (Optionally, we can make them invalid until we explicitly choose to enable this as a publishing feature)

[ampprojectbot]

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

[ampprojectbot]

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

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[newmuis]

Reviving this -- we'd like to reconsider option 1 and determine the amount of effort needed to support this. The primary change to what is written above is that we'd like to, instead, make this PREVIEW equivalent to PRERENDER by default.

However, given that previews are indeed user-visible, this new state would allow further customization to ensure that each component looks as users would expect while this state is active (e.g. videos can be played (assuming that their source(s) were able to be loaded))

[newmuis]

/to @coreymasanto can this be closed?