_Do not alter or remove anything below. The following sections will be managed by moderators only._
step 1 in the Wizard flow, and would ask the user if they're technical. choose mode screenreader mode screenNext button
Observation: Asking if someone is a technical person is not the same as asking if they are technically a person.
If the user is not technically a person, then the plugin should default to Reader mode.
@westonruter Do you think the "Are you technical?" question in the setup wizard can tie directly into whether developer tools are enabled/disabled? So "Yes, I'm technical" would enable them, and "No, not technical" would disable them. Do you know if there's an in-progress branch somewhere implementing this option? I assume it would just be a developer_tools_enabled boolean, correct?
The dev tools enabled option is in the Reader themes prototype PR (#4644), but it needs to be revisited. In particular, the dev tools option needs to not be an option at all, but rather something that is stored in user meta. It needs to be a user-level preference. But yes, the technical question should be linked to this user preference. If you want to implement support for that user preference independent of the option then that would be good. The option would end up being what user roles have access to the dev tools, but probably we should just make them available to users who can manage_options period. So that user option would be whether dev tools are enabled by default for that user role or not. Then again, perhaps we don't even need that option either. We can just have dev tools enabled for admin users by default, but the wizard can allow them to turn it off for them individually.
So I'd say go ahead and press forward with the user preference regardless of there being any option.
Also, the "are you technical" question should probably be a bit more specific. For example, we should reference comfortability with hacking WordPress theme and plugin code and familiarity with web technologies (HTML, CSS, JS). Just being "technical" could mean many things (e.g. a power plant engineer).
Connecting the "Are you technical?" selection to a user-level option isn't 100% making sense to me. Imagine a scenario where a website has (1) an editorial administrator and (2) a technical administrator; each might choose something different on that screen, and the outcome of the wizard and its impact on the site could end up being completely different (editorial person would end up in Reader mode, while technical person could end up with AMP native). But we want both people to feel qualified to go through the wizard and make the right choices.
I'm thinking it might make more sense for this screen not to be about "you" (the user going through the wizard) but rather the capabilities of you and your team. The choices would be more like (1) a simple turnkey solution not requiring development expertise or maintenance vs. (2) a customizable solution befitting an individual or team with web development capabilities. The phrasing might be harder to pin down, but ideally the answer would be the same regardless of who was going through the wizard. What we have now in the comps is not far off. We'd just steer it away from the "you" language.
In this case, we'd still save the answer as an option at the very least to have it persist when the wizard is revisited, but it could also tie into developer tool defaults for those with manage_options roles.
Thoughts, @jwold ?
@johnwatkins0 we may be able to get around this by showing the user that dev tools will be turned on/off and letting them change that if they disagree. We make the smart defaults in the wizard and let them override.
If a website has both a technical administrator and an editorial administrator, it seems very unlikely that the non-technical administrator would be the one tasked with installing and configuring the AMP plugin. In fact, a technical question may even prompt them to ask their technical administrator for help. Otherwise, if the editorial administrator made the wrong choice then the technical administrator could just go in to fix the configuration.
In this case, we'd still save the answer as an option at the very least to have it persist when the wizard is revisited, but it could also tie into developer tool defaults for those with manage_options roles.
I think this can still be stored in the user preference and not an option. In that way it would still persist for that user when they re-enter the wizard, but if a different user starts the wizard then they'd have to answer that question anew.
Something that comes to mind in relation to minimizing validation error messages (#2673) is that if it so happens that there are technical and editorial administrators. Since both administrators would have developer tools turned on by default, there needs to be an easy way for non-technical administrators to suppress them. This could be accomplished by having a button in the editor notice to permanently turn off the warnings, rather than just just to dismiss them for the editor session. Maybe clicking the dismiss button in the notification could even open a prompt asking if you want to permanently hide the validation error messages. I'll add as a comment on that issue.
馃憤 I'll go ahead with tying the "Are you technical?" screen to a user meta field.
This also brings to mind another potential detail for the Template Modes screen (@jwold): when the user arrives on that screen they will see what's recommended, but nothing will be selected by default. But if the setup wizard has been completed previously then maybe we should not only have the existing option checked but also have a note to the effect of "This mode is currently active" to make it explicit. That will surface the fact that the mode is being changed.
So, on the "Template Modes" screen:
1) If the wizard is being used for the first time, we show the recommendation but don't have anything selected by default.
2) If the wizard is being used again, we show the recommendation _and_ select the previously selected option.
And the recommendation may change based on the current user's technical experience. The messaging shown with each template mode may change. But the previously-selected template mode would still remain selected by default. The user could change the template mode based on any changes to the recommendations, however.
QA passed.