Disclosures: Explore patterns for handling nested selection

Problem to solve (values)

In some cases, selecting a value where there are large numbers of possible values, or where values may have similar keys, can be difficult or impossible. Grouping can help, but if there are many groups, or many values in a group, it can still be difficult to find what you're looking for. Additionally pagination, and query performance, often limits results, which cannot be addressed by grouping.

Summary: Allow users to find and select any valid value.

Examples (GlCollapsibleListbox)

We're considering adding the ability to create custom fields in work items using tags or releases as the selectable. However in some cases the project the work item is in is not the project that tag or release is in, in fact the work item project might not have a repo at all. The ideal case would be to allow users to select a project, then select a tag, but where we could start in the current project when there is a repo.

We already have a similar pattern with parent, where we limit context to items in the work item namespace hierarchy. Users however can select an item anywhere, but must use the URL to find it. This is OK, but circumvents the expected behavior of the combobox to search using keywords. We could similarly use this for tags, but it's even less likely the user has the tag URL on hand.

Another example is iteration, where values are grouped by cadence. However in certain contexts, such as filtering, users want to be able to filter by past iterations, which can mean many iterations per cadence. Even in standard selection if there are multiple cadences it can be more difficult to find the right selection compared to first identifying the right cadence, then the right iteration; similarly when changing iteration it's likely going to be within the same cadence, so starting from that list would be sensible.

Secondary problem to solve (actions)

In some cases there are many actions that can relate to a single item, and some of those actions may be related, such as multiple copy actions. In other cases it may be helpful to show secondary selectors as part of the action selection, for instance showing users available types when using "Change type" would help clarify what this action does — you can immediately see what choices it affords you.

Example

One immediate place we could implement this is "Add related item", which could instead be "Add linked item > Related, Blocked, Blocking".

Summary: Allow users to easily browse actions and understand potential options for use (when relevant)

Proposed solutions

A: Traversal

Optionally support a back button in the disclosure header.

When a context selection is present, the back button provides navigation back to the context selector. The context should be referenced in the value selection header. Whenever relevant we should start users in the value selector to streamline selection, while optionally supporting other paths.

Pros: Supports default context, likely easier to manage focus

Cons: Difficult to browse across contexts, may be less obvious how to navigate efficiently with keyboard (e.g. we could make left-arrow a back shortcut, but this isn't entirely intuitive)

Context	Value

B: Flyout

Extend the dropdown model to a second dropdown, rather than replacing content.

Pros: Easier to look in multiple contexts quickly, more obvious keyboard patterns

Cons: Doesn't support a "default" context

C: Move from disclosure to modal

When using a non-default context, push users to a modal. This gets a bit tricky with state management — we'd potentially have to show the selected value in the default context.

Pros: no component changes

Cons: more complex state management between dropdown/modal

Default	Non-default (Browse)

D: Require links/ids (status quo)

Only ever utilize a default context, don't allow context switching. Require users to find a usable ID they can use to associate the item.

Pros: no component changes

Cons: not an expected use of "search" pattern, requires users to leave this context to find a link

Proposal

Option A provides a strong foundation for use in value selection use cases (GlCollapsibleListbox), where users are selecting values.

Option B provides an easy to use pattern for action selection, where a default context isn't necessary. This would allow extending our action menus further and move some information gathering up in the workflow, which could streamline workflows (i.e. by selecting the value initially, we pre-load the right content in a modal, rather than loading a modal then updating content)

Alternate keywords for searching: nesting, multistep, multi-step, parent child, hierarchical, progressive disclosure