Redesign Validation Screens (Developer Tools)

[westonruter]

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]

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

[amedina]

• 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 Enhance Compatibility debugging workflow narrative #2023.
• Redesign information exposure approach (i.e. expose baseline information, and make more complex/advance information accessible on demand)

/cc @pbakaus

[pbakaus]

OMG I'm so excited!

[amedina]

• 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 Allow Developer Tools to be turned off to minimize (even hide) validation error info #2673.

[amedina]

• Provide programmatic access to hide compatibility tool

[westonruter]

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]

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

[westonruter]

See also #3664 (comment):

With the work being done to add stylesheet information to the validated URL screen (#4026), we also need to surface this information proactively in the post editor, in a similar way to how validation errors will get surfaced. One idea would be to incorporate the admin bar item similar to what Site Kit does.

The same admin bar item could also be present on the frontend. Clicking it would trigger a validation request and then show the results right there on the frontend instead of having to go to the validated URL screen.

[westonruter]

First target: upgrade the make the validated URL screen. The validated URLs (post list table) and Error Index (term list table) will come later, especially with #5553.

A dependency for the validated URL screen is the REST API endpoint for validating a URL and retrieving the validation results for a URL (#5552).

[delawski]

@kenrodriguesdesign @jwold I was wondering if we want to keep the scope tight or attempt to do a deep redesign?

By keeping the scope tight I mean porting over the existing core table views to React components. UX improvements like the ones listed in #5191 would be done along the way.

By deep redesign I mean updating the Validated URL screen UI so that it matches the existing Settings page, Onboarding Wizard, and AMP sidebar in the block editor. We've done the first steps towards this goal in #5304 and #5995.

Between those two there's a broad space where we can eventually land so let's keep the discussion open.

[westonruter]

+1 to keeping the scope tight.

We'll need to do a deep redesign with the introduction of PX Analyzer, when the scope of the screen moves beyond just validation data to include information such as provided by PageSpeed Insights.

[jwold]

I spoke with @kenrodriguesdesign a few days ago, and he was quite interested in bringing a new UI to match the settings page and onboarding. Perhaps, depending on the timing, @delawski could implement parts of that, and postpone others.