7 Rookie Mistakes to Avoid When Building HTML5 Dashboards

Gone are the days when information dashboards were restricted to desktops in corporate environments. Today, they need to function just as good on a smartphone or tablet as they would on a PC. HTML5 has emerged as the prefered way to build dashboards within mobile apps, and mobile websites. However, web developers, designers, and product managers are still grappling with this shift in paradigm.

This post discusses 7 common pitfalls when building HTML5 dashboards, and what you can do about them. Avoiding these mistakes can save you a ton of time and redundant work.

Not showing the important information first

In many cases, developers strive to port a dashboard that’s built for desktop browsers to a mobile device as is, and end up with inefficient and cluttered dashboards. Here’s an example of one such dashboard:

With the small screen size of mobile devices, the first step to building a dashboard is to decide what its core purpose is. Once this is done, the dashboard should be stripped down to meet just that purpose. Next, add the features, and functionality that contribute to the purpose of the dashboard directly or indirectly, being careful not to add any dead weight. Every design decision should start with the purpose of the dashboard, and let that dictate what information should be included in the dashboard. This approach has ripple effects on every aspect of the dashboard, and will make a big difference in how it eventually turns out.

Not prioritizing multiple dashboards

Most applications have multiple dashboards. Showing the important information first allows you to design the perfect ‘Overview’ dashboard. However, most ‘Overview’ dashboards link to deeper, more granular dashboards within the app. Developers who don’t question the purpose of every dashboard in their app end up overloading their ‘Overview’ dashboard, and duplicating information across the other dashboards.

When working with multiple dashboards, ensure all the dashboards are linked in the right way. Here’s an example of good prioritization:

A user may take many paths from the ‘Overview’ dashboard, but they should easily find their way back to the main dashboard when needed. This brings us to the next point – Navigation.

Navigation menu getting in the way of er.. navigating

From the ‘Overview’ dashboard, if a viewer wants to drill down into a particular piece of information, they’d immediately look for the navigation controls. On a PC this would involve clicking on a chart, or filtering the data using a filter wizard. On a mobile device, with the absence of a cursor, the user would rely on touch input instead of a click, and the filtering options may be hidden by default. In this case, it’s important to make the viewer of a mobile dashboard aware of which sections of a dashboard can be touched to drill down, and where the filtering options for a dashboard are located.

For real-time dashboards, it’s good practice to position the navigation menu below the information, so the focus is on the time-sensitive data. For viewers who want to drill down to a particular deeper dashboard right away, the navigation could be placed at the top of the ‘Overview’ dashboard.

If you’re building an enterprise application with tens or hundreds of dashboards that can be drilled down to, you may want to include a search box that pulls up dashboards by their title, or caption. A search box is an effective way of getting users to where they need to go without having to wade through fifteen levels of navigation just to get there.

Unlabeled navigation buttons

Once you’ve found the right position for the navigation, you still need to decide on the right labeling of icons and options in the navigation menu. If the icons in the navigation are not labeled it can be confusing for the user to guess what function each icon performs. Unlabeled icons can be misleading, so opt for well-labelled text links. Here’s an example of a confusing navigation menu:

Unoptimized assets – CSS, images, and vector graphics

In most cases mobile devices are slower at loading pages than desktop computers, and this could frustrate users. That’s why you need to optimize your dashboards for high speed content loading. It’s best to remove all images from mobile dashboards. But if you have to use, let’s say, a company logo, then make sure it’s compressed. Similarly CSS, and vector graphics can be compressed to speed up load times on mobile. The ideas is to focus on simplicity and functionality, instead of mere good looks.

Inefficient transfer of data from a backend server

Despite the advances in client-side technology, dashboards still need to rely on backend servers for data-intensive tasks. If you have a backend server, design the system to have burst transfer of data rather than periodic ones. Periodic transfers (such as polling, user behavior etc.) are extremely resource inefficient even though they generate very little traffic.

Data caching can also be used to reduce frequent communication with a server. Both local cache and server cache can be used to decrease the amount of data transferred via the network. This helps provide a quicker, smoother experience, and is easy on mobile data and battery limitations.

Using the same visual elements across all devices

A desktop browser can easily fit three charts, a gauge, and a couple of KPI metric, all in a single dashboard. However, mobile screens can’t include this many visual elements because of their smaller screen size. Using the same charts, gauges, and KPIs across devices will result in crowded interfaces that are cluttered, and hard to navigate through.

One solution is to use KPIs (numbers) instead of charts and gauges wherever possible. Text is lighter than the vector graphics a chart, or gauge would need, and is easy to accommodate within any screen space. However, a text-only dashboard may sound boring to some. In that case, another option is to use smaller chart types like sparkline charts, and bullet charts instead of full blown line charts, or bar charts. These charts have a high data-ink ratio, and are ideal for mobile interfaces. Here’s an example of a mobile dashboard that uses sparkline charts well:

These tips will add much needed simplicity to your HTML5 dashboards, and enable you to craft exquisite experiences with data. Users will appreciate how you leverage all the capability of mobile devices, and your dashboards will now look droolworthy.

Twain is a marketing specialist for RazorFlow, a JavaScript dashboard framework that lets developers build effective, cross-device dashboards quickly. Download a trial of RazorFlow, and get your first dashboard up and running in less than an hour.

LEAVE A REPLY

Please enter your comment!
Please enter your name here