How to group selectors using tabs with vertical display

Center of Excellence · March 25

1088x612_Article_Cover_How-to-Guide (1).png

1. Abstract

When developers encounter the need to segregate sets of selectors on a screen, the utilization of the tab object can be advantageous but presents challenges, particularly when dealing with limited screen space.

This is because tabs are inherently designed for horizontal display by default.

Tabs are originally configured for horizontal presentation, featuring the names of each tab in a horizontal list, with the content of each tab positioned below.

Although the design of the screen with tab objects to hold the selectors is not deemed a best practice - where it is highly recommended to inject the selection through data model security, screen selection or a pre-navigation screen (*) whenever possible - the method subsequently outlined may serve as one viable display option.

(*) The approach typically involves prompting users to make selections before reaching the destination screen where the selections are applied.

2. Context

In some cases, requirements go towards displaying a high amount of selectors (selectors organized by distinct groups).

In this specific case, developers will face three main challenges to resolve:

Avoid taking too much space while designing the tab container (each group of selectors will have an allocated space where selectors will be placed inside)

Display an esthetic view where each selector group’s name will occupy a row in the container (rather than a space in a horizontal list as it is in Board by default)

Collapse only the tab that the user will want to see its selectors, and be able to regroup again to have collapsed groups displayed by default (instead of seeing a particular group’s details by default – 1st tab’s element generally-)

3. Content

Before we start, let’s have a look at an example of a standard tab object used for grouping and showing selectors by groups (a combination of tabs, panels and selectors):

The main idea is to use a parent tab object containing (in each child) as many panels as distinct groups we will have to create. Selectors will be then placed inside panels for each selectors group.

After designing the tab object and making some front-end adjustments (to have groups names in a specific row for example), we will have the following configuration:

(in this case we have subgroups and will use child tabs that will contain the panels and thus selectors objects)

This method, even if it covers, in some cases, the technical and functional requirements, can be limited due to the following limits:

One selector's group details will be displayed by default (1st tab natively)
Need to use “___” symbols or other symbols to have each group in a specific row
Inability to collapse selectors group after interaction with a given selectors group

These challenges will be covered with the following approach.

3.1 Step 1: Creating a pyramidal system

To showcase n groups of selectors, the concept is to create n tiers of tab pairs, with two children in each level.

The structure will follow this logic:

At the 1st level: there are two children one housing a tab object, and the second containing a panel object responsible for holding selectors associated with a particular group

At the 2nd level, there are two children: one with a new tab and the second containing a panel to house selectors belonging to the second group

LVL 2 A and LVL 2 B are both nested within the LVL 1 A tab.

The first-level tab serves as the parent for the tab object and panel object at the second level (LVL 2 A as the tab object and LVL 2 B as the panel).

Conversely, as LVL 1 B functions as a panel in this context, it houses selector objects for our first group of selectors

The identical rationale will be replicated for LVL 2 A and LVL 2 B:

LVL 2 A will encompass two children (first a tab and then a panel);
LVL 2 B will house the selector objects for the second group of selectors;

Expanding this pattern to additional levels:

LVL n A: will consist of two children (a tab and a panel);
LVL n B: will accommodate the selector objects for the nth selectors group.

3.2 Step 2: Front end/naming and icons

Employ a transparent naming convention, and consider the use of icons for tabs at every level for enhanced clarity.

The provided structure utilizes a pyramidal tab structure, with the first child facilitating navigation within the structure, and the second child responsible for presenting a distinct group of selectors.

Upon reaching the lowest level of groups, the structure becomes symmetrical, providing a comprehensive view of the completed group tabs structure:

3.3 Advantages

Having the capability to showcase the desired group and navigate through the structure of selectors groups, both ascending and descending:

Having the option to present only the name of a selector group per row without relying on symbols like "___" to enforce line breaks, given the vertical orientation of tabs as opposed to a horizontal arrangement.

Examples of using symbols to adapt a vertical display of tabs:

3.4 Weaknesses

When navigating into an intermediate selectors group, such as the third group in this instance, the selectors within the tab become visible. Yet, the remaining selectors groups (from the fourth group onwards) remain hidden until we click on the tab, which enables us to ascend in the pyramid - utilizing, for example, the specified icon:

4. Conclusion

As mentioned, the standard approach (use of classical tabs with a system of distinct groups with each tab containing its panel, and thus, selectors) can often the technical/functional needs.

However, for a better user experience and utilization of screen space, adopting a vertical tab arrangement for navigating through different selector groups can prove to be more beneficial.