During the last couple of weeks, we finally managed to get the UI classes of the classic engine in a better shape. When you now fire up a report, you will be greeted by a nice print-preview that is sized to show the complete page, the buttons obviously work, and best of all: The progress dialog really makes sense now.

In the old days, it was hard to tell whether the report is finished or how much work will need to be done to paginate the report. The progress bar happily jumped from 100% to zero several times making the thing look all funny.

Now the progress bar runs smoothly from left to right, without jumping back and forth. But the ugly point is: We could have fixed this ages ago. All the parts where there, they just needed a couple of tiny modifications.

So why didn’t we fix this earlier?

The answer is as simple as stupid: Because we did not care. The user interface worked (some sort of), it did not crash, and no one ever complained. The last point really worries me: Why did no one state the obvious? We get feature requests for really tricky items, but no one ever stood up and said: Guys, your dialogs really suck!

And I know they do. Although I worked ages on and with them, so close that I got used to their familiar ugliness. But now, after stepping back and looking critically on what I have helped to make, its awful ugliness strikes me.

It is outright evil.

Why do we have to overwhelm the user with questions about character-set encodings?
Why do we have to show each and every screw you could tweak on the front page of the dialog?
Why do users have to care for anything else than just pointing the engine to where they want to export the reports to?

Well, I do not advocate to forbid power users to tweak all the settings they can find. And yes, the UI should offer access to these settings. (After all, I’m not a Gnome-developer, who seem to believe that even the file name input-box is way to complicated to be offered to any of their users.) But there is no need to put them in front of the unexpecting user. Let’s put them in tabs or sub-dialogs instead so that they are not visible to the unexpecting traveller. And for those installations, where this level of access is definitely not needed, lets add a configuration setting that removes these tabs from the UI. This way, stripping down the UI is as easy as placing a properties file into the ClassPath.

Lets create the best print-preview and exporting UI one can imagine. Yes, that’s what we should do.