Building a Better Bar Graph: What an Analog can tell you with just a glance

By Nicholas Imfeld on February 15, 2012

In my first post in this series, I briefly discussed my experience of reading the book The High Performance HMI Handbook, the initial skepticism I felt and how I started to come around to their ideas. In this and subsequent posts, I’ll be sharing a few of the concepts the authors discuss. These are concepts that seem so simple but they aren’t often used. And yet, if they were implemented in our HMIs it would go a long way toward improving the usefulness of our HMIs for us and our operators.

            The concept that I want to talk about in this post is the presentation of Analog values. How do you usually see an analog data point presented on a screen? I can think of two ways:

1.   As a value on a screen based on a P&ID:

So what does this tell us? This one tells us the discharge pressure for this pump. Doesn’t look like the pump is running. Pretty straight forward. But that is all it says.

2.   As a simple bar graph:

This one almost always turns up to indicate tank level. In this case, our tank appears to be a little bit over 50% full.

We are all familiar with these two approaches. We know how to read them. We know what they tell us. But can we do something a little bit differently to make these data point more useful?

            The High Performance HMI Handbook says “Yes!” And I agree. They proved this to me in a way that I found very clever. So I will unapologetically duplicate their example here (see page 54-55 for the original).

First, they presented a chart for a blood test for Fluffy the cat (next to a photo of a rather vicious looking feline, you’ll have to use your imagination): 

But what of our operators, who might not have all process knowledge for the system stored in their heads? They might need a bit more information to make heads or tails of the data we give them. So in the book, they added a range column to the table: So what does this table tell us? And how long does it take to get what it tells? If we’re honest, it takes us a long time to discover that we can learn nothing from this table. This is an extreme example, because we are process people and know nothing about the health and wellness of house pets. If this were a table of process values (or perhaps data points on a screen like our discharge pressure above) we could probably interpret it with a few minutes to think about it and we’d know exactly what our system is doing.

So we introduce the bar graph. But not just the bar graph shown above, but a bar graph that is designed to communicate as much information as possible in as short of an amount of time possible. Like this: Again, what does this table tell us? And how long does it take to get there? With a little bit of time to analyze it, the process folks and even our operators can tell that everything is right where it needs to be with our cat, except for the PLT (hope it isn’t serious). So do we append a range to all of our date points? That doesn’t really gain us much if our HMI has lots of screens and lots of data points all over the place. Our operators are going to have to spend a significant amount of time navigating and interpreting to make sure that everything is in order.

Imagine if all of your HMI screens had bar graphs like this. An operator could quickly glance at a screen and immediately know that the system is doing exactly what it should be doing, or quickly identify a trouble spot. Since the job of most operators I’ve encountered is to make product and not decipher HMI screens, a simple design change like this could make it so operators spend less time looking at screens and more time doing their primary tasks. And isn’t that the whole point? The bar graphs give us the same information as the second table. But we can glean that information with just a glance. In fact, the results and range columns become unnecessary when we’re trying to quickly determine how the system is behaving. So instead of cluttering our screen, we can potentially leave some of that information on the analog value’s pop-up screen, where it can easily be accessed should an operator actually need it. Not only can we quickly see how our system (or cat) is doing, this bar graph gives us some other indicators as well. The white, gray, and black sections indicate warning limits that we weren’t able to get from the table, and if we did put them in the table, it would likely become a confused mess. The other element that this bar graph has is a bold color change (more on color in a later post) when a value falls outside of the normal range. Immediately my eye is drawn to the red arrow. All of the other data points are gray and therefore normal. And that is all I need to know about them. But I see the red one and I immediately know that this is where I need to direct my attention. I can start to figure out what is going on there without wasting time on the other elements.