Make it easier to find and edit the "Home" page in the editor

[getdave]

A critical user task is editing their homepage and is often regarded as the top priority for users.

However, the current WordPress Site Editor presents challenges in locating the current "Homepage", leading to user confusion which I have observed in recent testing sessions.

The root issue lies in the ambiguity of the terms we utilise to label the "Homepage" within the editor.

Problem Description:

WordPress currently exposes users to the underlying template hierarchy, causing confusion.

Depending on the theme's templates, the homepage may be labeled as "Blog Home" or "Front Page," introducing unnecessary technical terminology to the majority (though obviously not all) users.

Proposed Changes:

Ensure Home is always used to refer to the "Homepage".

We may be able do this as follows:

1. Consistent Labeling:

   • Change the "Home" Page item label to always be "Home," irrespective of the template used for rendering.

2. Reduce prominence of Template information:

   • Move the template name into the Page's details panel under a "Template" heading.
   • This removes technical "noise" for the "80%" of users who don't need this information.
   • Still allows more technically inclined users to understand the template in use.

3. Warning for "Template Impact":

   • If the template in use affects other pages (e.g., page.html or index.html), display a small warning notice in the details panel
   • Include a button to allow users to automatically create a custom template specific to the homepage (e.g., front-page.html) so that they can avoid making unintended changes.

Rationale:

• The proposed changes aim to eliminate needless distractions caused by technical terminology for users who are not familiar with or concerned about the template hierarchy.
• In a block-based environment where all elements are editable in the Site Editor, the utility of the template hierarchy in regard to the Homepage is diminished.
• Enhancing the details panel with template information caters to more technical users while maintaining a clear and consistent user interface for the majority.

Related

• https://github.com/WordPress/gutenberg/issues/52335

[getdave]

Also for reference here is some information on the template hierarchy and how it applies specifically to the "Homepage" of a given site. This was generated during a chat with ChatGPT:

---

In block themes, the determination of what affects the homepage follows a structure similar to traditional themes but with HTML file extensions. Here's a summary:

1. Default Behavior:

   • Block themes, like traditional themes, set the site's homepage to display the latest blog posts by default.
   • The template file home.html is used to render the blog posts index.

2. Template Hierarchy for the Front Page:

   • The front-page.html template file takes precedence over home.html if it exists.
   • If front-page.html is not present, WordPress looks for home.html.
   • If neither is found, it falls back to page.html.
   • If none of these templates exist, it defaults to index.html.

3. Static Page Setup:

   • If the front page displays a static page, WordPress looks for front-page.html first.
   • If front-page.html is not found, it looks for home.html.
   • If neither is present, it uses page.html.
   • If none of these templates exist, it defaults to index.html.

[jameskoster]

There's definitely some gnarly-ness to address here, so thanks for bringing this up.

Ensure Home is always used to refer to the "Homepage".

I'm not sure we should do this when a static homepage is set. In that case the current behavior (displaying the page name with the home icon at the top of the list) seems fairly reasonable?

Static homepages are handled this way regardless of which template resolves.

Side note: there does seem to be a pretty big bug here... if you set a static homepage and add a Front Page template, the page details panel and Inspector should tell you that it (Front Page) will be used, that's not the case. And it gets worse, if you click any of the 'Edit template' flows in the full-screen editor, you get taken to the wrong template. This only occurs in the Site Editor. I'll open an issue.

---

This issue seems most egregious when the homepage is set to display latest posts. That's when the template name (which can be Index, Blog Home, or Front Page) is displayed in the Pages list, with the home icon again. The icon helps a bit, but the variable name can definitely be confusing, especially as the names aren't all that intuitive.

We could try a static "Home" label as you suggest, but it's worth noting that the 'homepage' isn't technically a page in this case, so to change its appearance the user must edit one of the aforementioned templates anyway. Additionally I see a lot of potential for confusion here. E.g., if Index is labelled "Home" in the Pages list, would it also be labelled that way in the Templates list? What if you then want to add a home.html template? Or front-page.html? They can't also be labelled as "Home", right?

Could there be a middle-ground, where the page is labelled as "Home", but instead of an edit button in the details panel there's an ellipsis menu with "Edit homepage template" and "Homepage settings" actions? That way it's a bit more obvious that the homepage is template-driven. Especially when coupled with the enhancements planned in https://github.com/WordPress/gutenberg/issues/55025. Here's a quick visual:

[getdave]

@jameskoster Thanks for the detailed response 👍

I'm not sure we should do this when a static homepage is set.

I'm not convinced. It's still the "Homepage" it's just a specific page is used. I would still vote that most users think the page that resolves when they go to www.mydomain.com is the "Homepage" whether or not it's technically another Page within WordPress. Therefore I would suggest we retain the Home and then either:

• append the actual name of the static Page next to the label (e.g. Home (Welcome).
• provide information in the details panel for the page that it's actually a static page set to Welcome

Again this comes down to being consistent with the nomenclature.

The icon helps a bit, but the variable name can definitely be confusing, especially as the names aren't all that intuitive.

This is 100% what I'm getting at. This is a huge pain point for users. They shouldn't need to understand any terminology or setitngs to be able to edit what shows up when they view www.mydomain.com.

We could try a static "Home" label as you suggest, but it's worth noting that the 'homepage' isn't technically a page in this case, so to change its appearance the user must edit one of the aforementioned templates anyway.

I understand this. However, I really don't think users should need to in order to get to the place where they can edit the homepage contents.

Could there be a middle-ground, where the page is labelled as "Home", but instead of an edit button in the details panel there's an ellipsis menu with "Edit homepage template" and "Homepage settings" actions? That way it's a bit more obvious that the homepage is template-driven. Especially when coupled with the enhancements planned in https://github.com/WordPress/gutenberg/issues/55025. Here's a quick visual:

I like this suggestion and your mockup. It means we can always ensure users get to the right place to edit their homepage. It also resolves my requirement to have consistent nomenclature around the concept of "Home" from a user perspective rather than from a WordPress perspective.

[jameskoster]

append the actual name of the static Page next to the label (e.g. Home (Welcome).

This would be a little strange if the static homepage was titled Home. The menu label would be "Home (Home)". (With a home icon for good measure 😁)

provide information in the details panel for the page that it's actually a static page set to Welcome

That might work when Front Page exists, but if the homepage is just a regular page then this would over-complicate an existing UX.

I still feel that in the case of a static homepage, the home icon (and emphasised positioning at the top of the list) is adequate in communicating the nature of the page. Using the page name helps create some distinction between homepage types too (latest posts vs specific page).

For the latest posts situation I 100% agree – the user shouldn't have to understand the inner workings of the template hierarchy. But since it is so intwined with how the homepage settings work, we just have to work around it as best we can until something like the "dumb template" idea can be implemented.

[getdave]

This would be a little strange if the static homepage was titled Home. The menu label would be "Home (Home)". (With a home icon for good measure 😁)

😄 I think we could make that one an exception. It would read Home.

...the home icon (and emphasised positioning at the top of the list) is adequate in communicating the nature of the page

I understand - it does feel like it would be sufficient. However, from the recent user testing I've been involved with I've observed the opposite behaviour. Users expect to see the word "Home" and if that isn't there then they have to think - which they shouldn't need to do. By using the word Home we remove ambiguity.

If a given Page is used as the "Homepage" then there's an argument that it's more useful that it's labelled Home rather than Welcome.

But since it is so intwined with how the homepage settings work, we just have to work around it as best we can...

I'm hoping that what I'm suggesting is a sort of work around, but one that is focused on improving the labelling of the "Homepage" concept within the UI which is currently fragmented and confusing.

Are you saying we can't progress any of this relabelling at this point?

If so can you help me to understand the roadmap for solving the problems illustrated above?

[jameskoster]

I'm not saying anything either way, just sharing thoughts :)

Re-labelling for the latest posts scenario (as per the mockup above) seems worth a try, if it's easy to put together.

For arguments sake I mocked up the static homepage scenario:

I think my main gripe is the discrepancy between the panel title and the title bar in the Editor when you click edit. But I confess it's not as bad as I feared.

If we think about this "Home" panel more like a settings UI then we might take it a step further by surfacing the homepage options here:

Edit: It goes without saying – all of these mockups should be considered rough. There are sharp edges to polish and copy to refine.

[getdave]

@jameskoster Thanks for being willing to dive in here. The explorations you've shared are really helping to flesh this out.

I think my main gripe is the discrepancy between the panel title and the title bar in the Editor when you click edit. But I confess it's not as bad as I feared.

I would agree it doesn't seem that bad at all. Again we can alter the top bar to be context aware and use the word Home there as well. I wonder if you would consider altering your mockup to show that?

If we think about this "Home" panel more like a settings UI then we might take it a step further by surfacing the homepage options here:

Yes. I think we could surface those options there like you've shown 👍

We still have the problem of template vs content which is potentially confusing. But improved labelling and what's shown in your mockup would improve things a lot in my view.

I'm not saying anything either way, just sharing thoughts :)

To avoid confusion, I was trying to understand if you were saying "no, this won't work". It sounds like that's not the case 👍

[jameskoster]

You mean like this?

We'd need to think about the Inspector too. Maybe that includes a Settings panel with the homepage options. If you select a static page then the Summary and Content panels appear.

[richtabor]

If we think about this "Home" panel more like a settings UI then we might take it a step further by surfacing the homepage options here:

I kinda think we don't need to better surface the existing reading controls in this block theme era. When you set a page as the front page, rather than editing the home "template" things get so much more confusing. If you want a blog for your homepage, you'd pick a home template with a blog on it.

[getdave]

I guess the exception to that rule would be if your site is already configured with reading settings? Then it might be useful to have a way to turn them off?

Either way they probably shouldn't be something that's a primary action that's given visual prominence.

[jameskoster]

@richtabor what about the opposite – static homepage with separate blog page? Doesn't WordPress need to know specifically which page is the "posts page" to generate permalinks etc?

I feel like removing the reading settings is linked to the "dumb template" idea. I like that idea a lot, but it's technically challenging considering backwards compatibility.

[richtabor]

Doesn't WordPress need to know specifically which page is the "posts page" to generate permalinks etc?

Yes. A permalink for the posts page is needed. Perhaps we should be able to set posts page independently from the home page? Which would also apply the blog home details view to that page. I detail this a bit further here.

[jameskoster]

Perhaps we should be able to set posts page independently from the home page?

Yup, the trick is making the UX seamless. One option could be, when a posts page doesn't exist, there's an "Add blog" option attached to the the "Add page" button. When that page is created it is assigned to be the 'posts page' behind the scenes.

Then if you want to make the blog the homepage there's an option to do so in the details panel:

[creativecoder]

I want to confirm the importance of this! I've been observing users creating themes in the Site editor this week, and it seems logical that going to edit the "Blog Home" template would modify the home page. But it doesn't work if you don't have the home page set to show latest posts!

I think it's okay that the template labels are different that the file names bound to the template hierarchy. The UX is just too confusing, otherwise.

[getdave]

To recap the above - there seems to be a consensus that:

• users rely on the terms Home / Homepage to find what they see when visiting https://mywebsite.com/. Everything else is just noise to them.
• We must afford options that provide full backwards compatibility with WordPress "homepage settings" and conventions - however that doesn't mean we need to expose them with equal prominence to new users.
• Having a single Home option which drills down into a settings view showing how your "Homepage" is currently configured seems like a good option. We can streamline this setting to prioritise new users and hide complexity.

[jameskoster]

Home and posts page are now marked in the Pages data view which helps with this issue a bit:

One big missing piece is when front page is configured to show latest posts. In this case the 'homepage' doesn't appear in the pages list at all, because technically there is no page associated with it.

I wonder if in this case we should spoof a homepage record in the pages data view? The edit flow would match editing the page_for_posts when a static home page is set.

[richtabor]

Yes, if I have the blog set as my homepage, I expect to see it listed in the pages of my site.

Why is the label "Front Page" rather than "Home"?

[richtabor]

I'd also expect perhaps the home page to be surfaced as the first page perhaps.

[jameskoster]

Yes, if I have the blog set as my homepage, I expect to see it listed in the pages of my site.

I've opened an issue for this specific flow here: https://github.com/WordPress/gutenberg/issues/60772

Why is the label "Front Page" rather than "Home"?

Reading settings refer to the "Homepage", so that's an option too. Agree this should be changed.

I'd also expect perhaps the home page to be surfaced as the first page perhaps.

I agree that 'special' pages should probably given additional prominence, but I'm a little uncomfortable with adding exceptions to the sorting logic. An alternative approach could be to add a generic 'pin row' feature to the data view component. Such a feature could be useful for third party consumers. Special pages could be pinned by default, but the user could also turn it off.