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

Redesign Compatibility Tool #2316

Open
westonruter opened this issue May 14, 2019 · 7 comments

Comments

@westonruter
Copy link
Member

@westonruter westonruter commented May 14, 2019

The admin screens for the Validated URLs and the Validation Errors are implemented in a classic WordPress way™, using post list tables and other traditional admin hooks. The end result is that much of the operations require full page loads, and the interfaces are dated. The UI needs to be revamped using modern WordPress interfaces pioneered with Gutenberg (e.g. using React). In the same way, we should eliminate synchronous validation as much as possible: #2069.

Additionally, more of the management of the validation errors should be surfaced inside of the validation error notices on the edit post screen. Instead of merely indicating the number of validation errors as well as the invalid markup with each block, there should be a way to access full error details and source information from the editor itself; authors should just be able to remove the block (#2285) and/or escalate the validation error to an administrator. Non-administrators should not be able to change the validation error state, and they should not be able to access the compatibility tool screens. In short, redesigning the compatibility tool screens should involve components which can be re-used in the context of the validation warning notices.

As part of this, the site validation functionality needs to be fully implemented in the REST API. Currently we have a bare minimum implemented for Gutenberg integration, the read-only amp_validity field added to the post entity. In addition to that, there needs to be endpoints for:

  • Listing all validated URLs.
  • Requesting a URL to be validated.
  • Listing the validation errors for a given URL.
  • Listing validation errors.
  • Listing URLs containing a given validation error.
  • Changing the validation status for one or more errors.
@amedina

This comment has been minimized.

Copy link
Member

@amedina amedina commented May 14, 2019

  • Allowing for advance information and options to be hidden (toggled), similarly to how advanced settings are dealt with in Chrome.
@amedina

This comment has been minimized.

Copy link
Member

@amedina amedina commented May 16, 2019

  • Revise and improve all messages/copy in the plugin
  • Change language from "Accepted" and "Rejected" to reflect the status of the error rather than the action taken by the user: i.e. "Markup Removed" and "Markup not Removed" (this will align the debugging workflow and language with the Sanitization aspects/approaches). See #2023.
  • Redesign information exposure approach (i.e. expose baseline information, and make more complex/advance information accessible on demand)

/cc @pbakaus

@pbakaus

This comment has been minimized.

Copy link
Collaborator

@pbakaus pbakaus commented May 16, 2019

OMG I'm so excited!

@amedina

This comment has been minimized.

Copy link
Member

@amedina amedina commented Aug 1, 2019

  • Enable contextual strict mode, where users on non-admin roles (e.g. editors, authors, contributors) would not have access to the compatibility tool and will not be allowed to control the transition status of plugin actions (e.g. can’t change a validation error action from “Accepted” to “Rejected”. See #2673.
@amedina

This comment has been minimized.

Copy link
Member

@amedina amedina commented Aug 1, 2019

  • Provide programmatic access to hide compatibility tool
@westonruter

This comment has been minimized.

Copy link
Member Author

@westonruter westonruter commented Oct 1, 2019

Something else to consider for this is to integrate the compatibility tool into the admin bar. In #3365 there is a demonstration of how to put the frontend in an iframe in a paired browsing experience. In this experience, the parent window could add additional UI at the top for managing the validation errors in the AMP iframe, even without there needing to be an iframe for the non-AMP experience. When changing the validation error status (rejected to accepted) then this could cause the AMP iframe to reload (and persist the scroll position), and the user could more quickly see the effect.

@westonruter

This comment has been minimized.

Copy link
Member Author

@westonruter westonruter commented Nov 12, 2019

Something to consider for guidance is what Plugin Detective where it could guide the user through removing/keeping invalid markup based on answering questions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
v2.0 Planning
  
To do
4 participants
You can’t perform that action at this time.