I recently stumbled across an interesting article about the interaction between designers and programmers at the #AltDevBlogADay:

Designers are fundamentally interested in the properties of the end result – the visible ‘outer shell’ of the product. They don’t care about the technology inside it, beyond the observable effects (like it being fast enough, not crashing, etc). Their descriptions of the product, and how it should be, are thus all written in terms of these visible properties: which things the player experiences, when and where the player experiences them, and so on.

Programmers, by contrast, are focused on the internals of the product – they are tasked with filling in the gap between the outer shell provided by the designers, and the solid core of functionality provided by the platform. It’s like a translation process – translating high-level game concepts into low-level hardware operations – and so their explanations are in similar terms: which lower-level concepts are in use, how they are combined into large structures, and so on.

I work on the Pentaho Report Designer at day time, so I know the programmer’s perspective all to well. The report designer, I have to admit, is full of programmer level references and low-level nudges and screws. The Pentaho Report Designer is explicitly targeted as a power-user tool. Its primary purpose is to make all features and all attributes and styles accessible so that no one ever has to go down into a XML editor to create a particular report definition. And hey, we were successful in that respect. If there is a way to do something with the reporting engine, then today’s report designer enables you to do it.

In dark and moonless nights, however, my other, sinister side comes to life. I turn into a designer myself. Over the years I accumulated a few projects at the side where I needed to either create some artwork or plain web-designs for myself or those close to me. The mind set of me as a designer is indeed different – its the what instead of the how that matters most.

When I look at the Pentaho Report Designer with Programmer’s eyes, then well, we are almost there. Feature wise we move more and more to the advanced side of the universe. Once native cross-tabbing and multi-column support is included we actually match the much more expensive tools feature check-box by feature check-box.

But it is not about features.

Healthy discontent is the prelude to progress. – Mohandas Gandhi

Looking at the Report Designer with the Designer Head on, I see by far more areas that we need working on. Right now, designing a mildly complex report requires me to switch between data-views and design-views, subreport-contexts and various dialogs and long lists of meaningless attributes – and each time I have to go back to make changes, I have to think about “how” instead of “what”.

The good thing: Once we have recognized what is wrong, we can fix it.

Over the last few weeks, I brought in a couple of smaller changes to make my life easier. Here are a few of my favourites:

• A new colour chooser:

  Java’s built-in colour chooser is a great example of engineering. It does exactly what the spec says, but those who implemented apparently it never actually used it beyond simple “yes, works!” tests. For me, getting to the right colours was just plain painful to do. It really made me wonder why none of our users ever complained about it.

• Hiding and Un-Hiding Elements from the design view:

  Another example of engineering gone bad: to hide a element, you have to select that element, go into the attribute-view, locate the hide-on-canvas attribute, select the value, and finally select “false” in the selection-box that appears. Takes me about 10 seconds.Right-Click on the element and select “Show In Design View” from the context menu: 1 second.

• Selecting fields in elements and groups:

  With the new version you can see all the fields at once, and a double click selects these fields and brings them into the selection.

• Expert and deprecated options hidden:
  The list of styles and attributes on the various elements can be daunting. When I edit reports, most of the time I start searching for the properties again, even though I work with the tool for years now. So lets cut back the chaos – expert options are hidden now until explicitly asked for. And deprecated stuff is not for use anyway – so why show it?
• Convert any data-source into a table-data-source

  It was never easier to make your reports into completely static ones. Great for creating replication cases for bug-reports too 😉

• I added a screen-shot tool that captures either the current dialog or the complete desk and saves it as PNG in your home directory. That alone saved me a few hours while writing blog entries.

Personally, I have a hate-love relationship with the style and attribute tables. They are needed to expose all the settings, but they are neither easy to use nor a great help during the design process. One of the more older cases from before the initial Citrus/3.5 rewrite is PRD-871. It proposes to create a special property pane that hides the complexities of these generic tables and that brings the most commonly used properties together in a designer centric way. I am still itching to get this thing started.

For me 2011 will be a good year, if crosstabs hit the road running and if I can make Pentaho Reporting 4.0 a user-friendly designer that even mom and pop are able to use. To make that happen, I need to understand better, where we are doing good and where we should improve.

And for that I will need your help:

What works great for you when you use Pentaho Reporting? What are the features you cannot live without any more? What are your pain-points when you design reports? What features do not live up to your expectations? How can we improve?

Either tell me here, discuss it in the forum or come and give me a new case in our JIRA system.