[UX] move the clear log messages button to bottom of dblog messages page

[jenlampton]

The question here is: Where should we put this "Clear Log Messages" Button?

There are several UX improvements we are addressing here:

• avoid accidental clicking/deleting FOR ADMINS + DEVS
• prevent confusion from too many available options above the listing FOR ADMINS + DEVS
• reduce the amount of scrolling needed to read the listing FOR ADMINS + DEVS
• make this interface more consistent with the rest of core FOR ADMINS + DEVS
• reduce #of clicks to delete messages ? FOR DEVS (only)

We will eventually want to remove the fieldset around the filters to reduce the number of clicks needed to filter the listing, too. (This will also make this interface more consistent with the rest of core). Our decision here should take that into account.

I indicated the ROLE of the person completing each task above because in Backdrop we put the needs of ADMINS above the needs of the needs of DEVeloperS.

Options as follows.

1. Leave it where it is, at the top of the page, buried in a fieldset:

2. Move it to the bottom of the page, but NOT in a fieldset:

3. Move it to another page, accessed by a tab, like Drupal 8 did:
   

4. Combine the two fieldsets for filtering the current list, and deleting all items to save space
   (no screenshot available)

5. move that button to the Log settings page: /admin/config/development/logging?

Objections to 1:

The clear log messages is inside a fieldset. I understand that we don't want people clicking this by accident, but I'm not sure a fieldset is the way to deal with the problem

I don't know of anywhere else in core where we make users go to the listing page in order to delete items. The delete option is always on another page/tab.

Objections to option 2

[DEVS will] need to scroll down this page

it might seem like a "save" button or something people are supposed to do here, and might increase the probability of people doing it by accident.

Objections to option 3

After doing UX reviews/studies, D8 have decided to remove all tabs and convert them to action links

introduction of [a new] UI pattern of having an action live as a primary/secondary tab. It just does not feel right UX-wise to me.

There have been extensive discussions and user studies in Drupal-land, concluding that things that are actions (such as the "delete" operation), should be buttons/links and not tabs; tabs are being reserved for navigational operations.

Objections to option 4

taking [the Clear Log Messages button] out of the fieldset and then having it anywhere near the buttons for the filters (above, below, to the right) would also be confusing [for ADMINS and DEVS]

If the button can be moved away from the top of the page (above what you're trying to access 99%* of the time), then I agree that a fieldset is not needed. But as long as the button's above the content, it should be in a collapsed fieldset.

Objections to option 5

it's convenient for DEVS to have here - right where you are anyway when you are debugging

Definitely wrong place with too long path, we need clear log button on same screen where we read it.

---

Original Issue

---

The 'Recent log messages' page has several UI patterns that are unusual for core.

The clear log messages is inside a fieldset. I understand that we don't want people clicking this by accident, but I'm not sure a fieldset is the way to deal with the problem, especially since it separates the filters at the top of the page with the list the filters are acting on, below the fieldset. How about we 1) remove the fieldset and 2) move the button to the bottom of the page.

First, the filters for the log messages are hidden away in a fieldset. This means you have to open the fieldset to filter the messages. Second, the Severity filter is a multi-select widget, which is nearly unusable. This should be replaced with checkboxes instead. See #3051 for these issues

---

PR: backdrop/backdrop#2142
PR by @opi: backdrop/backdrop#2148
Alternate PR by @indigoxela: backdrop/backdrop#3048 (closed in favor of a contrib module)
Alternate PR by @klonos: backdrop/backdrop#3055

[serundeputy]

This PR: backdrop/backdrop#2142

Addresses the first and third bullets:

• removes fieldsets
• moves the clear messages to the bottom and adds button-danger class

The second bullet use checkboxes is not addressed:

• I tried to use checkboxes, but I could not get the connection between type and severity to persist with checkboxes.
• I think this improves the UX quite a bit, and we should hold off on the second bullet and address that UX issue when we get the select2 library in core

[findlabnet]

When I open this page, I'd like to see logs itself, but not filters/buttons occupying a large part of the page (same as in D8?).
What's wrong with fieldsets? And yes, I use filters everyday, same as "clear log messages" button.
IMHO, we can combine two fieldses to one, something like "Manage log messages" and get even more space on screen for messages.

[serundeputy]

Sounds like @findlabnet and @jenlampton have conflicting ideas about what is best for this page.

Combining into a single fieldset will be tricky as they are two completely different forms being added to the page with a $build variable.

Talk it over and see if we can come to consensus.

[jenlampton]

Maybe we should get a ux designer to weigh in?

…

On Sun, Apr 22, 2018, 12:37 PM Geoff St. Pierre ***@***.***> wrote: Sounds like @findlabnet <https://github.com/findlabnet> and @jenlampton <https://github.com/jenlampton> have conflicting ideas about what is best for this page. Combining into a single fieldset will be tricky as they are two completely different forms being added to the page with a $build variable. Talk it over and see if we can come to consensus. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2353 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAYSR-1uStRoP36RsEK0Ql2dk5eVIVudks5trNv_gaJpZM4K6Q4Q> .

[ghost]

I'm not a UX person (just a regular developer)...

I like moving the 'clear' button to the bottom (and out of a fieldset), but I don't like the space the filters in the screenshot now take up vertically.

If select2 is close to being added to core, I'd suggest leaving the filters in a fieldset until they can utilise that instead.

[jenlampton]

If select2 is close to being added to core, I'd suggest leaving the filters in a fieldset until they can utilise that instead.

What if it's not? Should we hold off on this change until it is?

[ghost]

What if it's not? Should we hold off on this change until it is?

Probably. I think the 'clear' button change can go ahead if others are happy with it, but without a way of making those filters take up less vertical space and still be user-friendly, I don't think we can do anything yet...

[jenlampton]

Sounds good to me.
Rescoping this issue to focus on moving the button for 1.10. I moved the filters fixes to #3051 which now depends on #1800

[opi]

PR backdrop/backdrop#2148 is a reroll of backdrop/backdrop#2142 with a reduced scope.

[findlabnet]

Thanks @opi, but it is still not clear to me what we have achieved with this change.
To be honest: on production environment this button should not be used at all (IMHO), but on dev (where it is very useful) I need to scroll down this page so many times, so where is our profit?

[opi]

by spliting the 2 forms (filter & reset), we reduce clutter for admin user ; Also, action buttons are often on page bottom, this is a common UX pattern.

[findlabnet]

common UX pattern

Do you like an idea to scroll down 2-3 screen heights any time you need to clear bunch of already unuseful log messages?
Common UX pattern for Drupal admin - looking for this button on top of page, or I wrong?

[jenlampton]

This change is in preparation for moving the filters out of their fieldset to bring them more in line with how the filters look and work on the other admin pages.

I don't have strong feelings about having the button at the top of the page (as opposed to the bottom) -- though it was convenient (for me) to have it at the top. I do worry that taking it out of the fieldset and then having it anywhere near the buttons for the filters (above, below, to the right) would also be confusing.

The primary benefit of this having this change on its own is that it brings the filters closer to the results that were filtered.

[opi]

Common UX pattern for Drupal admin [...]

Backdrop is a good place to fix some odd drupalism, and become a great product on its own <3

[laryn]

Side note on the UX pattern in question: I was struck the other day after editing a View and then a Layout that the action buttons are not always consistently placed. (top right / bottom left respectively, although bottom does seem more common in the rest of the interface)

[findlabnet]

My question is:

Do you like an idea to scroll down 2-3 screen heights any time you need to clear bunch of already unuseful log messages?

This is like to UX improvement?
"New" is not always equivalent "better", this is about

to fix some odd drupalism

[jenlampton]

@laryn I think thee's an issue somewhere about Views' funky submit-button location, but if not can you create one?

@findlabnet there are several UX improvements we are addressing here 1) bringing the filters closer to the form 2) eventually, getting the filters out of the fieldset, which 3a) makes this interface more consistent with the rest of core and 3b) reduces the number of clicks needed to accomplish the goal of filtering this list.

I think your point is that there is also a UX regression in moving the button to the bottom of the page, for the cases when this log is full of messages that you would like to delete.

In my experience, most of the time I am on this page I do not need the Clear log messages button, so I personally won't mind scrolling to the bottom of the page when I do need it.

This is probably the same reasoning behind burying the button it in a fieldset: In most cases, that extra click is not needed, because the button isn't needed.

I'd prefer to focus on making this interface as good as we can for the most-of-the-time experience, and if that means it's slightly less good for the some-of-the-time experience, I'm okay with that :)

[laryn]

@jenlampton I found this and this RE: views submit button location.

[findlabnet]

@jenlampton, thanks for clarifying, but as I mentioned above, on development stage I personally use this button very intensively and this is only case when this button is needed.
So, for me moving button to bottom means UX regression, but maybe it is for me only.

[jenlampton]

@larn I've created #3054

on development stage I personally use this button very intensively [...] So, for me moving button to bottom means UX regression, but maybe it is for me only.

@findlabnet It's not only you, but in Backdrop we put the needs of developers below the needs of site architects, and below the needs of end-users. (see https://backdropcms.org/philosophy#importance)

[findlabnet]

Maybe I lost difference between philosophy and religion, but I don't see site architects (BTW, who is site architect in this context, maybe site buider?) or end-users as users of this button.
Anyway, it is just my opinion only.

[jenlampton]

but I don't see site architects or end-users as users of this button.

Yes! That's the point exactly. :)
They don't need this button, so it doesn't matter if we move it "out of the way". Those people will need the list of log messages and the filters for them, which is why we want those things to come at the top of the page :)

(Architects are the people we called "site builders" in Drupal. Here, in Backdrop, they get a more respected title.)

[findlabnet]

@jenlampton thank you! I got the point. ;)
So, when this changes is merged to mainstream - just need build contrib to get it back for low-priority users.

[klonos]

FTR, @jenlampton I disagree with your last review. Take the "Delete" button in the node edit form for example:

...that also looks "friendly", and we don't have any specific "danger" indication or text accompanying it. There's a confirmation dialog when you click it, with a danger button and text that explains things:

And this pattern is basically the same with canceling user accounts, deleting content types, layouts, menus, views etc. I am not doing anything differently in the current PR 🤷

One thing that we could do in order to avoid accidental clicks, is to float the button to the right (left on RTL languages), which is also the pattern we seem to be going for with the buttons to be added as part of #4289:

That way, it's not "visually grouped" with the main-focus elements on the page (breadcrumb, page title, filter fieldset label etc.), and by it having no "danger" style, it is also not "screaming" for attention. You still have easy access to it if that's the task, w/o having to scroll or click on a fieldset to show the option.

[jenlampton]

But there's no confirm form on this page, and there are on those pages. Those pages need one because they delete important things like content, this page doesn't need one since it's only clearing away clutter, so shouldn't we use a more dangerous button color?

[ghost]

I vote for escalating this to the PMC, then they can decide what direction to take (parking this, top or bottom of the screen, danger class or not, etc.).

[olafgrabienski]

But there's no confirm form on this page, and there are on those pages.

Clarifying before we continue in the PMC: I've just had another look at the PR sandbox site. It (rightly) does provide a confirm form.

[ghost]

I updated a comment above that I made earlier this year, but I'll add it here too, since there seems to be some confusion about when to add the 'danger' class (i.e. red button) and when to have a confirmation form.

As far as I can tell, the pattern Backdrop uses is like this:

• If clicking a button will perform a destructive action straight away, then that button is given the 'danger' class (i.e. styled red). For example, confirmation forms when deleting a node, etc.
• If clicking a button displays a confirmation form, then technically that button is not destructive and is therefore styled normally. For example, the Delete button at the bottom of node edit forms.

The current situation for the 'Clear all log messages' button is that there is no confirmation form and therefore the button is rightly given the 'danger' class (styled red).

Some people are proposing that a confirmation form be added, in which case this 'Clear all log messages' button will be styled normally (i.e. grey) and the new button on the new confirmation form will be styled red.

The confusion seems to be stemming from screenshots of the new, grey button. Since screenshots don't show the addition of a confirmation form, people are thinking we're removing the 'danger' class without knowing that a confirmation form (with a red button) is also being added/proposed.

I hope that clears that up.

[ghost]

In today's Design/UX meeting this issue was discussed and PMC members in the meeting seemed to suggest that they would need a summary of this issue before they discuss/vote on it. I've therefore gone ahead and made the following summary after re-reading through this issue:

---

Problems

1. Destructive action button too prominent at top of page
2. Need to scroll past button to get to log listing
3. Additional click(s) needed to clear log messages

Solutions

1. Leave it as-is
   Problems fixed: None
   Thoughts:

   • Fieldset not the best solution for avoiding accidental button clicks
   • Elsewhere in core, the delete button for a listing is on another page/tab

2. Move button to bottom of page, no fieldset
   Problems fixed: 1, 2, 3
   Thoughts:

   • Need to scroll down the page to clear messages
   • Might be seen as an action button (i.e. made more prominent)

3. Move button to a new tab
   Problems fixed: 1, 2
   Thoughts:

   • This is how Drupal 8 does it, but they're in the process of changing it (based on research/studies)
   • New UI pattern (we don't do this elsewhere in core)

4. Move button into Filter fieldset (and have it expanded)
   Problems fixed: 2, 3
   Thoughts:

   • Might be more confusing having it near filter button(s)
   • Button should not be immediately visible above listing (i.e. fieldset should be collapsed)

5. Move button to Logging and Errors page
   Problems fixed: 1, 2
   Thoughts:

   • Not as convenient, moving button to separate section of the site

6. Move button to floating section at bottom of screen, display confirmation in modal
   Problems fixed: 1, 2, 3
   Thoughts:

   • 'Sticky' button might be too visible/prominent
   • Not consistent with rest of UI (unless [UX] Make form submit buttons "sticky". #566 is implemented)

---

I hope this is sufficient for the PMC to make a decision on this.

[findlabnet]

IMHO, to make the system more attractive to the end user, we don't need endless movement of buttons or polish of the tongue, but instead we need something really valuable - for example, correctly working paragraphs (available right out of the box.)

[indigoxela]

to make the system more attractive to the end user, we don't need endless movement of buttons or polish of the tongue, but instead we need something really valuable - for example, correctly working paragraphs

@findlabnet although this endless discussion is hard to follow, this issue deals with a real problem: two very alike buttons (fieldsets actually), next to each other. In switched order compared to Drupal, one of them with a destructive action. That's an unnecessary pitfall.

It's simply not helpful, if you try to divert us with something unrelated, for instance paragraphs. That whataboutism is frustrating for people, who try to contribute something useful to get some progress here. If you don't have the problem, this issue tries to solve, fine. But please accept that other people do have a problem with it.

[findlabnet]

Sorry for my so wrong opinion.
Will not participate in this thread anymore.

[klonos]

Thanks for taking the time and putting the effort to summarize things and update the issue summary @BWPanda 🙏 🙏 🙏 🙏

One comment re this:

I don't know of anywhere else in core where we make users go to the listing page in order to delete items. The delete option is always on another page/tab.

We have the similar paradigm of views listings + checkboxes to "select all" (although #3798) + the "delete" bulk operation.

[olafgrabienski]

summary after re-reading through this issue / #2353 (comment)

@BWPanda Thanks for the concise summary, it'll help a lot. There's one topic missing, in my opinion: the discussion about adding a confirmation form (and changing the button color). You have however already summarized that topic nicely, just a comment above in the thread. I guess, linking to that comment might be enough to give an idea.

[ghost]

@olafgrabienski I think the main decision is where the button should be displayed. I think a separate decision is if it should be converted to a regular button that has a confirmation form. But I'll let the PMC decide on all that.

In other news, I just realised that we have a similar situation with the Simpletest UI: admin/config/development/testing - on that page, the list of tests comes first, then there's a 'clean environment' button at the bottom... In case that helps make a decision about keeping consistency in core's UI.

[klonos]

...we have a similar situation with the Simpletest UI

Good catch @BWPanda 👍 ...and both these pages are meant for the same audience (site admins/developers).

[stpaultim]

At the request of the community, I have officially opened a ticket in the PMC issue queue for this issue. I expect it will take at least several weeks for any resolution. If anyone has ideas on how to resolve this without the PMC, I'm sure that the PMC would be fine with that. :-)

[ghost]

Status report...?

[ghost]

Seriously, what's the status of this issue?

[klonos]

@BWPanda last I recall is that there's various options/opinions here, but we need a UX/design opinion from an expert (hence the design label). Basically we need to make a decision.

[ghost]

we need a UX/design opinion from an expert

@klonos I thought that's what this was: #2353 (comment)

[olafgrabienski]

As requested, the PMC talked about it already last year, but we didn't manage to communicate the result for various reasons. (Sorry for that!) One of the reasons: the PMC discussion result isn't absolutely clear. There was a preference for two of the approaches mentioned in your summary #2353 (comment).

As a preparation, I list the different approaches from the summary again:

1. Leave it as-is
2. Move button to bottom of page, no fieldset
3. Move button to a new tab
4. Move button into Filter fieldset (and have it expanded)
5. Move button to Logging and Errors page
6. Move button to floating section at bottom of screen, display confirmation in modal

Our impression of the discussion in this very issue thread was: At a certain point, most support was expressed for solution 3, moving the button to a new tab. But after solution 3 became available as a contrib module, the discussion became more open toward solution 2 again. At this point, the discussion stopped.

The PMC itself remained undecided between approach 2 and 3, but all members like one of these both. At the end, we didn't want to decide but to give the question back to the community, pointing to the two mentioned approaches.

[jenlampton]

Thanks @olafgrabienski ! The last comment in the PMC queue recommends that we promote option #2. @BWPanda

[ghost]

Thanks @olafgrabienski and @jenlampton. Nice to have an update on this issue and a way to move forward.

I'd like to recommend now that we close this (very long) issue and open a new one where we can make a PR to test and develop this change.

[jenlampton]

I think that's a fantastic idea @BWPanda :) thank you! Would you do the honor of creating the next issue?

[ghost]

Here's the follow-up issue for anyone interested: #5484