...Removing All Doubt

Frankly I am not sure how to respond to Beware The GUI Builder. I have spent nearly all my programming career building what this article describes as  GUI builder (I have always called them designers, but that's me, I hate the term GUI). It is not often you come across an opinion piece that condemns nearly your entire body of work as worse than worthless (unless you are a lawyer or politician, that is). Let me see if I can find myself and respond.

At this point, if you haven't already, read the referenced article, if just for the clever poem. My response will make more sense that way (well, hopefully, anyway), and I apologize for my lack of a poem (well, not really; be glad I didn't try one).

"major failings of this application genre"

Don't be fooled (OK, you can be fooled if you want but I don't have to like it). This article is really just a diatribe about the short-coming of a particular unnamed Java based SWT GUI builder with passing references to Swing builders. Many of the flaws of "GUI Builders" it points out are not really faults of the entire genre, but, rather, flaws in the combination of Java, SWT, and this unnamed GUI builder. I wish the author would have named it, at least I could then verify the claims made in the piece, but I will trudge ahead anyway, blissful in my ignorance. Many of the flaws are common to a wide range of designers, but not all, and certainly not mine, of course ;-).

Reliance on Static Code Analysis

Not all designers rely on "static code analysis". Many, such as all the ones I have worked on, store the result of the designer in as a serialized image of the form. This is what code generating form designers do as well, such as WinForms, but the format of the serialization of the form is in code. I also have to quibble with the description of how the loading of the form is done, "By 'static code analysis', I refer to those aspects of the code's behavior that can be determined from consideration of it's structure alone, without regard to it's runtime behavior." I am not sure what this means. All the code-generating form designers I am familiar with have a language interpreter that can execute a subset of the serialization language. The subset is usually restricted from executing flow control logic, but not always as in Visual dBASE. The reasons for these limitations is to simplify translating gestures in the designer to changes in the code that was generated. In an example given in the article, it would be difficult for a designer to figure out the mapping between the array,

    String[] colors = { "Red", "Orange", "Yellow",  "Green", "Blue",
        "Indigo", "Violet" };

and the value passed to the setText() method in the for loop (which isn't actually there in the example, but should be). But, in my mind, this is no excuse, if the language allows it the designer should support it. My solution in the past is to use a language that only allows what the designer supports. In the case of Delphi it was the .DFM file format, and currently, in my "new" job, it is XAML. In these cases, the language is designed in such a way that it is limited to supporting only that which the designer can figure out. This is one of the several reasons I don't like the code generator style of serialization, programmers are tempted to futz with it and the will always use a feature of the serialization language the designer doesn't support. The authors has a point, Java does not make very good serialization language (nor does any other general purpose language).

Going back to the example used in this section (instead of skipping ahead as above), localization and handling dynamic values are typically where designers excel, not fall down. If you separate the logic of the form from the initialization state, you can have localizers just edit the initialization information, not your code (good reason not to code-gen, by the way). The article refers to resource bundles in "capable" GUI builders but it goes beyond that. The entire initialization state should be localizable, not just strings or what the developer might feel generous about allowing the poor localizer to fiddle with. The localizer might need to entirely reorient the form for a right-to-left language, reorganize the form in a more culturally friendly order, etc. If layout is done in code this is notoriously difficult, if not impossible, for localization teams to deal with. Most localization teams I have had the pleasure to interact with require the framework to have a form designer for these very reasons. Don't layout a form in code. Just don't. What assumption you have about how the form will look is culturally biased. Writing layout in code just makes the bias impossible to remove. Localization is a tough, thankless job. Don't make it harder.

As for dynamic values based on "male" and "female", is easy to do a one-liner, but data binding is what is really needed here. A form should follow good MVC (Model-View-Controller) principles, where appropriate, and this example screams model-view. If you have a model that controls changes the salutation options, a good class library will have a data-bound version of a radio group that will update accordingly. This is not a GUI builder problem, it is a framework/data-binding problem.

Masking Understanding and Inhibiting Learning

This whole section is arguing against a false premise. No designer, ever, was written with the idea that the user would never have to code again. (Well, I have to admit, the marketing teams for them often have said that, but they were lying). Good designers are written to smooth and facilitate the transition between designing a form and writing code, allowing the user to do those things that are better done in a designer in the designer, and leave those things better done in code, done in code. They also where never intended be the only way you learn the framework (although they do help a lot) or take the place of good framework knowledge. Their job is to make using the framework easier, period. The author has a good point, most of your time is not spent in the designer, you spend most of you time in code. That is when the designer really shines, when you don't have to use it much to get the job done.

"How do you visually represent these infinitely variable sets of constraints amongst components, and in such a way that they can be configured with mouse clicks and keyboard operations? The answer is 'With great difficulty'."

This is a criticism of frameworks, not designers. The framework should present a model where this is straight forward. The designer should make using it easy to use and easily discoverable. Also, remember, doing this in code might be easier for you, it just makes other people's jobs impossible. You are not the only one that needs to control the layout of the form. A localizer might have a different idea of where the OK button should go. And, to be blunt, if your code has "infinitely variable sets of constraints" on anything, you should consider a different line of work.

Missed Opportunities for Reuse

I covered most of this above, use data-binding; understand data-binding; love data-binding. The second part, the address form example, is a job for nested forms or data templates. Each of the address should be a an instance of a single nested form or data template (depending on the framework you choose). This is where data-binding shines again since moving data in an out of controls is what data-binding does. This is a case where you shouldn't need to write much code. The code is shared if you use the sharing techniques provided by the framework and the designer.

Dependency Upon Another Tool

Ideally the framework and the designer come from the same company and are rev'ed at the same time. If you get your designer from two different places, the author has a point. In my opinion, the designer and the framework should be developed together with full knowledge of each other. In Java, these are typically provided separately for reasons I will never understand.

Signs That Your Predecessors Used A GUI Builder

Most of these are either artifacts of code generation, covered above, or just signs that your predecessor didn't leave because he wanted to. You can write bad code in any language and and using any tool. These are common problems, granted, but well written code is not common. As a retort, here are some signs that your predecessor didn't use a GUI designer,

• The form looks hideously ugly; something only a Unix user would love.
• You are considering rewriting it because you cannot change it without breaking something in the layout.
• There are dead spots, places where the controls are obviously missing on the form. This happened because it was just easier to hide the control than figure out how to re-layout the form or because the predecessor forgot to save the "prototype".
• Your not sure the form you are looking at in the UI or what code creates it.
• The localization team curses when your predecessor's name is mentioned.

OK, so mine are not as witty...

Conclusion

They have some utility for mocking up interfaces. You can create static "snapshots" of your interface and show them to users, perhaps employing printouts of them as paper prototypes.

This is truly damning with faint praise. If this is all you use a designer for, go get a better designer. Seriously. They exist and hopefully you now know what to look for in order to find a good one.