[UX] distinguish single url and dynamic url layout groups on layout list

[stpaultim]

Description of the need

In issue #4839 - we are discussing user confusion over how the default "Home Page" layout in core is applied, especially when the default home page setting has been changed.

@philsward - suggested that creating some distinction between single page layouts and multi page layouts might better help users understand what is happening. I'm opening this ticket to discuss that idea, which goes well above and beyond my simple (short term) suggestion for a change in help text.

Proposed solution

Proposal by @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

[stpaultim]

@philsward - It's not entirely clear to me why the distinction between single page layouts and multi-page layouts is important. Technically, they are the same thing. I can envision that this distinction MIGHT be useful to users, but it's not quite clear how it's useful. Any additional insight on why this distinction is helpful would be useful to me.

I'm guessing that most sites don't use lots of single page layouts (I welcome feedback if this assumption is wrong). Would it be sufficient to better highlight "single" page layouts on this page.

Although, now that I look at this page - I'm noticing that there are three "single" page layouts. Layouts that only effect a single path. Also, I'm not noticing that these pages have headers that are clickable, which is already a step towards distinguishing them as single page layouts.

• Dashboard
• Home
• Kittens

(SIDE NOTE: I would have expected the "Kittens" layout to be listed above the "Pages" layout, since it has priority and is of content type page.)

[philsward]

Two main reasons for separating them:

1. To help new users
   By separating them out and showing Single Pages vs Multi-Pages, at a glance a new user can see the logical workflow between the two methods of layouts. One houses layouts that are designed for single page paths, the other houses layouts that are for multiple page paths.

How it sits now, new users come to this page and get overwhelmed and have no idea what they're looking at or why. There's no "order" to the page.

Let's think of it this way. Imagine going to a store and walking up to a bin that is full of movies, games and music. They are all in the same style and color of case. If you're only interested in movies, you have to weed through games and music just to find the movies. The better UX would be 3 separate bins, each labeled with the respective media type. In this case, someone interested only in video games can rummage through the one bin that only has video games.

2. Scalability
   For a small website with a handful of pages, one page seems fitting. However as the site grows, it becomes more difficult to mentally separate the single path pages from the multi-path pages and more time must be spent trying to find the layout that needs changed.

If I know I need to change the layout for the "/about" path, and there are 25 other layouts in there, I have to weed through all of the unnecessary mult-page layouts to try and find the /about layout. If I work for an organization that brought me onto an existing project where I didn't create the layouts and there are lots of them, I now have to try to weed through someone else's mind to find the layout I'm looking for.

Additional Thoughts / Ideas

1. Add a search
   This idea would also need to show results based on the path. (Example: I know the path I need to change, but I don't know the name of the layout)

2. Color or icons
   Change the color or add icons that distinguish between a single path or multi-path layout. I think a large icon with a single page and a large icon with multiple pages would work.

Single: https://fontawesome.com/icons/file?style=solid
Multiple: https://fontawesome.com/icons/copy?style=solid

3. Physically separate the path type on the same page
   Put all single path pages together and all multi-path pages together on the same page with a heading and gap between the two.

4. Add a "/" in front of the path
   Currently, the path is:
   home
   admin/dashboard

This should probably be:
/home
/admin/dashboard

Or, we should put an inline title with each to indicate it's the path and not a heading

Path: home
Path: admin/dashboard

5. Change the ordering of information
   For me, my eyes train to the name of the layout (Default Layout, Home Page etc.) before they train to the path up in the header. I honestly didn't even notice header was the path until this discussion...

I think visually, changing how the information is displayed might help with the UX of this as well. Maybe get rid of the header and change the spacing with a small card style gap, but have the Title, Path and Template name all housed together.

6. Add "Layout" as a tab to every single page that uses a layout

I think this idea is the winner because instead of going to the layouts admin page to weed through all of the layouts, you go to the page where the layout needs changed and edit the layout associated with it. This also solves the problem of figuring out which layout is actually overriding the page.

With this idea, some sort of notification needs to be put in place on multi-page layouts that warns the user "This is a multi-page layout and changes will affect all other pages managed by this layout".

Given the circumstances that led to these ideas, I set a node to /home but it wasn't being overridden by the /home layout. So which layout is actually overriding it? I have no idea. If I had a "Layout" tab on that node it would have taken me to the "Default Layout" where I could go "Ok, so it's not being overridden by the layout I was expecting, so let's see if we can investigate further and find out why." For new users, having the View Edit Layout tabs on the node / page itself, would lead people toward the proper layout instead of trying to figure out which layout does what. In my scenario of creating a node with /home, I had no idea there was a "layout" that already took over the function of the /home page.

To extend this idea further, the mouse-over of the "Layout" tab should have the title="" set to the name of the layout. Mouse over the tab and it tells you exactly which layout is overriding that page.

[philsward]

Side Thought
This isn't exactly relevant to this discussion but rather encompasses the bigger picture...

At the end of the day, what gets displayed to a user as output is a "page". The fact that a node can be a page, an entity can be a page, a webform can be a page, a layout can be a page etc makes it really confusing as-to "what is actually a page??" New users want to "add a page". They don't care if it's a node, or a webform or a layout, all they know is they want to add a page. The discussion of separating out single page layouts vs multi-page layouts stems from the fact that a layout can be a "page". This thought, stems from a discussion on Zulip where I described how non-tech people love how easy Wordpress is to use vs the Drupal/BD platform. Non-tech people just want to add a page to their site and show text and pictures on that page. They don't care how they get there or how the backend handles it, they just want it to be easy.

Rhetorical question: How do we make the UX encompass the fact that there are multiple types of "pages" and depending on which one you pick determines what you get out of it and make it easy for the average person to figure out?

[philsward]

Regarding idea number 6, this probably won't work because of the conditions that can be applied. There would have to be an intermediary page to show all layouts that can control the output. That could be even more confusing if it isn't executed well. 😕

I think at this point, I would be happy if there was a (better) visual distinction between layouts that control a single URL vs layouts that can control multiple URLs. I believe some UI magic could make it go a long way.

[philsward]

Here's another idea for the "split" design: Add a filter system at the top of the page that will let a person only show single url layouts, multi-url layouts or both (default). Use ajax to hide the filtered results.

[indigoxela]

Just a quick thought regarding the separate tabs/pages for single-page and multi-page layouts:

Wouldn't that require people to know what sort of layout it is? Worst case this leads to more confusion, if people have to scan both pages for the layout they're searching for.

[philsward]

I don't think it will. Maybe at first glance, but I think they would understand real quick that one is for single URL paths the other is for wildcard URL paths.

I think my latest idea of keeping everything on one page and having an ajax filter hide one type or the other is the best approach.

Combine that with a search box that will filter using ajax and I think it would help a lot.

[docwilmot]

I very much dislike the idea of tabs. How about separating paths like this? (Not that I understand or agree with the need here but to try and understand how someone with fresh eyes would see the layout UI).

[philsward]

@docwilmot I'm also leaning away from the tabs idea so no worries there.

That page is hard to customize for a mock-up because of the tables.

I was thinking maybe more of a card style for the UI of each layout.

My biggest hang-up with the current UI is the TR with the path. My eyes don't train to it first. That row acts more like a separator than a header of the layout, probably because of the color contrast with the link color so what I see first are the layout names, not the paths. Combine that with the lack of a front "/" and they look like header titles instead of paths. (I'm approaching this from a "new user" perspective. Once you know what you're looking for, it becomes easier). I just realized (haven't actually tried it) that path "header" groups all of the layouts for the given path... That changes things a bit for my discussion and I'll have to think on it. That actually means the thought number 6 could actually work. Instead of taking the user to the layout config page, it could take them to the layout list page as a link anchor so it shows that paths layout group and list of layouts. Maybe even go as far as having some JS automatically filter out all other layout groups based on the URL query so it only shows that paths layout group.

What you presented is something I was also thinking. A clean separation between single URLs, dynamic URLs and everything else. Three total areas.

[ghost]

When I read this issue title of single-page and multi-page layouts, I think of multi-step forms spanning multiple pages.

Can we therefore rename this issue to something like "single-path layouts vs. placeholder path layouts"?

[philsward]

The original thought was to have separate pages. It has evolved from there, so much so that I'm tempted to close this issue and start a new one with better focus on the tasks needed to pull it off.

[philsward]

Placeholder idea: make the save button sticky to the bottom.

[stpaultim]

@philsward - Not sure if you have seen this issue, but it's related.
Make form submit buttons "sticky" #566

[philsward]

@stpaultim that's exactly what I was thinking 😉 thanks for digging it up.

[klonos]

Would adding filtering in the layout listing page help? I was thinking 2 checkboxes that would allow filtering by single-page vs placeholder layout paths (or both).

[philsward]

I brought up a disconnect in the issue #4871 that "single url" isn't really single URL layout, but rather a layout page vs the dynamic url layouts are actual layouts based on the URL.

Layout pages (single url's) control the path itself, which means that URL becomes "the page". You CAN NOT override a single node with a page layout, which means the layout page is at the very top and controls the path.

For example, if you have a node /about, then try to create a layout with path /about, you have to remove the node from being the controller and give it to the layout.

This creates a disconnect of using a single path for a layout, as the "display" of that path. The current implementation makes it seem like a page with /about, will simply override the display of anything on the /about path. This is not the case as it becomes THE path.

Either we need to rework the way layouts fundamentally works (probably not going to happen but my personal preference) or we need to show the difference between layouts that become the page or dynamically overriding existing paths. It's confusing looking at the layouts page and understanding that a single URL doesn't override the display of an existing path but rather becomes the path. Then you have the dynamic layouts that don't become the path, but rather override the display of those paths.

[jenlampton]

Would adding filtering in the layout listing page help? I was thinking 2 checkboxes that would allow filtering by single-page vs placeholder layout paths (or both).

I don't think so. People would already need to understand the difference in order to use a filter.

"single url" isn't really single URL layout, but rather a layout page vs the dynamic url layouts are actual layouts based on the URL.

Minor terminology nit (since we are talking about terminology here...): everywhere above you say URL in the comment above, I think you mean Path. :) A URL contains the https://www.example.com.../ part at the beginning, a path is what comes after that.

That said, I like the idea of using the terminology Layout page. I think we could also use this for other things that create pages, like Views page or even Content page.

You CAN NOT override a single node with a page layout, which means the layout page is at the very top and controls the path.

Well, it turns out you kinda can, as we found in our testing last week. You can replace that node by using a Layout page at the same path.

For example, if you have a node /about, then try to create a layout with path /about, you have to remove the node from being the controller and give it to the layout.

In the battle for the path /about, Layout wins. So you don't really need to remove anything.

The current implementation makes it seem like a page with /about, will simply override the display of anything on the /about path

edit: Wording Update: A Layout page with the path /about, will override replace anything else.

or we need to show the difference between layouts that become the page or dynamically overriding existing paths.

edit: Wording Update: Layouts that replace the page at that path, vs layouts that are used to render the page at that path.

It's confusing looking at the layouts page and understanding that a single URL doesn't override the display of an existing path but rather becomes the path.

hm... I think when you say "override" maybe you mean something different than I do when I say "override".

• When I say "override" I mean that the current page get's thrown away, and is replaced by the layout.
• When you say "override" do you mean that the Layout is used to render the current page?

Then you have the dynamic layouts that don't become the path, but rather override the display of those paths.

Yeah, you used "override" again here, but in this case it's clear that we're not speaking the same language... I'm going to start saying "Replace" instead of "Override." Would that be more clear? Maybe we should put that word in the UI.

[jenlampton]

(SIDE NOTE: I would have expected the "Kittens" layout to be listed above the "Pages" layout, since it has priority and is of content type page.)

Is there a separate issue for this yet? If not we should create one.

[philsward]

Well, it turns out you kinda can, as we found in our testing last week. You can replace that node by using a Layout page at the same path.

I would need to re-test to get confirmed reproducible steps, but if you create a layout with the path to an existing alias, you are told the alias already exists and asked to delete it in order to create the layout page.

Now, if you use a node as the path, you are free to create the layout. So as you suggested a few weeks back, this is more of a bug than an intended design. Because of this, it makes layouts super confusing that you can override a node path but you can't override an alias path (you can only replace the alias path). Having a better understanding of how layouts was intended to be used, I agree with the design approach but it isn't clear because there isn't that distinction.

I think if this bug is fixed where an alias or existing node path can not be used to create a layout, and create the distinction between a layout page and layout path, it will help the UX flow a bit better.

Yeah, you used "override" again here, but in this case it's clear that we're not speaking the same language... I'm going to start saying "Replace" instead of "Override." Would that be more clear? Maybe we should put that word in the UI.

You might be on to something. That's why I was struggling with the layout pages because I thought that creating a layout with a specific path, simply overrides the default layout or even a dynamic path layout. Nope, the path becomes the page and in this case "replaces" the default layout or dynamic layout. Maybe we're still crossed but in my mind the dynamic Layouts override the default layout.

Layout Page = Replace path
Dynamic Path = Override path

It doesn't help that I'm coming from panels and some things are just enough different that it's throwing me off from past experience.

[jenlampton]

I would need to re-test to get confirmed reproducible steps, but if you create a layout with the path to an existing alias, you are told the alias already exists and asked to delete it in order to create the layout page.

Not quite. You are instructed on how to create a layout that will be used to render the current page, rather than one that will replace it.

Maybe we're still crossed but in my mind the dynamic Layouts override the default layout.

Interesting, here's a source of even more confusion. Previously we were misscommunicating about "overriding" what gets output on the page, but here we're talking about "overriding" which configuration will be used... These are similar, but not exactly the same thing.

I think we should avoid using the word "Override" at all -- especially because it also has these configuration connotations.

Layout Page = Replace the page at this path
Dynamic Path = Render current pages at this path, using this layout.

[philsward]

Not quite. You are instructed on how to create a layout that will be used to render the current page, rather than one that will replace it.

At first glance, this was what I was expecting from a layout page that used a specific path. Disable the existing layout and use the specific page layout.

I want to say this is what page manager did on Drupal. It hijacked the path regardless of what was there. It didn't care and as long as the path was "enabled" through the page manager, it ran with it.

[bugfolder]

Just noticed this issue. The separation of single-page vs multi-page layouts in the layout listing page proposed above seems related to the separate issue #5077, which is proposing separating layout-provided pages/layout-overriding-pages. So just mentioning it here.