Document the "Filter builder" pattern
For more sophisticated filtering of more complex data, a more sophisticated pattern is required. One that would allow high level of customisation of filters with different operators and possibility to select multiple options for a parameter.
Goals of this issue:
- Discuss and decide whether we should document multiple filter builder patterns or just one?
- Consider all the requirements for filtering complex data (is there something missing in current explorations?)
- If we decide to update the filter component as described here (Filter component — move filter tokens outside o... (#1477)), do we still need the filter builder pattern?
- Solution validation as required
Single dropdown
Pro: minimal UI placed contextually to where the filter adding is triggered.
Con: the interaction inside the dropdown is new to GitLab, maybe it's a bit unusual?
Drawer 1
Pro: Very flexible and gives designers a lot of space to work with.
Con: Isn't placed contextually (opposite of single dropdown) and adding numerous filters could get cumbersome.
Drawer 2
Pro: Very flexible and gives designers a lot of space to work with and it's fast to add filters.
Con: Isn't placed contextually (opposite of single dropdown) and adding numerous filters could get cumbersome. But because this option is faster, maybe less cumbersome than Drawer 1?
3 dropdowns
Pro: Lots of flexibility contextually placed right in the UI.
Con: Problems with placement in condense UI when there's little room to work with.
Modal
Pro: High level of flexibility with amount of content and its placement, more contextual placement than the drawer.
Con: It's a modal