Improve UX around filter customisation of bundled data views

[jameskoster]

Based on the discussion below, let's update the UX conventions around customising views like so:

• Filters that are part of the view config (for example status = trash in the 'Trash' view) are locked – they cannot be edited or removed.
• When additional filters are added, the 'Reset' button should restore to view to its original state rather than removing all filters as it does now.
• When additional filters are added, mark the view as modified:

• Add actions for modified views in the sidebar; 'Reset', 'Save' (for user-generated views), 'Save as...' (for bundled views):

---

Original issue

It can sometimes be confusing when you edit the filters associated with a bundled view so that the visible records no longer reflect the purpose of the view.

A great example of this is the "Trash" view in page management. If you remove the status filter in this view you see all pages, yet the active view suggests you're viewing trash:

trash.mp4

[jameskoster]

Three options to consider:

1. Lock default filters for bundled data views

Perhaps too restrictive, but one option could be to simply lock the filters associated with a view. So in the Trash example users simply wouldn't be able to modify or remove the status filter.

2. De-select active view once modified

Another option could be to deselect the active view once it has been customised. This would eliminate some of the confusion, but potentially introduce more as you effectively end up in 'limbo'

3. Mark views as modified

Thinking further ahead to custom views, this option would involve marking views as customised somehow, so the user is able to understand why the records on display may not match the view label. Such a UI could facilitate the creation of custom views down the road, as well as a reset affordance.

Initially it could be purely informational, with a simple reset action:

Later it could be a place for other view actions to live:

cc @WordPress/gutenberg-design for thoughts.

[jasmussen]

My immediate instinct is that the "Status: Trash" is not something that should be showed for a bundled view, perhaps not even a saved view.

Semantically, those filter chips feel like filters on the current view. This is separte from the view itself. When I click trash, the filter is implied, and seeing the chip on top of that is both duplicative and confusing.

There's still some work to be explored around how custom views are pinned, managed, sorted, unpinned, renamed, etc. But could one solution be that as soon as a view is saved, whether from a user or the plugin/admin, those chips are absorbed to be implied and therefore hidden? That would solve the issue of being able to toggle off that chip without selecting a different view, it would solve the duplication, and it would arguably even clarify the reason why views can be saved.

[SaxonF]

I think we should still show the filters as the view is just a predefined set. Similar behaviour in other tools like Notion , GH Projects. I'd be fine with deselecting but only on default views. On custom views we should indicate that a change has been made and can be "saved" or "reset".

[jameskoster]

@jasmussen the drawback to hiding the bundled filters is the potentially confusing behavior when you add more filters. Unrealistic example, but communicates the point; you filter the Trash view by status to show posts with any status: "Published, Draft"; the UI confirms this, but the records also include trash.

@SaxonF De-selecting could work, especially in the short term. It would mean; if you filter "All pages" to show trash, then "Trash" becomes the active menu item. But then if you add another filter no menu item would be active. Probably fine, but there's a chance it feels a bit unexpected in practise. Hard to say without trying it.

On custom views we should indicate that a change has been made and can be "saved" or "reset".

Any reason not to do this for bundled views too (with "Save as..." instead of "Save")? I think I lean that way overall.

[SaxonF]

We decide which views are active based on filters? I wouldn't expect us to select the views unless explicitly clicked . Two views could have the same filters applied for example

[jameskoster]

I wouldn't expect us to select the views unless explicitly clicked

I suppose that's the simplest place to start :)

[jasmussen]

The main headache I'm having is: if the view on the left is just a shortcut to applying a filter, what does that mean for future saved views? It's essentially two links to two different destinations, that both show the same end result. There's possibly nuance, to Saxon's point, that I'm missing. But as is, either the chip or the view feels redundant.

[jameskoster]

I think saved views are the same thing – a configuration of filters and view options (layout etc).

that both show the same end result

That was the concern I have about de-selecting menu items. E.g. go to All pages and filter to show trashed pages. No menu item is active. Now click the "Trash" menu item – it becomes active and the records in the table remain identical. Hard to say if that'll feel strange in practise without trying it. Maybe I'm over-thinking it it? :)

On balance that's why I lean towards marking views as modified (with reset action) – option 3 above. Is there a pitfall I'm not seeing there?

[SaxonF]

@jasmussen they are all just views which are a saved set of filters / settings . We are just providing a few sensible views by default depending on the post type. Same behaviour as other tools that utilise saved views.

@jameskoster option 3 is good as well. It just felt a little weird that we show indicator when you can't actually save it (unless we make it so you can actually adjust default views)

[jameskoster]

I reckon we should try deselecting and see how that feels as a starting point.

[richtabor]

The main headache I'm having is: if the view on the left is just a shortcut to applying a filter, what does that mean for future saved views? It's essentially two links to two different destinations, that both show the same end result. There's possibly nuance, to Saxon's point, that I'm missing. But as is, either the chip or the view feels redundant.

This was my initial thought as well, especially in the views like this:

[SaxonF]

Let's disregard the default views for a minute, for saved custom views do we agree we should show the filter? Without showing filters we aren't giving visibility over what the view is actually doing and we aren't letting the user customise. This is pretty standard across other products that utilise views.

Default views are exactly the same it's just they are applying a single filter (status) which is where the confusion is coming from. One option is to just remove them completely. We then face a scenario where it might make more sense to move views functionality inside the content frame (eg as tabs above filters) and just not drill down on index pages.

[jasmussen]

for saved custom views do we agree we should show the filter?

This is where I'm not in agreement. The fact that I've chosen a view on the left means I expect to see what's in the trash. I do not think of that saved view as a shortcut to filters, but rather, as primary navigation. Same as when I compare Posts, Pages, Media, Comments in the top level admin, I'm not thinking of those as saved filters of the database. I recognize there's nuance here, but fundamentally that's where my hiccup is.

[SaxonF]

@jasmussen by saved views I mean custom views created by the user. If I create a view that has a set of filters, would you expect to see which filters are applied ?

Another question, if a user selects "all", should I be able to filter by status? At that point we aren't showing all anymore. Play with GitHub Project or Notion views for comparison.

The point of these default views was that they were meant to provide a set of starting views for users. Part of the confusion though stems from them only being one filter eg status = draft. Maybe we let people customise them?

[SaxonF]

Thinking about this a little more today. What if we hide filters by default on any type of view (default or user created)? To expose filters you click the filter button after which you can see the filters applied and add new ones. For default views (like trash) you can't remove the filters applied, but for user created ones you can. "Reset" removes any customisations to the view. After making a change you can then save these back to the view. If a view contains no filters (e.g. default "all") then we just show "add filter" and reset clears all. The reset behaviour goes against what I mentioned here and is more in line with your thinking @jameskoster

The idea behind the above is that hiding will help to reduce the confusion mentioned in this thread but also allow customisation when needed.

[jasmussen]

by saved views I mean custom views created by the user. If I create a view that has a set of filters, would you expect to see which filters are applied ?

Thank you for clarifying, this seems to be the crux of the issue.

Consider the primary navigation:

And shown here, "Saved views":

Visually there's no difference between the two. Why do the latter show filter chips, and the former do not?

If there's a very cogent argument for showing those filter chips, then that collapsed version is an improvement (nice work!) but it's not clear to me we are fully considering the implication of what a saved view is meant to represent.

Here's trashed posts in the admin:

In the new designs, would I similarly see a "Status is Trashed" chip by selecting "Trash", here? And would I be able to remain on the Trash main section after I dismiss said filter?

[SaxonF]

Visually there's no difference between the two. Why do the latter show filter chips, and the former do not?

@jasmussen Those aren't easy to compare. Every page in the navigation shows something different on the right. In the case of views its a page that has filters set.

In the new designs, would I similarly see a "Status is Trashed" chip by selecting "Trash", here? And would I be able to remain on the Trash main section after I dismiss said filter?

In classic admin the status filter is the tab. If we went that route then we'd remove the status filter above the table and add a link for every status in the sidebar. In the new data views you have more flexibility when it comes to filtering (e.g. is/is not and selecting multiple ) so that approach becomes quite limiting.

Have a look at the proposal I added above. The idea is you can't remove filters that a default view sets but you can add to them e.g. trashed items who have an author.

In general I should be able to dig in to understand what a view is actually doing/filtering as some teams might create complicated views depending on the post types.

We talked early on about being able to pin or elevate views as well e.g. add "assigned to me" view to my top level navigation.

[jameskoster]

@SaxonF that sounds a lot like the 'locking' suggestion here, or are you saying that the status filter on the trash view would be editable but not removable? If so that brings us back to the original point about what to do with the navigation item... does it get de-selected if you change the status filter? In this case I'm not sure what is the benefit to locking it? 🤔

Perhaps this is what you're suggesting, but for bundled views I'd consider locking the filters entirely – you can still add new filters (e.g. status = trash + author = bob), but those associated with the initial view config cannot be changed. This would clarify the reset behavior and means the menu item can remain active. For custom views you can edit / remove anything – the menu item indicates the customisation and you can update/discard accordingly.

"Reset" removes any customisations to the view. After making a change you can then save these back to the view. If a view contains no filters (e.g. default "all") then we just show "add filter" and reset clears all.

This part is exactly what I had in mind for custom views. For bundled views "Save" is "Save as...".

[SaxonF]

@jameskoster not going to lie, I somehow missed the top locking suggestion , that's basically what I mean yep . Can't edit or remove. Only difference shown above is hiding filters by default but only if that helps clarify some of the confusion around exposing filters.

[jameskoster]

Okay, sounds like we're honing in on a combination of locking and marking views as modified.

To clarify... for the 'Trash' view:

• The status filter is locked so that you're always viewing trashed items. This means the menu item can remain active until you navigate away.
• Additional filters (e.g. 'author', 'date', etc.) can be added, at which point the view is marked as modified, and a 'Reset' action becomes available.
• Clicking 'Reset' will restore the view to it's original state.
• In the future, when a view is modified there will be a "Save" action (for user-generated views) and a "Save as..." action (for bundled views).

I'll update the OP :)

[jameskoster]

I left out the 'hiding' detail for now. Not opposed to it, but think it's worth trying the other parts initially then re-evaluating.

[jasmussen]

The value of showing "Trash" as a filter, when you're on the dedicated Trash page is still unclear to me, but you both have more context on some of these bits, and the locking approach can be worth trying unless I'm misssing something.

The main sitaution we should avoid is that you're on the dedicated Trash page, and seeing anything other than trashed items because of a filter you dismissed.

[jameskoster]

One benefit is the clarification around why you can't add another status filer, or if you can then why "Trash" wouldn't be an option there.

But more importantly it's helpful when there are multiple filters associated with the view. It allows you to interpret precisely what you're seeing at a glance, which may not always be intuitive from the view title alone.

I think the usefulness will become more apparent once its possible to save/edit views.