Random Thoughts

Why can’t we just draw our own reports?

Here’s a way-out thought I had over the Xmas break for a new approach to building BI reports….

Have you, when you’ve asked a typical non-technical business user what they want a report to look like, asked them to draw a quick sketch? I do all the time – I find seeing what the user wants the report layout to look like is much the best way to understand what they want and for the user it’s the best way to express their requirements. So on the back of the proverbial envelope you’d get something like this:


…and then go back to your desk and write the query and design the report layout in something like SSRS. So – why can’t we cut out a step and go direct from the sketch to the report design? I can see two options for the first step here:

  • Using a tablet PC you write some software that works a bit like OneNote, but where the user can draw the outline of a report freehand. Unfortunately tablet PCs just aren’t that common and the really tech-phobic end user wouldn’t feel comfortable using one.
  • The user draws the report on paper and then the drawing gets scanned; definitely something the most computer illiterate manager would be comfortable with.

You would then take the freehand drawing and:

  • Interpret the freehand lines into the borders of a table, and
  • Interpret the text on columns and rows as either
    • Explicit selections of members, or
    • Set expressions
  • Apply a lot of smarts to format the report in ways that conform to the best practices laid down by the likes of Stephen Few et al. Almost no business or IT people (me included) have any idea on how to format reports properly, and while you could argue that this might be intrusive I think users would appreciate a tool that did this for them.
  • Apply a standard corporate template, with the appropriate logos etc in place.

Working out what the borders of a table should be from a freehand drawing must be possible (although implementation would be well beyond me). Interpreting what the user has written they want on columns and rows would present more problems:

  • Handwriting recognition is notoriously difficult to do well, and usually the software needs to have a bit of practice to get good. On the other hand, in this particular scenario it should be easier because the user won’t be writing just any old text. For instance, if we assume that we’re working with an Analysis Services data source, we know that any text is either going to be the name of a member or something that will resolve to a set expression; we also know, for instance, if there are what look like multiple member names on the same position on the same axis they will all have to come from the same hierarchy.
  • Resolving text to member names is all very well, but turning sentences into set expressions would be trickier. It seems reasonable to think that phrases like "Products where sales is greater than £100" could be interpreted effectively, but whether your average business user can write something as clear as that is debatable. Any tool would certainly have to prompt the user to confirm that the interpretations it has made was correct, and do to that it would have to resort to the kind of techy interface that the tool is trying to get away from.
  • Similarly there are going to be ambiguities that need to be resolved when looking at a the design. For example, the drawing might have the years 2006, 2007 and 2008 on columns. But does this mean the report should always have these three years on columns, or the last three years with data, or something else?

So it certainly wouldn’t work like magic, but at the same time I think it would offer some advantages over current report design tools, the designers of which have fallen into the trap of building a UI on top of the functionality they’ve got  available in MDX or SQL, rather than building a UI for what the user actually wants to do. After all, don’t you think that it’s actually very difficult to lay out anything other than the most simplistic reports in most report design tools, compared to how easy it would be to draw the report?

One thought on “Why can’t we just draw our own reports?

  1. Good (out-of-the-box) thinking with focus on layouts. But I feel that equally important items for report design are:1) Use Case or Reason For Existence. Usually the business case for the entire reporting project is known and defined. But when it comes down to defining individual reports, the number of reports "that we must have" starts to increase. And then plod thru the requirements definition with the demotivating thought that "this is yet another report that nobody will look at after UAT." So, I\’ve started to prod the end users with "who-when-why" -questions to provide a use case for the report in question. This usually yields good insights into the end user\’s day-to-day business processes and help in creating solutions that better match the actual business need lurking behind an individual report request.2) Lack of common (platform-independent) design methodology for reports. I guess the common methodology is to draw the reports in Excel, but that method usually fails in catching the "devil-in-details" of user requirements. Likes of the "oh, but this should not include accruals" or "average sales price per year is calculated as arithmetic average of monthly ASP\’s". I\’ve thought about doing it thru "test cases" with a given set of source data and then asking users to provide expected results for each report with that data — but never actually done that.Cheers,-Harri

Leave a ReplyCancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.