-
Notifications
You must be signed in to change notification settings - Fork 384
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
Improve User Experience of Subset Selection Controls for Standard AMP #1273
Comments
Note that by default the individual templates are not displayed to the user as options to select. The default is for all templates to be made available in AMP. |
I would be happy to help test this. I am working on adding a few non-AMP pages to my fork of the AMP News page (for checkout, mostly). I saw the changelog for #1235, but the
|
As a user, I should expect an intuitive way to be able to understand how, when and why I can enable Native AMP on parts of my WordPress site.
Related #934, #1006.
As discussed in our last few meetings, we want to validate that the solution we've come up with in #1235 makes the most sense for users and their use cases. Binding error validation next to the toggles (for example, highlighting that a user could enable AMP on a given subset) might also provide for single context understanding of what's already possible.
Further, the layout could become very long and feels a tad confusing: It's not clear, yet, if site admins understand what content types, templates and the various sub-page types and whether this is the most intuitive interface to display that. It's clear to me that there may be a good reason to bind the errors that occur elsewhere next to the toggles, or perhaps to merge these interfaces.
We've broken this sub-ticket out from #1006, hoping to bind parts of #1007, so that we can think though ways to provide a better, more streamlined new-user experience for admins who will be grappling with multiple concerns here. As a user clicks on the pointer described in #1254, I'd want them to be able to quickly figure out what's "good to go" with AMP. (Perhaps the experience should feel like: "All this is ready for AMP except these few content types, click this button to turn it all on except what you can't.")
The ideas here may be too lofty to squeeze into the
v1.0-stable
release, but if we can at least start the discussion (AC1) I'd like to see where this goes.Looking for assistance from @jwold, @ThierryA, @westonruter as you are available to figure out next steps in discovery and implementation.
cc: @kevincoleman.
The text was updated successfully, but these errors were encountered: