Items filtering in Sidebar

[deeleman]

Hello there!

We at the One Admin team have been busy lately building the new shell for the One Admin project that will spread across the new React pages and the legacy Monkey pages, now wrapped by the One Admin layout. Such new layout implements the new Paste Sidebar plus a masthead wrapping a Topbar component including a UserDialog element. Everything works like a charm.

However, and given the HUGE density of links across all different centers in One Admin, several customers have requested some kind of filtering options so they can easily access the links they're after, without having to dig into each section or subsection in the hierarchical sidebar. Therefore, we came up with the idea of introducing a filtering search box so customers could more easily find the links they're after by keyword filtering:

small.mov

Some notes about the implementation:

• The search box is actually an <Input type="text" /> component since we could not figure out how to access the search event, inherent to the type=search input.
• The search input stands between the SidebarHeaderLabel and the SidebarNavigation so it remains always visible when scrolling.
• The matching link items are displayed by disclosing all sidebar disclosure wrappers, so everything remains visible at a glance.
• We highlight the items found by implementing a custom <Highlight /> component that leverages Text primitives to insert <mark> elements within the markup. The yellow color for the highlighted part is the default color for mark elements in the Twilio theme in use.
• The search query persists across SPA navigation and is reset upon collapsing the sidebar.

This is currently a PoC that still needs to be censored by our product designers but we wanted to get some early feedback from the Paste team as well, and also address some questions:

1. Is there any way we can subscribe to the search event in an <Input type="search" /> component in Paste?
2. We tried to abide to the content foundations for the placeholder copywriting. Any suggestions to improve it?
3. Is the search box location the most convenient one? We did not find any guidance in the list of patterns that could apply to this scenario?
4. Is the use of mark justified in this case from an a11y PoV?
5. We have noticed how the search box, which lives in a custom wrapper between elements SidebarHeaderLabel and SidebarNavigation, features an odd CSS behavior upon switching content, whereas the SidebarHeaderLabel features a different bottom margin/padding for no reason upon changing elements and sometimes the input even mpounts of top the sidebar header upon scrolling. Any hint why this might be happening?
6. Some of us believe that the search box stands out too much a,d perhaps it would be nice to leverage some sort of "ghost" or secondary variant for it (so it remains dark and blended over the sidebar and is only highlighted on focus). Is this something that could be considered?

Thanks and keep up the good work! 🚀

[serifluous]

Hey @deeleman !

1. Is there any way we can subscribe to the search event in an <Input type="search" /> component in Paste?

After some digging, it looks like the search event is non-standard according to MDN: https://developer.mozilla.org/en-US/docs/Web/API/HTMLInputElement/search_event , so your implementation may just be the way to go for now.

2. We tried to abide to the content foundations for the placeholder copywriting. Any suggestions to improve it?

For any inputs that aren't search, we recommend using a Label instead of relying only on placeholder since the placeholder disappears when text is entered. The reason is that a search bar with the search icon is a widely used UI element across the internet that it can be understood without a label.

Otherwise, the copy itself seems pretty clear.

3. Is the search box location the most convenient one? We did not find any guidance in the list of patterns that could apply to this scenario?

The location of the search box seems logical since it's always visible, but if you can do any user testing on the entire interaction, that'd be even better.

4. Is the use of mark justified in this case from an a11y PoV?

Yep!

5. We have noticed how the search box, which lives in a custom wrapper between elements SidebarHeaderLabel and SidebarNavigation, features an odd CSS behavior upon switching content, whereas the SidebarHeaderLabel features a different bottom margin/padding for no reason upon changing elements and sometimes the input even mpounts of top the sidebar header upon scrolling. Any hint why this might be happening?

Without seeing the exact code, it's hard to say why you're experiencing the odd CSS behavior. Can you share a Codesandbox reproduction?

6. Some of us believe that the search box stands out too much a,d perhaps it would be nice to leverage some sort of "ghost" or secondary variant for it (so it remains dark and blended over the sidebar and is only highlighted on focus). Is this something that could be considered?

You can use the inverse variant of the Input:

<Label variant="inverse" ... >
<Input variant="inverse" ... >

We don't document it on our website because we haven't yet developed guidelines for our inverse components, but you can see an example in Storybook: https://paste-storybook.twilio.design/?path=/story/components-input--input-inverse

Hope that helps! Let us know if you run into any other issues.