Sample dashboard: Monitor server processes

Here's one way to highlight delayed and failed processes on a given day

1 2 Page 2
Page 2 of 2

Why This Works: Labels on the Gantt bar

Mark could have put the header labeling each task at the lefthand edge of the chart, in a header area. Instead, he chose to label the Gantt bar itself. On first glance, this makes the view look busy: there’s an awful lot of text butting up against the bar. When you look at Figure 18.3, though, you can see why he did it. When he sees a red, failing task, its name is right there, where his eyes are. He doesn’t need to do a careful lookup to the left to find the name of the task.

Reference Lines

In addition to finding the failing processes quickly, Mark needs an indication of which other processes might be contributing to the failures. In this case, he uses reference lines to show schedules and durations.

In the example in Figure 18.4, Mark can see that the Epic Radiant Orders task failed (it’s red). The dotted vertical lines for each task show him when each task was due to start. We can see in this case that Epic Radiant Orders was significantly delayed. It should start around 10:30 a.m. but didn’t start until around 5 p.m.

The solid vertical lines show the average duration of each task. In this case, Mark can see that the previous task, Epic ASAPEvents, also finished later than normal. Did one delay cause the other? Mark knows he’ll have to investigate both of these.

URL Actions

The tool tip contains a URL (see Figure 18.1 on the previous page). Mark can find which details need further investigation and, with a single click, can go straight to the relevant information. This speed and directness is important to any dashboard as it puts users in the flow. Mark doesn’t have to waste time finding the relevant next dashboard; the URL takes him there directly.

c18f003 The Big Book of Dashboards

Figure 18.3: The topview shows how Mark designed the dashboard: with labels next to the Gantt bars. The lower view shows the labels on the left. 

c18f004 The Big Book of Dashboards

Figure 18.4: Each scheduled task is shown by a Gantt bar. The dotted lines indicate scheduled start time and the solid lines indicate average task duration. 

Overview, Zoom and Filter, Details on Demand

As we know, one aspect of successful dashboards is to create an exploratory path through the data. Ben Shneiderman, Distinguished Professor in the Department of Computer Science at the University of Maryland and a pioneer of information visualization study, described his mantra of data visualization:

  • Overview
  • Zoom and filter
  • Details on demand
c18f005 The Big Book of Dashboards

Figure 18.5: A dashboard with a great top-down flow. 

The dashboard in Figure 18.5 demonstrates this flow. Starting at the top, Mark has an overview of the server performance for recent days (1). Clicking on a day allows him to filter down to a single day view(2). He can then get details on demand by clicking on a task (3), to open the details on task summary view (4), or use the URL to go directly to the task on the server itself (5). The flow is top down and easy to follow.

Author Commentary

ANDY: This is a simple dashboard. I think that works in its favor. Mark designed it to answer the three most important questions he has each day:

1.       How many tasks failed?

2.       Which ones were they?

3.       Are the failures a trend or a one-off?

Bar chart. Gantt chart. Gantt chart. That’s all it took and the dashboard needed no other adornment

In anticipation that followup questions will arise, the URL link lets Mark get to the next set of questions he might need to ask. The strategy of linking dashboards together allows you to keep each one from becoming cluttered. Attempting to answer too many questions in one dashboard reduces clarity.

There are several issues with text overlapping the vertical reference lines in the Gantt bar. That might have earned a few “uglycats” but this dashboard got an exemption for an important reason: It is for his eyes only. Because the destined audience is himself, he has built something that works for him.

When designing a dashboard, how much spit and polish should you put on it? If it’s just for you, then, really, what you put on your dashboard is between you and the computer screen. If it works for you, that’s fine. However, if it’s for consumption by an entire organization, you have to make the experience as smooth as possible. If Mark’s dashboard was to be used by the entire organization, we might suggest workarounds to avoid the overlapping text.

The above dashboard was built for personal consumption. Dashboards built for a broader audience will put more time and consideration into typography, layout, color, etc.

Copyright © 2017 IDG Communications, Inc.

1 2 Page 2
Page 2 of 2
9 steps to lock down corporate browsers
  
Shop Tech Products at Amazon