Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
jenlampton opened this issue Nov 23, 2016 · 76 comments
Open

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

jenlampton opened this issue Nov 23, 2016 · 76 comments

Comments

@jenlampton
Copy link
Member

@jenlampton jenlampton commented Nov 23, 2016

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 comment has been minimized.

Copy link
Member

@serundeputy serundeputy commented Apr 22, 2018

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

screen shot 2018-04-22 at 11 22 12 am

@findlabnet

This comment has been minimized.

Copy link

@findlabnet findlabnet commented Apr 22, 2018

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

This comment has been minimized.

Copy link
Member

@serundeputy serundeputy commented Apr 22, 2018

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

This comment has been minimized.

Copy link
Member Author

@jenlampton jenlampton commented Apr 22, 2018

@BWPanda

This comment has been minimized.

Copy link
Member

@BWPanda BWPanda commented Apr 23, 2018

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

This comment has been minimized.

Copy link
Member Author

@jenlampton jenlampton commented Apr 23, 2018

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?

@BWPanda

This comment has been minimized.

Copy link
Member

@BWPanda BWPanda commented Apr 24, 2018

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 jenlampton changed the title [UX] clean up the dblog messages page [UX] move the clear log messages button to bottom of dblog messages page Apr 24, 2018
@jenlampton

This comment has been minimized.

Copy link
Member Author

@jenlampton jenlampton commented Apr 24, 2018

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

This comment has been minimized.

Copy link

@opi opi commented Apr 24, 2018

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

@findlabnet

This comment has been minimized.

Copy link

@findlabnet findlabnet commented Apr 24, 2018

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

This comment has been minimized.

Copy link

@opi opi commented Apr 24, 2018

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

This comment has been minimized.

Copy link

@findlabnet findlabnet commented Apr 24, 2018

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 comment has been minimized.

Copy link
Member Author

@jenlampton jenlampton commented Apr 24, 2018

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

This comment has been minimized.

Copy link

@opi opi commented Apr 24, 2018

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

This comment has been minimized.

Copy link
Contributor

@laryn laryn commented Apr 24, 2018

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

This comment has been minimized.

Copy link

@findlabnet findlabnet commented Apr 25, 2018

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

This comment has been minimized.

Copy link
Member Author

@jenlampton jenlampton commented Apr 25, 2018

@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

This comment has been minimized.

Copy link
Contributor

@laryn laryn commented Apr 25, 2018

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

@findlabnet

This comment has been minimized.

Copy link

@findlabnet findlabnet commented Apr 25, 2018

@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

This comment has been minimized.

Copy link
Member Author

@jenlampton jenlampton commented Apr 25, 2018

@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

This comment has been minimized.

Copy link

@findlabnet findlabnet commented Apr 25, 2018

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

This comment has been minimized.

Copy link
Member Author

@jenlampton jenlampton commented Apr 25, 2018

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

This comment has been minimized.

Copy link

@findlabnet findlabnet commented Apr 25, 2018

@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

This comment has been minimized.

Copy link
Member

@klonos klonos commented Jan 29, 2020

Do not seems like consensus, IMHO.

I know 😅 ...perhaps @jenlampton was right:

Maybe we should get a ux designer to weigh in?

@BWPanda

This comment has been minimized.

Copy link
Member

@BWPanda BWPanda commented Jan 29, 2020

I was under the impression that the collapsible fieldset was there in order to introduce an additional click, in order to prevent accidental deletion.

It may well have been, in which case the validation page serves instead. However it was also useful in minimising the scrolling needed to get to the main content of this page (what 99%* of people use this page for - viewing the log messages).

See the following UI places where a similar pattern is being used

Cron: This makes sense as the first thing on the page, as that's what this page is all about (and it's more-or-less non-destructive)
Search indexing: As this isn't the first thing on the page, it's fine as it doesn't hinder accessing/viewing other content on the page.
Performance: I can see this one being moved further down the page, but I also don't mind it where it is as it's a more-or-less non-destructive action.

I cannot think of any listing/view that has such a "delete all" button at the bottom of the page

No, I was thinking more about nodes, terms, etc. with Delete button at the bottom.

Would removing the fieldset entirely achieve that in a better way?

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.

* Made-up number

@BWPanda

This comment has been minimized.

Copy link
Member

@BWPanda BWPanda commented Jan 29, 2020

Also, I think destructive actions like irreversibly deleting all log messages should be styled appropriately (e.g. red).

@BWPanda

This comment has been minimized.

Copy link
Member

@BWPanda BWPanda commented Jan 29, 2020

All in all, my vote is still for @indigoxela's PR which:

  • Reduces scrolling to content
  • Avoids accidental clicking/deleting
  • Removes unnecessary fieldsets
  • Moves functionality unrelated to the primary purpose of the page to a separate tab
@klonos

This comment has been minimized.

Copy link
Member

@klonos klonos commented Jan 29, 2020

  • Made-up number

🤣

@findlabnet

This comment has been minimized.

Copy link

@findlabnet findlabnet commented Jan 29, 2020

trying to access 99%* of the time

Where is last one percent? :-)
Right now it is 100% of the time, for me at least.

@BWPanda

This comment has been minimized.

Copy link
Member

@BWPanda BWPanda commented Jan 29, 2020

Where is last one percent? :-)

It's the people testing these PRs 😆

@olafgrabienski

This comment has been minimized.

Copy link

@olafgrabienski olafgrabienski commented Jan 29, 2020

I also still like @indigoxela's PR the best. Sure, consistency is important. On the other hand, pages like Performance have another main purpose and are not really comparable. I'm however open for @klonos' PR if the Clear button at the top stays without fieldset and without danger class (but with confirmation dialog). Ironically, in that case the Clear section doesn't disturb or irritate as much as it does now with the big fieldset.

@klonos

This comment has been minimized.

Copy link
Member

@klonos klonos commented Jan 29, 2020

FTR, my main objection here is the introduction of the 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. See:

https://www.drupal.org/project/drupal/issues/402760
https://www.drupal.org/project/drupal/issues/1834002

Summary Summarized: this issue is just making the location of delete more standardized. Not a tab. Make it a action button/link in the same area as, Save, Update, Preview.

(See #7) We discussed this at length in Drupal 7, and decided to go for buttons - since tabs are to be used for navigational purposes only, not actions. It is even represented in our guidelines (see the last recommendation) at Community Documentation Page: User Interface Standards: Navigation: Tabs http://drupal.org/node/1090012.

http://drupal.org/node/1090012

Avoid using tabs for actions, there is a conceptual split in Drupal between local actions and tabs.

@docwilmot

This comment has been minimized.

Copy link
Contributor

@docwilmot docwilmot commented Jan 29, 2020

This conversation to me typifies my concern with our need for prioritizing in Backdrop. Two comments:

  • This page works perfectly fine for its purpose. It can be improved, but 61 comments! And counting!
  • We've started yet another new PR on an issue that had an active PR with active ongoing discussion. We could have had a conversation first, and then the PR if needed, no?

Excuse the rant. Carry on.

@olafgrabienski

This comment has been minimized.

Copy link

@olafgrabienski olafgrabienski commented Jan 29, 2020

This page works perfectly fine for its purpose. It can be improved, but 61 comments! And counting!

For me, it doesn't work fine at all. Every time I go to the Dblog page, it feels irritating, and I go there quite often. I see it's difficult to get consensus but that doesn't necessarily mean it's not important.

@klonos

This comment has been minimized.

Copy link
Member

@klonos klonos commented Jan 29, 2020

We've started yet another new PR on an issue that had an active PR with active ongoing discussion.

New PRs generate new sandboxes. So people can play with both/all proposed solutions, and see which one feels better (rather than rely on mockups). I find that a good thing.

@indigoxela

This comment has been minimized.

Copy link

@indigoxela indigoxela commented Jan 30, 2020

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.

@klonos ...right, and Drupal 8 uses tabs:
screenshot-drupal8

I'm afraid, the "Curse of the Long Thread" strikes here (the longer an issue thread gets, the less likely it can get solved). Sad to see...

@BWPanda

This comment has been minimized.

Copy link
Member

@BWPanda BWPanda commented Jan 30, 2020

@klonos Regarding consistency, I see this log page as a listing of items. You can click on the items to view them (on their own page). Kind of like the content overview page (/admin/content), or the term listing page (/admin/structure/taxonomy/tags). Now imagine going to either of those pages and the first thing you see at the top is a 'Delete all [content/terms]' button... I don't think that would be very good UX, so why do that here? Let's copy D8 in this regard and have a separate tab.

EDIT: Also, I don't know of anywhere else in core where we make users go to the listing page in order to delete items (e.g. you don't go to the search page (/search) to clear the search index). The delete option is always on another page/tab.

@BWPanda

This comment has been minimized.

Copy link
Member

@BWPanda BWPanda commented Jan 30, 2020

you don't go to the search page (/search) to clear the search index

Actually there's a point: the option to clear the search index in on the Search settings page. So if we're really against have a separate tab to clear the DB log, what if we move that button to the Log settings page: /admin/config/development/logging?

@findlabnet

This comment has been minimized.

Copy link

@findlabnet findlabnet commented Jan 30, 2020

what if we move that button to the Log settings page

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

@klonos

This comment has been minimized.

Copy link
Member

@klonos klonos commented Jan 31, 2020

@klonos ...right, and Drupal 8 uses tabs:

I know it does (now)...

Let's copy D8 in this regard and have a separate tab.

After doing UX reviews/studies, D8 have decided to remove all tabs and convert them to action links (again, please refer to https://www.drupal.org/project/drupal/issues/402760, where using tabs is considered UX regression, as tabs should be used for navigational purposes - not for actions). So do not rely on what is the current situation in D8, the roadmap is to change that, for the sake of better UX.

I don't know of anywhere else in core where we make users go to the listing page in order to delete items

The way I see it, we do that everywhere actually 😅 ...and if we were to convert the list of log messages to be generated by a view (see https://www.drupal.org/project/drupal/issues/2015149 and https://www.drupal.org/node/2850115), there could be a checkbox column to allow selecting all/individual log messages, and a bulk operation to clear/delete them.

...we need clear log button on same screen where we read it.

@klonos klonos closed this Jan 31, 2020
@klonos klonos reopened this Jan 31, 2020
@indigoxela

This comment has been minimized.

Copy link

@indigoxela indigoxela commented Feb 3, 2020

Different people want different things. That happens and is usually a use-case for a contrib module.

How about that:

People who prefer to have the Clear action on a different page, install Dblog Page Split

People who prefer to have the button on the same page, proceed here with @klonos' PR.

@findlabnet

This comment has been minimized.

Copy link

@findlabnet findlabnet commented Feb 3, 2020

And people who prefer to have the button as it is?
Build another module?

@indigoxela

This comment has been minimized.

Copy link

@indigoxela indigoxela commented Feb 3, 2020

And people who prefer to have the button as it is?

I'd suggest to discuss that here. At least, some people have a (contrib) solution now. The rest is (hopefully) able to find one soon. It depends on how this discussion proceeds. 😉

@findlabnet

This comment has been minimized.

Copy link

@findlabnet findlabnet commented Feb 3, 2020

It seems like I need some module to register any core changes with the ability to roll them back.

@stpaultim

This comment has been minimized.

Copy link
Member

@stpaultim stpaultim commented Feb 3, 2020

Clearly there is substantial disagreement on this PR/issue. It's not unusual for UX related issues to get bogged down in disagreements. During last weeks meeting, we talked about this as an example of when we need some better way to make decisions. Especially, when there is no consensus.

I am putting this on the agenda for an upcoming UX meeting.

@BWPanda

This comment has been minimized.

Copy link
Member

@BWPanda BWPanda commented Feb 3, 2020

Or should we just ask the PMC to make a final decision so we can all move on with our lives? 😉

@findlabnet

This comment has been minimized.

Copy link

@findlabnet findlabnet commented Feb 3, 2020

If you need someone who make a final decisions instead you - it is pretty simple - world of Apple/Microsoft/<another_monster> awaiting you in one step away.

@klonos

This comment has been minimized.

Copy link
Member

@klonos klonos commented Feb 3, 2020

Or should we just ask the PMC to make a final decision so we can all move on with our lives? 😉

I find this issue too trivial for the PMC, but if we do take it there, then I think that perhaps I will abstain from voting, as I am directly involved (filed a PR with a solution that may come out as opinionated). ...having said that, I am currently the constituent for non-coding site builders among the PMC 😅

@BWPanda

This comment has been minimized.

Copy link
Member

@BWPanda BWPanda commented Feb 3, 2020

I don't think it's a matter of triviality, but rather do we want to spend days/weeks/months going back and forth trying to reach a consensus, or just let the PMC decide for us, commit the appropriate PR and then move on...?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

You can’t perform that action at this time.