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 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.

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.

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”

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.

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?

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

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?

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).

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.

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.

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 R² 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.

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.

“The last mile” is a term that often is applied in the telecom industry in reference to “the final leg of delivering connectivity from a communications provider to a customer.” It is an expensive and complex step due to the challenge of pushing information from centralized, high capacity channels to many diverse end-points where information is ultimately used.

We think there is a “last mile” problem in business intelligence too. This critical bridge between data warehouses and communication of insights to decision-makers is often weak or missing. Your investments and meticulous efforts to create a central infrastructure can become worthless without effective delivery to end-users. “But how about my reporting interface?” you wonder. That’s a creaky and narrow bridge to rely on for the last mile of business intelligence.

Listening to our clients, we are confident the last mile is a real problem. The ultimate source of this failure is less clear. Here are a few of theories:

1. The engineers who built the data warehouse build the interface. No offense to the talented individuals who can push around, clean, normalize, and integrate data—but they may not be ideally suited to designing a user interface for non-technical users. A designer wouldn’t create charts that look like this (our favorite example of chart-based encryption):

In the worst case, developers are dismissive of user experience. I’ve met with IT folks who felt confident that providing a massive data table would provide a suitable solution for delivering information to users. “Hey, they’re getting their data. Is there a problem?”

2. Reporting is considered the fundamental mechanism for working with data. Here’s a framework we’ve started to consider in thinking through the multiple approaches for getting value from data:

• Reporting lets you monitor things that are well-understood and relatively predictable.
• Exporation or analysis helps you understand new processes and erratic and shifting behaviors.
• Presentation is about communicating insights and understanding, often building on both reporting and analysis.

Many people assume that a reporting tool is sufficient to do in-depth analysis and communicate results. That’s like trying to build a deck with a screwdriver.

3. Poor fundamentals in information display. Despite the efforts of folks like Edward Tufte and Stephen Few, general literacy in this area is still low. Shiny, 3D pie charts are still acceptable, even desirable in some places. Particularly disturbing is the persistence and pervasiveness of this problem in Excel where there still remains some confusion as to why this is bad information display:

You don’t have to go any further than the Dashboard Spy to find examples of the visual muck that is commonplace.