[UX] Better action button and page title for the layout reorder page.

[klonos]

When there are multiple layouts configured under the same path, a "Reorder" button is rendered in the layout listing page, in the grouping row for those layouts:

I have not come across this feature before, because the sites I was working with had very simple layout needs. When I first saw this button appear, my first thought was that it is used to reorder layouts merely for visual purposes, but then realised that it is meant to be used to change the priority that will be given to layouts when doing condition matching (1st match in the list wins).

I think that we can do better with the label of that button, as well as the page title of the respective form.

---

PR by @klonos: https://github.com/backdrop/backdrop/pull/2412

[klonos]

...I went with "Configure layout priority" for my PR, but suggestions are welcomed:

...and I also changed the plain "Reorder" page title for the form in /admin/structure/layouts/reorder to mention the path of the layouts being reordered:

[klonos]

...hmm, I wonder if I can squeeze in a fix for the breadcrumb in that page to point back to the layout listing page.

[klonos]

...OK, PR updated to also fix the breadcrumb in /admin/structure/layouts/reorder:

That one was a simple fix, but a nice travel back in time... so I initially thought to use backdrop_set_breadcrumb(), but then thought that there must be a better way. Research brought me to Better breadcrumbs for callbacks, dynamic paths, tabs, which was closed as a duplicate of Breadcrumbs don't work for dynamic paths & local tasks, which in turn was closed in favor of Breadcrumbs don't work for dynamic paths & local tasks #2 after the original issue reached ~300 comments ....didn't you just love those kind of issues in d.org? 😅 🙄 😜

...anyway, the result of that 2009-2013 ordeal was http://drupal.org/update/modules/6/7#menu_breadcrumb (emphasis mine):

MENU_CALLBACK meaning has changed for breadcrumbs, and some other menu API changes

In order to have breadcrumbs work better, the meaning of the MENU_CALLBACK constant changed. In your module's hook_menu(), you should only use 'type' => MENU_CALLBACK for items that are real callbacks (i.e., hidden, internal callbacks, typically used for API calls, with no menu or breadcrumbs). Previously, although MENU_CALLBACK was documented to have the same meaning in Drupal 6.x, items with type MENU_CALLBACK still had breadcrumbs. They don't any more, and therefore the menu routing processing is much faster.

...oh the fun for a single line of code to change 😄

[stpaultim]

I think that this is an improvement. My initial concern is that the label is too long and that we ought to be able to shorten it. It occurs to me that the word "Configure" is unnecessary. We don't say "Configure Menu Settings," we just say "Menu Settings."

I think that "Layout Priority" would be sufficient, the word "Configure" is implied and unnecessary.

[klonos]

You are absolutely right @stpaultim ...I have updated the PR:

[stpaultim]

I like it, but I'm not sure if we should get more opinions on something like this before marking it RTBC?

[olafgrabienski]

Maybe better to use a verb, as it's in the Operations column. I see that "Configure layout priority" is lengthy, so I suggest another one: "Change priority". It's shorter, and in my opinion also more easy to understand.

[jenlampton]

I have a problem with the word "priority", because this setting has nothing to with the priority of a layout. In fact, this order is more like the opposite.

Layouts here are selected in an if-else fashion, which means your most obscure ones are usually first (if A and B and C and D) with your highest priority ones (otherwise only if Z) coming last. For most of my sites, my highest priority layout comes last because it's also the fall-back or catch-all layout.

I have no idea what this order is called... but I like "Re-Order" as the button label, because then we don't need to know :)

"Re-Order" is also an exact port from Panels. People who have experience with Panels in Drupal will find the term familiar.

edit: removing 1.12 milestone, adding new milestone review label

[klonos]

"Re-Order" is also an exact port from Panels. People who have experience with Panels in Drupal will find the term familiar.

This is a fair point, but...

I have a problem with the word "priority", because this setting has nothing to with the priority of a layout. In fact, this order is more like the opposite.

Then there must be some disconnect here @jenlampton. Here's what the help text in the /admin/structure/layouts/reorder page reads currently:

Layouts at the same path are selected based on the first layout that matches its conditions. Reorder the layouts on this page to affect the layout that will be used first.

...to me the above clearly translates to prioritisation (similar to firewall rules for example). Are you saying that this is not what is happening in reality?

[jenlampton]

Layouts at the same path are selected based on the first layout that matches its conditions. Reorder the layouts on this page to affect the layout that will be used first.

That description is correct. To me, that does not translate to prioritisation, because my high-priority layouts always come last. They are most important, so have the fewest selection rules. The crazy edge-case layouts (that are low priority) have to come first because they have a lot of selection rules that need to match in order to be used.

I'm only squabbling here because I don't want people to put their layouts in order of "Priority", and then wonder why the first one is always being used, when in fact they are executed in this if-elseif-else fashion (which -- depending on how they've set up their conditions -- may have nothing to do with the actual Priority of their layouts).

Now, I haven't ever set up firewall rules - so I don't have that definition of "Priority" in mind - I am using only my english language definition :)

[elainejut]

I suggest just using "Change order" for the button. It is simple enough to understand the idea of the button, such as "Reorder," but might be a little more clear. Additionally, the respective form can give more information.

The description in the respective form ("Layouts at the same path are selected based on the first layout that matches its conditions. Reorder the layouts on this page to affect the layout that will be used first.") can be more clear. This description can be longer and more detailed so that the title of the page can be shorter and the button doesn't have to be super clear either.

[aparwani02]

I suggest just using "Change order" for the button. It is simple enough to understand the idea of the button, such as "Reorder," but might be a little more clear. Additionally, the respective form can give more information.

The description in the respective form ("Layouts at the same path are selected based on the first layout that matches its conditions. Reorder the layouts on this page to affect the layout that will be used first.") can be more clear. This description can be longer and more detailed so that the title of the page can be shorter and the button doesn't have to be super clear either.

I agree.

[elainejut]

I suggest just using "Change order" for the button.

Or something like "Manage order"

[jenlampton]

I'm concerned about Change order because that could be a noun or a verb. People expecting to be able to submit a change order by clicking that button will be confused when they are presented with a form to re-order the items. (does this bother anyone else? Maybe it's just me...)

Manage order is slightly better in that it's not as ambiguous, but it's not as common a usage as Re-Order, at least in English.

I know I'm saying this again but... Re-order also has the benefit of being the same language as was used in Panels, so people upgrading from Drupal 7 will already know what that means.

[klonos]

How about this: we (conditionally) show the same help text as the one in each individual reorder page, also in the main "Manage layout" page. That way, we can leave the button label as "Reorder".

My only concern with this is that if the help text is placed at the top of the page, above the layout table, then it may get "disjoined" from the actual thing that we are trying to describe (especially on sites with many layouts, where that table can get very long). Perhaps if we included the help text in a table row?

Rough mockup:

[stpaultim]

I think that any of the proposed improvements are better than status quo. I agree with Jen regarding use of the word priority.

I am fine with recent suggestion by @klonos - but, taking a stab at something shorter just in case I come up with something better:

CURRENT PROPOSAL: "Layouts at the same path are selected based on the first layout that matches its conditions. Reorder the layouts, to affect the layout that will be used first."

1. "Reoder layouts keeping in mind that the first applicable layout will be used."
2. "Place (reorder) layouts in the order you would like the conditions evaluated. The first layout to apply will be used."
3. "Place layouts in the order you would like them evaluated for use. Default layout should come last."

[jenlampton]

Do we need the text about re-ordering on the page where there's no re-ordering? What about:

Layouts at the same path are selected based on the first layout that matches its conditions.

ugh that's still confusing... trying again...

When there are multiple layouts for the same path, the first layout that matches all visibility conditions will be selected.

or even simply...

The first layout to match all visibility conditions will be selected.

[stpaultim]

It was my understanding that the text would only show up for a path when re-ordering was possible.

I think Jen's final suggestion works and is the shortest (and sweetist). "The first layout to match all visibility conditions will be selected."

[jenlampton]

It was my understanding that the text would only show up for a path when re-ordering was possible.

In @klonos's screenshot, the text shows up on the layouts landing page. (I'm not sure yet if I like it there, as it clutters an already confusing page, and it will be repeated several times)

It shows up WHEN re-ordering is possible but not WHERE re-ordering is possible. Re-ordering happens on the re-order page, not the listing page.

[klonos]

Do we need the text about re-ordering on the page where there's no re-ordering? ... It shows up WHEN re-ordering is possible but not WHERE re-ordering is possible. Re-ordering happens on the re-order page, not the listing page.

...why are we not enabling tabledrag on this table again? That way, we'd be done with this, because the reordering would happen on this very same page.

It was my understanding that the text would only show up for a path when re-ordering was possible.

Yep, that's the idea. Currently, the "Reorder" button is shown conditionally, when there are multiple layouts for the same path.

[jenlampton]

Because this UI is overwhelming enough already. Adding more stuff to this interface will likely make the situation worse.

Also, it's hard :)

[klonos]

I initially filed this issue to improve 2 things:

• the page title of the form that allows reordering layouts (that was an easy fix, and I guess no debate about it)

• provide some visual clues for Backdrop novice users as to why the "Reorder" button is only shown on certain layout "groups", while not on others + what reordering is used for.

For the second part, I initially thought that changing the label of the button to be more specific and more verbose could help; but that could only be achieved with longer buttons, which is not ideal.

When we need to explain when something does, we generally use help text; but we are used to help text for fields - not for buttons. The exceptions are the buttons for clearing cache, for reindexing search, and for setting the site in maintenance mode, but all these buttons are "special", in that they have their own page, and the action is performed there.

My point is that when a novice sees that "Reorder" button, the only way to figure out what it does, is to click it. That should not be the case.

[jenlampton]

Why is clicking the button such a problem?

It's a safe thing to do, and if we can properly explain what it's for with more space, and by not making the main page more cluttered or confusing, that seems like a win to me.

[klonos]

Why is clicking the button such a problem?

As a new user of a piece of software, I usually scan the entire screen for options/controls, and I would like to be able to understand what each control does. When something seems "unknown", I either do not touch it (in fear of breaking things), or I get a "feeling lucky" moment and just click away. I think that Backdrop users should not feel any of those two things if we can help it. The "Reorder" button is kinda "mysterious" the way it is now, so it would help if we could make it be self-explanatory to newcomers. As I said, the only 2 ways I have thought to address that were to change the button label and/or to add help text somewhere.

...come to think about it, the thing we are doing here resembles the UI pattern of the "show row weights"/"hide row weights" links we have for tables where reordering of items is allowed. The only problem here is that the reordering happens on another page, whereas in those other cases it happens directly on the table. I am guessing that this is because the reordering does not apply to the entire table here (like it does where the show/hide weight links are being used). Just mentioning this because reusing already established UI patterns feels less "mysterious".

[jenlampton]

Just mentioning this because reusing already established UI patterns feels less "mysterious".

Yes, but reusing already hated UI patterns probably isn't the way to go... What if we added a new UI pattern that's already been proven successful, something like a tooltip?

See https://github.com/backdrop/backdrop-issues/issues/3707