As our followers know, for the past few years Juice has been creating software applications that solve customers' real information visualization problems in purposeful, understandable, and beautiful ways. In doing this, we have found ourselves reusing quite a few components over and over again - which has made our jobs a lot easier. It occurred to us that others might like to benefit from using these components to achieve great results too.

We're proud to announce the open source release of Juice Analytics' JuiceKit SDK.

The JuiceKit is a toolkit built on Adobe's Flex SDK to make it easier for web designers and software developers to build visually compelling Information Experiences™. It contains a wide variety of development components from individual data renderers such as a single "small multiple", to a large visualization component such as a treemap or US Map, to fine grained "helpers" that provide handy capabilities such as copying data to the computer's clipboard. These components can be used independently, within other applications, or assembled together to create full applications.

What can I do with it? (Show me the money)

Because we've been using the JuiceKit for quite a while, we have a number of customer proven applications based on the SDK that we thought you'd be interested in seeing.

Here is a screenshot of an application that we built to help our client see trends in their internet search and traffic activity. We used the JuiceKit™ to create the small multiples data visualization component of this application.

We've also frequently used JuiceKit to create dashboard prototypes. If you haven't seen our recent application of our treemap component to the incomprehensible Federal Stimulus Plan, here is a nice example (click to explore):

And here is a very quick one we did for an IVR monitoring application where we assembled multiple different components together into one view:

Finally, we've used JuiceKit many times to build full enterprise applications such as this sales pipeline tracking dashboard:

How do I get it?

Now it's time for you to have a go. Here's how you do it:

• Go to the JuiceKit SDK web page at juicekit.org and catch up on the current status of the project
• Check out the JuiceKit discussion group on Google Groups
• Download the JuiceKit library from github
• Contribute back to the JuiceKit community to make the JuiceKit even better

While Juice continues to focus on designing and providing software solutions (as opposed to toolkits) for our clients, we believe offering the JuiceKit as open source will benefit the information visualization community we try to serve. In the future we will continue to extend the JuiceKit with other components and technologies.

Good luck, and make sure you share how you're using the SDK so we can continue to drive it in the right direction not only for us, but for you as well.

In the information visualization world, treemaps are on the rise…and justifiably so. Treemaps simultaneously show the big picture, comparisons of related items, and allow easy navigation to the details.

However, treemaps aren’t easy to get right. In contrast to basic charts where Stephen Few, Edward Tufte, and the Chart Chooser have laid down the law, treemaps roam the Wild West of interface design, obeying few rules, breaking many, and contributing to much infovis lawlessness.

Over the last year or so we’ve been building treemaps for our clients using our (recently open-sourced) Flex-based JuiceKit™ SDK. Over the course of these projects, we’ve thought a lot about the best way to make treemaps easy to understand and use. I won’t claim we have “cracked the code,” but we have gotten a feel for what works and what doesn’t. I want to share some examples of the good and the bad in treemap design, and hopefully gather some feedback so we can continue to evolve our thinking.

1. Choose the right measures for size and color

Each box in a treemap can show two measures:

• Size of the boxes should be a quantity measure. The measures should sum up along the hierarchical structure of the data. The sum of all the elements in one branch need to sum to the value of the branch as a whole. Therefore, you can’t use ratios or dates or any other measure you wouldn’t use in a pie chart.
• Color of the boxes is best suited to a measure of performance or change such as growth over time, average conversion rate, or customer satisfaction.

The King of Treemaps — Smart Money’s Map of the Market — offers a classic set of measures: size represents market cap; color represents change in market cap.

2. Space matters

Like a pie chart, size represents value in a treemap. In the following example from LabEscape, the category labels use space -- almost as if you added slices to a pie chart for labeling. This approach distorts the values by arbitrarily using space, making it harder for the viewer to visually compare sizes.

3. Labels should add value

Labels are hard to get right in a treemap. If you aren’t careful, labels can clutter up the treemap without adding useful information. This Macrofocus treemap wasn’t careful. Notice how the majority of labels get reduced to just a few letters or simply an ellipses (“…”). It would be better to show nothing until the user rolls over a box.

4. Labels must stand-out against treemap colors

One of the unique challenges of a treemap is that the labels need to stand out against a multicolored background. The ILOG Elixir treemap chooses to put the labels in a white text box. Unfortunately these text boxes look clunky, obscure some of the data, and don’t always fit into the allotted space.

To neutralize the contrast of the label to the background and ensure legibility, we created a “glow” around the text.

5. Explanatory legends

The New York Times folks know what they are doing when it comes to visualizations and the explanations around them. Below is the legend for a treemap about automobile sales. The meaning of size and color aspects are articulated in a small space.

6. Color ranges fit the data

The nature of your color measure should determine whether you need a one-sided or two-sided color range. In situations where the color measure has both negative and positive values (e.g. period over period growth), we typically use a two-sided color range with a light grey at the middle. A one-sided color range is a better fit when the measure starts at zero. The Hive Group treemap below offers an example where a two-sided color range (red to green) doesn’t make as much sense. This treemap is using color to show geographic area rank from 1 (largest) to 195 (smallest).

7. Show correlation by highlighting

One of the nice advanced features treemaps can offer is highlighting items that meet a user-specified criteria. In the Many Eyes treemap below, a search features identifies that companies that include the selected search term. Not only does this aid the navigational capabilities of the treemap, it allow allows you to see color, size, and location correlations for the selected items.

8. Show changes with animation

When you want to show variations in the data (e.g. changing time periods, filtering, changing measures), we’ve found that animation effects can help emphasize the differences. In our stimulus plan treemap, flipping between “cost” and “votes” to size the boxes results in an animated reorganization of the boxes. The boxes that get bigger move to the upper left and those that shrink move down and to the right. The effect helps the user track where things are moving and get an understanding of the overall differences in the treemap.

9. Simple presentation of node detail

When a user selects a node in a treemap, they should see the available detail either in a tooltip window or in the sidebar. If the detail is substantial in size, it is best to push it into a sidebar as we did with our Stimulus Plan Explorer. Simpler data can show up in a tooltip box like the beautifully designed tooltip created by MIX Online (notice how it flips around to stay within the borders of the treemap).

ILOG Elixir’s demo recognizes the need to see detail, but the execution is flawed. Selecting a box in their treemap highlights rows in a table, but the rows are not consolidated so you are lucky to see only one or two rows of highlighted data. Users need to scroll through a massive table to be able to see the complete details.

10. Gradually reveal detail

Panopticon has a powerful treemap offering, but their demo treemap has some missteps in showing the detail. In particular, they choose to show as much detail as possible, but in a faint grey text. When you roll-over a box, this text becomes legible just as a redundant pop-up box appears. Detail is shown before the user has even expressed any interest in the box. Better to wait until the user rolls over or clicks on a box, then show the details. In the meantime, let the size and color do the talking.

These are just a few of the design lessons we’ve considered in our work. Treemaps offer an opportunity to make vast and complex data accessible — but they depend on thoughtful, user-friendly design.

How about you? What are some of the design features you have seen in treemaps that you think are particularly effective in making the communication of information stronger?

We’ve seen a lot of anxiety about the huge price tag of the stimulus bill winding its way through Congress. Some of the complaining is about the difficulty in understanding the contents of this complex legislation. Certainly the stimulus bill looks impenetrable if you try to sift through 700 pages of details or even a 25-page summary. In response many people evaluate it based on their gut feel.

To help out, we’ve created the Juice Stimulus Bill Explorer — a treemap visualization that summarizes the House version of the stimulus bill and let’s you vote on its pieces.

The data in this treemap comes from the 1/15/09 summary (pdf) of the House of Representatives version of the American Recovery and Reinvestment Act. Selecting any box will show a description of the individual program, the price tag, and an opportunity to express whether you like or dislike the idea. The treemap boxes are sized by the proposed cost of each program. The color is based on the average level of support for the program from user votes.

Thanks to Scott Love for encouraging us to put this together.