I2I: Allow amp-form in Story Page Attachments

Summary

We are expanding story page attachments to support forms so that readers can submit input fields.

Constraints:

1. To prevent form input from interfering with tappable interactions (e.g., story page navigation), forms will only be allowed within story page attachments.
2. For security purposes, the publisher’s domain will automatically be visible in the header of any page attachment that contains a form.

Motivation

The amp-form component is currently disallowed in stories, but its addition would allow creators to securely engage with and gather information from their users. Once allowed, forms will become the primary method of communication between creators and their users.

Open Questions: All questions are currently resolved.

Resolved Questions:

1. Should we display the domain in the headers of all page attachments, or only page attachments containing forms? Only page attachments that contain forms should display the domain.

2. Should we require that the domain is an HTTPS URL, or is it sufficient that the form’s data is sent to an HTTPS URL? Or both/neither? And does the answer here mean that we should display the site’s protocol as well as it’s domain? We will not restrict this feature based on the publisher domain, and we will not display the protocol along with the domain.

3. How do we display domain names that are too long to fit in the header? We will fit the domain name on a single line, using an ellipsis to truncate names that are too long.

4. Should we redirect users to the next story page upon successful form submission? We should not redirect users to the next page. Instead, the expected flow is for users to swipe the page attachment down and then continue the story navigation themselves.

5. What will the UX be for the soft keyboards on mobile? Should the keyboard overlap the page attachment or push it upwards? The soft keyboard behavior is primarily system dependent: iOS keyboards push the page upwards whereas Android keyboards overlap the page.

6. Should we commit to showing the padlock icon to the left of HTTPS domains? We will not display the padlock icon because AMP forms are already required to send data to HTTPS endpoints. We do not yet have the UXR to support the inclusion of the padlock, and it would confuse users if we later decide to remove the padlock after initially including it. Conversely, we could always revisit the padlock idea and begin including it in the future.

7. Should form input be preserved or reset upon page attachment dismissal? The input will be preserved, to prevent cases where the user closes the page attachment with the intent to return to the form (e.g., the user accidentally closes the attachment or they close the attachment in order to briefly refer to information on the story page).

8. Should publishers be able to specify the submitting, submit-success, and submit-error states for their attachment forms? For the initial release of this feature, we will provide default states that will be used by every page attachment form. These default states will be used in place of any submission response attribute element that the user has not included within the form.

Launch Tracker

Implementation Tasks

• Update amp-story-page-attachment.js to display the domain in its draggable drawer’s header, if it contains an amp-form child element
• Update the domain display logic to account for domain names that are too long to fit within a single line of the header

Testing Tasks

• Verify that amp-form’s many features (i.e., custom validations and attributes) work properly within the context of a story
• Verify that unit tests and visual regression tests provide adequate coverage (and add more tests, if necessary)
• Fix all launch-blocking bugs found during the previous testing steps
• Implement V0 default success/failure validation states to appear beneath the form upon submission
• Create new QA test for forms in stories

Release Tasks

• Create an Intent to Ship for allowing forms within page attachments
• Add form and related elements to the validator as an allowed descendant of page attachments

Notifications

/cc @ampproject/wg-approvers /cc @ampproject/wg-stories

[processprocess]

@processprocess is it ok if the content of the page-attachment is dynamically resized? Will the page-attachment drawer height automatically adapt?

It will adapt automatically:

https://user-images.githubusercontent.com/3860311/128920946-b202168d-41dd-4e74-885a-ec58644e2eba.mp4

[newmuis]

Hey!