Since the launch of our new all-web architecture in December 2017, many of you have discovered the rich set of configurable charts, gauges, maps, and other visual elements included with Operations Dashboard for ArcGIS. You have showcased to your audience the status and performance of your personnel, services, assets, performance metrics, and so on. For many of you, your dashboards have been configured to update themselves in real time. And for others, your dashboards represent a more static view of your data. It doesn’t matter to us. It all just works. You have been putting this product through its paces, and we have seen some truly great examples.
While getting to know the product, many of you have commented on how access to dashboards on your smartphones was not working. And it’s true: we disabled it. Dashboards that are designed to look great on a desktop browser or wall-mounted monitor simply do not look good when viewed on a phone’s much smaller display. However, through your feedback, we have realized we are guilty of not allowing you to follow our own advice: a dashboard should be authored to look good for the environment in which it will be used. If a dashboard is authored to look good on a desktop or wall-mounted monitor, it will look good on a desktop or wall-mounted monitor. If a dashboard is authored to look good on a phone, it will look good on a phone. It is with this in mind that we are pleased to announce that starting with the June 2018 update of ArcGIS Online, we will no longer be blocking access to dashboards on mobile phones.
The most important thing to consider when designing a dashboard for mobile use is that it should not try to compete with or replace existing dashboards. Rather, a mobile dashboard should complement other dashboards, and does not need to cover all the bases. Like any other dashboard, the design of a mobile dashboard should start with a thorough understanding of the end user. What is this person’s role in the organization? In what scenario(s) will this mobile dashboard be used? What organizational goals are reached with mobile data access? And so on.
A dashboard displayed on a phone should be kept as simple as possible. Most users will have little or no need for in-depth visualizations, and interaction between elements should be limited. The small screen size of a smartphone simply does not lend itself to in-depth analysis, and don’t forget that the mobile user will probably not be sitting down and will not have the benefit of an input device like a mouse to initiate dashboard interactivity. If a mobile dashboard has too many visuals, chances are it is not focused enough. Consider creating another dashboard. When it comes to mobile dashboards, less is more.
Because mobile dashboards have less real estate than their desktop counterparts, it can be challenging to create an aesthetically pleasing interface and still provide users the ability to get the answers they need at a glance. One way to do this: using color effectively, and contrasting background and foreground colors is one technique that can be effective. With contrasting colors, metrics and outliers will stand out more.
Many mobile dashboards are about conveying performance. To this end, indicators and gauges are often the best visualizations as information can be consumed quickly and action can be taken immediately. When showing charts, limit the use of text and grids, and so on. Limit or avoid visuals that contain too much information to be consumed quickly. This includes details, list, and legend. The following are offered as best practices to consider when authoring your dashboards for phone use.
• Pick a phone orientation (portrait or landscape) and design for that. Dashboard elements are designed to take up 100% of the display and do not re-align themselves with changes in the display’s aspect ratio.
• Take advantage of the fact that many desktop browsers (e.g. Chrome) have built-in tools that enable you to get a close approximation of how your dashboard will look on mobile devices. When assembling your dashboard, periodically turn these tools on to get a sense of how things look, and adjust sizes, text, colors as necessary.
• Take advantage of the fact that dashboard elements can be expanded at runtime to fill the entire display.
• Use a dashboard’s ability to group and stack elements to your advantage, but be conservative. You should not try to re-create a desktop dashboard for your phone by over-using these abilities. When used, stacks (tabs) should be renamed to reflect their content.
• When adding elements to the dashboard, do not add any unnecessary text such as titles and descriptions.
• Don’t add a header to your dashboard unless it really needs one.
• Limit the amount of text you place in each element’s title and description (or omit text in these areas altogether).
• For all elements, turn off the “last update text” option.
• For pie chart and serial chart, turn off the “hover text” option.
Maps and legends:
• Maps should be as simple as possible. Limiting it to one operational layer whose symbology contrasts with the background basemap is ideal. This will make the map easier to interpret, faster to draw, and reduces the amount of data being downloaded to your device over what might be a slow network connection.
• Disable popups on the operational layer(s). Tapping on a single feature on a phone is difficult, and there really isn’t enough real estate on the phone to show an info window on top of the map like there is on your desktop.
• Consider whether a refresh interval is necessary. Many mobile dashboards will be opened and then immediately closed once the information it displays has been consumed.
• When adding a map to a mobile dashboard, avoid enabling map tools such as search, layer visibility, legend, basemap switcher, etc. They are rarely needed in mobile situations.
• Because the map used on a mobile dashboard should be simple to understand, adding a map legend element is typically unnecessary.
• Dashboard actions should be kept to a minimum.
• Use selectors sparingly. When used, consider placing them on a left panel configured to slide over the dashboard rather than on a dashboard header.
The following is an example open shelters dashboard you might see in a typical emergency operations center. Through it, the command center support staff can acquire, analyze and act on information as it shows up on the dashboard. The dashboard is flexible, and can display data in rapidly changing conditions. To improve situational awareness, the map shows many operational layers. The open shelters are shown on a list, and key metrics for the number of open shelters, shelter population and shelter capacity are included. To save screen real-estate, the key metrics have been stacked, and additional metrics are shown along the bottom using serial charts. Because this dashboard is intended to be shown on a wall-mounted monitor, large texts sizes are used, and contrasting colors improve legibility in artificially lit rooms.
To take this dashboard into the field for smartphone use (by an area commander, for example), it needs to be simplified and some design choices should be changed. The following is one interpretation of how this might be accomplished.
The above is a single dashboard organized into two named tabs: Metrics and Shelters. On each tab, the elements have been grouped. Not all the elements in the original dashboard were included in the mobile dashboard. Text sizes have been reduced to look better on a phone. The color scheme of the elements and the basemap have been changed slightly so that the colors contrast even more (just in case the dashboard is used in daylight conditions). The number of operational layers of the web map has been reduced to one, pop-ups have been disabled, map tools have been not enabled on the map element, and the list has been configured to show essential information only.
As you can see, by simply making some straightforward design choices, creating dashboards that look great on your phone is possible. With that said, we want you to know that there are some things we know we need to work on. This includes element responsiveness, ‘fat finger’ usability, providing better design time tools, and so on. You can think of our unblocking phone access for the June 2018 release as only our first step. You can expect incremental improvements in future releases from here on out.
Contributors: Patrick Brennan and Derek Law