The Use of Tab Container
1. Abstract
As soon as developers face screen creation, in particular, if we are talking about reports or BI Dashboards, where usually a lot of different data has to be shown, they need to use carefully the layouts to avoid any screen object overflow and, consequently, less impactful data meaning.
2. Context
In the Dashboard or Report’s screen creation, the balance between data shown and performance should be our key focus here since, even if it's true that showing more information on the screen can be useful (sometimes can be also misleading), leveraging the Tab Container, is the most efficient option to have more information in the screen, quick accessible (just one click), segregated by topic and, never the less, the performance in the latest Board versions, is better than having multiple layouts.
3. Content
The Tab Container creates folders that can contain other Objects, including other containers (eg: Panel, Transition Container, Matrix Container). It shows one Object at a time with the option of selectively moving through tabs.
Developers need to be aware that the screen rendering in each and every application counts the number of screen objects and, in the layout case, also the rendering query complexity, so easily, more objects and more complex layout queries, more time will be required to render and make available the full screen.
As you can quickly understand, having a lean screen, and combining the perimeter filtering objects has an impact on the performance side. But also, if you ever faced a Dashboard creation (whereby the definition of a lot of different data has to be shown) this linear dogma, can be difficult to respect.
It is interesting to better understand how these objects and layout query creation interact with the database, in particular:
Before completing the screen rendering and allowing the users to fully interact with the data (drill down, selection, trigger a procedure and so on), Board 12 engine collects all the different queries coming from the different selections and data views and then will render each of them, and just when all of them will be completed, the screen will become available for the final user.
So clearly, the more data views a screen has, the more complex they are, and the more time is required to fully render the requested data. Now, leaving aside the fact that having a lot of crowded information on the same screen can be misleading and less impactful, a solution for this type of crowded screen can be the new Tab Container Object.
From the Board Spring ’22, with the Tab Container Object, the developer can include in the same screen much more different data views, having the same performance as one single data view, thanks to the Asynchronous Layout execution on folders feature that is changing the approach on the screen creation.
Figure 1
Let’s see how this Asynchronous Layout execution works:
With this feature active, the engine executes the Layout of each Screen Object added to its folders only when said Object is visualized by the user.
Practically with four dataviews:
Figure 2
Number of actions, 4 (see capsule log):
Figure 3
Now let’s look at the same fours dataviews in the Tab Container:
Figure 4
Number of actions, 1 (see capsule log):
Figure 5
As you can clearly see, the action is 1 as opposed to 4 so, even if the 4 actions are taking less than a second each, performing just 1 action is, at any time, faster.
So, leveraging the Tab Container Object power can help to reduce the rendering time and clean crowded screen improving the data impact and look and feel (that in a Dashboard situation is a valuable KPI).
Asynchronous layout execution is a clear advantage in case the first tab is the most frequently reviewed because it avoids execution of rarely used secondary tabs. In case of all tabs are equally frequently reviewed these options will impact the navigation from one tab to another one since the execution of secondary tabs has not to be done while landing on the screen.