Posted On: 2020-08-10
Today's post is part 1 in a series about how to add tabs to an in-game UI in Unity. Tabs (like most common UI constructs) are not provided built-in by Unity, and thus developers have to either make their own or find a third-party implementation. Fortunately, tabs are relatively simple both conceptually and in implementation, which makes them excellent candidates for tutorials (like this one.)
Part 1 will primarily focus on high-level concepts behind tabs: what are they, how are they organized, and why you would want them. Later entries will dive into the implementation details, starting with a simple approach and then providing examples of some additional polish and features that can be added on top.
A tab is a control for organizing different segments of mutually-exclusive content, such that each piece of content will appear in the same screen space location. It is a convenient and (nearly) ubiquitous interface design element, used extensively in both software and website design*. It is so ubiquitous, in fact, that the software I am using to write this very post makes use of tabs, to allow me to switch between different posts easily. Not only that, I used tabs to organize the content on my various bi-weekly prototypes - keeping the game itself on one tab, and my various design notes and reflections separate. Even the Wikipedia article about tabs uses tabs.
From a structural standpoint, a tab control is made up of two parts: a tab strip and the tab content area. The tab strip is a series of selectable UI elements ("tabs"), typically laid out either horizontally or vertically*. The tab content area is a section of screen space where the content associated with that particular tab is displayed, when that tab is selected.
In order to explain why to use tabs, it is beneficial to instead explore situations in which tabs would not be appropriate. This is, in large part, because tabs are so versatile that trying to explore even a subset of useful situations would leave the territory grievously under-explored. Thus, instead, focusing on those few places where tabs are not appropriate will both serve to highlight just how many situations they can be reasonably used in, as well as some key features that factor into deciding when to use them.
The primary situation in which to not use tabs is when multiple content entries needs to be accessed simultaneously. Since displaying content from one tab hides any others, the user becomes responsible for remembering any required information on other tabs. In such situations, one either needs to rearrange the tab content to eliminate the need to cross between tabs, or choose a different representational structure that better fits users' needs (such as displaying content in separate windows that do not overlap).
A second situation that does not benefit from tabs is when a user's ability to input their intent is diminished. When designing realtime games this is a fairly common situation, as realtime controls often require many (or all) of the game's inputs be focused on the action. This, in turn, diminishes the user's ability to interact with the UI - including changing tabs.
As a hypothetical example, imagine a combat game with multiple weapons, each using its own ammo supply. In a turn-based game, putting each weapon's information (including current ammo) on a separate tab could work out fine. In an action game, however, doing so would be to the player's detriment, as changing tabs would mean that the player must stop aiming* any time they wish to check the available ammo for their weapons.
The third (and final) situation in which tabs are not a good choice is when there is a significant difference in the amount of content associated with each tab. Since all tabs (generally) display their content in the same space in the UI, substantially different content can have significantly different user experiences. These differences can become distracting/unpleasant for users if they are too extreme.
Consider, for example, two tabs, one that contains a paragraph and one that contains a single word. The difference in content length will likely be distracting for users - either the single word will look awkward surrounded by blank, unused space, or the paragraph will be squished down to the point where it is difficult to read*. When content is predefined, this can often be resolved simply by rearranging the content to better accommodate known lengths. When dealing with dynamic or user-generated content, however, one's ability to adjust to this is often limited.
From looking at those three places where tabs don't make sense, one can extrapolate a set of simple criteria for where they do. Firstly, the tab content needs to be mutually exclusive: users should be able to accomplish their goal on a single tab without needing to change to a different one. Secondly, users should be free to interact with the tabs, without jeopardizing their goals. Thirdly, the tabs' contents should have some aesthetic similarities, including margins and spacing. If the content area of tabs changes too radically, it may distract users from achieving their goals.
Hopefully all this talk about tabs has whetted your appetite for coding one in Unity - because, in part 2, that's exactly what will happen. I hope to see you then!