Rendering Blinks

Clients that support Blinks should take any of the 3 above formats and correctly unfurl the action directly in the client.

For clients that do not support Blinks, there should be an underlying website. In other words, the browser is the universal fallback.

If a user taps anywhere on a client that is not an action button or text input field, they should be taken to the underlying site.

• Option 1 above is the most basic form, but also the most limiting in that unsupported clients have no way to handle the link.

• Option 2 is the most advanced, in that the developer has done work to map some site to some action.

• Option 3 on the other hand, is the purest manifestation of the actions technology: it fully decouples the action to be taken (the inner URL) from the client in which it’s taken (the outer URL).

We cover Option 3 in greater detail in the next section.

Layout

Multi-action

Blinks should support some combination of the above—multiple actions & at most one user input text field—where there may be multiple actions, & user input.

Text fields have a single button associated with them, that requires an input from the user to be clicked. Text fields may not be linked to multiple buttons. (E.g. memo on your vote is not supported by the MVP.)

Render lifecycle

Users should not have to tap anything to render the current state of an action, including any dynamic content or validation state that may be needed. That state is determined when the action is first rendered on the screen.