Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!pasteur!ucbvax!decwrl!sun!pitstop!sundc!seismo!uunet!mcvax!cernvax!pan!aratar!chac
From: chac@aratar.UUCP (Chuck Clanton)
Newsgroups: comp.cog-eng
Subject: how to build widgets
Message-ID: <339@aratar.UUCP>
Date: 24 Feb 89 11:26:26 GMT
Reply-To: chac@aratar.UUCP (Chuck Clanton)
Organization: Adasoft AG, Solothurn, Switzerland
Lines: 46

i am wondering if anyone reading this newsgroup has an interest
in programmers and programming.  in particular, i have been
thinking about the following problem.  

most of the recent toolkits for bitmapped workstations seem to have
the design philosophy that interactive components, widgets, should
have an extremely high degree of customizability.  hence, one often
finds 20 to 40 parameters that can be set.  the code for such widgets
is extremely difficult to understand, and the interactions among
those parameters is extremely difficult to document and understand.
if you have programmers who are willing to build whatever widgets
that the interface designers want, i wonder if this is the right
design philosophy.  an alternative is the "inheritance by editor"
slogan-idea.  that is, if a programmer has a very simple table
widget that has 5 rows and 2 columns, that programmer can quickly
build one that has 6 rows and 3 columns.  it may take less time for
the programmer to build a new widget in the new format than it would
take a non-programmer to figure out how to set up all the combinations
of height, width, column number, column order, number rows, number
items per row, etc of the parameterizable widget.  

clearly this has the makings of a religious issue currently, and clearly 
if you do not have programmers to devote to this kind of work, you need
the parameterizable widgets.  however, i wonder what kind of data, or
lacking data, experience people have in comparing these two paradigms.
if there is empirical data, then perhaps some answers are possible.
certainly, the simpler widget is more likely to be bug free, and the
inherited code is much simpler.  of course, the well-used settings of
the parameterizable widget are likely to be bug free as well, though
the lesser used ones or unusual combinations may not work as expected.
further, debugging the parameterizable widget may be much more difficult.
also, obviously, i have chosen an extreme case, and intermediate positions
are defensible.

one point made by rob pike is that he prefers to make design choices
carefully, then not provide customizability but rather defend ones
choices or become convinced that one is wrong and change them.  this
is not an unattractive view.  further, many of the people building
highly parameterized widgets are doing so explicitly because they do
not want to make interface design decisions.  but if an interface
designer is available during the programming process, perhaps these
decisions can profitably be made.

i would be very interested in hearing what others think about this
issue.  especially but not exclusively if you have any data or experience
that bears on it.