Why I generally avoid GUI Builders

How’s that for a non committal title (c:

Most of my own thoughts have been better explained by others.  Beware the GUI Builder is an excellent article on Hacknot, and a response by Karsten Lentzsch to this post sums up the design issues well (search for “Karsten Lentzsch” and you’ll find his comment).

The meta design issues described by Karsten are a major sticking point for me. The implication is that if you use GUI builders and your UI design requires that the label/component gap be 4 DLUs, or that section titles should have 12 DLUs of top padding, then every developer must know every rule and ensure they implement it correctly on every form. You will have problems.

Custom layout builders on the other hand don’t generally suffer the same fate. They’re able to capture the design rules in one place (i.e. the DRY principle) and your developers can live blissfully unaware of the nitty gritty requirements or implementation issues.

For larger projects you can also specialise the builders and integrate them with other infrastructure such as a binding or command framework.

//  a trivial example that doesn't really make sense.
SimpleFormBuilder b = new SimpleFormBuilder();
b.setFormTitle("My Cool Form");
b.addTextField("First _Name", firstNameValueModel);

Of course the real problems with layout builders is that you have to design and write them, and there will always be cases that break the rules. You can minimize this pain however if you start with a decent builder and layer your architecture so developers can drop down to “manual” for the edge cases.

This then is the real issue for me: if you only have a few static screens, then a GUI builder is probably an acceptable option, but once your project grows you’re heading for trouble.

This entry was posted in Development, UIs and Swing. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *