Description
Sub-panels are sub-levels to regular Panels. When a Panel and Sub-panel are used together, they depict two different levels of the same information: the Panel reflects the broader context while Sub-panels is concerned with its details, usually reflecting the user's selection. Because of this dynamic, Sub-panels take on a kind of child relationship to the parent Panel.
Usage
Sub-panels don't make sense alone and should never be used unless combined with a Panel. Use Panels to build or define the broader context and Sub-panels for individual components belonging to that context, such as cards, columns, widgets, and so on.
For example, the Panel may be used to define the of a data table, while multiple Sub-panels are used to define the that make up that table.
- You want to build two different aspects of a file at the same time: the file itself and its smaller entities
- Your parent and child objects need to be defined simultaneously in the same space and workflow.
- You intend to use it by itself without a parent Panel.
- You intend to misuse the arrow button for a different function other than switching back to the parent Panel.
- Your child objects can be defined on the parent Panel or the main content area.
- Your child object is too complex for a panel. Use a Object Page instead.
- You just need a second panel. Use a Panel with a tabbed header.
Anatomy
- Panel header, required
- Content area, required
Header
The Sub-panel's header is characterized by the backward arrow (1A) that allows a seamless transition to the parent Panel. From the parent Panel's header, click on the button in the far right (1B) to return to the Sub-panel.
See for more information on this transition.
Themes & Styles
Sub-panels are represented by a border in a dark shade of blue and a white background. Don't introduce Sub-panels in different colours or themes, even to match color-coded objects. The only currently acceptable colour variation is used to represent Styling mode. See for more information.
Behaviors & Interactions
Panel Access
Sub-panels are not accessed like regular Panels directly from the View menu. Rather, when the parent Panel is on display, the Sub-panel reacts contextually to a user's selection. Simply select an object on the screen to have the Sub-panel slide from the right over the parent Panel. show a parent Panel and its children Sub-panels side-by-side or at the same time.
To hide the Sub-panel, either deselect the object on display, select a new object, or transition manually to the parent Panel (see next section). To hide the Sub-panel from view altogether, use the Show and Hide controls in the View menu of the Application toolbar to hide the parent Panel, effectively hiding both at once.
Panel and Sub-Panel Transition
When a Sub-panel is active, click on the back-facing arrow on the left to transition back to the parent Panel. Similarly, click on the Sub-panel's icon on the right to transition to the Sub-panel. Toggle back and forth between both panels by interacting with these header buttons.
Resizing
A Sub-panel’s size is defined by its parent Panel’s width and cannot be resized individually. So, when either one is resized, both are expanded together. Since the same rules of a Panel apply to the Sub-Panel, never expand them beyond 50% of the browser screen.
All contents of a Sub-panel should be fully visible at its default size. Expansions should never be used to reveal additional or new content that was previously hidden in the panel’s default size. When resizing, ensure all of its contents behave responsively.
To learn more, please refer to section of Panels.
Best Practices
Recognize the forest for the trees
A Panel with a tabbed header (using the icon tab bar) is as a Panel with a Sub-panel. The relationship between a Panel and its Sub-panels is like the one between a whole forest and its individual trees.
A tabbed header, on the other hand, would be more appropriate for showing the different forests belonging to the same region. Learning the difference between these two styles, and when to use one over the other, will ensure the right usage of both.
Panels are not pages
Panels and their children Sub-panels are not pages and should never be used in such a way: they should never occupy the full screen, be overloaded with content to require its own internal navigation scheme, or contain a bevy of complex interactions. The best use for these two panels is to the workflow in the main content area with supporting content or interactions, not for them to have complex workflows of their own.
When Panels and Sub-panels are used for building large objects and their smaller entities, if a single scrollbar proves to be ineffective for browsing their contents, then that is a good sign these panels have exceeded their limits. At that point, consider retiring the panel combo altogether and restructuring the workflow so it transitions in and out of an Object Page instead. Your users will thank you for it!
Specifications