Problem:
In Drupal core we have at least six different search/filter interfaces for listing pages (see below). We need a generic UI interaction pattern for search/filter what we could re-use in all current core cases and extend to other listing pages when needed. There are currently several developments what improve Drupal filters such as #497804: [meta] Search entities (nodes, terms, etc.) within the administrative interface, #355820: Improve query filter UI on admin/content #538904: D8UX: Redesign Modules Page and #1452188: New UI for string translation but this meta-issue here is here to sync up those improvements and provide an universal UI pattern what could be applied to any listing page when needed.
Requirements:
- Compact but scalable UI (might need expanding/collapsing functionality)
- Responsive
- Support both textfields and selector fields
- Optimize for simple (1-2-3 fields) filters but do support advanced (multi)filter.
Q&A:
Q: Why re-invent the wheel (Views + VBO)?
A: Views will not make it to D8 core. We need a solution for this release. Ideally this search/filter UI pattern could be re-used in future Views versions as well.
Technical implementation:
Comment | File | Size | Author |
---|---|---|---|
#8 | before-after-content-filter.jpg | 169.75 KB | yoroy |
#8 | publish-options.jpg | 27.14 KB | yoroy |
#7 | Compact-filter-UI.png | 67.75 KB | yoroy |
#4 | filter_boulton.jpeg | 49.62 KB | kika |
#4 | filter_query.png | 21.25 KB | kika |
Comments
Comment #1
kika CreditAttribution: kika commentedHere's the current situation:
Aliases search. Non-collapsible search textfield.
Comments filter. A special case of filter, implemented using 2nd level local tabs.
Content filter. Non-collapsible multifilter a la UnConeD.
Dblog filter. Two multiline selects, collapsed by default
People/User filter. Non-collapsible multifilter a la UnConeD. Note: "Status" field contains only "any / active / blocked"
Translatable strings filter. Non-collapsible search textfield and two single-line selects. Note: "Search in" field contains only "both / translated / untranslated"
Comment #1.0
kika CreditAttribution: kika commentedmore
Comment #1.1
kika CreditAttribution: kika commentedmore detailed proposal
Comment #3
kika CreditAttribution: kika commentedComment #4
kika CreditAttribution: kika commentedSome previous work:
Mark Boulton's work from D7UX days:
http://www.flickr.com/photos/mboulton/3569318373/sizes/z/in/pool-903403@N22/
From #355820: Improve query filter UI on admin/content
http://drupal.org/node/355820#comment-5004240
From #497804: [meta] Search entities (nodes, terms, etc.) within the administrative interface
http://drupal.org/node/497804#comment-2202732
From #538904: D8UX: Redesign Modules Page
http://drupal.org/node/538904?page=1#comment-5347988
From #1452188: New UI for string translation
http://drupal.org/node/1452188#comment-5697524
Comment #5
klonosIn #538904: D8UX: Redesign Modules Page there's mention of the Module Filter project. This module already provides some sanity in D7 for those of us that don't want to way till D8 before they have a modules admin page as it's meant to be. I personally install it in every setup along with Admin Menu.
One of the issues in Module Filter's issue queue is #1023252: UI should utilize Drupal 7 core more - new 7.x-2.x branch? and in that issue there was some discussion that it we should consider standardizing the filtering used in the modules page by implementing a re-usable mechanism across various admin pages. This way we'd have less duplication of code and more UI consistency.
So, it was suggested that we'd use the Instant Filter project. As it already states in the project's page it was born to address #396478: Searchable modules page since that one didn't make it in D7. So, in turn the Module filter NG sandboxed project was born that had Instant Filter as a dependency. That dependency was the main reason that the changes did not make it back to the original Module Filter project.
Should we make it one of this meta-issue's tasks to move Instant Filter in D8 core or at least re-write & implement its functionality for D8?
Comment #6
drupalvino CreditAttribution: drupalvino commentedComment #7
yoroy CreditAttribution: yoroy commentedLooking at the Gmail ui for adding multiple categories to emails:
Comment #8
yoroy CreditAttribution: yoroy commentedShowing it in context:
Which only covers the filtering part of course. Still leaves the update options to be refactored a bit. Here's an idea for that:
It goes with the idea that this should be really close to the 'Select all' checkbox. It sacrifices the 'Title' header for the titles column which is not that great a loss I think but a very specific design solution of course, which is likely to break in other scenarios.
(I'm seeing a trend where the headers for table columns are not shown at all anymore. In our application of this we'd need to rething the sortable links of course)
Comment #9
nod_It looks nice but it's going to be very messy because of sticky tableheaders… Also what would the no-js fallback looks like?
I'm not trying to sabotage the thread, I like the new layouts very much, I'm just a bit concerned about fallbacks and mobile.
Comment #10
LewisNymanI've implemented a rough demonstration of how a search and filter functions could work on mobile in my prototype here:
nav3.d8mux.org
Sandbox here
Comment #11
klonosI like these designs too! The actions drop-down & button in table header part not so much (because it'd break the ability to sort alphabetically). Why can't we have them next to the "Search & filter" drop-down?
Comment #12
yoroy CreditAttribution: yoroy commentedI agree the idea for the bulk actions is pushing it too far. I do think we need to bring these actions in close proximity to the 'select all' checkbox. Needs more exploring :)
Comment #13
x7ian CreditAttribution: x7ian commentedOne thing that i would like,
is to be able to show in the list of nodes a CCK field and taxonomy values column
and if it is posible to apply filters the list of nodes using this fields.
That would be a great feature to include on D8.
;-)
Comment #14
andypostThere's a process of fixing form for string translation, Please review screenshots of filters #1452188-95: New UI for string translation
Comment #15
klonosI've filed #1757618: Add Instant filter functionality in D8 core. so we can actually move on with implementing the actual idea suggested here. Let's leave this issue here open for discussion in case we come up with a better idea. Instant Filter does the job pretty well so lets go with what we have for now and improve things later on.
Comment #16
klonosI'm glad that thus far this was not pushed against D9, but at the same time there was no actual progress either :/
Comment #17
tkoleary CreditAttribution: tkoleary commentedThe following prototype combines filtering and bulk operations in a fairly clean way using styles from the new Seven style guide and not going too far away from the current implementation. I think this is a good step that we could reasonably get in to D8.
http://invis.io/R8F4K2BC
Comment #18
tim.plunkettRegardless of the actual filters exposed by #2020167: Add a name and email search field to the admin/people view, that is what it looks like now.
Also tagging, since AFAIK this is 100% about views.
Comment #19
dawehnerAnything which is adding functionality is a feature request from my perspective and so has to be moved to Drupal 9.
Comment #20
xjmRelated: #2023683: Improve the layout and usability of the admin/people exposed filters and actions.
Comment #21
tkoleary CreditAttribution: tkoleary commented@dawhener
I don't think I'm suggesting adding functionality "to Drupal" all I'm proposing in #17 is exposing functionality already found elsewhere in Drupal in slightly different ways and in different places.
FYI I also started a meta issue for reviewing all of the table UIs, creating consistency and removing antipatterns.
#2022297: [META] Unified toolset for Views in core
Comment #21.0
tkoleary CreditAttribution: tkoleary commentedmore links
Comment #22
klonos..from the issue summary:
I think it's time for a summary update.
Comment #23
tim.plunkettLOL
Comment #24
dawehnerNice, it was all a dream!
Comment #25
webchickSince views is in fact in core now, I actually think we can mark this fixed.
Comment #26
Bojhan CreditAttribution: Bojhan commentedErr. Views is in core - but no way that we have a consistently applied pattern that is highly usable?
Comment #27
dawehnerYeah, pages like /admin/content and /admin/extend certainly behaves totally different, on the other hand I wonder whether you really
want to behave it the same way.
Comment #28
webchickThe issue title/summary says nothing about a consistently applied pattern that is highly usable. ;) It says a generic search/filter UI, which we have.
Marking "needs more info" on an updated issue summary.
Comment #30
riddhi.addweb CreditAttribution: riddhi.addweb commentedComment #42
smustgrave CreditAttribution: smustgrave at Mobomo commentedClosing this as outdated as it moved to PNMI 8 years ago for more info that didn't happen
If still valid task please reopen addressing #28