Define standards for search/filter/sort bar group component.

Primer video: Practicing "Sophisticated Simplicity"

Description

There seems to be no standard for filtering, sorting, searching. As well some times action buttons are thrown in on top or around for extra spice. I would like to propose a standard search + filter + action bar group to keep things more uniform and easier to implement across the platform as a single component to build off of, rather than piece meal every time. This should include styling and formatting. This might also be tied to tabs, which also need more clearly defined rules for choosing tabs vs. filters.

Examples

Filter	Search + sort + action button	Search + action button
		cell

Search + sort bar	Filter + sort bar	Filter + filter + sort + action button

Figma file

View working file in Figma →

Proposal

1. Define visual standards for the component
2. Update documentation on when to use tabs versus filters.
3. Define and standardize sort behaviors and appearance.
4. Evaluate instances of tabs in the environment to see what should be converted to filters.
5. Improve documentation for action button position for page versus page section/container.

Checklist

Make sure the following are completed before closing the issue:

1. Assignee: Design in your working file. When applicable, follow our structure, building, and annotation guidelines. If you have any questions, reach out to a FE/UX Foundations designer.
2. Assignee: Update the link to the working file in the issue description.
3. Assignee: Ask a FE/UX Foundations designer to review your design (ensure they have edit permissions in Figma).
4. Reviewer: Review and approve assignee’s design. Specific design questions can be addressed with comments in Figma. Comment in this issue when the content is less specific to the design or requires greater visibility.
5. Reviewer: Assign to a Figma maintainer for final review (make sure they have edit permissions in Figma).
6. Maintainer: Review and approve assignee’s changes.
7. Maintainer: Merge the branch or add the changes or additions to the target file.
   1. Ensure that all styles and components now belong to the target file.
   2. For changes to the Component Library file, view the components in the Assets panel to ensure they align with our asset library structure guidelines.
8. Maintainer: When applicable, publish any library changes along with a clear commit message.
9. Assignee: If work was not done in a branch (a merged branch will automatically be archived), move your working file to the shared Figma project:
   1. For Component Library changes, move your file to the Component archive project.
   2. For all other changes, move your file to the Misc archive project.
   3. If you’re a community contributor, please consider transfering ownership of your draft file to the maintainer so they can move it to our archive, along with its version history and comments.
10. Assignee (or Maintainer, for community contributions): If it’s a new pattern or a significant change, add an agenda item to the next UX weekly call to inform the team.
11. Assignee: When applicable, create an MR in this repository and apply the "component-guideline" template to create or update the component’s documentation page. If you do not have capacity, create an issue in this repository using the "Component documentation" issue template. Bring the issue to your team planning session for prioritization and scheduling. Mark the new issue as related to this one.
12. Assignee: When applicable, create an issue in GitLab UI using the "Component" issue template to build or update the component code. Bring the issue to your team planning session for prioritization and scheduling. Mark the new issue as related to this one.
13. Assignee: Congrats, you made it! You can now close this issue.

added Figma UX labels

assigned to @dmoraBerlin

Hi @dmoraBerlin,

Please make sure that both a workflow label and weight are added to your issue. This helps to categorize and locate issues in the future.

Thanks for your help!

changed title from Define search bar group component. to Define standards for search/filter bar group component.

added Category:Design System Pajamas Pajamas UI Kit groupfoundations labels

changed title from Define standards for search/filter bar group component. to Define standards for search/filter/sort bar group component.

changed the description

changed the description

added workflowvalidation backlog label

changed the description

Setting label(s) ~"devops::ecosystem" sectiondev based on groupfoundations.

added sectiondev + 1 deleted label

marked this issue as related to #1215 (closed)

marked this issue as related to gitlab-org/gitlab#238183 (closed)

changed the description

mentioned in issue #1228 (closed)

marked this issue as related to #1228 (closed)

unassigned @dmoraBerlin

mentioned in issue gitlab-org/gitlab#343115

mentioned in issue #1337 (closed)

changed the description

@matejlatin I think you can assign yourself this issue for the filter component.

cc @tauriedavis

assigned to @matejlatin

1. Define visual standards for the component
2. Update documentation on when to use tabs versus filters.
3. Define and standardize sort behaviors and appearance.
4. Evaluate instances of tabs in the environment to see what should be converted to filters.
5. Improve documentation for action button position for page versus page section/container.

@dmoraBerlin which component did you have in mind here? I'm also thinking this list should be broken down into smaller issues (one for each) instead of tackling this all together at once. WDYT?

@matejlatin I agree I think it could be broken down to smaller issues for sure.

I think the first thing that can be done which is a good project is Item Define and standardize sort behaviors and appearance. (Tied to Item and for documentation) Right now we have a sort drop down in some tables, and some tables have sortable columns. And some sort options in the drop down are not in the table. This behavior should be unified to prevent having sorting options in multiple locations.

Item should probably be separate, but tied to the documentation to be done on Item . There are cases where tabs are being added to content/tables where they could be filters, or whole other sections. Tabs on top of tabs is another related problem.

Issue is more of a problem for outlier issues this is a very old example I worked on, moving the green button to the primary button rows:

Thanks @dmoraBerlin I'll create issues as I go through these

@matejlatin I had recently created this issue related to these topics as well. #1404

@dmoraBerlin @matejlatin I struggled with figuring out how to make a filter more discoverable and prominent using the filter component recently... I ended up pulling that filter out and using a toggle to show/hide the data. @mnichols1 suggested I add my use case here:

Groups can manage their own runners that are installed in that group or in projects in that group. Today, the group owners do not see all runners that are available to run jobs in that group. For example, they don't see shared runners that are used to run jobs (and set at the instance level by the admin). In a project and at the admin level, you can see all runners available to you to run jobs. We wanted to make those runners discoverable to the group owner, but adding those to the list by default might be confusing since it would jump the number of total runners up. Also, since group owners won't be able to edit those runners, they may not want to see them at all times. To me, that meant using a filter would be best, but I didn't want to hide it under the filter component, given that the number of runners could increase so much and it may be confusing why. I ended up elevating that filter and using a toggle to display it.

Thanks for sharing this interesting example @gdoyle.

I ended up elevating that filter and using a toggle to display it.

Where is this toggle? i can't seem to find it in the screenshot above

@matejlatin It is next to the filter component!

@gdoyle was your primary requirement discoverability? ("I want my users to see this feature") I'm not sure I agree with this implementation, as it is now a new form of filtering, but it does help prove the point of the issue that there needs to be better guidelines and processes for filtering data. I'm wondering if the filter component itself is the object failing here as it does not offer sufficient discoverability for your requirements. A counter (extreme) example being a shopping filter, where the discoverability is visibly apparent. Regarding "sophisticated simplicity" it completely lacks sophistication, but is very simple.

CC: @matejlatin

was your primary requirement discoverability? ("I want my users to see this feature")

@dmoraBerlin Yes! Unfortunately, we also were already using tabs in the view as a "form of filtering", and we didn't want to create more levels of tabs to improve the discoverability of "all runners that are available to run my jobs".

Oh, I see @gdoyle. Thanks for clarifying.

I ended up pulling that filter out and using a toggle to show/hide the data.

I think it's this part that confused me. Where was the filter before?

I'm wondering if the filter component itself is the object failing here as it does not offer sufficient discoverability for your requirements. A counter (extreme) example being a shopping filter, where the discoverability is visibly apparent. Regarding "sophisticated simplicity" it completely lacks sophistication, but is very simple.

Interesting point @dmoraBerlin! Something we should look into. The more I look into filtering, the more I think we rely too much on the filter component.

I think it's this part that confused me. Where was the filter before?

@matejlatin It didn't exist before!

@matejlatin That is something I didn't realize at first, but after you vocalized it perhaps that is an issue, where we have a abundance of data we want to manifest, but we have a table with a filter so we use that as the default solution... That connects with the idea of creating tabs to "pre-filter" data.

That connects with the idea of creating tabs to "pre-filter" data.

Exactly. I'm working on updating the filtering guidelines to suggest that there are alternatives to the filter component. Combinations of these alternatives could actually be more usable. Tabs is one of the components that can be used as alternatives (in combination with others).

It didn't exist before!

@gdoyle got it. Thanks for clarifying.

marked this issue as related to #1404

mentioned in merge request !3043 (merged)

changed the description

changed the description

mentioned in issue gitlab-org/gitlab#337838 (closed)

mentioned in issue #572 (closed)

I'm focusing on filtering right now (https://design.gitlab.com/regions/filtering) so I decided to create a new issue to build on top of these filtering guidelines which were recently merged. This is the new issue: #1424

As I mentioned earlier, I think this issue should be broken down into smaller ones, the issue I mentioned above could be treated as one of the ones required to solve the problems described here. It's not an exact match though, that's also why I decided to open a new issue. I'll work on that one and I'll unassign myself from this one.

unassigned @matejlatin

mentioned in issue gitlab-org/gitlab#378259 (closed)

A related issue to this could be investigating and documenting strategies when a search/filter has less than 3 characters.

There are sometimes performance issues that prevent searching when the query is short.

Related issues/MRs:

• Prevent search for when under 3 characters (gitlab-org/gitlab!101540 - merged)
• Namespace filter works only after 3 characters (gitlab-org/gitlab#327658 - closed)
• Allow searching of users using less than 3 chars (gitlab-org/gitlab!79927 - merged)

cc: @matejlatin @dmoraBerlin — please point me in the direction of a different issue if you know of one more relevant.

@danmh I'm not sure on that one. An example is the label UX. I'm not sure there would need to be standards defined on that, but rather code improvements? Unless we're sacrificing code improvements to force documentation on the limitations, which doesn't feel like good UX.

FYI: @badnewsblair @chrismicek

@danmh I think it would be best to open a new issue for this discussion.

My opinion right now is that we shouldn't prevent searches when under 3 characters. The reason that @dmoraBerlin put forward is a good example.

Maybe there's a difference between the two types of searches we have? "Search by click" and "Search by type". The first one is not a problem, if there are at least two characters in the input field, the user should be able to search. It's the second one that gets problematic. Maybe we can trigger searches only when there are at least 2 characters in it?

@matejlatin @dmoraBerlin thank you both for the input. I've created the issue to discuss this further #1451

mentioned in issue #1451

mentioned in merge request gitlab-org/gitlab!101540 (merged)

added devopsmanage label and removed 1 deleted label

marked this issue as related to #1424

added groupdesign system label and removed grouppersonal productivity label