A tree view provides users with a way to navigate nested hierarchical information.
A tree view is text-only by default. This option is best used when a hierarchy consists of all of the same content type.
Icons can be used to add clarification about tree view items. These help to signify content types, which creates easier reference and context within the hierarchy.
Use thumbnails for when a user needs to have a preview of the content contained in a tree view item. Thumbnails are primarily used in experiences such as layer panels.
When a tree view is used outside of a panel (no borders on the left and right sides), the detached option will display the tree view items with rounded corners. A tree view is used inside of a panel by default, spanning from edge to edge.
By default, a tree view is not emphasized. This is optimal for when it's used with a clear indication of selected items elsewhere in the interface (e.g., a main/detail split view in which the selected item’s label is repeated or clearly indicated in the detail view).
The emphasized tree view has a translucent blue background and blue border for its selected state, to provide visual prominence that meets accessible color contrast ratio. This is optimal for when the selection should call attention (e.g., selecting a file to upload from a tree view, or when the tree view is the sole UI element for the interaction with the hierarchical content).
A tree view comes in four different sizes: small, medium, large, and extra-large. The medium size is the default and most frequently used option. Use the other sizes sparingly; they should be used to create a hierarchy of importance within the page.
Tree view items can display a drag icon, if necessary. The drag icon provides a keyboard-navigable indicator when multiple actions can be taken on a single tree view item. It only appears on hover, down, and keyboard focus states.
Tree views have the option of being either single-select or multi-select, for both checkbox and highlight selection styles. The default selection behavior for a multi-select tree view is to toggle selection on and off when selecting an item. The default selection behavior for a single-select tree view is to replace the current selection with the new selection.
Some tree views let a user select items, on which they can then take an action. Both single-select and multi-select tree views can display checkboxes to the far left side of each item, or display only a highlight state. With the checkbox selection style, clicking another tree view item will add that item to the selection. Clicking a selected tree view item will deselect it.
Sometimes it may not make sense to use checkboxes to indicate selection. In those cases, use the highlight selection style to display a highlighted state when a user is selecting one or more items. With this option, clicking another tree view item will select the new item and deselect any existing selection by default.
For the highlight selection style, use the emphasized option in order to meet contrast minimums. All tree views have a hover state, regardless if actions or selections can be made.
From the design point of view, each component has a number of options. These options and their names are platform agnostic, and each implementation should adapt these to fit into their framework.
small / medium / large / extra-large
yes / no
yes / no
|show drag icon|
yes / no
Drag icon only appears on hover, down, and keyboard focus.
single / multiple
checkbox / highlight
toggle / replace
The context area is reserved for icons or thumbnails that provide additional contextual information about the individual tree view item.
Clicking the collapse and expand button will expand or collapse a tree view item that contains child tree view items.
Tree view items can be dragged and dropped as a way for reordering or restructuring the hierarchy. Multiple tree view items can be dragged and reordered simultaneously. When selecting tree view items in different hierarchies, dropping them in a new location will flatten their hierarchical relationship with one another as sibling children of the tree view item that they were dropped into.
Tree views should also accept dropped items from outside the component in order to create new tree view items (e.g., dropping a new file into a tree view in order to upload a file to a specific folder).
When using this option for a tree view, the drag icon receives keyboard focus in order to allow for a keyboard-based drag-and-drop interaction.
When a tree view item label is too long for the available horizontal space, the label truncates. The full label is displayed on hover and focus within a tooltip.
For proper functionality, a tree view needs to display the collapse and expand button, which uses a chevron icon. This makes it clear to a user as to what kind of behavior to expect when they click on the icon of a tree view item.
Use the chevron icon to show how to toggle the collapse/expand behavior.
Don't remove or replace the chevron icon with unique iconography.
If you need to display hierarchical information from different sources, display them in a single tree view as separate sections with section headings. These sources should not cross-reference each other so that you don’t confuse users. Single selection and multi-selection should work as expected for a single tree view component.
Separate tree views into sections with headings.
The root (topmost) level of the hierarchy doesn't always need to be displayed, nor be displayed as a tree view item. In some cases, the root does not provide a user with any context and it can be hidden or replaced with a section header. In other cases, such as with mixing tree views, the root can be displayed as a “back” button.
Use a heading and unique icon for showing a root item.
Sometimes it's necessary to show different hierarchical displays based on the context of what a user is navigating. In those cases, allow for a user to replace a tree view item by “driling" into it, displaying a different variation of the tree view within the same panel. Place the tree view within a navigation controller (which should provide a “back" button) to enable this type of drill-in navigation.
Display a tree view within a navigation controller for drill-in views.
Choose icons that relate to the object type being represented in the tree view. These icons can be unique to specific data types, to add better clarification for users.
Use an icon that correlates to the type of object being shown.
Tree view items can show thumbnails as an alternative to icons. Thumbnails are best used when a user needs to have a preview of the content represented by the tree view item. Icons can be used as a fallback for when an image is unavailable, but should be appropriately sized to match the thumbnail.
Use thumbnails to preview content.
Tree views with thumbnails should use a thumbnail size that is appropriate to the size of the tree view itself. For example, an extra-large tree view would not work well with small thumbnails; those proportions may be better suited for using icons instead.
Don’t use large thumbnails in a small tree view.
In some cases, multiple thumbnails need to be displayed in-line with the tree view item (e.g., layer masks). These thumbnails should be individually selectable and inherit all other behaviors of a standard tree view item, such as drag-and-drop behavior. Don't use more than 3 thumbnails per tree view item.
Separate multiple thumbnails with an indicator.
One way to address overflow is to set a limit on how many levels of hierarchy deep that a user can create in a tree view. Some products use this method to mitigate the complexity that comes with deeply-nested hierarchies. Limits can help for when having a complex hierarchy isn’t necessary to an experience.
Restrict hierarchy depth when appropriate.
When a label's length is too long to display within the tree view, the text will truncate at the end using an ellipsis. Hovering over or focusing on the truncated tree view item should reveal a tooltip that shows the full text of the label.
Show truncated labels using a tooltip.
When a user’s tree view hierarchy could be deeper than the available space in the layout, use an adjustable layout mechanism like panels or rails. This will allow users to modify the layout and still preserve visibility on their tree view.
Use an adjustable layout for deeply-nested hierarchies.
If you have a layout that doesn't allow for users to adjust the width of the container for a tree view, allow them to horizontally scroll in order to see the full depth of the hierarchy.
Allow horizontal scrolling in a fixed layout.
When tree views are very large, use a progress circle or a "show more" affordance to show additional parts when it’s contextually relevant. These loading patterns can apply to the entire tree view, or to nested tree view items.
Display a progress circle when loading large tree views.
If system processes are delaying the display of child tree view items when a parent tree view item is expanded, show a clear indication that the items are in the process of loading.
Show a progress circle when waiting for tree view data to load.
Users should be able to sort a tree view. Sorting should not affect the hierarchical structure since each layer of the hierarchy is sorted individually.
Sort at the individual layers of the hierarchy.
Users should be able to filter a tree view’s content in order to quickly find the items they're looking for. When filtering hides sections of the hierarchical structure, the remaining tree view items are displayed as a root item. If filtering doesn't remove structures, the hierarchical relationships are still retained.
Flatten or retain hierarchy in filter results.
Users may need to be able to directly modify a tree view. They should be able to create new parent or child tree view items, such as a grouping or a folder. They should also be able to flatten the hierarchy at an individual tree view item level (e.g., ungrouping a group of layers). In some cases, the tree view item labels should be editable by the user.
Any action for modifying the hierarchy should be presented as both an explicit action as well as keyboard shortcuts (if needed), but never as keyboard shortcuts alone.
Use persistent actions to allow for modification to the hierarchy.
Allow users to explicitly enter a multiple selection mode when keyboard shortcuts (Shift + click) are unavailable, or when you want to display a unique kind of selection. Do this by toggling between the selection style, from highlight to checkbox.
Allow users to enter multiple selection mode.
The checkbox selection style is intended for performing bulk actions on tree view items. Use this option when selection corresponds to bulk actions.
Use checkbox selection for modifying items in a tree view.
When you need to provide selection controls within a hierarchy, use a checkbox component in place of the tree view item’s label. This shouldn't correspond to the selection of specific content, and is optimal for use cases like categorized filtering.
Use a checkbox component for selecting hierarchical options.
For RTL (right-to-left) languages, the entire tree view is mirrored horizontally, including the direction of the collapse and expand button. Workflow icons follow iconography internationalization guidelines.
|Tab||Moves focus to the tree view, placing the first tree view item in focus.|
|Down Arrow||Moves focus to the tree view item below or to the next thumbnail of a tree view item.|
|Up Arrow||Moves focus to the tree view item above or to the previous thumbnail of a tree view item.|
|Enter or Space||Selects the currently focused tree view item. If focus is on a child of the tree view item, subsequent action is based on the child component’s keyboard interactions. For the drag icon, this places the user in drag-and-drop mode.|
|Right Arrow (Left Arrow in RTL)||Expands the currently focused tree view item. If the tree view item is already expanded, or if the tree view item is not expandable, focus is moved in a left-to-right direction along child components. If focus is on the rightmost child of the tree view item, focus does not move.|
|Left Arrow (Right Arrow in RTL)||Collapses the currently focused tree view item. If focus is on a child of the tree view item, focus is moved in a right-to-left direction along child components. If focus is on the leftmost child of the tree view item, focus is placed back on the parent tree view item.|
|Home||Moves focus to the first item in the tree view without opening or closing a level.|
|End||Moves focus to the last item in the tree view that is focusable without opening a level.|
|Cmd + [ (optional)||Moves the currently selected item up in the view order.|
|Cmd + ] (optional)||Moves the currently selected item down in the view order.|
|Cmd + Z (optional)||Undoes the action most recently taken, such as after the user drags and drops, reorders, or performs an action on a tree view item.|
|Cmd + G (optional)||Groups the selected tree view item(s) into a new parent tree view item.|
|Shift + Cmd + G (optional)||Ungroups or removes the selected parent tree view item, placing its children at the same level of hierarchy as the removed items.|
|Apr 06, 2022||3.0.0|
|Mar 23, 2021||2.0.0|
|Feb 14, 2020||1.0.0|
Includes all interactive states that are applicable (hover, down, focus, keyboard focus, disabled).
Works properly across all four color themes (lightest, light, dark, darkest).
Includes a desktop scale (UWP, macOS, web desktop) and a mobile scale (iOS, Android, web mobile).
Color is not used as the only visual means of conveying information (WCAG 2.0 1.4.1).
Text has a contrast ratio of at least 4.5:1 for small text and at least 3:1 for large text (WCAG 2.0 1.4.3).
Visual information required to identify components and states (except inactive components) has a contrast ratio of at least 3:1 (WCAG 2.1 1.4.11).
UI language and information design considerations have been incorporated into component design.
Includes relevant options (variant, style, size, orientation, optional iconography, decorations, selection, error state, etc.)
Includes guidelines for keyboard focus, layout (wrapping, truncation, overflow), animation, interactions, etc.
Includes a list of dos and don'ts that highlight best practices and common mistakes.
Includes content standards or usage guidelines for how to write or format in-product content for the component.
Works properly across various locales and includes guidelines for bi-directionality (RTL).
Follows WCAG 2.0 standards for keyboard accessibility guidelines and includes a description of the keyboard interactions.
All design attributes (color, typography, layout, animation, etc.) are available as design tokens.
Includes a downloadable XD file that shows multiple options, states, color themes, and platform scales.
Includes a downloadable XD file, generated by code using design tokens defined in Spectrum DNA, and shows multiple options, states, color themes, and platform scales.
Component is included in the Spectrum for Adobe XD plugin.