Choose carefully when deciding what to include in your report design. Every element you include, whether it is a cell border, background color, chart or text communicates information of some kind.

Tufte talks about data density in visual report design - packing as many data points into as small an area as possible and getting rid of or minimizing everything else - the genesis of ‘spark lines‘.

I tend to think in terms of information density. Sure, the data is the important part and I want to make it is the focus of the design but because I am trying to make understanding easy and am trying to drive action, I want to make sure that every element in the report design is informing the user.

If an element is not providing the information that I want to or if I am unsure of what an element might be communicating - I leave it out. I don’t want to distract from the point, don’t want to provide mixed messages.

Everything counts, make sure that you know what your report is saying, in all it’s parts.

Just caught this post from David Schatsky at Jupiter Reasearch. It seems that Jup and Kagan are merging. I have to (humbly) admit that I don’t know Kagan at all (humbly because I am in the Entertainment/Media business) so I have no personal sense of whether this is a good thing or not.

I do like David’s relative frankness about why the deal makes sense from both his perspective (business)

“The overlap in our client bases is minimal, and where we do share clients, we tend to have different buyers: Kagan’s users tend to be on the financial and strategic planning side, while our users are typically in marketing (to oversimplify).”

With little overlap in their clients, they won’t be cannibalizing too much revenue.

and from the client perspective (product)

“Our business models are complementary as well. Jupiter’s business is mostly renewable syndicated research, with a hearty slice of custom research and consulting that extends and personalizes our research services and often feeds back into our syndicated capabilities. Kagan’s got a strong consulting and appraisal business–if you are weighing a deal in the entertainment and media sector, Kagan can give you a rigorous appraisal of the true value of your deal.”

Based on the above, Kagan looks like a go-to player for business development (does this deal make sense). Which adds a new dimension for Jup clients to explore/use while Kagan clients potentially gain access to a great library of syndicated research.
With David taking the President role and Tim Baskerville (Kagan) taking the CEO title, it will be interesting to see how this plays out.

Dashboard Spy, e-mailed this link with a commentary in a Business Week Blog. Now it was just a quick note so I don’t know if Spy was pointing out the humor (or perhaps DUH! factor) of the large spike in ‘Beer’ at St. Patrick’s Day. But we’ll set that aside for a moment.

The chart, which is a featured report from BlogPulse tracks the buzz of various alcoholic spirits over time. The most obvious spike was the aforementioned beer spike but there’s an interesting spike for Vodka right around New Year’s and then a more convential spike for Wine around the holidays. Aside: the cyclical trend makes me wonder if bloggers blog about drinking more often on the weekend (or just after the weekend)

Stephen Baker, in his blogspotting blog points out that some of the terms tracked like ‘Gin’ often return results for farming (e.g. Cotton Gin) instead of the beverage. His point, it seems, is to show how ‘dumb’ systems like search have a difficult time attaching meaning to a term and so search in general and analytics suffer because of it. That’s true - sort of. Think about how Search companies have tried to solve the problem. Back in the early days, Yahoo! was just a directory service - they used people to organize all those web pages in a meaningful way. Google’s play is page rank which infers meaning based on the number of links into a page (yes it’s a simplification).

So the point is, not that these systems are ‘dumb’ because hey - they are - we made them that way, but that they are good at matching.

People are good at analysis which in my world means that we’re good at figuring out what something means and whether or not that meaning is relevant to the question we are trying to answer.

So what’s my point? The BlogPulse chart, left to it’s own, is just a curiosity. If an analyst were paying attention to it, instead of just letting the system run it, and improving the validity of the data, then it is a tool because the data has an accurate and understood meaning.

Maybe I’m overly-sensitized because I just finished a site search project and am working on a report design presentation for Emetrics but it occurs to me that there are a few similarities between the approaches to site search and reports.

1. Both are designed to drive action
In search, we are providing information to our users in order to drive them deeper into the site, to purchase, to sign-up, etc. In report design we are providing information to our users that drive them to improve the usability of their site, to optimize the shopping cart process, to develop great content that users will come back for again and again.

2. Both strive to reduce huge volumes of data into manageable pieces
Search relies on an index - typically a huge flat file of all the URLs on your site that it can find along with all the associated meta data. Reports (typically) rely on a database of some kind but in the end, to goal of search and reports is to make that unimaginably large dataset understandable and useful.

3. Both are short-cuts or crutches
Reports seek to distill all that data and that learning that the web analyst has in her head to meaningful information so that the end users don’t also have to be web analysts to take action against the data. Search allows users (hopefully) to circumvent the standard site navigation in order to more quickly arrive at the information or location they desire.

We could, of course, list out some other similarities or many, many differences but the 3 statements above are concepts that I have applied equally well (or poorly) to search and report design.

The other day, Dashboard Spy pointed out Dundas - a provider of Data Visualization solutions using .net and Flash.

I took a peek at their solution gallery and about the best thing I can say is that these are polished examples. Dundas obviously went to a great deal of trouble to develop examples that would appeal to a stereo-typical marketer (wow! wouldn’t these look great in a presentaton!).

But just because a report design is polished doesn’t mean that it’s any good at conveying information. Take for example their ‘3-D’ line chart. ‘3-D’ lines are a bad idea to begin with as the prespective tends to skew the data and makes understanding difficult, but the animation also distracts and slows down (literally because we have to wait for the data to load in) understanding. The one useful bit of information in the chart is the highlight on the month of July - except we don’t know why it is highlighted - what’s so important about July?

Here are a couple of tips:
1. Don’t use 3-D charts unless your data is three dimensional (has an x,y and z coordinate)
2. Provide context (specific chart title, x-axis and y-axis labels) even if you think the definition of the data is implicit or as in the above, it’s ‘dummy data’ - context supports understanding. Without context we’re left scratching our heads, wondering what to make of it.

Post Script: Dundas’ solutons may be wonderful (I wouldn’t know) but I think their pitch (e.g. their .NET Gallery) is not well targeted. Folks who are serious about visual reporting (and thus likely to convert for the right tool) probably won’t be any more fond of their examples than I was. Always put your best foot forward.