Tips and techniques for dashboard development on mobile devices

Introduction

What do we take with us every day that keeps us up to date with on the latest events or information? It’s our smartphone. We can also use this little helper for business analytics, too. Tableau has developed an app specifically for the use of mobile dashboards, as well as new features for creating layouts for individual mobile devices. Developing mobile dashboards requires rethinking the structure, content and design. This post takes a look at the basic development differences from traditional dashboards and provides useful tips and tricks.

Differences between requirements analysis and dashboard development

First, we need to get away from the idea of showing as much data as possible in a dashboard. Dashboards on the smartphone are not suitable for this purpose and fail to live up to their benefits. Therefore, we need to take a higher level of view and consider it in the requirements analysis. Below we discuss a list of typical questions of the requirements analysis.

Device-specific questions:

• Which mobile devices will be used?
• How big will these devices be?
• Are there specific devices/brands that are used in the organisation?
• How will the devices be used? Are tablets used?

On one hand, these questions are identifying the maximum display size of the respective layouts. When defining the display size, Tableau automatically sets the appropriate frame dimensions. For example, if this size is exceeded when using a larger tablet, Tableau will automatically display the next largest dashboard. Knowing what devices are being used, you can set the appropriate sizes in advance and Tableau will not show the next largest layout.

On the other hand, the decision of how the devices will be used plays an important role in dashboard design. For example, if a dashboard is designed for portrait use, the visualizations might be distorted when the device is rotated. Functionally, there are no limitations here, but the view will no longer look appropriate. It is recommended to provide multiple layouts with defined sizes. Tableau will automatically switch to the appropriate layout when the device is rotated.

Content specific questions:

• What metrics do you check on a daily basis?
• What information do you check on the way to a meeting?
• What information is mandatory in order to be able to use the mobile version appropriately?
• Should there also be a detailed view for further analysis?

The user only wants to consume the information on a mobile dashboard at a very high level. Accordingly, the views must present the key figures or their results directly and meaningfully. The user does not want to explore the data, but rather get the information quickly and directly. Therefore, it is also important to know exactly what the user wants to consume.

The classic way is to start with a desktop version. This version contains additional information, such as longer texts and visualisations with a high level of granularity. This version is then reduced to a mobile version.

The second way is the opposite. We start with the development of the mobile dashboard. Then we enrich the mobile dashboard with further information to create a desktop version.

Rethinking? Do it!

When a user holds a smartphone or tablet in his/her hands, what do they do most? Do they scroll or swipe, tap or talk? It is important to consider these aspects when developing mobile dashboards. For example, input is done with the finger. There is no separate button or mouse. This should be considered for interactive dashboards. Here is a small example:

A dashboard uses a visualisation to filter the regions “Central”, “West”, “South” and “East”.

The user has different options for selecting multiple entries. They can use the lasso functionality or hold down the CRTL-Button in combination with their mouse. In every case, the user has another tool which helps to select more than one entry. This is not the case with a smartphone or tablet. The user does not have the option of holding a separate button or using the lasso function. Therefore, we need to take this into account when developing mobile dashboards. For filtering, we recommend the use of Tableaus’ conventional filters. These are optimised for use on mobile devices.

The most underestimated thing in mobile dashboard development is the space for scrolling. In order to be able to scroll with the finger, the user needs a free area to tap on. Some visualizations offer this space, but often unwanted selections are made. In doing so, the user can open a tool tip or possibly trigger a filter action. This disturbs the user experience. A simple solution is to offer enough free space between the visualizations.

On a smartphone or tablet, the user cannot see if the dashboard contains additional content. This happens because there is no scroll bar on the side. To let the user know that there is more content, you can overlap the following headline or visualization. Tooltips can be used to easily integrate further information about the respective visualization. However, the use of tool tips should be well-considered, as they often cover the content in mobile dashboards. This is especially disadvantageous for a smartphone version. An alternative is to jump to a second dashboard that is filtered and opened when the respective element is selected.

If performance is already poor during development, it will not improve in the app. You should avoid complex queries, embedded visualisations in tooltips and too many filter or set actions. The same applies to table calculations, as these are calculated at runtime. However, this depends on the amount of data and the visualisation. For example, if you only show the top 5 and their ranks in the visualisation, the load time is very manageable. However, if you display a top 100 with ranks, this can lead to longer loading times. Additionally, the execution of filter, parameter and set actions take longer to perform and you have to expect longer load times.

Tips und Tricks

• The most important things should be placed at the top, other details should be positioned further down.
• Make the dashboard scrollable, this creates more space and scrolling is normal on a smartphone.
• Elements should be easy to select. Avoid small elements. Also pay attention to the number of different categories and the size of each element. Pie charts are great, but they have the disadvantage of making smaller items difficult to select with your finger.
• Avoid a high level of detail in visualizations. Tables and scatterplots are unsuitable for mobile dashboards.
• Pay attention to the selectability of filters. This is not a problem in Tableau as long as the mobile app is used. The view of the filters is optimized and they are displayed at a larger size.
• Avoid complex visualizations. They cannot be properly interpreted due to the small space. This belongs in the desktop version.
• A font size of at least 12 pt is recommended. Of course, is is the possible to zoom, but it is better for the user to be able to read everything directly.
• The use of tabs should be avoided, as they break up the view on tablet and smartphone versions. If you need to switch between multiple dashboards, use the navigation buttons.

Test, test and test again

Testing the dashboards on the appropriate devices is an important point that should not be underestimated. You cannot assume that the version developed in Tableau Desktop will actually be shown in the same way on the devices. For example, unanchored elements are shifted and distorted, or personalized backgrounds do not fill the entire view. Experience shows that during development the mobile dashboard will be published many times more than the dashboard for the desktop version. Often, minor changes to the design or layout are changed and published again. This increases the testing effort during development. In addition to the appearance, the usability and performance of the dashboard should also be tested. The final test should be performed by a person who was not involved in the development. This person can pay attention to other aspects that were ignored during development.