GUI Builders Considered Harmful
Should we Beware the GUI Builder?
I came across this Hacknot blog entry today, and thought I'd like throw in my own two cents worth on this topic...
The following pretty much sums up the tone of the blog entry:
"For the benefit of those who risk falling for the superficial appeal of GUI builder tools, this article will outline the major failings of this application genre."
Hacknot goes on to list some very real problems that folks encounter when using GUI builders. Some of his examples might be a bit forced, but he certainly doesn't fabricate anything.
Hacknot's intent was to sound an alarm and warn folks from making a costly mistake, but what grabbed my interest was something quite different... the article unintentionally points to the features that a Successful GUI BuilderTM would have to incorporate.
I think that the primary mistake of the unsuccessful GUI Builder's that I have used to date is that they are Screen or Page oriented.
Many of the issues raised by Hacknot involve interactions between low-level components on a screen.
Consider the following interface panel from the Hacknot blog:
Hacknot offers this commentary:
"Looking at the above, it is immediately obvious that the "Home" and "Work" groups are so similar that they could be different instances of a custom component, with labels and callbacks parameterized differently. Will a GUI builder spot this? No. Press the "Generate Code" button and the GUI builder will happily generate two near-identical blocks of code, probably within the same class body, probably within the same class method.
But of course! Most GUI builders will not spot the obvious need for a custom component... but most programmers will. To create the Successful GUI BuilderTM, all we have to do is make it very, very easy to create custom components, and add those creations to the GUI Builder's palette.
All successful programming tools complement the skills of the human programmer (rather then over-riding those skills). In Hacknot's example, the programmer may have not recognized the advantages of creating a custom component when first designing the screen... but it would have become obvious soon after prototyping began.
We don't really need tools that spot opportunities for code reuse. We need tools that help us refactor our code once we have recognized the patterns. The one thing that us humans are really good at is pattern recognition.
How does this apply to creating the Successful GUI BuilderTM?
I think it all boils down to blurring the lines between what is a screen and what is a component. We should be able to build up sophisticated components from common atoms, and then build up sophisticated screens using sophisticated components... all without having to switch to another tool or radically shift our development paradigm.
In this respect, I think that theTapestry web component framework is a bit better then Java Server Faces. In Tapestry, there is almost no difference between a component and a page definition. In JSF it's quite a bit different (hopefully this can be addressed in the future).
Will the Successful GUI BuilderTM ever be built? I don't know for sure, but I wouldn't bet against it.