John Reynolds's Blog

GUI Builders Considered Harmful

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'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 Builder^TM 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. "

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 Builder^TM?

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 Builder^TM ever be built? I don't know for sure, but I wouldn't bet against it.

Comments

• I guess there are two main points:

  1. In all the years of GUIs, none are really all that great (so, it's at least hard if not impossible to build a Successful GUI Builder)

  2. If such as great GUI Builder were to exist, would it be better than hand-coding?

  GUI builders assume that much of the effort spent building a screen/dialog/whatever is in deciding where the components go and making them go there. While GridBagLayout certainly can make that process difficult for a beginner, there is so very much more to building a gui than layout, and that is where GUI builders just plain suck.

  Posted by: davetron5000 on July 25, 2005 at 02:22 PM

• Regarding better component reuse. Check out JSR-273, it's slated to adress just that; making is easier and more standardized to create components that work in a GUI builder.

  Cheers,
  Mikael Grev
  

  Posted by: mgrev on July 25, 2005 at 03:02 PM

• Dave wrote:"GUI builders assume that much of the effort spent building a screen/dialog/whatever is in deciding where the components go and making them go there."

  I'm thinking much more along the lines of Visual Basic, where the "GUI Builder" does much more than component layout... like clicking on a component to edit its event handlers.

  I used to make fun of tools like VB... until I met a VB programmer who could generate pretty good applications in a third of the time that it took me to create the same functionality in Visual C++.
  Of course I had much more freedom in C++ than the VB programmer... but in the end my nifty UI code was packaged in (you guessed it) a VB component.

  Live and learn,

  --John
  

  Posted by: johnreynolds on July 25, 2005 at 05:23 PM

• 
  "I'm thinking much more along the lines of Visual Basic, where the "GUI Builder" does much more than component layout... like clicking on a component to edit its event handlers. "

  JBuilder has done that always (or something very similar, you select the event handler to edit from the component properties et voila one event handler).
  Works well, but still not quite smart enough.

  I think Netbeans does it too, in some way.

  The problem isn't things like that, most GUI builders can handle that quite well (and nowadays often even allow manual modifications to such code and still recognise it).

  My main gripe with GUI builders (apart from the often crappy code they emit) is educational.
  Students learn to use a tool, not to use the language features.
  When they get confronted with another tool (or worse yet, have to do without a tool) they can't.

  This isn't a problem of just GUI builders but all code wizards, generators, and somesuch.

  Just read any Java (or C++, or whatever) forum and see the amount of questions from people who don't know what a classpath is, or how to launch a program outside the editor environment (or how to compile something).

  Usually there's someone stepping in advising they switch to the responder's favourite IDE which will cure all their problems (but of course it won't, it hides those problems to a later date).

  Such people DO get hired as programmers, and then become a liability for their colleagues who have to work overtime to do the work that poorly trained person was supposed to know when hired.
  Indeed a person who knows what he's doing would in the example create a component and place 2 instances on his form, but that requires independent creative thought and learning the technology behind the shiny tool, something that using that tool is designed to hide and prevent.

  Posted by: jwenting on July 26, 2005 at 01:17 AM

• I used to hate GUI builders in Java, but this changed for me recently after playing with the latest Netbeans releases and I'm currently developing a large GUI application using a GUI builder.

  I am a very experienced developer and I can build GUI manually at least as fast as I could use a GUI builder tool, so why would I use this tool?

  Maintainance and work with the designer, when I work with the designer we can prototype together and communicate more visually. Maintainance is simpler (as long as I keep using the tool, which is free/open source), since I can actually "see" the code.

  There are several missconseptions about GUI builders:

  1. They don't considerably speed up development, they do speed up visual design and tweeks that matter quite a bit when you want to productise something. If you are both an expert Swing programmer and a person with a keen sense of esthetics then welcome to a very rare club (I have a terrible sense of style). Most of us need the help of someone who is not a programmer and going back and forth with compile run cycles with these guys tends to consume time.

  2. 2-way tools are EVIL! Delphi/C++ builder use special hints and VB doesn't even let you see the generated code. JBuilder constantly broke down when I tried to change some trivial things and it couldn't recover (so did Sun's Java Studio Creator). Netbeans made a hard yet briliant choice of generating code into locked sections, this is a tool that is MUCH harder to break in normal development.
  Better yet, by default the generated code is folded and so you don't have to see it.

  3. Bad code generation is a valid claim but really pointless. So the GUI builder generates another useless component so... Most of the performance issues for Swing are in the model and not in the view. Netbeans lets you insert model code and custom creation code for every component. I don't mind is the code is just dumb in these hidden away sections, it only becomes a problem if I stop using the GUI builder and since I am relying on a freely available tool...

  4. The example in the article with dynamically changing the radio buttons is just WRONG in terms of UI design! You should never change a UI, at most you should make the component disabled or better yet for this particular case... Use a combo box. If you insist on doing this you can do it with a GUI builder by setting radio buttons to invisible, yes you will have more code/widgets but why should you care if its just a few clicks to accomplish and won't cost all that much in performance/size.

  
  I think that GUI builders are a matter of what you expect. You still have to know Swing IN DEPTH even though you are using a GUI builder, they won't help you there. It probably won't shorten development time considerably and the code won't be unique. You will probably be stuck with the tool for the remainder of the projects life cycle.
  If you can live with the above then there are benefits in working with design personel and customization along the way that make GUI builders a nice choice.

  Posted by: vprise on July 26, 2005 at 07:55 AM

• I read the hacknot article and agree about the problems he has seen as being standard problems many GUI builders have.
  Therefor I am even more frustrated since I have been shipping a solution that solves each and every one of his problems for more then 2 years now; its even open source and free. But apparently its not really widly known...
  See the 'designer' page on uic.sf.net

  Posted by: zander on July 26, 2005 at 10:48 AM

• Borland Delphi introduced visual component inheritance in version 2 or 3. It was... 1996? 1997? A while ago, anyway.

  Posted by: michael_jouravlev on August 12, 2005 at 12:38 PM

This work is licensed under a Creative Commons License.