[UX] Help people understand the connection between Home Page Path and Layouts

[stpaultim]

Description of the need

Within the context of this issue https://github.com/backdrop/backdrop-issues/issues/3343 about the "Default Home Page," I raised a related source of frustration for at least one user in the forum who changed the default home page to a specific node, but was confused when the blocks on their home page layout did not appear on their new home page.

If you change the default home page, that page still uses whichever layout is associated with that page - NOT necessarily the "home" page layout. This is a reasonable behavior (in my opinion), but not very clear to users.

The better way to accomplish this users goal, would probably have been to added a node block to the front page layout, rather than changing the default front page. But, how is a new user to understand that.

Proposed solution

I'm open to better ideas, but at a minimum, I'd like to add a line of text under the "Default Home Page" setting that says.

"NOTE: The home page will use whichever layout is currently associated with this path."

I had hoped to include this change as part of #3343 ([UX] System -> Site Information: Sort out issues with setting the default home page), but I'm afraid that issue might be getting to complicated and that this can be broken out and dealt with separately, either before or after that issue gets merged.

Alternatives that have been considered

1 - @BWPanda suggested the following in another issue.

I propose moving the homepage field on the System Information page into a collapsed fieldset (maybe called 'Advanced Settings'?) that, when expanded, displays a warning above the homepage field pointing people to the Home layout and saying that editing this field changes how Backdrop works and therefore should only be done if you know what you're doing.

2 - An info status message that appears IF the user changes this path in such as way as to also change the layout being used on the home page.

NOTE: The path you selected for the home page will uses a different layout.

Additional information

This is the current situation. I would just like to make it a little clearer to users that if they change this path, they may no longer be using the active home page layout.

EDIT: I view this issue as a simple improvement while other more extensive improvements to the home page setting are discussed and worked on. This issue is not about finding the best UI for the home page setting, it's about making it a little better, quickly in parallel with larger improvements to the UI that might also be under consideration.

[stpaultim]

Does it make sense to create a PR for this given the active work on https://github.com/backdrop/backdrop-issues/issues/3343?

[philsward]

Discussing this a bit with @stpaultim on Zulip after running into the same problem myself, I've realized there's a problem with how the "single page" layouts are bundled with the "multi-page" layouts.

I think a better UX would be a separation of single page layouts that override a single path, vs multi-page layouts that override multiple pages.

My recommendation is to do a check against the path and search for the wildcard. If none exists, assume it is a single page layout. If it does exist, assume it is a multi-page layout.

From here, I would separate the layouts page into two tabs: Single Page Layouts and Multi-page Layouts

EDIT: This proposal has been moved to https://github.com/backdrop/backdrop-issues/issues/4841

[indigoxela]

@stpaultim would you prefer this issue to only cover the help text or should proposals for UI improvements also go here?

[stpaultim]

@philsward - I think your suggestion merits additional discussion, but it's not clear to me that it's directly related to my proposal in this issue. I'm proposing a simple (and quick) way to help users understand how the home page layout is applied. Your suggestion is a much larger than that and will likely take some discussion before any action. Let's give it it's own issue.

https://github.com/backdrop/backdrop-issues/issues/4841

I welcome other quick ideas to help users better understand how the home page layout is being used here, but I think that larger changes to the UX for the layout system should have their own issues.

@philsward - Do you think the help text change I proposed might have helped you and/or help others in the future, until we get larger UX improvements in place?

(The goal for this issue is a quick/simple change that will make things a little better while we wait for any larger UX changes to take place.)

[stpaultim]

Listening to @philsward makes we wonder if in fact this confusion is most likely to effect Drupal 7 users that are used to changing the setting for their home page.

I think we've set up Backdrop CMS to dramatically reduce the need to change the default home page, because we already have a customizable home page layout in core. But, this might not be obvious or understandable to newly arrived Drupal 7 users.

Maybe the challenge here is just helping these new users understand the power of the home page layout and how to use it.

[philsward]

@stpaultim yeah, this is going to be a big hurdle for Drupal folks...

99% of the Drupal builders override the home page. Coming here, Drupalers will expect to do the same thing.

There's also the fact that layouts can be pages which is what the home page is but it isn't declared anywhere that is easy to understand at a glance.

See point 6 in the additional thoughts section of: https://github.com/backdrop/backdrop-issues/issues/4841#issuecomment-752721121 which might pave a slightly better UX for this.

[philsward]

Thought: Add text to point people to the home layout

"Before you change the home page path, you might want to check out the Home Layout"

[stpaultim]

Discussion of this issue at today design meeting (and after the dev meeting) led to another idea to help solve this problem. That is reducing the need for users to change the default path for the home page. See: https://github.com/backdrop/backdrop-issues/issues/4849

[stpaultim]

I added this idea by @BWPanda to the original description. I THINK I like this idea better than my original idea, but I'd like to hear other feedback.

I propose moving the homepage field on the System Information page into a collapsed fieldset (maybe called 'Advanced Settings'?) that, when expanded, displays a warning above the homepage field pointing people to the Home layout and saying that editing this field changes how Backdrop works and therefore should only be done if you know what you're doing.

[philsward]

Regarding @BWPanda suggestion, I would add the home page path as the fieldset link or somehow show what the current path is without clicking on the fieldset. (The actual form field should live within the fieldset).

[klonos]

Since #1628 was not discovered when this issue here was created, I'm thinking to at some point take the time to revisit my thoughts and ideas from that issue (it was back in 2016, so lots have changed since 😅 ) and sum them up here, in hope that they will help.

Not sure I agree with the "good first issue" label here @stpaultim

[stpaultim]

Since #1628 was not discovered when this issue here was created

I opened this issue as a short term fix while better longer term solutions are considered for a problem that some users seem to be very frustrated about. I think that https://github.com/backdrop/backdrop-issues/issues/1628 is suggesting ideas for a better solution, but ideas that might take much longer to implement. This issue is about a quick change to the help text while those bigger ideas are discussed.

Not sure I agree with the "good first issue" label here @stpaultim

I applied the "Good First Issue" label because I have a suggested temporary solution of adding some simple help text which I think is a big improvement over status quo. Creating a Pull Request with this help text is a simple task for a newcomer and I'd love to see a PR to that effect (I created a similar PR on this issue https://github.com/backdrop/backdrop-issues/issues/3343 which turned out to be out of scope).

In my view, creating such a Pull Request is sometimes helpful to move an issue along, even if the change is never accepted. I stand by the idea that a first time contributor might easily create a PR for this issue as long as they understand that there is no consensus that this is a good idea or a long term solution.

For the purposes of this issue, I'd like to keep it focused on alternative improvements to the help text or other simple solutions that can be implemented quickly, while we work on larger UI improvements such as https://github.com/backdrop/backdrop-issues/issues/1628.

If we can solve https://github.com/backdrop/backdrop-issues/issues/1628 quickly, then this issue is not necessary and can be closed.

I'm not sure that we have any consensus that creating temporary changes to help text while working on larger UI improvements is a good idea. But, I'm in favor of it.

[philsward]

Regardless of what is decided, I still think an update to the description that points people to the home layout group, should be a permanent solution. (See several comments ago)

At first, I thought a profile that explains how the home layout works and how to modify it would be enough. Then I realized that as a more advance "Drupal" user, I would probably never have even checked out that profile to learn about the home layout and headed to the site info page so I think a permanent change to the description or UI that makes people stop and pay attention before changing it, is still warranted.

[stpaultim]

Another solution for this problem would be to alert a user anytime they change the path in a way that also changes the home page layout.

1) When a user changes this path we check to see if they are also changing the effective layout for the home page and give them either a warning or a status message that says "The path you have selected uses a different layout for the home page than the previous path did."

@jenlampton - Is this feasible? Does this make more sense?

[bugfolder]

From https://github.com/backdrop/backdrop-issues/issues/3343#issuecomment-1007481262:

...maybe, because of the several possibilities of where the home page path could come from, and the significance of it and potential for confusion for new users, this would be another candidate for some expandable description, something like this ([more] is a toggle that reveals the stuff below it):

[jenlampton]

When a user changes this path we check to see if they are also changing the effective layout for the home page and give them either a warning or a status message that says "The path you have selected uses a different layout for the home page than the previous path did."

Yes! This matches my suggestion from https://github.com/backdrop/backdrop-issues/issues/3343#issuecomment-1007123428.

It's very important that the warning about changing layouts NOT be included in the help text for this setting UNLESS a layout is being used. If I were to change this setting from /node to /node/1`, both of which used the default layout, a warning here about layouts changing would be confusing.

I love the idea of hiding this setting in a fieldset, and I would also like to make that collapsed when:

• the setting is /home, and
• the route for /home is owned by layouts module, and maybe also
• the home page layout is enabled?

We can add lots of additional help text in the collapsed fieldset for exactly this use-case -- and we should -- since that's the default for new installs.

But it might be hard for us to tell exactly when we're "changing effective layout for the home page" due to an infinite combination of possible visibility conditions on layouts. If, for example, I set the front_page setting to node/4 and I have a layout for node/% that layout has visibility conditions for something like "Field has value" then whether changing this setting changes the effective layout for the home page or not, will depend on a field value in node 4, and whatever other node I'm replacing it with.

Please provide the path to the preferred content.

I don't like using the word "content" here because in most cases this page won't be a node. So far, we've been very specific in the backdrop interface that content = node. This would be the first instance of breaking that pattern. Whether a view or a layout contains "content" or not depends on a person's definition of "content", and what's in the view.

[bugfolder]

In trying to think about all the possibilities and what to show when, the two variables are:

• what the current setting is (which is often home, e.g., for new installations);
• what the user currently has entered (or is typing in). For this, we could, as we do with layout paths, give "live" commentary on the effects of what they've entered.

So this bit of help text could start by saying what the current setting is and what that implies for where the home page comes from. (This would include the possibility that the current setting is invalid, which can arise if the user set it to a specific node and then deleted the node, then went back to the site info page.)

And then we can have live-updating text that says what would be the result of the value currently entered in the box, warning if the given path doesn't exist, saying if it comes from a layout or elsewhere.

Below that, we could say what the possiblities are (like the text 2 comments up: "...which could be...[list]", which would be expandable from a "details" toggle.

How's that sound in broad outline?

[klonos]

...we could, as we do with layout paths, give "live" commentary on the effects of what they've entered.

I like that idea 👍🏼 ...especially now that we have a pattern elsewhere in the admin UI.

How's that sound in broad outline?

Yes, I like the suggested ideas 👍🏼 ...we'd basically be trying to (as best as possible) dynamically explain what will change.

[bugfolder]

Just noting for reference: we can use #ajax to realize the dynamically-updating text. For the expanding/collapsing example details, use the technique in https://github.com/backdrop/backdrop-issues/issues/5090 once it is merged (so that issue is something of a blocker for this one).