Action bar (component name tbd, formerly filter bar)

[hej-wesley]

A filter bar is a collection of components that provide controls to give users more agency over their content or data sets.

This page covers principles, controls, behavior scaling for build a filter bar.

Figma LINK

[agliga]

Initial passthrough for this seems to me there are some concerns with this component.

Questions and concerns:

• the buttons that live in the filter bar are based on the teams. I assume the page should decide what filtering components, and items should be added.
• The end bar is the same, some teams might have search, some might not
• The first filter button, what does it do exactly?

If we were to build this, the only thing I could see is us building a resizable bar to allow teams to place what they want in there.
We could have the first filter button as the only part of this that we provide and then have a section for users to add filter buttons and another section to add end buttons or something and space them out and resize them properly. But other than that, I don't believe there's anything else for us to build.

[hej-wesley]

Currently we present filters / section level controls in a lot of various ways across the experience. This is a framework a consistent presentation for designer to use.

Yes a lot of this is up to domains.

[agliga]

Lets have a kickoff with this, need some questions answered.

[agliga]

Probably will not do this issue. Will keep it open for now.
We need to extract the icon buttons that are present here and create a module for those since those do not exist in skin currently.

[agliga]

Had an initial kickoff. We will do the layout for this. Still waiting on updated design treatment

[agliga]

• Will need to build a add new item component, which has the + button on small containers, but on large container shows text as well
• Will need to build a search textbox, and have the search button turn into a search textbox. This will need to be built first Search text input field #2341

We will need to discuss what parts need to be built by skin and be generic enough to be a skin component.

[ArtBlue]

I added back the blocked discussion tag because we need to build other internal components first, and we haven't begun to talk about those yet. See Andrew's comment from June 27.

[namtheho]

Final Design & Specs under Action Bar — https://www.figma.com/design/8Tkj9vHE3BOHoWjiZ1pNt2/Playbook-2.0-%2F-Patterns?node-id=203-59654&t=x4gsBWK7B6tQwpdp-1

[namtheho]

[agliga]

For start need to investigate on how to do the responsive layout.

[ArtBlue]

❗ An issue to track:

1. We likely need some form of a horizontal scroll affordance for the menu buttons. This can be a gradient transparency overlay, a permanent scrollbar, or some other solution.

[hej-wesley]

@ArtBlue updated the documentation to address the visual affordance for when the filter bar has scrolling.

[ArtBlue]

@hej-wesley , I'm not seeing it in the Figma. Is there some new Figma? Can you paste a screenshot along with the correct Figma?

[hej-wesley]

https://www.figma.com/design/jFbAR0o364WhsjELfxl2SI/Playbook-2.0-%2F-Components?node-id=3995-278520

[agliga]

https://www.figma.com/design/jFbAR0o364WhsjELfxl2SI/Playbook-2.0-%2F-Components?node-id=3995-278520

Thanks for that
Can we also update the initial body text of the issue so that we're constantly not clicking on the wrong Figma file?
That would be great if we could do that for all of issues that get an updated Figma

[ArtBlue]

@hej-wesley , thanks for the quick turnaround. Just so we're all on the same page, since our page grid has gutters, the overflow will have spacing to the left and right. The design doesn't account for that as it is going all the way to the page edges. Just letting your know how the final implementation will look.

[cordeliadillon]

Was chatting a bit with @namtheho today about filter bars and just caught up on this thread. A few thoughts:

@hej-wesley , thanks for the quick turnaround. Just so we're all on the same page, since our page grid has gutters, the overflow will have spacing to the left and right. The design doesn't account for that as it is going all the way to the page edges. Just letting your know how the final implementation will look.

@ArtBlue, are the page grid gutters dictated by Skin or the containing app? If Skin, perhaps there could be two CSS variants of this component, one that's aware of gutters and one that isn't. The gutter-aware variant could use negative margins to offset the gutter and go full width.

@hej-wesley, does the overflow gradient only apply to the end of the list, or also the beginning once the list is scrolled? In other words, should there be a gradient on the left side once the user has scrolled the initial list elements out of view? From the spec, it looks like just the right side, but wanted to confirm.

[ArtBlue]

@cordeliadillon , as far as the gutters go, it's definitely technically feasible. However, to achieve it we would need to absolute position the filter bar - a strategy we use very sparingly as it pulls the element out of the natural page flow. The best use case for absolute is something temporary or blocking, like a tooltip or a dialog. If at all possible, I would personally very much like to avoid an entire permanent element being absolute. It's usually a doorway to a whole host of potential issues. I'll see how the rest of the team feels about it.

As for the gradient, I don't personally think we need one on the left. Since all pages start with the content aligned left for LTR, we just need an affordance for scrolling forward. Once a user does scroll forward they already know they can scroll back. We'd just need to do the opposite for RTL.

[randybascue]

Updated library component

[randybascue]

Updated doc draft for v1

[randybascue]

To recap on the v1 release:

• The team discussed the current design of the filter bar component, focusing on simplifying its functionality.
• Andrew raised concerns about having two separate functionalities: hiding buttons when there is a right-side action bar and scrolling when there is no action bar.
• The team proposed simplifying the design by always hiding buttons and showing as many filters as possible, with an 'all filters' option always available.
• Randy explained that the original intention was to maximize space usage across different screen sizes, showing more filters when there were no actions.
• The team discussed potential issues with horizontal scrolling on different devices, particularly on Windows machines where it is less intuitive than on MacBooks.
• They agreed to simplify the design for the first version (V1) by removing the scrolling functionality and implementing only the collapsing feature.

We'll follow this up with a v2 spike on the scrolling issue discovered during the build