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)
- Resposive
- 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:

See #450666: Filter DB Extender

Comments

kika’s picture

Here'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"

kika’s picture

Issue summary:View changes

more

kika’s picture

Issue summary:View changes

more detailed proposal

kika’s picture

Title:Provide a generic search/filter UI interface pattern for listing pages» [META] Provide a generic search/filter UI interface pattern for listing pages
klonos’s picture

In #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?

drupalvino’s picture

yoroy’s picture

StatusFileSize
new67.75 KB

Looking at the Gmail ui for adding multiple categories to emails:

 select boxes in a select list

yoroy’s picture

StatusFileSize
new27.14 KB
new169.75 KB

Showing 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)

nod_’s picture

Issue tags:+JavaScript

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.

LewisNyman’s picture

Issue tags:+mobile

I'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

klonos’s picture

I 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?

yoroy’s picture

I 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 :)

x7ian’s picture

One 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.
;-)

andypost’s picture

There's a process of fixing form for string translation, Please review screenshots of filters #1452188-95: New UI for string translation

klonos’s picture

I'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.

klonos’s picture

I'm glad that thus far this was not pushed against D9, but at the same time there was no actual progress either :/

tkoleary’s picture

The 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

tim.plunkett’s picture

Issue tags:+VDC

Regardless 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.

dawehner’s picture

Anything which is adding functionality is a feature request from my perspective and so has to be moved to Drupal 9.

xjm’s picture

tkoleary’s picture

@dawhener

Anything which is adding functionality is a feature request from my perspective and so has to be moved to Drupal 9.

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

tkoleary’s picture

Issue summary:View changes

more links

klonos’s picture

Issue summary:View changes

..from the issue summary:

Q: Why re-invent the wheel (Views + VBO)?
A: Views will not make it to D8 core. ...

I think it's time for a summary update.

tim.plunkett’s picture

LOL

dawehner’s picture

Nice, it was all a dream!

webchick’s picture

Status:Active» Fixed

Since views is in fact in core now, I actually think we can mark this fixed.

Bojhan’s picture

Status:Fixed» Active

Err. Views is in core - but no way that we have a consistently applied pattern that is highly usable?

dawehner’s picture

Yeah, 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.

webchick’s picture

Status:Active» Postponed (maintainer needs more info)

The 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.