Sectioned Select

[TJ-G]

😯 Problem to Solve

I don't see anything tagged as 'client-request' or 'enhancement' that matches this, but please feel free to close if I missed an existing request similar to this.

When a user selects a notebook (say from the analyze slide-out in the files grid), they see all notebooks published to workspaces they have access to. One key thing here is that notebooks are published to workspaces for access control. Notebooks with the same name may be published to different workspaces and, currently, will show up in the dropdown without any way to differentiate which one is in what workspace.

💁 Proposed Solution

I'd like the ability to section/segment/group the items in a combo-box and give each section a header. This would let me group the notebooks by what workspace they're in, and let the user know the name of that workspace by using that as the header for each section.

It looks like we can sort of get this behavior by inserting disabled items as the header, but that means we can't actually have disabled items in the list, and they don't really stand out as a 'header' and are hard to read.

[m-akinc]

You can actually include elements other than nimble-list-option in the combobox's content, e.g. <h3>Workspace 1</h3>. Does that fully address your use case?

[TJ-G]

Oh, interesting... yes, I think it would, especially if we can stylize them a bit.

Thanks for letting me know that's already possible!

[rajsite]

You can actually include elements other than nimble-list-option in the combobox's content, e.g. <h3>Workspace 1</h3>. Does that fully address your use case?

@m-akinc @atmgrifter00

I don't see any stories or tests describing that use case. Is it tested (maybe I'm missing it)? Do we know how things like tab order and keyboard interactions, etc behave? What kind of content are we supporting, just decorative or interactive (can you dump a textbox, or a nimble-button in there)?

If we say it's supported we need testing and user guidance of what is supported. In addition we need documentation and examples in storybook.

Generally speaking we do not support placing arbitrary content in slots. Only certain use-cases are supported and we should add tests if we want to say we support additional use cases.

[atmgrifter00]

@rajsite @m-akinc @TJ-G, yeah I'm not sure how this will behave with things like filtering. We should explore this use-case a bit, and as @rajsite mentioned update tests and docs as needed.

[TJ-G]

okay, sounds good. Thanks for the input! I guess the right thing to do for now is to click this re-open button and when there's time to prioritize some research and testing we can evaluate if inserting html elements meets our needs.

[jattasNI]

One other workaround available today would be to append additional information to each item's text. e.g. "Notebook 1 (Default Workspace)"

[jattasNI]

This request came up again in this SLE PR. It was the same use case: notebooks in different workspaces not being easily distinguished.

[jattasNI]

Here's another SLE PR implementing the approach described above of adding <div> elements to delineate sections. As suggested above, we should add test coverage and documentation for this case.

[jattasNI]

@NIbokeefe in this SLE PR we're adding section headers to separate groups of combobox items. Do you have any visual design feedback about the styling of the headers? Personally I think the padding looks a bit cramped but I defer to your recommendations.

[NIbokeefe]

@NIbokeefe in this SLE PR we're adding section headers to separate groups of combobox items. Do you have any visual design feedback about the styling of the headers? Personally I think the padding looks a bit cramped but I defer to your recommendations.

@jattasNI

I have a design for headers/group-labels for menus. In this design you've shown here it looks like we are using the controlLabel_1 token as the menu header. Instead if you can use the GroupLabel_1 token documented in both XD and Figma. It's an 11px Source Sans Pro Semi-bold font. The color token is Black91 @ 100% Opacity.

You should be able to extract the correct spacing from either of those spec documents. Please let me know if you run into any issues.

https://www.figma.com/file/PO9mFOu5BCl8aJvFchEeuN/Nimble_Components?type=design&node-id=1295%3A93863&t=JljnGeOi5lXwzyQf-1

https://xd.adobe.com/view/33ffad4a-eb2c-4241-b8c5-ebfff1faf6f6-66ac/

[rajsite]

@NIbokeefe would we expect to use the horizontal line between each of the headed groups like the menu? Notice that the screenshot of the select currently doesn't have those.
Are we concerned about forcing all caps on user provided strings? I'm not actually sure if workspace names are case-sensitive.

[NIbokeefe]

@rajsite

Great questions Milan, thank you!

Horizontal line: My instinct is to keep the lines by default for the sake of simplifying the way we handle our patterns. If it's important to separate items by group it's ideal to visually reinforce it. This horizontal line brake concept derives from our general menu and serves multiple purposes. I always try to back a concept by 2-3 visual cues to account for accessibility and unknowns. I'll point out the added benefit to the line brake when regarding potential modification to the typography of the header.

All caps: I don't have the context to this specific situation to say one way or another about the all caps. By default, we should us all caps to drive consistency. If the headers are user inputs or the case styling is important; this is for sure a concern and we should consider deviating from the all caps. The header visual design is supported in multiple ways: Headers are at the top of grouped items, in semi bold font and are divided by the horizontal line brake. We're not entirely relying on all caps to determine what's a header, so if we need to make that change it should not be a huge concern. However, I can't guide whether that's necessary without learning more about the functionality and use case.

[rajsite]

A related issue that came up in an SLE PR is for the following scenario:

• The combobox has two options that have the same value under different header elements (a notebook with the same name in two different workspaces)
• The Angular CVA for the combobox always picks the first model object that matches the selected option value
• How can the app get the second model value instead?

This goes against the design of the combobox as-is which is modelled as a text input field that should not have knowledge of option selected but instead of text selected. Likely the desired behavior is to use a select control instead with the UX of being able to type ahead to filter options which can model a selected option correctly.

[atmgrifter00]

Early prototype for API demonstration (and Storybook]). This prototype was focused on the Select, but its API would be identical for the Combobox.

Some observations made while demoing the prototype (noting its use in combination with filtering):

• Allow groups to be used to filter on, which would both find ListOption entities with that name, and show all of the ListOption entities under a group with that label.

[jattasNI]

Interaction Design Questions

1. how does filtering impact the section headers? Are the headers still visible after items are filtered (they likely should be)? Do section headers match the filter? If they do, should we show everything under the header that matches even if those items don't themselves match the filter?

We plan to have the dev team propose answers to these questions and run them by IxD.

[m-akinc]

The functionality is now part of the Nimble select. We'll use a separate AzDO feature to track integration into SLE.