The UI for filters and bulk operations on listings (content, files, comments, users and more) are inconsistent and not very pretty.




Proposed resolution

1. View with filters + actions

By default, the only view with both filters and actions is People page:
- People (/admin/people): #2023683: Improve the layout and usability of the admin/people exposed filters and actions

Proposed design:

2. View with filters.

The rest of the views that have several filters in a fieldset. The proposed design follows the style guide (
- @TODO: Decide label for the field set to suit both filters and sort options.
List of places in core where it can be found:
- Content (/admin/content) #2521808: Visually encapsulate the content listing filter to distinguish it from the 'add content' action link
- Files (/admin/content/files)
- Custom block library (/admin/structure/block/block-content)

In case there are several lines of filters, they should be nicely placed in several lines: #2711337: Too many exposed filters and operators create weird view.

3. Single text filters (filtering in-page).

This one is a single filter used to filter elements in the current page. A new design have been created with a bigger input and a magnifying glass to make it clear what is its purpose. List of places in core where it can be found:
- Views (/admin/structure/views)
- Extend (/admin/modules)
- Uninstall (/admin/modules/uninstall)

4. Single filters with button (paged list).

A single filter appearing used to filter elements in several pages. In this case the single filter should be envolved in a fieldset and a button will be placed inline, following the current design in the styleguide (

List of places in core where it can be found:
- URL aliases (/admin/config/search/path)

5. Only actions.

The design to use should be the same used for People view page.
List of places in core where it can be found:
- Comments (/admin/content/comment)
- Unapproved comments (/admin/content/comment/approval)

  1. Explore visual design options
  2. Decide on a direction
  3. You are here: Implement:

User interface changes

Pretty & consistent UI pattern and design for filters and bulk operations on listing pages.

API changes


Data model changes



yoroy created an issue. See original summary.

yoroy’s picture

yoroy’s picture

yoroy’s picture

yoroy’s picture

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

yoroy’s picture

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

ckrina’s picture

Assigned: Unassigned » ckrina
40.32 KB

For now, the closest thing that I've seen in the Seven Style Guide is this for fieldsets. So I'll try to work in that direction during Drupal Dev Days in Seville.

Fildset proposal on Seven Style Guide.

ckrina’s picture

Assigned: ckrina » Unassigned
Issue summary: View changes
83.41 KB
85.44 KB
98.76 KB
95.75 KB

It looks like there are several issues regarding a new design for filters and bulk operations. So I'll try to do a quick summary here:

A. This ones are active but working on isolated elements. Perhaps a design decision has been made without taking into account all the elements, so I created an image where we can see all elements playing together.

Only local images are allowed.
Only local images are allowed.

B. This other ones have completely different proposal for this pattern.

Only local images are allowed.

I'd suggest we decide first a design taking into account all the elements on top (main action button, filters, VBO and results list) and the other design solutions. Once we agree we could close the older issues and continue working on the small pieces. We could talk about it during the next the Usability meeting.

xinyuma’s picture

Besides the visual elements, I am actually thinking of the placement of these two functional areas.

For filters, it is logical to place it at the top, since in most of the cases, people first decide what they want to see then see it.

For bulk actions, users normally first select the items then perform the action, maybe it should be place below the content overview?

ckrina’s picture

Assigned: Unassigned » ckrina
47.21 KB
107.16 KB
187.06 KB
163.58 KB

In the last UX meeting we agreed that the 2 designs approaches are good and play well together, but some adjustments are still needed (like margins, etc).
Also we needed to know the different situations we need to give a solution to. After looking around an standard profile with Seven I found 3 general situations:
- Pages with filters + operations
- Pages only with operations
- Pages only with filters. Inside this, we have:
- Several filters
- Standalone filters

Another thing discussed during the call was to find the minimum filters needed for each situation and maybe remove some of them. The reason is that we would simplify the UI and if someone wants those filters they can easily add them again because they're views now. So I'll create a list with all this pages and its filters to we can review and decide for each situation if we really need to remove or not any filters.

Next step will be to find a general and unified design solution for this 3 situations. I'll work on that.

And thank you @xinyuma for your feedback. I agree that in long forms having the submit button below has sense, but we don't always have long forms. Right now I'm not sure what's the best solution so I'll do some research.

yoroy’s picture

yoroy’s picture

ckrina’s picture

Proposal for standalone filters.
I think that if we have only one text filter it would be better to give it more importance. We can do it by adding a fieldset around it (A or B) or by making the input itself bigger and more obvious (A and C). Adding the loupe to it will also help to identify its use. I would go for adding this new component because it can be easily reused in other places.

What option do you prefer? I would go for option C.

Integrated Actions + Filters
I’m adding the content example image. From the previous issues, I would try to make the space between filters bigger, as suggested in the styleguide. The reason is that it helps identifying each of them if they are more separated.

Minimum filters needed.
I would try, in general, to mix filters in search/text inputs so we only have one single input as we have in Views. Do you agree? I'll try to make a list so we can discuss further.

yoroy’s picture

Link to the recording where we discuss this:

Spoiler alert: we decided to go for option C for the filters. Design for more filters + sorting options also needs to take in account those versions that people can build themselves using Views exposed filters and sort options.

ifrik’s picture

21.96 KB

I think I was asked during the last UX for some examples of how a page like the Content page can looks when it's customized, for example when exposed sorting is added.

Example of the Content page, customized with additional exposed sorting and a changed "Apply" button

If I get it correctly, we have three different set of admin pages:

  1. Core has some admin pages that can't be customized: for example the Modules and the Views pages. Both have a search field.
  2. Some other pages are by default just a simple table, but if the Views module is enabled, then these pages are replaced by Views pages: for example the Content and Peoples pages. These pages then by default have some exposed filters and bulk operations.
    Because they are views, they can easily by changed by users. This includes exposed filters and exposed sorting. These two options have one button to apply whatever action to them.
  3. Other admin pages are created by users or by contrib modules. A typical case is to clone to Content or People Views page for different content types or roles, depending on the specific workflow. Another example are 'content' pages created for custom entities.

By using Views for such admin pages we gained an enormous amount of flexibility that allows users to customize these pages and create new ones while maintaining a consistent look across the site, no matter whether a page comes from core, contrib or the user.
Unfortunately, Views doesn't have an option to provide placeholder text for the exposed filters. (There's a patch for the Better Exposed Filter module to do so.)

So if we somehow configure pages like Content or People to look more appealing then we need to take into account that users need to be able to change them.
And we can't really do things to a views page that users can't do with Views themselves. If users clone a page then it should look the same, otherwise we set them up for an endless struggle in finding out why that page looks different (and how to explain that to others.)

ifrik’s picture

Another point to take into account:
Once a filter is selected, there a Reset button appears.

ckrina’s picture

Thank you @ifrik, we really have to keep in mind all you said. So here is a list of the filters I've found right now in Core:

List of filters and operations

Some proposals for each of them:
A. Filters coming from views:
- Must have a label
- Can’t have placeholder

Filters filtered:

Several filters, so it jumps to another line.

B. Standalone text filters (in-page):
- Filter in page will go with the bigger input proposed in C in comment #16 because we don’t need the prominence of a fieldset.
- We’ll use the magnifying glass icon, but we’ll try to make it lighter like the throbber #2775725: Update throbber icon in Seven theme.
- @TODO: Animation

C. Standalone filters with button. This that need a button because the search is not on the same page:
- We can’t use the bigger input because the button would be too small.
- We should try to use the defined fieldet from the styleguide, with its margins and background color.

D. Only actions:
- Implement the design from #2785051: Improve usability of Views bulk action form in Seven theme

E. Filters + actions in a view. They could keep the same design from A and D, taking into account the space between them.

I will work on the animation for the standalone filter in-page.

ckrina’s picture

Issue summary: View changes
30.1 KB
52.25 KB

1) Option A. Revisiting the filters I’ve realized that the filter for Files doesn’t have enabled the Reset button in views. Should we keep the same pattern as in Content or People and enable it?

2) Option B (Standalone filter) revisited. We probably won't animate it. I've changed the color for the magnifying glass. What do you think?

3) Option C. I’m going to create an issue to suggest a design change for the URL aliases page, to keep the fieldset styles closer to the style guide. I'll check if there's already one and update this comment with the link.

4) Option E. Filters + Operations. In previous meetings there was the suggestion to decrease the number of filters for some view pages where the users could add them later just changing the default view. From my quick research, the only pages where it has sense are People and Content:
- For People we agreed on the last UX meeting than we could remove the permission filter. It is big and probably not really used. I'll check if there's already one issue or create a new one, and update this comment with the link.
- For content we agreed on removing the Language filter on sites where there’s only one language. This one is already being addressed here #2473989: Lack of dynamic language field / filter makes shipping core views hard to be both compatible with mono and multilingual.

5) Another thing pointed by @ifrik is that the fieldset label should change from “filter” to something else when there are Filters and Sort options. I am not sure if it can be done dynamically, so maybe looking for a common label would make sense. Any suggestion for it?

ckrina’s picture

Issue summary: View changes
75.85 KB
32.53 KB
45.18 KB
61.59 KB
60.39 KB