Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

I2I: Allow amp-form in Story Page Attachments #35569

Closed
9 tasks done
coreymasanto opened this issue Aug 9, 2021 · 6 comments
Closed
9 tasks done

I2I: Allow amp-form in Story Page Attachments #35569

coreymasanto opened this issue Aug 9, 2021 · 6 comments
Assignees
Labels
INTENT TO IMPLEMENT Proposes implementation of a significant new feature. https://bit.ly/amp-contribute-code WG: stories

Comments

@coreymasanto
Copy link
Contributor

coreymasanto commented Aug 9, 2021

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.

forms_in_attachments_mock1

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

@coreymasanto coreymasanto added the INTENT TO IMPLEMENT Proposes implementation of a significant new feature. https://bit.ly/amp-contribute-code label Aug 9, 2021
@newmuis
Copy link
Contributor

newmuis commented Aug 9, 2021

Looks like the cc didn't go through.

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

@processprocess
Copy link
Contributor

processprocess commented Aug 10, 2021

My 2cents:

  1. Should we redirect users to the next story page upon successful form submission?

I don't think so since it's unrelated to the user action.
I think showing the "Thank you" message in the attachment and letting the user close it manually is good.

  1. Should we commit to showing the padlock icon to the left of HTTPS domains?

I think it could help visually communicate a secure connection so I think it's okay.

  1. Should we require submit-success and submit-error response attributes, or leave it up to the publisher?

I think we should require it. The clear feedback will help users know the action is complete and that they can return to the story experience.

@gmajoulet
Copy link
Contributor

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

@processprocess
Copy link
Contributor

@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:

Aug-10-2021.15-12-24.mp4

@processprocess processprocess added this to To do in wg-stories Page attachments via automation Aug 11, 2021
@processprocess processprocess moved this from To do to Forms in attachments in wg-stories Page attachments Aug 11, 2021
@coreymasanto coreymasanto changed the title Allow amp-form in Story Page Attachments I2I: Allow amp-form in Story Page Attachments Aug 27, 2021
@coreymasanto coreymasanto self-assigned this Oct 5, 2021
@Shohelorg
Copy link

Hi

@newmuis
Copy link
Contributor

newmuis commented May 17, 2022

Hey!

@newmuis newmuis closed this as completed May 17, 2022
wg-stories Page attachments automation moved this from Forms in attachments to Done May 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
INTENT TO IMPLEMENT Proposes implementation of a significant new feature. https://bit.ly/amp-contribute-code WG: stories
Development

No branches or pull requests

5 participants