GUI builders considered harmful (Was: anygui,anydb, any opinions?)

[Mike Meyer]

"Thomas Bartkus" <tom at dtsam.com> writes:
> "Paul Rubin" <http://phr.cx@NOSPAM.invalid> wrote in message
>> Are we talking about a drag-and-drop GUI builder?
> I am!
[...]
> I happen to be one - and I *know* I'm not alone - who thinks that building
> user interfaces is way too difficult and way too important.  It is
> particularly frustrating in that we do seem to be moving backwards in this
> department.

"What GUI builder should I use", or similar, is a common question on
c.l.python. I'm a curmudgeon, and don't like GUI builders - so I avoid
them. While normally that wouldn't cause me to encourage others to
avoid GUI builders, I think they have a worse problem: they encourage
the delivery of applications without flexible, robust user
interfaces. In short, the help produce inferior applications. While
this isn't strictly a python issue, c.l.python is where I run into it
- so I'm bringing it up here.

Now, I'm not an expert on GUIs, GUI toolkits, or GUI builders. I've
used some of each, and draw my conclusions from that admittedly small
sampling. Possibly there are other samples that don't have the
problems I describe. Part of the point of posting this is to expose
these thoughts to others, and find out what I've overlooked. I'll
return to these points where appropriate.

What the user deserves.

I'm going to take a side trip into what constitutes a robust, flexible
user interface - which is what I believe the user deserves. Please
bear with me. By robust, I mean the user interface should adopt to the
environment it's being run in. Windows that don't fit on the screen
are simply unacceptable - but all to common if you use a very small
screen resolution. By flexible, I man the user should be able to
adjust the UI to suit their viewing conditions - the DPI on the
screen, the viewing distance, and their possibly aging eyesight.

I use two systems with graphical interfaces, and both are a bit out of
the ordinary. You might even call them extreme. One is a 1600x1200
desktop on a 21" monitor viewed from about 18" away. The other is a
640x480 desktop on a 53" monitor viewed from about 10' away. Even
those these are on opposite sides of "normal" users systems, they both
suffer from the same problem - out of the box applications have UI
elements that are unreadably small.

The obvious solution would be for the system to detect all these
environmental factors, and scale the applications
accordingly. However, things like viewing distance and the quality of
my eyesight are hard to detect automatically, and it would be a pain
to have to enter all those things manually. Since the end result of
all these is a single factor - a UI scale factor - a system wide knob
to scale applications would seem to be the solution.

Note that this is *not* an easy thing to do. Anyone who's tried
scaling bit-mapped fonts will tell you you can't simply scale something
and expect it to look good. Scalable fonts have "hints" and other
goodies in them so they look good as you scale the fonts up/down. This
may be why, but most windowing systems don't seem to do provide a
global UI scale knob. X certainly doesn't. Windows has a limited
capability to scale fonts system-wide, but it doesn't work very
well. OSX seems to have a system-wide display DPI setting one can play
with, but it's not clear how well that works. NeWS and NeXT could
probably do this, but would seem to have a negligible to nonexistent
user bases. rio seems capable, but the typical rio UI is ugly even by
my admittedly low standards.

Failing the single system-wide knob, a flexible application should
have allow the user to scale the application with a single knob. This
is hard to do with modern GUI toolkits. I do it by using text for
imagery in the UI, and having a scaling factor that is applied to the
font sizes. While I prefer text to graphics for UI elements, that's a
rant for a different time. I'll concede that such an interface is
probably unacceptable on a modern commercial application - users now
expect graphics. But how many GUI toolkits let you use a scalable
graphics format (SVG, PS, etc) for images in the UI? My predilections
have kept me from looking closely, but I certainly don't recall seeing
any in the GUI toolkits I've looked at.

I claim it's obvious from this what's wrong with GUI builders. But I
want to look at what I, as a developer, want from GUI development
tools before going into details.

What the developer wants.

Ok, what I mean is what *I* want. But I don't think I'm that unusual,
so I'm going to generalize to other developers as well. I'll point out
what has to be different for this generalization to fail.

First, I'm not a graphics designer. While I've studied page layout and
typographical design, and read Tufte's books on design, I'm a *long*
way from being a good graphics designer. I know even less about the
field of human-computer interactions. Hopefully, a good GUI library
will have had people on the development team who do know something
about these fields. In this - the desirable - case, the library should
have more knowledge about good UI design than I happen to posses.

Given that, the more I can depend on the library to do for me - the
less I have to specify - the more likely I am to produce a good UI
with that library. Conversely, the more I have to specify in the GUI
development process, the more likely I am to screw things up. I claim
this statement should hold for most developers, unless they happen to
be experts in the fields of graphics design or human-computer
interactions.

What's wrong with GUI builders.

Ok, *now* we're ready to deal with GUI builders.

The first, and most obvious, thing that GUI builders do is force the
developer to specify an exact position - if not size - for the
graphical elements of the UI. Better GUI libraries don't do
that. Instead they let the developer specify the position as part of
the overall structure, say as "the third button in the second toolbar
from the top", or "one of two buttons in a toolbar running across the
bottom of the window". This latter allows the knowledge of the library
designers to dominate the design, hopefully producing a better UI than
the you get from your typical software developer.

The GUI builder might provide an advantage if it allowed the GUI
design to be cleanly separated from the underlying code, so that a
specialist in UI design could do the graphics design, and then the
developer could come and add the underlying code. However, the GUI
builders I've dealt with require specifying names for the various
elements of the UI, which names should make sense in both
environments. This would seem to defeat such a split design, but I've
never tried it, so I can't say for sure.

Further, look at the kind of interface the GUI builder gives you. The
position of all the elements are nailed down. This makes it hard for
the GUI to adopt to the extremes of display environments that you find
in the wild. The GUI builders I've used made it hard, if not
impossible, to build an application that can scale the GUI to meet the
users needs. In other words, the GUI builder helps build applications
without flexible, robust user interfaces that are inferior to what can
be built using a GUI library.

Typically, I don't find a GUI builder that much faster than a good GUI
library. If I have to specify pixel positing for elements, the builder
will be a win, but if not, then not. So I haven't examined all the GUI
builders in depth. Maybe there's one out there that will let the
application developer scale the GUI when the application is invoked,
and will re-arrange elements of the GUI so they fit on the screen
properly. If so, I'd love to hear about it.

          Thank you,
          <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.