Discussion: User onboarding, selecting your front page

[carolinan]

What problem does this address?

Choosing a front page remains a difficult task for many users. What if, the Site Editor detected if neither home (blog) or front page templates existed, and then presented the user with a modal dialog where they could choose what type of front page they wanted. Their choice would then be saved for them with the correct settings, without the user needing to change reading settings, page assignments and templates themselves.

Then users could skip the part where they need to 1) Understand how the current theme front page works 2) Know how to replace it manually

Users should be able to dismiss the modal but also re-open it when needed.

Themes could include page patterns, but leave the actual template choice and template creation to the user through this dialog. (So they would include index.html, page.html etc but not home.html or frontpage.html)

I understand that this is not groundbreaking ideas. But I think we need to continue discussing this onboarding as a part of WordPress and not leave it to third-party plugins.

[markhowellsmead]

There are various processes to consider: for example a user who is setting up WordPress for the first time, and another for someone who is installing a theme for the first time. These are two separate processes and the UX (if not the modal content) can be shared between the two.

A step-by-step flow would be the best approach: to explain what's necessary, to provide the options for each step, and to explain what each option does in non-technical language. For example, I can't imagine that your average user would have the slightest idea why you'd choose one permalink structure option over another, and why it's a bad idea to change the structure once all of the content has been created. Right now, the chances are very high that these kind of things aren't even looked at by inexperienced users.

If this modal system were in place—a help centre, named so that it could be understood by anyone who uses the internet—then this could replace the historic help panel in classic views (like the page and post list views). By using the same type of immersive modal which is in use in the Site Editor, this would allow for both short explanations and for long-form multimedia content (e.g. introduction videos). If this content were managed by using a custom post type, then not only WordPress Core but also Themes, Plugins and even content creators could have simple access to extend it.

[carolinan]

@WordPress/gutenberg-design Hi, has there already been desgins created for the settings page (like the reading settings) as part of the admin redesign? I am unsure how these settings pages fit in with the updated dataviews.

[carolinan]

@markhowellsmead I really want there to be a broader discussion about the different user needs and different steps. I don't think the editor should include something that is a half-measure or that might make it more difficult to improve onboarding later: But I think it would be more actionable to focus on the front page selection because the template system is already in place for block themes. It is not a replacement for complete onboarding.

I am not sure how we can get such a discussion started, since its a big undertaking that would likely be a WordPress feature project, preferably with a dedicated lead to make sure that decisions happen.

I also know that @luminuu had many good points about a more complete onboarding API in the outreach channel on the WordPress Slack (account needed) (https://wordpress.slack.com/archives/C015GUFFC00/p1710485192366029?thread_ts=1710471313.627559&cid=C015GUFFC00

[jasmussen]

There's a related discussion in #56244.

I'm not aware of any settings designs, and fundamentally I would expect them to more or less have a similar structure to what exists today — perhaps more legible, the new componentry and the higher contrast that brings, etc. So even improvements to settings pages as they exist today I would expect to largely translate to any new initiatives.

[luminuu]

Copying my post here that was linked by @carolinan above, but feel free to view it in Slack to get the entire discussion this comment was written in:

While the two issues you linked above are more about the general idea of how to work with patterns, I'd see Onboarding as a completely separate thing. In my opinion, when we talk about Onboarding, we should think of an API that theme and plugin authors can use to get their users set up in a short amount of time. Just like WooCommerce has this onboarding wizard, or the Ollie theme had it. I'm thinking of a unified API where steps can be defined, the contents to be displayed and various actions that can be triggered through this onboarding/wizard. Setting the home page could be one option, or setting the language, or choosing the style variation of the selected theme, or configuring a plugin... Imagine a standardized API that could be able to handle all these actions and where individual steps could be chained to create a useful user onboarding. But that's just my idea, maybe we should define first what we understand as Onboarding, so we can all move into the right direction together.

I think the ticket mentioned by @jasmussen is already having a good direction for adjusting the backend to make clearer what the Home template is.

From what I'm understanding @carolinan, do you want to move us forward on the general idea of an Onboarding API in this ticket?

[carolinan]

From what I'm understanding @carolinan, do you want to move us forward on the general idea of an Onboarding API in this ticket?

I think it would be more actionable to focus on the front page selection.

[JosVelasco]

I am reposting my experience here for visibility:

One thing about the current template system is that I usually start by creating the homepage, and I like having access to the Site Editor from the same tab to configure the first things, such as fonts, spacing, colors, etc.

Creating a "real" page and setting it as the homepage would require me to open another tab to access Site Editor tools like additional CSS.

Having access to the same Command Palette from both editors would help.

[carolinan]

In block themes when the user either creates the template or saves changes to an existing template, the content is in the template and the need for using a page is reduced.

• Making the saved template available after you change themes would completely remove the need for selecting a page.
• Teaching users is another challenge.