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] Add a filter weight reset option so we can Show 'enabled' text filters above 'disabled' ones #4408
Comments
@BWPanda the order of filters matters (see this oldie: #1033). It should be customizable by the site builders/admins for each site as needed, but still certain ones need to come before others; so the order should ideally be according to that (IOW in a way that would cause the less trouble/issues if more filters are enabled). |
I guess I am wanting consistency with other UI's where enabled/disabled items with draggable weights are separated: Can we not order the table by: enabled/disabled status, weight? That way all enabled/disabled modules are grouped together, but they still keep their weights, so that enabling a disabled one puts it back where it should go? |
Yes, I see what you're saying re consistency; it's the same in views, content type display modes, disabled themes, etc.; so perhaps that could work. The difference in those other places is that once enabled, the items go to their place (which is alphabetical order) and that happens instantly, as the same action that enables the item also submits the form.
Yeah, with the difference that this table is also draggable, and enabling happens via checkboxes. Placing the enabled filter in it's "failsafe position" after ticking the checkbox would require submitting the form; whereas in the meantime the user might be "urged" to move the filter manually to the "enabled" section, which in turn would change the weight 🤔 ...perhaps the UX feels better when I actually test the implementation, rather than imagining how it would work. ...unless we convert the checkboxes to an "enable" operation. But then again, the "configure" operation is not a drop-button (see #4378) 🤔. Anyway, I'd have to see it in action to make an informed decision; all the above is guesswork 😅 ...I'll let others chime in. |
I see the desire to put the enabled ones above the disabled ones, but I'm also nervous about this because the order of these items (their weight) is important. It's not arbitrary, like it is on the other forms, where the order a user sets only affects the visual outcome. Here, there are security implications. In this case, the creator of the module that's providing the filter almost always knows better than the administrator, and it's very rare that the order needs to be changed.
I wonder how that would work with draggable tables. In all the other instances, is weight of the disabled items set to zero when disabled? Or is the weight value retained?
In this interface, we need to make sure that the value is either retained, or reset to the module-provided default when the filter is enabled again. |
@BWPanda I understand your feature request, but am also a bit concerned about side effects and about growing complexity. @klonos and @jenlampton already identified possible problems. And actually - an unrelated bug report you recently posted is a clear example for such a side effect. |
I think the current system will actually cause more problems than the alternative... Consider this: An admin sees the enabled filters, but there's a few disabled ones mixed in amongst them. They decide to move them to the bottom since that's what they're used to seeing elsewhere and because its easier to read/understand this page then. Later when they decide to enable one of the previously disabled filters, its stuck at the bottom where they put it and mucks up the site. I feel like we're preferring developers/code over user experience in this issue... If we can make the UX more friendly and usable, but keep the weighting system working properly, then that's a win-win, right? |
Again, I understand your intention - but I have concerns. It's not that I oppose here, but we should be very careful. Broken / buggy functionality won't make users happy either. |
Removing the ability for end-users to change the weights here would put the needs of developers first, but I don't think anyone's talking about completely removing the UI. We're just debating the best way to protect people from accidental harm :)
That's a good example. I hadn't considered that people might change things to neaten up the UI rather than to achieve a necessary result. In my experience people who are less experienced tend to leave things alone. But now that you mention it -- I could see myself doing this. And only later when things aren't working right come back here and think "Why did I do that?!" |
I think that I've mentioned this before somewhere, but I believe that there should be a help text along the lines of "order of filters matters" (in more/nicer words 😅 ). That may be enough to prevent people from moving filters merely for tidying things up; but then again not. As I said earlier, I would have to see this UI change in action before I decide whether it has UX oddities or not. |
I didn't find the time yet to look at the necessary code changes, but as we're supposed to cleanup the filter configuration code anyway - maybe that's a good opportunity to align the look and feel of that form to existing patterns Backdrop already uses (like manage field / display). Not sure if that's possible, though. |
just had a thought: we could add a "reset" button that could restore the weight of the filter from the providing module. And use the reset feature every time a filter is enabled (the first time also). We'e need to explain why the reset button is necessary (and maybe choose a better name) but this might solve a lot of frustration for people who had changed the order of items previously, not understanding the consequences. |
On
/admin/config/content/formats/[FORMAT]
the filters are shown in a seemingly random order, with enabled and disabled ones mixed together. It'd be nice to have all enabled ones shown first, then the disabled ones below.The text was updated successfully, but these errors were encountered: