Introducing Chart Chooser

Find and Download Great-Looking Excel and PowerPoint Charts

Chart Chooser is an online tool that answers two questions we commonly get:

  1. What type of chart should I use to show my data?
  2. How can I make good looking Excel or PowerPoint charts?


Chart Chooser


Chart Chooser is easy:

  1. Check the boxes on the left that best describe your objective
  2. Select the chart that you want to use
  3. Choose from Excel or PowerPoint downloads to get a formatted chart template

A few notes about Chart Chooser:

  • Thanks to Andrew Abela of Extreme Presentations for inspiring Chart Chooser with his “Choosing a Good Chart” post and for working with us to put this tool together.
  • We’ve tried to make the charts both Tufte-compliant (i.e. minimal chart-junk) and visually attractive (thanks to Google for the color scheme).
  • Feel free to suggest other types of charts that you’d like to see in the Chart Chooser. Send an example to chartchooser@juiceanalytics.com.
  • If you’d like a customized version of Chart Chooser for your organization, write us at chartchooser@juiceanalytics.com or call me at 202.251.7750.
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License. All source code is released under a BSD License unless otherwise specified.

23 comments | Show all comments only the last 5 are shown


November 27, 2007
Kelly O'Day said:

This is my 3rd and hopefully final try at getting the link to work.

http://processtrends.com/toc_chart_doctor.htm


December 20, 2007
Stef said:

Hey there, the website is still not visible from Switzerland! Gush....


February 27, 2008
Mike said:

Hi guys!

This is fu&%$ awesome! Thank you very much for this!


February 27, 2008
Tom said:

I love your site and have used several graphs to make myself 'look good' at work. Thanks.
I want to use the Waterfall chart but for the life of me I can not figure out how you remove/hide the color fill from the data points after the first one and leave it in for this one.

Thanks.


April 12, 2008
Priya said:

Hey thanks for this useful site... I was wondering if there is a write up for different type of charts displayed here, as in what type of data or steps / FAQs etc.

If I am missing something here, let me know

Your name

Email (optional, will not be shared)

Type the word "juice" (required to confuse the spammers)

Your comment


Add a comment





Analytics Roundup: Collaboration and Presentation

Death by PowerPoint » SlideShare
Quick inspiration for great presentations.

Role Modellers - Home
Software to manage human collaborative work via a workflow motif. Driven by Human Interaction Management.

This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License. All source code is released under a BSD License unless otherwise specified.

0 comments | Add a comment

Your name

Email (optional, will not be shared)

Type the word "juice" (required to confuse the spammers)

Your comment






The Ultimate Business Driving Machine

What do you do when you’d rather be out driving your BMW rather than sitting in your corner office? Make a business dashboard that looks like your car dashboard, of course. You’ll want to have lots of tachometers, temperature gauges, and traffic lights. It’s the ultimate business-driving machine.

It isn’t controversial to complain about the ineffectiveness of “gauges” for data visualization. In fact, even some of the worst offenders admit that gauges aren’t ideal:

Dr. Robert Alison of SAS in showing off a new easy graph procedure for creating gauges says:

“I know, I know … gauges have lots of drawbacks in dashboards. But hey, the other philosophy is 'give the customer what they want' … and try to make it work as well as possible. So, as far as gauges go, these are pretty decent.”

Here’s the example he uses to show off “one of the sharper-looking dashboards I’ve seen”

SAS dashboard

The folks at Business Object’s Xcelcius admit that gauges shouldn’t always be used in their article entitled “The Use (and Misuse) of Gauges”.

That doesn’t stop them applying a triple-coat of carnauba wax while neglecting their rule to always label the endpoints.

Xcelsius gauge

In the end, they primly note: “Despite some recent bad press, a gauge isn’t inherently a poor graphic.” Bad press, is it. If only gauges had better PR.

In my opinion, warning about potential misuse isn’t firm enough. Gauges shouldn’t be used except under the most severe threats from a client offering enough money to buy absolution.

Stephen Few, a man who doesn’t mince words on information visualization, says:

“If you squint really hard, you can barely make out some of the values. But who cares, because if you’re an executive who likes to pretend that you’re driving a car while sitting at your desk rather than actually managing your business, then having a dashboard that is truly informative doesn’t really matter.”

Charley Kyd says:

“Using dashboard gauges for management reporting typically is a mistake. Gauges hide information that managers need and consume significant space in a report.”

Let’s break down the problems with gauges:

Gauges hide trends. For all the focus on how a value is performing, you’d think people would care about the historical trend.

Circles aren’t good for showing differences. Like pie charts, circular gauges aren’t the best way to show size or changes in values—bars are a more straightforward, if less sporty, approach.

Space eaters. Often gauges are used to show a single value. All that decoration for a single value must send Tufte into a tizzy. Attempts to cram two values into a gauge can be confusing. How do you read this one?
Two value gauge

Difficult to read. The values can be obscured by all the attractive accoutrement:
Black gauge

Ranges can be tricky. By the analogy to a car dashboard, gauges are expected to have a static minimum and maximum value. What happens when a value goes beyond the pre-set range. Here’s an example of the “right way” from Xcelsius with the label: “This gauge shows a retail store’s progress against a daily revenue target.” We can only presume the maximum value is $45,000. What happens if I go beyond $45,000?
Xcelsius revenue gauge

Traffic lights are contradictory. I may be getting nitpicky, but I can’t both have my traffic light look like the real thing (red on top, green on bottom) and abide by basic data visualization assumptions (better is higher).
Traffic lights

Lastly, there are so many better options. Here’s a beautiful data display (courtesy of Mr. Few) that could have been done with gauges, but mercifully was not.
Good dashboard

This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License. All source code is released under a BSD License unless otherwise specified.

10 comments | Show all comments only the last 5 are shown


November 16, 2007
Loren said:

I agree that gauges consume valuable real estate space and may not be an ideal option for displaying numerical information. However, gauges can be revealing when they are combined with sliders, dials, and other interactive components; as they help to visualize hidden relationships in the underlying mathematical model.

-- Loren


November 16, 2007
Chris Gemignani said:

Loren, it is better to use basic bar charts or lines if you want to "visualize hidden relationships in the underlying mathematical model". Bad is bad no matter the source of the number you're displaying.

If you're trying to illustrate the working of a model embodied in a spreadsheet you're better off designing more sophisticated displays that can show how multiple values covary. XY charts and animation leap to mind.

Stephen Few has a nice article here on visualizing change: http://www.perceptualedge.com/articles/09-27-07.pdf


November 16, 2007
Andy said:

Presumably the point of using gauges is that they are "understandable" and familiar to people not confident with proper charts, so I am often struck how little resemblance there is from BI dashboards to the real thing.

I imagine that some car makers but considerable effort into designing their dashboards to give a small amount of very important information genuinely "at-a-glance". In my (admittedly cheap) car this is done with one large speedometer and a small fuel gauge with the other information in warning lights that only come on if there is a problem, plus an odometer and clock.
But then, when I drive my car I mostly look out of the windscreen towards the road!

I've also seen a few rows of 4 traffic lights at complex multi-lane motorway junctions, and its one of the things that make motorway driving intimidating for some people.

But I have to admit to using Jon Peltier's speedometer chart (in the past).


November 16, 2007
Ken said:

All the confusion on gauges on dashboards is definitely a result of the automotive context. It made me think about a few years ago when I was looking at buying a Saab. The coolest feature of these cars is the Night Panel display. At night, the only gauge that is illuminated is the speedometer.
<img src="http://z.about.com/d/cars/1/7/F/j/ag_07saab93_nightpnlon.jpg" width="100" alt="Saab gauge">
Then if there is an issue with another system, illumination is added to that system's indicator. This was inspired by the Saab aircraft designs.

Too many aircraft pilots have flown into the ground because they were too enthralled with the overload of "useful" information showing up on the instrument panel. I wonder how much this is happening in businesses today?


November 17, 2007
Brett said:

Hi Guys,
I wasn't sure where to put this so here is some website feedback:
I really like the site and the content that it contains is amazing, so much in fact that i have spent a long time now reading all of the posts going back through time. But there are a few navigational bugs...
When you access the posts directly through a url such as: http://www.juiceanalytics.com/writing/#Year#/#Month#/#ArticleName#/ the navigation using the categories (or filters) of author and date do not give valid pages. Using the author navigation list leads to a url such as: http://www.juiceanalytics.com/writing/#Year#/#Month#/#ArticleName#/author/#AuthorFirstName# which gives a page not found message.
The behaviour of the categories when not viewing a page directly appends some sort of query to the url eg: from http://www.juiceanalytics.com/writing/topics/analytics/ clicking on Zach as the author appends ?author__first_name=Zack to the url it filters just perfectly.

The screencast links from all apart from 1 of the previous posts (when they are hyperlinks, not embedded) don't seem to work.

The navigation seems to be completely missing from a couple of pages such as:
http://www.juiceanalytics.com/writing/2006/12/square-pie-screencast/
http://www.juiceanalytics.com/writing/2007/07/recreating-ny-times-cancer-graph/
the next and previous links point to both pages from either side but they are then both dead ends!!

Once again an awesome site and thanks for sharing!

Your name

Email (optional, will not be shared)

Type the word "juice" (required to confuse the spammers)

Your comment


Add a comment





Analytics Roundup: Extreme visualization

Mapping Philly
This geomapping project is digitizing and mapping historical images of Philadelphia, including meta data..

ICCARUS: Three Dimensional Data Visualization
3D is fun, but would you really be able to extract insights from this tool?

Convert your portrait to a character from "The Simpson's"
Ever wonder what you would like like if you got one of those sweet cameo appearances on "The Simpson's?" Now's your chance to find out. Go to this site and follow the directions to upload your photo—and poof, you're in Springfield.

This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License. All source code is released under a BSD License unless otherwise specified.

0 comments | Add a comment

Your name

Email (optional, will not be shared)

Type the word "juice" (required to confuse the spammers)

Your comment






In Fogbugz 6.0, Future Results CAN be Predicted by Past Performance

Monte Carlo. It's a car. It’s a song. It's a casino. It's a city in Monaco (near France, somewhere). It’s also a method of statistical simulation that is used to better understand the probabilistic distribution of known set of data. Great. So what?

I recently attended the Atlanta session of the FogBugz World Tour to hear from Joel Spolsky about the latest version of his bug tracking software, FogBugz 6.0. Joel Spolsky has been writing about software development, management, business, and the Internet at joelonsoftware.com since 2000. Three books have sprung from content on his site: User Interface Design for Programmers, Joel on Software, and Smart and Gets Things Done. They are good reads for software developers and business folks alike; smart, funny, and focused on the human face of software development.

Before starting his company, Joel was a Program Manager at Microsoft on the Excel team to provide programmability to Excel.

The new release of FogBugz has quite a few nice features to make bug tracking much easier, but I was most intrigued by the new capability called Evidence-Based Scheduling, or EBS for short. This new capability uses a Monte Carlo simulation approach to determine probabilities associated with the expected “ship dates” of the software release project.

The core premise behind this capability is that unlike in the financial realm, in the software world, future results can accurately be based on past performance. FogBugz remembers the original estimate and the actuals for each task for each developer, and for all the projects they've been assigned to. Here's where it gets interesting. Based on this information, FogBugz runs a series of Monte Carlo scenarios where it randomly generates different plausible results for each member of the development team. It then assembles the results to create a distribution for probability of completion for each developer—and more importantly, for the entire project. The result of this analysis is a "Ship Date" probability curve that shows potential ship dates on the X-axis and probabilities of achieving those dates on the Y-axis. Ship Date depends not only on estimates for remaining components, but also on the probability that the individual developers will be able to individually meet their commitments. A steeper curve means the developer estimates are more confident and a flatter curve means estimates are less confident.

The classic software development process involves balancing three things: time, money, and features. Most projects of reasonable duration are not going to be able to effectively add staff mid-stream—at least not to accelerate delivery timeframes. If you assume the primary factor in determining "money" is tied to people, time and features are your only real variables. FogBugz 6.0 lets you experiment with changing these two factors. This is a useful tool. Consider a scenario where the business people come to the development lead because they need a project to be complete by a specific date. This tool gives the project lead enough information to understand the probability of making a specific date. Additionally, it lets you test out what will happen if you remove a particular feature. With this new information, the development lead has the visibility to provide back additional guidance to the project sponsor about the probability of making the requested date, as well as the effect that changing release date and scope have on the probability of on-time delivery.

So how does it know? The ship dates are based on each developer's history of estimation accuracy supported by developer time sheets. Yes, that’s right. I said time sheets—the bane of all developers. But stick with me, it's not as bad as you might think. Each developer (or responsible team lead) can turn on a timer that automatically tracks time spent on each of their cases.

Fogbugz plots a linear fit through the data points for each developer and then uses the calculated R2 value to determine how consistent the developer’s estimates have historically been. Based on this calculation, probability distributions for remaining tasks for each team member are determined, which leads the ship date probabilities. It’s then easy to see the long pole in the project (Milton Ritchie in this example). This doesn’t necessarily mean the most work, but only reflects the probability of on-time completion—and correspondingly, the most risk to the project.

Anyone who has followed Joel's writings knows that he is keen on the idea of improving the process of software development. And, we all know that estimating an accurate time to completion, or “ship date,” for any software project is a pain in the rear even after all these years of "practice." The unique approach that Fog Creek takes is not to predict the specific completion time, but rather to predict the probability of completing the project across a range of dates.

So, project estimating will likely never be a simple turn and churn process. But with this release of FogBugz, Fog Creek Software has shown great outside-the-box-thinking that could significantly improve how we deliver software projects.

This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License. All source code is released under a BSD License unless otherwise specified.

2 comments


November 7, 2007
Ian Rae said:

Very interesting. First time I saw this concept as relates to managing software development projects was a few years ago at devshop.com - they billed their approach as "manage the risk" so I would be interesting in knowing where the approach originated (aside from the obvious fact that software projects always go overtime and over budget).


November 8, 2007
Sephir said:

This is great stuff, and can really be useful in any scheduling problem. (For Monte Carlo Excel plug ins, look for Crystal Ball software from Oracle, or @Risk from Palisades). The key is reliable historical data that is relevant for the future. Software delivery seems ideal because you can measure each developer's past performance, which is likely to be the same on future projects ... but as you add complexity and more variables, the accuracy and predictability quickly erodes.

Your name

Email (optional, will not be shared)

Type the word "juice" (required to confuse the spammers)

Your comment


Add a comment





Analytics Roundup: Earmarks in Google Earth

Congressional Earmarks in Google Earth
Brad Forrest from the O'Reilly Radar blog points out a new way to better understand where your tax money is actually being spent geographically.

This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License. All source code is released under a BSD License unless otherwise specified.

0 comments | Add a comment

Your name

Email (optional, will not be shared)

Type the word "juice" (required to confuse the spammers)

Your comment






The Last Mile of Business Intelligence