Design for filters and bulk operations

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.

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.

• #2521808: Visually encapsulate the content listing filter to distinguish it from the 'add content' action link
• #2023683: Improve the layout and usability of the admin/people exposed filters and actions

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

• #2022297: [META] Unified toolset for Views in core
• #2023683: Improve the layout and usability of the admin/people exposed filters and actions

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.

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?

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.

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.

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

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

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:

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

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?

Unassinging in case anyone else wants to work on this.

Adding a proposal for the bulk operations: convert the checkbox for select all/unselect all from the tables to a button on grids visualizations that toggle depending on the need:

Sorry, uploaded the wrong file.

Too bad there's not been any progress for a while.
In the meantime #2711337: Too many exposed filters and operators create weird view goes another route, particularly in order to visually group exposed operators with their value fields.
However, both designs may be easily combined. We only need visual grouping for operator and field, if on a page there is an exposed operator at all.

New designs happens in #3070558: Implement bulk operation designs

The Seven theme has been removed from Drupal 10 core. I confirmed that this issue only affects Seven and no other themes included with Drupal core, so I am moving this to the contributed Seven project.