SciCatProject
Proposed design for Dataset Filters
Issue Name
Proposed design for Dataset Filters
Summary
Currently the datasets list filter form does not contain all the relevant high level fields and has a different workflow to add filters on scientific metadata. This issue is to open the floor for a discussion on how to improve the UI/UX when working with filters on datasets
Proposed new design
Where applicable, the filters should contain also the operator, and, in case of scientific metadata, the units. The new form should look something like the following
The user should be able to change the operator and the unit where applicable. Unit is not shown in the image. When the user wants to change the filters used, it should click on the "more filter", which should be rendered as a normal button. This will open a modal similar to the following:
The selection modal has too columns: enabled (aka shown in the main filter form), and disabled (aka not used at the moment). The individual filter can be enabled or disabled by dragging and dropping it in the correct column.
If the user wants to add a filter on a scientific metadata entry, he/she can use the text field combined with a drop down which will show the available options once at least 3 letters are present. The search box should work on both the machine and human (display) name.
Once he/she pick the correct metadata, he/she click on add scientific metadata filter and a new filter will be added in the enabled column. Scientific metadata filters have the additional "trash bin" icon as they can be deleted from the list. Example is "Run Number" filter.
Users can also order their filter using the left icon. The form in the datasets list page will be modified accordingly.
Datasets' high level fields will be always available and a default configuration can be set in the main configuration. Each use can than configure their own form and the configuration will be consistent across sessions.
I agree that this section needs improvements. However, I think we can achieve it with less changes than the proposed design.
Moving forward, I think "Keep It Simple" would be a great motto.
The current way of enabling/disabling filters seems simpler and easier to understand than the proposed design. What is wrong with the toggle we currently have? I think we can keep the "More Filters" / "Configure Filters" modal and move "Conditions" out of there.
How about something like this?
The cogwheel next to the heading "Filter and Conditions" would open the modal that would let you toggle the high level filters on and off (as we have today with "More filters" excluding "Conditions")
Clicking "Add Metadata Condition" would open a modal like this (as we already have too, it needs some padding though)
Then when you have added a condition like that you have the option to toggle it, edit it (opening the modal again) and delete the condition as you can see in the first image.
Added benefit is that when you add a condition you only have to click "Apply" once.
Also, why do we need reordering of the filters?
@emigun The issue with keeping both enabled and disabled filters in one column is that the list can become very long, especially as we add more high-level filters (e.g., proposalIds, sampleIds, etc.). We can improve the interface by, for example, using a green color for the “Enabled” title and a red color or reduced opacity for the disabled section. Regarding the scientific metadata condition, it is simply a nested high-level filter with operators, so we prefer not to separate its filter form from the other filters. About reordering I don't have a comment on that, I think it's fine to have or not have it
I think it should be very rare that a user should need to go into this "Configure Filters" modal. With the conditions removed I don't see how it will be that long. Also if a user would want all filters it would still be as long.
~~I would argue that in your proposal, the scientific metadata conditions are different as you can't edit the filter values directly in the left side as you can with the others.~~ On the other hand, I don't see a problem with a somewhat different workflow for scientific metadata as it is different (operator, unit).
Here is a proposal from our UI dev on how to simplify the scientific metadata conditions in the left side even more:
Having two different workflows for the filters on high level fields and scientific metadata add complexity. I would love to have one behavior for all filters. Regarding the ordering of the filters. It is a nice-to-have that it is already implemented, it would be nice to maintain it. In addition, different users use filters in different ways and they want to order them in their own way.
Few questions about your approach:
- how would you enable/disable filters on high level fields?
- what would you do if you disable a scientific metadata filter?
- some high level fields would benefits from having an operator selection, for example "title" matching or containing a string. How do you envision to implement that? Right now you cannot say, please find me datasets where number of files are between two values or greater than.
Okay I understand your perspective better now!
- how would you enable/disable filters on high level fields?
As today, but with the cogwheel instead?
- what would you do if you disable a scientific metadata filter?
Click the checkbox/toggle?
Perhaps I misunderstand these two questions.
- some high level fields would benefits from having an operator selection, for example "title" matching or containing a string. How do you envision to implement that? Right now you cannot say, please find me datasets where number of files are between two values or greater than.
I see. If we need a filter for number of files in a range, I guess a normal filter would look something like:
For the title, wouldn't the normal behaviour for such a filter be that it looks for a title containing the string you put there?
I think in both approaches scientific metadata has different workflows compared to high level filter. Maybe the user will think it is a bit messy to mix them. Not sure.
A nice thing about your approach is that you can edit the value directly and you only have to click "Apply" once. (I missed that first). That is a keeper!
Hi, apologies for my naive view but why can we not have the user type in the key of a scientific metadata in the prominent search bar? Thanks.
The following issue on the backend is related to searching and we would appreciate this taken into account on the frontend too. https://github.com/SciCatProject/scicat-backend-next/issues/1970
