Programmers vs. Designer

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.

This entry was posted in Non-Technical Topics on by .

About Thomas

After working as all-hands guy and lead developer on Pentaho Reporting for over an decade, I have learned a thing or two about report generation, layouting and general BI practices. I have witnessed the remarkable growth of Pentaho Reporting from a small niche product to a enterprise class Business Intelligence product. This blog documents my own perspective on Pentaho Reporting's development process and our our steps towards upcoming releases.

5 thoughts on “Programmers vs. Designer

  1. Smoodo

    I really love what you have done with this product. It keeps getting better without presenting half baked ideas in the name of sprint accomplishment.

  2. Diethard Steiner

    I think the Pentaho Report Designer is an extremely powerful tool, but certain features are not that intuitive:
    – In a lot of cases I just want a some simple tables with heading. In most cases a report designer doesn’t want to define column titles in an extra step. I saw that you are working on a new table feature, so I am looking forward to this.
    – main report canvas should be empty at start and user should be able to choose what kind of report elements they want to add (charts, crosstab, table, etc)
    – sub reports: inline editing would be a great plus. Ideally, the concept of sub reports should be hidden from the end user. It should be just report elements.
    – using subsets of the data: it’s currently a style that you have to apply for where conditions and groups to summarize. You could offer a GUI that allows to create subsets of the main query in a drag and drop fashion

    Just some thoughts … I really would like to see the concept of simple and advanced mode. I think that you could open the PRD to a wider audience and it would be far easier to start using it.

  3. Thomas Morgner

    “In a lot of cases I just want a some simple tables with heading. In most cases a report designer doesn’t want to define column titles in an extra step. I saw that you are working on a new table feature, so I am looking forward to this.”

    The table will be a small step into that direction, but there is another JIRA case that says something about “when dropping a file into details, generate a header element, and then keep them linked so that they move together”. That will sort this case out.

    “Inline editing of Subreports” is on the way.

    “Using subset of data” – that needs a JIRA case. It will fit well into the case that says: I want the reporting engine to sort my data for me. I hope to get that into the 4.1 (the one after the initial crosstab throw-out).

    “Mainreport canvas as empty sheet” – that is a bit more tricky as it works against the banded nature of the default engine. So that would be more likely in a 5.0 release.

Comments are closed.