After reading a couple of reviews (notably by Stephen Few and Nathan Yau) of The Wall Street Journal Guide to Information Graphics, I picked up a copy myself out of curiosity.

For the most part, I agree with Stephen Few's critique of the book, but his vantage point is as an expert in the field. In author Dona Wong's defense, it's hard to write a book for newbies and present do's and don'ts that won't ruffle the feathers of anyone who knows better.

Being in BI, I see a lot of crappy reports with poorly chosen graphics. And many of these are coming from "seasoned veterans" in report writing. The problem is that "seasoned veterans" in report writing only means you really know how to use the tool, not necessarily how to communicate quantitative data visually.

I think that this book, despite its many flaws (Wong almost had me in a tizzy by referring to "sans serif" fonts as "sanserif" - that's as heinous as a Freedom Fry), is ideal for one particular audience. And that is people who have no knowledge of visualization, and who do not have the will or the patience to learn.

The book has two key strengths for newbies:

1. Everything is in bullet points (ideal for the attention challenged)
2. Wong's rules-of-thumbs are pretty black and white (ideal for the critically thinking challenged)

One glaring weakness, however, is that while the images in the book are lovely, they weren't really created by real world BI tools. You're not going to be easily able to reproduce these charts and graphs in Cognos Report Studio or any other tool to match Wong's aesthetic.

Stephen Few's books are easy reads, but only a small percentage of the people to whom I recommend his books actually read them (sadly, I think the reason behind this is that too many people just don't seem to care enough about their "craft" to improve). Edward Tufte's books contain prose that requires a significant amount of patience, and are much more appropriate for true believers than newbies.

Bullet points and "black and white" rules be damned, I think this book should be read by anyone who designs reports in Cognos or any other other BI tool. It's about 100 times better than what is usually described as "the most popular seminar each year" at Cognos Forum, where the presenter talks about Few and Tufte, and then goes ahead and presents the one of the most horrible PowerPoint decks I've ever seen.

If we're lucky, people who start with this book will develop an interest in visualization and then actually read something meatier like Information Dashboard Design or Beautiful Evidence.

I first heard about Palo last year after finding a thread on OLAP Forums in a Google search for open source Cognos TM1 alternatives.

While I did download the software last year, I didn't get around to installing it. Jedox recently released version 3.0 of the software, and I've just started looking at it.

I really have to say that I'm impressed, and I've only scratched the surface. The documentation is professionally written, complete, and best of all, free. Palo also offers a web-based spreadsheet interface that is super-polished (to me, it's significantly nicer than TM1), and offers a nice selection of charting features, including microcharts and analog gauges (which I'm not a fan of, but there's no accounting for taste).

The Excel plugin has a similar feel to the one provided by TM1 as well.

I haven't been able to dig deeper, because I'd like to use a different data set from the provided sample, but I'll get there soon.

While I'm not ready to give this product a thumbs up, based on my cursory experience with the tool, I do strongly suggest that prospective TM1 buyers take a close look at this tool. At the very least, you can use it as a negotiating chip when you start talking about the pricing on TM1.

When I'm disparaging a piece of software's user interface (in the past few years, that would be Cognos products), I often describe the product as having a "programmer's interface".

The rationale behind my pejorative use of the phrase roots back to my experience in "enterprise development" shops where the software was designed by the developers, not by someone with field experience or familiarity with the needs of the target users. Most enterprise software developers just like to code, and that means building cool algorithms. The user experience is often just an afterthought.

Granted, not all programmers are inconsiderate of their users. After all, one of my favorite programmer personas, Joel Spolsky, wrote a wonderful book just for programmers to teach them how to design user interfaces.

Programmer's interfaces are usually the resolution of a technical issue in an environment where expedience is valued over careful thought.

Bigwigs like to talk about ease of use (here's my snarky response to that), but usually senior managers in enterprise software companies don't really spend a lot of time eating their own dog food.

In the development scenarios that I've been a part of, the teams that build the software are more often populated with architecture astronauts at the top of the food chain and pure coders at the bottom. The real problem lies in the fact that there are often no team members with actual field experience. That is to say, nobody who actually uses the tool that is being developed, in the real world, to provide some insight into what real users want. The result is software that succeeds in a technical capacity, but fails in a human context.

Now note that I've been careful to use the phrase "enterprise software", and not "consumer software". They are two completely different beasts, targeting two completely different types of markets. Consumer software tends to be better at avoiding the programmer's interface than enterprise software, mainly because they're trying to please Joe Sixpack. Enterprise software targets IT managers and other stakeholders who are buying based on Feature Checklists, and not Feature Excellence (two terms that I'll outline in a subsequent post).

The sad news for buyers of enterprise software is that they accept programmer's interfaces as a fact of life. My hope is that you'll see startups and open source projects shake up the industry and make usability a competitive advantage.

Sadly, I'm not holding my breath.

Just a quick post about what type of file you should use when modeling Cognos Transformer cubes. I know the old school thinking for Windows based Transformer users was to use PYI or PYJ, but here are some reasons why I think you should use MDL instead.

• The performance gap between cube builds using PY* and MDL has narrowed significantly over the years.
• Ever get a corrupted PY* file? 'nuff said.
• MDL is a pure text format. That makes diff comparison easy when you are using source control or a tool like WinMerge
• MDL files now contain encrypted user information.
• MDL files are cross platform.
• MDL's can be parsed using a tool like Pentaho to create cube model documentation (assuming you have good habits and documented everything within the model).
• Remember the fiasco when Transformer moved to PYJ and you couldn't load a PYI? Well I do.

Just my two cents. Your mileage may vary.

Something of note, that I've been whining about for years. Cognos 8.4.1's Report Studio now plays nice with Firefox. It doesn't appear to work with Webkit-based browsers like Safari (even if you change the User-Agent), but at least there's no longer a lock-in requirement with Internet Exploder.

I would love to see a standards compliant Report Studio using open frameworks, but having been in the enterprise software racket, I know how product managers and developers think. Vision, usability and feature excellence usually aren't in their vocabulary. Marketing and Sales drive the feature checklists that make up future releases. Wishful thinking for me.

Beyond the obvious size and resources, I don't consider my one-man shop much different from any other company.

My business collects its own performance data, and if I don't keep track of it, I'm a little lost.

So while a full data warehouse is probably overkill for me, a mini-warehouse is quite useful.

The last time I was an independent contractor, I ran my business on Excel. Accounting, invoicing, you name it. In the past seven years, the world has changed a little. There are plenty of free, "in the cloud" applications that a small business like mine can take advantage of. And, of course, if I grow large enough, I can buy more capacity.

So let me give you an overview of how I run my business so that you can get an idea of what my data needs will be.

Accounting

I use Freshbooks to do my billing as well as my time and expense tracking. It's a nice little app, grown locally in Toronto. When I was with my last job, I used Harvest, which is also an excellent app. Because we had a billing solution in place, Harvest was a more appropriate solution. Freshbooks will even send out snail-mail invoices for a nominal fee.

KPIs

• Billings (Dollars and Hours)
• Utilization
• Expenses Incurred
• Age of Accounts Receivables

Reporting

• Income Statement
• Balance Sheet
• Cash Flow Statement

Work Management

Fogbugz is the cornerstone of my operations. I use it for tracking knowledge, tasks and all sorts of useful things. At the atomic level, every activity at Braintapper is rooted in a Fogbugz case.

KPIs

• Number of open cases
• Average age of open cases
• Number of recently closed cases
• Time spent on cases
• Estimation accuracy

CRM

I use Highrise for CRM. I only need to track very simple things like new leads and activities. Most actual deals and tasks still get managed in Fogbugz. I don't really think I'll ever need to upgrade this account, since I don't really need the additional functionality.

KPIs

• Number of new leads
• Close percentage
• Pipeline size

Reporting

• Pipeline
• "Tickler" list

Putting it all together

So, as you can see, even for a one-man shop, I have a list of analysis requirements that is pretty typical for a consulting company of any size. And, these are just my initial requirements. I haven't even talked about joining any of my data sources together yet.

ETL

So the solution to do my data extraction is relatively easy. It's going to be a hybrid of shell scripts and Pentaho Data Integration. All of my solutions above provide a REST API, which makes for easy data extraction using curl statements.

Some of these statements are easily handled in Pentaho, with the exception of Freshbooks. Freshbooks requires a POST with an XML payload, and the "Execute a process" step seems to have trouble with spaces in the payload. No worries, a 3 minute shell script can extract all my Freshbooks data into XML to be handled by Pentaho.

In terms of databases, I basically stage the data into a staging database, and subsequently clean and transform the data into my mini-warehouse. Easy stuff.

Reporting

So, what is my Reporting solution going to be? Being a Cognos developer, you'd think Cognos would be my solution, right? Wrong. Cognos is not cheap, and there's no "free" version comparable to what Microstrategy is offering. Even if I did have cash to spend, the fact that Cognos only supports IE for the advanced studios is a dealbreaker.

Speaking of Microstrategy, that one's off the list too. Nothing against Microstrategy, but it requires a Windows server, and I'd rather have a solution that runs on any platform.

Pentaho does have a reporting solution as well, but to get any decent documentation, you have to buy a server maintenance license. No thanks. After I did my Dashboard exercise, I realized that it took me just as long to write a dashboard from scratch (and that wasn't much time at all) as it would for me to fine tune the exact same report in Report Studio. What?

Report Studio is one of those 80/20 tools. You can get your data and raw layout done very quickly (80% of the task in 20% of the total time), but the remaining 20% (and 80% of the total time) to get "pixel perfect" (I'm using this term very liberally) is time consuming. The easy response is to deliver a substandard report that has all the data there - I know plenty of people who will call it a day at that point. Myself, I would rather deliver the maximum amount of quality in a reasonable amount of time.

If I have to deal with a clunky interface, I'd rather write my own code, thank you. So what I'll be doing is basically a simple web app using the open source CodeIgniter framework, jQuery, and the Google Charts API. The coolest thing is that I'll probably be able to get my reports done quite quickly, with very granular control over the appearance in a short period of time.

Development

So as I develop my solution, I'll be posting some of the tips, tricks and hurdles that I encounter. I've already built out my ETL, which took less than a day. While I might complain about the one Transformation step that didn't allow me to do my entire ETL in Pentaho, it offers more transformations out of the box than some very expensive, name-brand ETL solutions... for Free (as in beer) no less.

In the coming weeks, I'll try to post information with respect to my dashboard design process as well. Keep in mind that design is not the same as esthetics. In business intelligence, the design of the dashboard is absolutely critical.

A great dashboard always has the right information, concisely summarized, and intuitively placed.

This is much easier stated than done.