Dashboards that display well on desktop computers don’t always scale well to mobile devices. To provide users with the best experience when viewing dashboards on mobile devices, you need to build dashboards designed specifically for that purpose.
It's a completely different way of building dashboards, so this topic aims to help you develop some skills in designing and building dashboards for display on mobile devices. We'll look at:
- how standard dashboards display on different devices and the issues around different device types and browsers
- the functionality that may prove problematic on a mobile device
- the importance of testing dashboards and the role of device emulators in that testing
- dashboard performance issues
- how automatic resizing of dashboard elements works
- some examples of well-designed dashboards intended for use on mobile phones
There's also an overview of the issues to consider when creating mobile dashboards:
- the Touch-Friendly Spacing setting
- how data and users interact on mobile dashboards
- the format of elements on a dashboard
- where to place elements on a dashboard
- how grids are sized
- how to optimize the display of charts
We’ve taken a standard dashboard, Global Analytics, and displayed it on different kinds of devices to show you what a user would experience. The dashboard isn’t amended in any way — we haven’t even applied the Touch-Friendly Spacing setting.
This is probably a good exercise to go through with your own dashboards, prior to embarking on any re-design work, to establish what changes need to be made to arrive at the best design.
This dashboard is expanded to occupy the entire screen on a desktop computer:
This is the default view of the same dashboard in portrait mode on a tablet:
This is the default view of the same dashboard in landscape mode on a tablet:
This is the dashboard on a mobile phone, in portrait mode:
This is the dashboard on a mobile phone, in landscape mode:
The display is different on each device, and can vary even further on different brands or models of the same device type. For example, a dashboard may not display in the same way on an iPhone and an Android phone; or in different browsers, such as Safari and Chrome.
Some functionality may not work on some devices. And you may find that it works on, say, Apple devices and not on Android. Until a fully mobile version of Anaplan is available, it’s necessary to carefully test both look and functionality of the dashboards you build.
Some of the functionality that may prove problematic on mobile devices includes:
- publishing to a new dashboard,
- publishing a line item to a dashboard,
- opening subsidiary views,
- editing cells — it’s not easy or, perhaps, impossible, and
- re-docking floating tabs.
For these reasons, we do not recommend providing complex dashboards, for purposes such as planning, to users on mobile devices — particularly phones.
Strategic or executive dashboards that provide overviews of or snapshots of data are more appropriate dashboards for displaying on smaller mobile devices.
We do not advise data entry on mobile devices unless you have fully tested the device and dashboard combination, and are confident that your design works.
These guidelines for building mobile dashboards were developed and tested using:
- tablet devices — approximately 128 x 764 pixels;
- small tablet devices — approximately 1024x768 pixels; and
- large mobile phones — approximately 414 x 736 pixels.
https://community.anaplan.com/anapedia/administration/system-requirements/mobile-support lists the details of the device types supported by Anaplan.
There are many factors to consider when building dashboards for mobile devices. If you’re new to developing these dashboards, or updating your existing knowledge, research on the Internet will reveal the most current trends.
Inbuilt device emulation tools are available with many web browsers and make the development process much quicker as you instantly see the results of change.
- Safari: https://support.apple.com/kb/PH21414?viewlocale=en_LA&locale=en_LA
- Internet Explorer: https://msdn.microsoft.com/en-us/library/dn255001(v=vs.85).aspx
- Chrome: https://developers.google.com/web/tools/chrome-devtools/iterate/device-mode/?hl=en
- Firefox: https://developer.mozilla.org/en-US/docs/Tools/Responsive_Design_Mode
However, once your design is stable, make sure you test it on a physical device. Although emulation tools can show you what a dashboard will look like, you need to engage with the dashboard on a device to fully understand the user experience.
Watch for performance issues: the more complex the dashboard, the more time it will require to load and refresh.
If your audiences use a range of browsers and devices, remember to test your dashboards in each of them: you may find slight differences in performance between them.
When you are designing your dashboards for mobile, consider the Touch-Friendly Spacing setting and how it impacts on the dashboards in a model. You can turn it on or off in Model Settings > Dashboards > Default.
Ask your users:
- what kinds of devices they use;
- whether they use touch screen; and
- whether they use a stylus.
The answers to these questions will help you to decide whether to turn Touch-Friendly Spacing on.
Disabling Touch-Friendly Spacing decreases the amount of white space between dashboard elements by 24 pixels: your users can then see more of the elements on the dashboard. However, it does leave less space for users to navigate around the screen. It’s a trade-off — test the user experience both with and without Touch-Friendly Spacing.
|Without Touch-Friendly Spacing, on a mobile phone.||With Touch-Friendly Spacing, on a mobile phone.|
|Without Touch-Friendly Spacing, on a tablet.||With Touch-Friendly Spacing, on a tablet.|
Now that we've highlighted all the things to consider when developing mobile dashboards — performance, testing, emulation, and so on — we can look more closely at how to design dashboards for mobile devices.
Keep the design as minimal and simple as possible and avoid clutter so that users can see the dashboard elements clearly.
Designing mobile dashboards requires you to think in terms of a display mechanism rather than a traditional dashboard layout. Allow the device to display the elements accordingly. Your mobile dashboard may look untidy in Dashboard Designer but when displayed on a mobile device it will look quite different.
Think carefully about the types of users who want to view dashboards on mobile devices and identify the kinds of information they want to see. Accept that the format does provide some limitations, especially in the level of detail it’s physically possible to see. Design your mobile dashboards with this in mind.
Designing a user experience always requires you to consider the process flow for user activity. Alongside this, designing for mobile requires you to consider the size of the screen you are working with and the shape of the elements you want to display.
Before you begin:
- decide which device you are going to design the dashboard for; and
- establish the screen resolution for that device, in pixels.
This information can be used to give a finer degree of control when sizing dashboard elements.
There are a few simple things you can do to make your dashboards easier to read on smaller screens.
- You may have more success displaying complex information in landscape format on a small device screen rather than portrait.
- Some charts may need to be extended vertically to adjust the scale on the axis to display meaningful values.
- Test using percentage height and width values first — they’re more flexible over a range of different device types.
- Pixel size is static but, in some circumstances, it's the only format in which a dashboard element will display consistently. Remember, we suggested that you establish the pixel size of the screen, before you start designing? This is where that knowledge comes in useful. You can use it when calculating the size of dashboard elements.
- If the image exceeds the screen size, elements sized using percentage values will have scroll bars. Elements that are sized using pixel values will not.
- It’s not possible to resize published line items. Test these elements carefully as you may find that when you try to make a selection — such as currency type — the dropdown arrow is beyond the edge of the screen.
- Place elements to the left of the dashboard, so that users don’t have to scroll right to see additional elements.
- Be sure to leave space at the right of the screen for the user to touch the screen to scroll — it can be very frustrating if you’re constantly opening items you don’t want to.
- Develop simple dashboards with drill-down capability. This will ensure that your users can see the detail you want them to.
- If you have synchronization applied to dashboard elements, consider using a list rather than page selectors for making choices. They're a little easier to tap and faster to respond — but, of course, the list needs to be fairly short, or it will fill the screen.
- Think about using small heading sizes in text boxes to reduce the amount of space they occupy on the screen. Heading 3 (H3) applies a rule under the text, which helps H3 to stand out whilst occupying the least amount of space on the screen.
- If you use them, order buttons in twos, side-by-side. If there are more than two buttons, arrange them in a grid pattern — two-wide — to the left of the dashboard.
- Wrap column headers to prevent grids affecting the display of other elements.
As a default, elements will always use whichever value will display the largest image on screen. For example, you might find, as you’re entering pixel values, that the element doesn’t seem to be resizing. That’s most likely because the number of pixels you’re entering represents a value that is smaller than that displayed for percentage size. If you make the percentage a very small number, say 2, the element will resize to the pixel value you enter.
Consequently, when you’re resizing elements, make sure that the measurement you are using (pixels or percentage) is much greater than the measurement you’re not using.For grids, the value -1, in the Minimum pixel field for Height and Width ensures that the grid resizes automatically. For charts, the -1 value should be in the Maximum fields for Height and Width. Never amend these values to zero. Doing this may cause dashboard elements to float over each other and you won’t be able to reorganize the dashboard!
https://community.anaplan.com/t5/Dashboards-Visualization/Height-and-Width/ta-p/11915 provides detailed information about sizing grids and charts on dashboards.
Grids are the easiest elements to display on a device screen as they automatically expand to show all rows or columns wherever there is enough room to do so. Where it’s not possible, scroll bars display to assist navigation around the grid. You may need to prepare large grids for display on mobile screens — use filtering and the hide and show functions to display only those values the audience is interested in.
There are a number of issues to consider when styling charts for mobile devices. Different chart types behave in different ways on smaller screens. These guidelines point out some of the issues you need to consider.
- Publish the element to the dashboard twice–configure one with percentage values and one with pixel values to see which one displays best. Delete the less successful element.
- It may be that making the element narrower will alter the increments displayed for the y-axis and make the chart easier to read. Resizing an element often affects the scale on its axes. A line chart, that is 100% high, may display the scale in increments of 25k. However, if the height is reduced to 50%, the increments will display in 100k increments. This could make it very difficult to compare values.
- Remember: if you make the height of an element 100%, it doesn’t mean the width must be 100% as well—play around with the proportions to create a chart that displays the way you want it to. You may find that a height of 150% and a width of 60% ensures that all labels can be read and that the scale is at the required level of detail. However, you must ensure that changing the proportions doesn’t distort the element to the extent that the data could be interpreted as misleading. It may be that a different chart type would be more successful for displaying this data set.
- Some chart types—pie and map, for example—display better in a square format, rather than oblong. If you make a Pie chart 100% wide, you may see an excess of white space on either side of it. You will need to experiment with size to ensure that labels aren’t truncated.
- Pie charts can look excessively large on mobile screens, particularly if one segment of the pie is considerably larger than the others—a large block of solid color. Making the pie chart smaller, whilst ensuring that the labels are legible, will improve the appearance.
- Despite the level of detail included, map charts can still be informative when displayed on a smaller screen. Users may need to expand portions of the map to be able to select an area and display pop-up information.
These dashboards show how simple task-oriented design produces easily-understood dashboards on very small screens.
|This dashboard displays sales bonus performance figures.||Using a similar format, but including page selectors, this dashboard displays sales bonus data for an individual.|
|This dashboard displays performance ranking. It also includes a message field to deliver information to users.||This dashboard displays benchmark information and makes use of conditional formatting.|
|This dashboard shows how informative maps can be, even on a small screen, and how supporting data can be displayed.|