Add autoplay mode for amp-story

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]

/to @coreymasanto can this be closed?

[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))