Enable Reader Mode to use any AMP-first (Standard) theme

[amedina]

Upon selecting Reader Mode as the AMP experience to be enabled, the AMP plugin offers a list with all known AMP-first themes, as per the AMP Plugin’s site Ecosystem page. This will:

• Enable support for non-singular templates , such as the blog index page, category template, author template, and other such archive templates.
• Enable brand synergy between the AMP and non-AMP versions of the site (Site logo/icon, Color palettes, etc.)
• Enable key functional components, either as part of the theme or via block plugins: 
• Enable the AMP plugin developer tools are available in Reader mode

[schlessera]

I think that we might need to rediscuss mode names at that point.

The difference between Reader Mode and Transitional Mode will boil down to: "Officially supported themes" VS "Arbitrary themes". It seems like, apart from that, Reader Mode would actually be Transitional Mode.

So, also, there's probably no point in working on extending Reader Mode, but rather work should go into limiting a copy of Transitional Mode.

[westonruter]

In this scheme, yes, Reader mode is essentially the same as Transitional mode except it is using a different theme's templates for AMP pages. Nevertheless, the theme used for AMP pages would be designed responsively so it would be assured to generate pages that render well on a mobile device.

[amedina]

The different goes further than that in terms of UX. In Transitional mode, developer tools and AMP debugging workflow are available; in Reader mode complexity is hidden. We have been calling these "Template Modes", but it is about use cases and the personas these modes are intended to.

[westonruter]

in Reader mode complexity is hidden

Not necessarily, right? Per #4480 the Reader mode should have the same developer tools made available to the user.

The minimizing of the complexity would be applicable to all three template modes, and that's captured in #2673.

[amedina]

Not really. Reader mode is intended for non tech-savvy users. Dev Tools will be hidden from users since they are not expected to to use them.

Right now no validation errors are compiled and kept when in Reader Mode. #4480 and related work means that validation handling will expanded in Reader mode, but the outcome will not be exposed to users. Instead, users will be able to communicate to their webmaster, or to the proper support forums. From there, qualified users will then get access to validation information.

[amedina]

The important thing is to separate the "Template mode" from the "AMP plugin use case" as a whole. The term Reader Mode encompasses not only template mode, but also the whole UX, including the onboarding flows (#1288), communication mechanisms (#4476, #4477), etc.

[westonruter]

I don't see it this way exactly. There are template modes and there are user roles. A developer user should be able to get all dev tools in Reader mode, and a non-technical user should be able to have dev tools hidden in Standard mode.

An onboarding wizard should be able to identify the user role and the best template mode for the user and their site. If the user is not tech-savvy and they have a site with AMP-incompatible themes/plugins, the wizard should lead to a configuration where Reader mode is enabled and developer tools are turned off.

This wizard wouldn't just be part of the NUX but it also needs to be accessible in the UX of the plugin for users who want to switch themes, and make re-configuring the AMP plugin a seamless process as part of that.