Chart Types for Web-based Dashboards

An article in Smashing Magazine lists many different options for charting in web applications. I've personally evaluated a lot of these and I settled on Fusion Charts and haven't been disappointed. It looks great, it's easy to code, and has a ton of chart types and features. And anytime I've had to use support, they've been extremely quick in getting back to me, which is impressive given that most of my support calls come at about 2 in the morning. Or maybe not so impressive, given that I think they're based in India. Either way, I highly recommend them.

On the same subject, there is one downside to doing Flash-based charts: printing. Maybe the user can print the full page in the browser and get the chart, but there's no good way to get it into a PDF without the user having to install additional software, e.g. CutePDF. I've looked for a server side component that will go from Flash to PDF. And I mean I've really, really looked. I tried in 2006 for days and got nowhere, then again a year later and still nothing.

Our solution was to use a separate server side charting package just for generating PDFs. It's not ideal - for starters we now have to maintain two sets of code per chart type. Also, it limits us on the server side technology; for example, the last time I checked Ruby did not have a very good charting package (although that was over a year ago and things change fast in the Ruby world). But I think it's worth the price to get the cool Flash charts and I wouldn't go back to a pure server side solution without a compelling reason.

Supply Chain Dashboard Tips

Mike Brooks of Chevron has some opinions about supply chain dashboards in this Supply Chain Digest article:

• Get rid of the clutter: most dashboard tools from vendors have all kinds of "overhead" on the screens that add confusion and make it difficult to find and focus on what's really important. "remove every pixel that doesn't show information" he said.


• Pie charts, especially side by side pie charts, and "gauges," really don’t communicate data for decision-making effectively.


• Work closely with users/execs to ensure the data is truly actionable


• Visualization provides maximum impact, but again that doesn't just mean pie or bar charts.


• Use very clear metaphors – for example, black means above plan, red means under plan. Gets attention very quickly.


• Focus on trends, and key changes over time rather than absolute precision. You are not trying to satisfy the accountants, but improve decisions.


• Make the navigation highly simple and intuitive. Strive for a "no nothing" interface.


• Focus on "now," not historical data.

He makes some very good points. In particular, pie charts have historically been overused just because they look pretty. As Stephen Few points out, the areas within a circle are deceiving so they can lead to incorrect assumptions about the relationship between the categories. A bar graph is much better for comparing values. However, Few also suggests that a dashboard needs to be pleasant to look at without sacrificing usefulness and the one they use as an example needs a little work in that area. And I'd interested in learning what decisions an executive would make based on that dashboard.

He doesn't mention this directly, but drill-downs to the lower level are key to making the dashboard actionable. You need to know why something is the way it is to make a decision about it. A dashboard should almost be a navigational path telling you who to call. Service level/fill rate is down? Drill down to see where the problem is. Maybe a particular DC or product line is skewing the numbers. So call the DC manager or the buyer. They should have a dashboard that starts at the level that the exec's ends at. But they can drill down and see more specifically where the problem is. Could be that a shift at the DC is understaffed so the manager can work with the shift supervisor to balance the load better. Or the main supplier is low on a part so the buyer needs to source the item from another location. Every level can easily determine the action they need to take by seeing the right level of detail.

Overall, it's a good article and some good ideas to keep in mind while building dashboards or dashboard software.

Liferay Portal

Check out this cool-looking open source portal server from Liferay. I played around with the demo a little bit and was impressed. It's definitely a developer tool but it has a lot of good ideas relevant to dashboard software.

Hyperion and SAS Vs. Best in Class

Here's a quote from a research paper by Aberdeen where they compare best-in-class companies versus Hyperion. There's a similar paper for SAS. The links to each paper are below.

The hardest part of delivering information is making the underlying data available to all decision makers. It's not just the top-line information itself that driver performance; it is the detail behind it that provides the insight and understanding of how to take action.

I agree, but what I'm interested in knowing is how do you build the top-line information without access to the details? Somewhere, someone has to have aggregated the details to get those top-line numbers. I suppose in some organizations, the processes that perform that aggregation are separate from the dashboard software that presents those numbers. When I'm building dashboards for customers, the hardest part is usually that the underlying data is so inconsistent that the aggregation makes absolutely no sense. But starting with the high level and not having access to the details at all seems like it would be much worse because as the report said, the data is just not actionable without the details.

The other thing I found interesting in the Hyperion article is the high percentage of companies that use Hyperion but claim "an inability to integrate data from all sources", "lack of internal IT skill sets", and "lack of internal BI skill sets (business users)". I thought tools like Hyperion were supposed to solve those problems. I know Cognos can integrate data from multiple sources using what they call Data Federation. But if companies are failing in BI implementations due to lack of IT and business user skills, the end-user drag and drop BI tool must still have a long way to go. The report somewhat validates my assertion that a good dashboard requires real development, not just drag and drop.

Link: Hyperion Comparison
Link: SAS Comparison

Startup Bipolar Disorder

I mentioned Founders at Work: Stories of Startups' Early Days in a previous post. This is my favorite quote from the book, I believe it was from the founder of Excite:

No, it was never clear that we were on to something huge. You never know anything. The hardest part in a startup is that you wake up one morning, and you feel great about the day, and you think, "We're kicking ass." And then you wake up the next morning, and you think "We’re dead." And literally nothing's changed.

Yep.

iDashboards

Disclaimer: iDashboards would probably be considered a competitor to my company so take this for what it's worth. This is just a mild criticism of their website, not their product. Under the company page on their website, they've got a section called "10 Reasons Why iDashboards". It had it some decent points, although I've made it clear how I feel about the "no programming" thing.

Then I saw a link to "10 Reasons Why Not iDashboards" and I thought, this is cool, somebody who recognizes the sales concept of "going for the no", and isn't just assuming that their product is a perfect fit for every possible customer. Oops, I was wrong. It was just a list of 10 more reasons why to go with them, but inverted to turn them into a negative, like "You don't want cutting edge technology." or "You want to see the friendly faces of consultants for 6 to 18 months". Kind of like in an interview when you're asked what your biggest weakness is and you say "I care about my job too much" or "I work too hard". I'm sure they thought it was clever, but it came across as slightly egotistical to me. Their product looks like it has some really nice features, but if I were a buyer that page of their web site would be a turn off. I suppose it is possible that they were deliberately being tongue-in-cheek, but it's a fine line to walk.

Next post: 10 reasons not to read this blog.

Analysis of the SAP Business Objects Deal

Some analysis of the purchase of Business Objects by SAP.

And more from this Computer World article:

"However, more than ever, there now seems to be a role for an independent BI/performance management vendor not tied to any database or applications company," Vesset said. "Informatica holds this place in the data integration market, and Cognos may be able to do the same in the business analytics market."

The question in my mind is when a large customer comes calling on SAP to integrate their best of breed applications (that don't include SAP), will Business Objects have the autonomy to do the deal like normal, or will the customer just get the big sales pitch from SAP.

This does seem like a good opportunity for Cognos, as the last of the big BI vendors that isn't tied to a specific ERP solution. How long will they stay independent though? And who's left that would buy them? Microsoft has already invested a lot of resources and money into their own BI solutions.

Infor? They are almost my former company. I worked for Dallas Systems which was bought by EXE which was bought by SSA which was bought by Infor - I left during the SSA buyout. Infor is one of the largest Cognos resellers and you can tell from the history that they're not opposed to a little M&A now and then. Maybe they're due for another large acquisition followed by an IPO followed by a private equity buyout followed by an IPO...

SAP to buy Business Objects for $6.8B

Link: SAP to buy Business Objects for $6.8B

I just wish they had known they could have bought my company for under a third of that :).

Dashboard Software: Drag and Drop Versus Coding

There seem to be two schools of thought when it comes to dashboard software and how the dashboards are created by the end user. What I'll call the Cognos philosophy seems to be by far the more prominent. The goal of that philosophy is to let the very final end user create their own dashboard. Pre-built catalogs, drag and drop, wizards, etc are used extensively so the user never has to interact with the data source directly. The other school of thought says that the job of building the dashboard is best left to a developer. The mechanism can range from simple SQL to scripting languages to full blown programming via APIs. I'm sure people had built software using that style long before I entered the scene, but I'll still egotistically call that the Blue Sky philosophy.

Clearly, I'm in the second camp. In my experience, there's a direct correlation between how useful a dashboard is and how difficult it is to build. Easy things are easy, hard things are hard. When we built our product, we decided right from the start that we would design the app to make it as easy as possible to program a new dashboard report (we call them Instruments). There are only so many things you can do with drag and drop or even pure SQL (I'm sure there are SQL gurus out there that would disagree, but I'm talking about expertise that is likely to be found within a company's IT department). In a program you can do all sorts of things to optimize the performance and it makes it very easy to aggregate data from multiple heterogeneous sources.

We chose Java as the programming language because it is probably the most popular language on the planet (for now), so it's like that any customer will have Java programmers on hand. Plus, Java has the third-party library support to talk to just about any type of data source, be it relational database, mainframe, flat file, web service, whatever. I know tools like Cognos do have scripting languages, but it seems like the goal is stay out of that level if at all possible. With the Blue Sky philosophy, we ask people to admit up front that it's going to require coding and we optimize for that situation.

Don't get me wrong - there are a lot of cool things you can do with drag and drop and ad hoc SQL queries and those kinds of interfaces definitely have a place, but for hard-core, real-time metrics, alerts, and exception management, coding is the way to go.

Dashboard Reading

Here are some good books and articles related to the topics on this blog: dashboards, software, startups, and supply chain. You'll find more in the links to the right. One of those links is to Stephen Few who wrote Information Dashboard Design: The Effective Visual Communication of Data, which is a great way to get started learning about the overall goals and pitfalls of dashboards. I've also just ordered The Visual Display of Quantitative Information by Edward Tufte, which I've been told is a classic.

Our company founders just went through an exercise where we all read Good to Great: Why Some Companies Make the Leap... and Others Don't. We're trying to incorporate some of the ideas although being a startup limits us - we need to get to a solid "good" before we can move on to great. Also related to startups, Founders at Work: Stories of Startups' Early Days has stories about the early days of a lot of famous startup successes.

I never thought I'd be recommending a sales book, but Exceptional Selling: How the Best Connect and Win in High Stakes Sales does a great job of demystifying the sales process and illustrating that you don't have to be a slick, smooth-talker to be able to sell.

Finally, from the wayback machine, the old Interface Hall of Fame/Shame is a classic site that shows good and bad UI design - not specific to dashboards, but still fun and informative.

Who Am I

This post will explain a little bit about me and my company. I've worked in software development for 15+ years, the last 10 doing software related to supply chain. 4 years ago, I started a company: Blue Sky (www.blueskylogistics.com) on the side with some co-workers. I did some consulting at Blockbuster Online until we got things rolling and then went full-time with Blue Sky two years ago.

Like a lot of startups, all we knew was that we wanted a company and had no idea what to do. We had been interested in supply chain visibility because we had seen our old company botch it on at least two occasions so we started out with a product called Insight that looked at some specific areas of the supply chain to show users where they were having problems. I don't recall using the term dashboard much, but here we are two years later with a full-fledged dashboard product and some fairly large customers. A big part of my role is to decide where to take the product so I've decided to use this blog to throw out ideas, get involved in the community, and learn a few things, and ultimately try to be a useful resource to others in the same field.