[Edu-sig] modelling objectoriented grapical user interface with and for beginners

[Kirby Urner]

Thanks for your interesting post to edu-sig.

There's always the tension between exposing students to existing 
paradigms, the way things are done today, vs. trailblazing something
new, which may be the wave of the future, but doesn't provide 
experience in the so-called "real world".

Many people today first learn to think in object-oriented terms
in connection with writing GUIs.  They come to think of screen
widgets (controls) as your paradigm "object", which are in turn
instantiations either of "foundation classes" (classes which ship
with the product/tool) or subclasses thereof, perhaps user-defined.

The standard GUI for designing GUIs features a palatte of controls
on a floating toolbar, which the developer drags to a canvas.  The
painting metaphor is uppermost.  You don't have to know much 
programming at this level -- it's more about the aesthetics of 
screen design.  Books like 'About Face: the Essentials of User 
Interface Design' by Alan Cooper 

      http://www.amazon.com/exec/obidos/ASIN/1568843224/

help to familiarize people with standards and pitfalls (ugly or 
cumbersome GUIs, e.g. idiosyncratic dialog boxes, are all over the 
place, including built right into various OSs -- Windows NT springs 
to mind).

However, you have to know your toolset pretty well to realistically
plan for the behavior of the various gizmos ('gizmo' is a technical
term in Alan's book -- like widget) -- which is where the programming
comes in.  Typically, the programmer will define behavior by write 
snippets of code that tuck into labeled compartments associated with 
specific events (click, resize, lostfocus, interactive change, mouseover,
mouseup...).  Sometimes this behavior-defining, event-responsive code 
is bound to a control by means of "event listeners" (Java), or 
by "callback functions" (Python + Tk).

In Microsoft products, the controls come with lists of properties and 
methods.  Among the inherited methods are those automatically triggered 
by specific events.  If you put code in those places, it'll get executed.  
If you leave 'em blank, the parent class methods (default methods) will 
take over -- which in many cases means no response at all (e.g. if you 
don't put code in a 'click event' area, then nothing will happen if you 
click the button -- other than the graphical/rollover response of a 
"depressed button" image replacing a raised button as long as the
mouse button is depressed -- perhaps with an audible "click sound").

There are a couple of important tends in GUI design.

One is to use HTML, and, by extension, XHTML and XML to encode control 
panel information. The browser then becomes the application interface.  
IS people like this because the browser itself is the only distributed 
app, while the look of the panel is controlled on the server side by 
the various text files.  No going around to each workstation to install
the latest forms, nor any downloading of the latest application 
executables over the intranet (with all the versioning problems that
entails, if users fail to keep pace).  Here's a product which uses the 
browser as a GUI front end -- the client paints a screen and a generator 
translates this to HTML:

       http://www.udms.com/explorer.htm

Another trend, in some ways at the other end of the spectrum, is to 
design highly stylized GUIs which break away from the standard rectilinear 
canvases and basic control sets.  You basically make up the whole look 
and feel, rather than developing from a canned set of components.  
Sonique's MP3 players are a good example.  

        http://sonique.lycos.com/customize/

Viewing the details of featured skins at the above URL gives us a sense 
of where some branches of the growing GUI tree are headed.  The 
availability of multiple XWindows desktops for Linux, e.g. KDE and 
Gnome, is another example of "skins" which are more than skin deep -- 
yet open the same door of possibilities:  making the front end much 
more customizable by the end user, with application developers having 
more responsibility to publish an API plus a default skin, to which 
API the alternative skins may attach.

Which brings us full circle back to object-oriented, event-driven 
programming.  What we might subclass is the functionality of a button
or combo box.  Our subclass will broadcast the same events to whatever
registered listeners (Java model).  But the graphical appearance of 
this gizmo is something we redefine completely, thereby overriding the
default shape (if one is even provided).

Kirby