So, to recap, we kicked off our Viva Visualization Tour in Atlanta in July to an eager and anxious crowd. In Boston, we were met by heavy downpours (of rain, that is), and some very dedicated data visualization fans who braved the weather, as their drought ended when we arrived in the Boston area. We were glad to be of service--and to bring lots of data visualization know-how with us, as well.

Now, it's your turn, D.C. September 16th, rain or shine, we're ready to make an even bigger showing in the Capital city and home to Juice Analytics.

If you're in the D.C. or surrounding areas, come meet Juice and learn about communicating better with data.

What you'll have when you leave:

• visualization best practices training around information layout and workflow, information visualization, chart selection, and styling
• networking within the D.C. visualization community
• a full breakfast buffet
• opportunity to pick the Juice collective for tidbits of vizo-knowledge
• a few pieces of custom designed Juice schwag

What Juice gets out of this:

• a much needed visit to one of the country's greatest cities
• a chance to meet D.C. folks who love making visual sense of data
• opportunity to talk about the stuff we're excited about with people who are actually willing to listen (besides our moms)
• a big ol' food bill

So, if this sounds like great fun to you (and who wouldn't think so), register. We can't wait to meet you.

This is the third in our series of topical reviews of the Federal IT Dashboard. As Ken noted in his discussion of Flow, we see this publicly-available dashboard as an opportunity to share some thoughts on ways to evaluate and improve dashboard design, while acknowledging the hard-work and challenges that went into its development.

Today we'd like to take a quick tour of the charts in the Dashboard and ask three questions of each:

1. Is it the right chart for the data being displayed?
2. Is the chart designed to communicate effectively?
3. How would we redesign the chart?

A column chart is used to display the top departments by IT spend.

They've chosen an appropriate chart for the job, though we often will go with a bar chart over a column chart. Bar charts tend to use space more effectively because the category labels can be wider. Notice how all the Federal Agency labels had to be compressed into an abbreviation (e.g. DOD, DOC, DOT, DOJ), almost requiring a beltway-insider to translate.

One quirky feature is that the y-axis is labeled "($) Billions" but there are no values on the bars (on rollover, a tooltip shows the values with "$B").

Finally, the chart uses animation when it is first displayed to grow each of the bars from the baseline. This is a useful effect that emphasizes the largest values which keep growing after the others stop. Not as useful: the reflection effect under the chart doesn't help with comparing column sizes.

Our redesign of the chart would include more explicit labeling and the total IT spending at the top.

Pie charts are used to show the distribution of performance of IT projects.

We've said a lot of mean things about pie charts over the years. We are not alone. Nevertheless, pie charts can have a legitimate place in presenting data. Here's how these pie's fall flat:

• At their miniature size, the relatively proportions are hard to see.
• On the summary page, there is no legend or labeling to provide any meaning. I appreciate that green is good and red is bad, but what are the definitions for those colors?
• As always, a 3d pie chart distorts values by making the "closer" slices seem bigger.
• Readers will find it difficult to compare across the three pie charts.

An alternative to multiple pie charts in this situation is a stacked bar chart:

Line and area charts are used to display trends in project performance.

These charts are appropriate and reasonably well executed. Our concerns would be with the design: the labeling isn't efficient for the limited space, the lines colors aren't high contrast, and the entire chart feels like it was compressed into too small a space. Here's our take on it:

A treemap is used to show the composition of projects and/or spend based on agency, functions, service groups, etc.

Is this the right chart for the job? Most definitely. Treemaps are awesome at displaying hierarchical data that can be summed at each level. It provides a comprehensive view of IT spending composition while allowing you to see changes and drill-down for more detail.

The design of this treemap needs refinement. The developers used the out-of-the-box version of our JuiceKit treemap, so we have room for improvements in our default settings. For example:

• The borders on the boxes are clumsy and distracting. We've started to de-emphasize the border with white or light grey.
• The label names provide very little value as most of them are a truncation of the word Department. A narrower font at normal weight would help. Creating an alternative label that leads with useful information would be better: "Commerce" rather than "Department of Commerce."

Here's a treemap demo that feels a lot cleaner from a design perspective:

All in all, the Fed IT Dashboard does a fine job of choosing appropriate visuals and keeping the chartjunk low. Here are a couple good source to help with these decisions:

• Chart Makeovers
• Choosing the right chart type
• Chart chooser, for Tufte-compliant charts
• Choosing a good chart

This is the second part in a series about better dashboard design. This part, Flow, follows Message to highlight the importance of taking that message and making it easy to work through in light of the larger business process.

Having said that and before we continue, we wanted to reveal an internal conversation we've been having about the example (Federal IT Dashboard) that we've selected to demonstrate some of our thinking. We appreciate that it is hard to build dashboards that satisfy a broad audience. From initial conception to delivery, these forces, often at cross-purposes, can chip away at an intuitive and clear design. This series of posts isn't meant to disparage the hard work and deep thinking that clearly went into the design of the Fed IT Dashboard; it is meant to offer some perspective and hopefully useful lessons for others in their dashboard design projects.

Part 2: Flow

In Part 1: Message, Zach introduced the results of some thinking we’ve been having about the Federal IT dashboard and how to continue to improve the effectiveness of its ability to communicate with data. This week, we’ll take a look at the next step in the process: Flow.

Communicating with data is like telling a story: there’s a beginning, a middle, and an end. When you grab that latest book from your favorite author, you know just where to get started, and (if that author is any good) you know exactly when it’s the end. Well, telling a story with a data application is just the same. The information designer needs to lay out the components of the story in a way that facilitates starting, learning, and finishing strong. We call this the workflow of the application. A great application workflow is not evidenced by easy-to-use software (although this might very well be a byproduct), but rather a great application workflow is about helping the user transparently achieve the objectives that make them successful at their job.

So let’s look at some of the principles that we at Juice would use to take the flow of the Fed IT dashboard to the next level.

Principle 1: Know what objectives people are trying to achieve

The first step to knowing the objectives of the users is to know who the users are. Because of the tremendous reach of the Federal IT Dashboard, this is a particularly difficult problem as the audience is so broad. Generally speaking, we think there are three types of users for this system:

• Inquisitive masses - Scope: broad but shallow - These folks are the general public; those people who are most likely looking for high level information and are looking for answers to broadly curious questions.

• Informed but distant 3rd parties - Scope: medium breadth, medium depth - This second group includes people who are looking for information on a specific program to compare to another program that they are more familiar with. In the case of the Federal IT Dashboard, this may include the CIO of a related project, or the chair of a Senate subcommittee, or a political watchdog group doing some research.

• Involved 1st parties - Scope: narrow but deep - This third group represents those who are directly involved with a specific program and want to drill deep to learn as much as they can about a single specific program.

Principle 2: Know how the solution will fit into the broader workflow

Since most “normal” people are paid to get stuff done and not paid to use software, it’s important for the application designer to make sure the tools that they provide are, at a minimum, supporting the workflow, and preferably, transparent to the workflow. Questions that the designer wants to make sure the user doesn’t find themselves asking are “Where do I start?”, “What’s the next step through the app?”, “What’s the end point and how do I know I’m finished?”.

Looking at the Federal IT Dashboard homepage, it’s not clear to me that there’s actually a place to start. The very first image is the Performance summary on the left with the column chart on the right. But just as I’ve decided that I can click, the image changes. I find myself being confused by this almost every time I visit this site - especially since I can’t click on the other views in the image rotation. All of a sudden, I’ve gone from trying to complete my workflow to trying to figure out how to get back to the dashboard - not very transparent.

Using existing methods such as behavior diagrams (such as Interaction Diagrams, Event Diagrams, and Use Case Diagrams) can really help an application designer overcome these sorts of hurdles and define intuitive action flows.

Principle 3: Make navigating the application layout intuitive

When considering application navigation layout, use a single simple rule: start high and enable drill down.

Start with high level KPIs that indicate the overall performance with as few metrics as are possible so the first thing that the user sees on a dashboard is nearly instantly comprehensible. This sometimes requires the application designer to be ruthless about “who” makes the metric cut for the first view. The number should immediately indicate whether further investigation is required. In our mockup, the important numbers are just four: spending and change, and performance and change.

The goal is that it’s simple enough that a first time user can quickly determine what’s next, but an experienced user can quickly determine if anything significant has changed since their last visit.

Once the high level “first view” is identified, enable the user to easily drill down for additional information and exploration. For example, as the user is investigating a particular number, clicking directly on that number should reveal the next layer of information. This is where the Federal IT Dashboard excels, by the way. Users can drill down by clicking on program names, or chart segments, and can navigate back up the crumb trail by clicking “clear” at the top of the data table or on the current view parent.

Finally, we need to address the main navigation. Navigation elements that are positioned such that they imply some sort of relationship, such as menu items, should either be siblings, or parent-child entities. In the case of the main navigation tabs on the Federal IT Dashboard, the items Home, Portfolio, Tools, and Data Feeds are distinct areas but all have different relationships to each other - or worse aren’t related. This makes navigation difficult because the user has to context shift to navigate. It’s a little like “Apples”, “Transportation”, “Monday”, and “Swimming” - they don’t have any thing to do with each other.

It’s OK to use tabs, but make sure they contain distinct and separate domains or views. For the Federal IT Dashboard, I think navigation would be more intuitive if the Home, Portfolio, and Tools tabs were merged. Start all the users with the overview, then allow them to navigate via the visualization to the Portfolio view. Then, toggle that view with the views that under the Tools tab based on the view the user needs to see.

Ok, back in July, we kicked off our Viva Visualization Tour in Atlanta and it was great! Now it's Boston's turn to show the folks down south how it's done.

If you're in Boston, come meet Juice and learn about communicating better with data.

What you'll have when you leave:

• visualization best practices training around information layout and workflow, information visualization, chart selection, and styling
• networking within the Boston visualization community
• a full breakfast buffet
• opportunity to pick the Juice collective for tidbits of vizo-knowledge
• a few pieces of custom designed Juice schwag

What Juice gets out of this:

• a much needed visit to one of the country's greatest cities
• a chance to meet Boston folks who love making visual sense of data
• opportunity to talk about the stuff we're excited about with people who are actually willing to listen (besides our moms)
• a big ol' food bill

So, if this sounds like great fun to you (and who wouldn't think so), register. We don't get to Boston much, so sign up now! We can't wait to meet you.

And, for those of you who aren't in the Boston area, we're also planning a September meeting in D.C., so keep your eyes open.

What do Tableau fans and Juice fans have in common? Both sets of groupies can see Tableau and Juice together at the 2010 Tableau Customer Conference! That's right, the great folks at Tableau have very generously offered the opportunity for Juice to speak at their annual conference.

This is going to be a great conference with speakers like Stephen Few, Garr Reynolds, and Stephen Dubner of Freakonomics fame. Four days of great principles and practices. If you haven't registered yet, there are just a few spaces left, so get to it.

As you all know, Juice highly admires the huge advances that Tableau has made to democratize effective visual analysis and we believe Tableau is setting the new standard for packaged information analysis tools. As it turns out, Juice has fans at Tableau as well. So come join us at the Mutual Admiration Society meeting in Seattle at the end of August.

Oh yeah, if you're going to be at the conference, don't let us get out of there without introducing yourself!