[UX] Configure Layout: "Save" redirects (but shouldn't)

[bugfolder]

When you are configuring a layout on the "Configure Layout" tab (e.g., /admin/structure/layouts/manage/home/configure), the two buttons at the bottom are "Save Layout" and "Cancel".

Clicking "Save Layout" saves your changes and then immediately redirects you to the "Manage Blocks" tab (/admin/structure/layouts/manage/home).

I think that "Save Layout" should save the layout and then leave you on the Configure Layout page.

I can see a reason for the current redirection: in many cases, the next thing you will want to do is manage blocks, so why not go straight there? But the current behavior is counter to the behavior of nearly every other configuration page in Backdrop. In most places, when you save a bunch of settings, you get taken back to the same settings page that shows that the values you just entered are now the defaults.

Furthermore, this redirection is most confusing to people coming from Drupal who are new to Layouts and are exploring this new area. If someone tentatively makes a change to a layout configuration, they're going to expect to see the result of that change, not an entirely new page, where they have to scramble around (or use the Back button and reload) to see the results of their save.

I note that the Manage Blocks page follows the usual model: clicking "Save Layout" leaves on you that page; it doesn't take you to some other page that might be next in the development flow.

So I would like to suggest that we follow the UX model of "saving a bunch of settings leaves you on the settings page" that applies to so many other settings pages.

For the power users who really do want to save and go straight to the Manage Blocks page, there's a simple solution: add one more button:

[Save] [Save and Manage Blocks] [Cancel]

(I might also suggest that since Configure Layout always precedes Manage Blocks chronologically that the Configure Layout tab belongs on the left, but I can see the argument that Manage Blocks gets visited repeatedly so it deserves the prime position.)

[klonos]

Layouts is not the only example where we redirect people to another page:

• Saving a content type configuration redirects you to the content types list. Although saving fields or comment fields on a content type does not redirect you.
• Saving a file type redirects you to the file types list. Although saving fields on a file type does not redirect you.
• Saving a custom block redirects you to the custom blocks list.
• Saving a menu redirects you to the menus list. Although saving menu links within a menu does not redirect you.
• Saving a new vocabulary redirects you to the list of terms within that vocabulary. Saving the configuration of an existing vocabulary redirects you to the list of vocabularies. Saving the fields of a vocabulary does not redirect you.
• Saving a view does not redirect you.

I think that there is a patter there.

[bugfolder]

Nice examples. For content type, file type, custom block, menu, and vocabulary, saving the object takes you to a list of similar objects. For all of those, saving the object takes you "up a level" in the hierarchy {list of objects}->{configure object}->{list of stuff that goes inside of object}. So following that pattern, saving a layout configuration should take one to the list of layouts, rather than to Manage Blocks for the particular layout.

So, yes, there is indeed a pattern there; but it's also different from what Configure Layout does.

I like the concept that "selecting Save shows you the results of what you saved", but going up a level (as in those examples) would still be preferable to "going down". Closest example seems to be saving a new vocabulary, but even there, saving an existing vocabulary doesn't take you to the list of terms (which would be analogous to what Configure Layout does).

[klonos]

I have to think the UX in all this a bit more before I'm able to make further comments 🤔 ...in the meantime, let's see what others think.

[ghost]

For those of us too lazy to go looking through an actual site to see what you're talking about, can someone please add screenshots to the OP of the two pages referred to there?

UPDATE: And then I find myself at a computer with nothing better to do 😄 So I did it.

[ghost]

I'm kind of ambivalent about this.

In most places, when you save a bunch of settings, you get taken back to the same settings page that shows that the values you just entered are now the defaults.

In this case though, from what I saw, there aren't a 'bunch of settings', just one (the layout template), So I can't really see the benefit of staying on the same page. Indeed, I imagine most people will, after changing the layout template, want to see the new template in action and the blocks assigned to the different regions (or at least confirm that the blocks are where they're meant to be)...

[bugfolder]

In this case though, from what I saw, there aren't a 'bunch of settings', just one (the layout template),

Also the title, the path, the contexts, visibility conditions, (and now) the relationships.

I admit that I was influenced by the behavior in 1.18.x noted in #5072, that saving didn't always save one's settings; so I wanted to come back to the settings page to see whether the changes actually "took". But with the change in behavior in 1.19.0 (fixing that issue), that incentive is lessened.

It does seem, though, that Configure Layout is different from other similar Configure <something> pages in not returning to the listing.

Looking at the listings in the Admin > Structure menu, they differ in where Configure occurs in the Operations list:

• Content Types — "Configure" is first item
• Custom Blocks — "Configure" is first item
• File Types — "Configure" is first item
• Layouts — "Configure Layout" is second item
• Menu — "Configure" is second item
• Taxonomy — "Configure" is third item
• Views — "Configure" is first item

It seems like there'd be value in having these listings all behave similarly, with "Configure" always being the first item in Operations, and using "Configure" uniformly (or "Configure <this thing>") uniformly.

[klonos]

How we solve similar UI issues is by placing a set of two submit buttons, one that saves and redirects to the listing + another that saves and edits.

• Creating a new view:
  

• Creating a new content type:
  

Perhaps we could solve this UX issue here using the same pattern: a "Save configuration" button + another "Save and place blocks" button. Thoughts?

[ghost]

Also the title, the path, the contexts, visibility conditions, (and now) the relationships.

Oh OK. I was looking at the default layout. I guess other layouts have more settings... Someone feel free to update the screenshot above then.

[klonos]

Someone feel free to update the screenshot above then.

Done 👍🏼 ...good opportunity to point out that the "Cancel" button in that form should be rendered as a link instead (for consistency with other forms).