Implementing Filters as Tabs in a Web Dashboard

Question

We are trying to provide users with a strong filter mechanism on a Dashboard that collects visit data. It feels like we have arrived at a point where only a few pieces of the puzzle are missing and we don't know how to place them.

The user should be able to:

1. Define the filter parameters.
2. Save them for future use along with a name.
3. Apply them for one-time use to quickly check or search something without the need for saving them.
4. Modify the parameters of an existing saved filter and save it again.
5. Open tabs in the software itself and apply different filters (saved and unsaved) to easily switch from one type of data to another.
6. Close tabs.

Constraints:

There is a live view tab that is static and can't be modified or removed by the user. (Mentioned from now on as the default tab)

Solution: (So far) 1. A filter button on the dashboard that opens a side panel for filters that contains all the parameters and allows the user to save a filter, save as existing or just apply.

2. A Tab System that works like you'd expect. It allows the user to change the filter applied in a tab by clicking on a drop-down icon on the right side of the tab itself and selecting from the saved filters list.

3. A plus button at the end of the tab list which works exactly like the drop-down above, prompting the user to select which filter view to apply on the new tab avoiding any empty states or empty tabs open.

Points we still can't seem to get a grip on:

1. How to make the experience of applying a filter to any open tab as seamless as possible? For example, if the user is on a tab and he clicks on the Filters button and changes some parameters and clicks Apply. Should we update the view to Unsaved View? Should we keep the name of the tab same with an asterisk to denote unsaved state with a reset button? Or should we open a new tab (potentially leading to a lot of unsaved tabs open?)

2. If subsequently, he refreshes his page? Should the unsaved view disappear (being unsaved) or should we keep it in memory (potentially not really creating a need to use the 'Save Filter' feature)

3. How to treat the default tab in all this? Should we disable all filtering options in the default tab to avoid any confusion leading to some loss in discoverability of filter features that are available as they will not show in the default tab or should we show filtering options on the default tab and open any changes made on the default tab in a new tab leading to a little bit of inconsistency (changing any filters from the default tab always opens a new tab while changing any filters from other tabs only makes changes to that specific tab and then implementing a fail safe or an error state if the user tries to make changes to the default tab with the maximum limit reached)

4. Creating a responsive design around the solution.

It'll be great to get insights and thought process on how to go about this problem.

Answer 1

1.In a modern, ideally programmed system, filters should work dynamically in real time - however, due to system limitations:

For a card with saved settings:

• a) Let's assume that we search for the target element by the X Y Z parameters

• b) We want to see the results so click apply.(the card closes
  automatically and we see the result)

• c) We see 30 results, but we decide to change the Y parameter to narrow down the results

In this situation, after opening the window with filters, I think that the parameters X Y Z should be remembered from the previous operation (stored e.g. in localstorage) - however, this requires analyzing several scenarios and discussing the most appropriate solution.

Perhaps the filters should be redesigned? (as a sliding div, not a collision modal)

2. It should keep the previous state (the memorization mechanism is often used in multi-step processes)

3.Limit the source of truth and minimize the solution to a minimum - if in the context of design the solution creates inconsistencies - it will be even more difficult to implement. Specifically I suggest keeping one card and remembering the state

4. hmm, create a new filter screen? limiting their number to the most necessary? This point will take much more time