Tools for User Interface Design and Construction

590H -- Spring 1995

Special Demands of UI Design and Construction

participatory design
prototypes
user-centered design -- need for iteration and testing of systems

Traditional models of system development:

waterfall model: application description, requirements specification, system design, implementation
Boehm's spiral model

UI design seems to work better with more frequent user testing using informal prototypes. (Aside about the difference between software development as it is taught and as it is practiced ...)

Input/Output Devices

Input: keyboard, chording keyboard, mouse, tablet, joystick, touchscreen, dataglove, microphone (speech), blowtube, various musical instruments, ....

Output: bitmap display, printer, meters, sound (speech, music, beeps, natural sounds), headmounted display, retinal scanner, force feedback, ...

What Makes User Interface Programming Difficult?

need for iterative design
multiprocessing (or at least a way of handling user interrupts)
rapid response
robustness (should never go into system debugger or dump core)
testability (difficulty of simulating mouse input)
complexity
... and because it's a large portion of the system! (See Myers's survey paper)

User Interface Toolkits; User Interface Management Systems

In the earliest systems, the user interface portions of the system were just scattered among the application code. This has several disadvantages for large systems:

lack of modularity
difficulty in changing the interface (while underlying application remains the same)
difficulty in porting from one platform to another

Researchers began exploring ways of separating the interface from the application. Perhaps the first such system was described in a paper by William Newman in 1968.

An influential workshop on "User Interface Management Systems" was held in Seeheim, Germany in 1983. (Compare with "Database Management Systems".) The Seeheim model was descrbed in a paper by Mark Green -- this model emphasizes the deparation of the application, dialog control, and presentation. (The concern here was text-based interfaces with a dialog eliciting responses from users.) The Seeheim model breaks down for UI's with tighter coupling between the application and its interface, e.g. a graphical checkers interface that flashes squares to which it is legal to move.

This is an instance of a general problem in designing a system architecture for a user interface tool: the tension between the desire to separate the user interface from the application (motivated by modularity concerns), and the need to couple them tightly

The term "UIMS" seems to be used in different ways -- generally indicates a system with substantial runtime support for the user interface; sometimes for tools that handle the sequencing of operations following a user input

More recent systems are often called UI toolkits, user interface development environments, interface builders, or application frameworks.

Window Systems

The currently dominant paradigm (rectangular windows, menus, icons, etc) was pioneered at Xerox PARC in the 70's by the Learning Research Group and others. (We will investigate this history in more detail later, as part of the case study of the Star system.)

On Unix workstations X windows is dominant; on Macintoshes the Mac environment; on PC's and clones Microsoft Windows.

Output: bitblt (RasterOp), often plus specialized drawing and text display operations. Some systems support Postscript.

Input: represented as a stream of input events. Each event typically consists of a mouse button or keyboard event, along with the cursor location, state of the shift and control keys. The windowing system is in charge of directing input events to the input focus (window that currently receives events). (Note that other windows may be actively displaying information at the same time.)

event-driven computation vs. polling

Typically change focus by moving the mouse into a new window, with or without clicking in it.

Linking the Interface to the Application

Some techniques:

procedure calls; callbacks to handle input (note callback spaghetti problem)
model-view-controller mechanism used in Smalltalk
one-way constraint systems
multi-way constraint systems

Callbacks

In this model, a widget (for example, a slider) will have a list of procedures to call if it receives some user input. This is the most frequently used technique.

Model-View-Controller

This is the system architecture used in ParcPlace Smalltalk. The model is the application object. The view is its graphical depiction (for output). The controller handles input. Models have a list of dependents (typically views). When the model changes, it sends itself the changed: message, perhaps with an argument (a symbol) indicating which aspect has changed. This invokes each of the views with the update: message (with the aspect as an argument). The views must then redisplay or otherwise update. The window manager distributes input events to the appropriate controller, which then sends messages to the model asking it to update itself.

Constraints

A constraint is a relation that should be satisfied. In user interfaces, these can be used for maintaining model-view consistency and for layout. More on constraints in a separate page ...

Tools for Prototyping

In addition to tools for rapid prototyping of deliverable systems, UI designers sometimes also use tools for building prototypes only, where the delivered system will be written in a different language or using a different toolkit.

Cardboard Mockups. Advantages: cheap, low-technology, break down barriers between experts and end users when doing participatory design, make it clear that the ideas are still in an early form. Disadvantages: static, not convincing to upper management or funders.
Hypercard. Advantages: relatively easy to add graphics and fields, functionality using Hypertalk. Disadvantages: UI mockup must fit into card/background structure.
Macromind Director. Advantages: allows animations to be produced, including fairly sophisticated animations with some effort. Animations can be produced by non-programmers. Can add functionality using a Hypertalk-like language called Lingo. Disadvantages: user interface more complex than for Hypercard; can't simulate sophisticated functionality; can get sucked into putting excessive, premature effort into the visual appearance of the prototype.