Human-computer interaction (CS 6751) final exam (part 2)
Volker W. Elling, 3/12/97


For Netscape users, 18 point proportional and 14 point fixed font is recommended (adjust in Options-General Preferences-Font). For realistic screen shots, select "dithering" in Options-General Preferences-Images.

User interface implementation

This essay is a short introduction to various aspects of implementing user interfaces. In addition to a discussion of general ideas (some of which are presented in [1]), references to specific tool support (programming languages and user-interface toolkits) and implementation examples are given in order to provide an overview over the many paradigms and tools for user-interface implementation. The essay focuses on screen-oriented user interfaces (as opposed to "unusual" interfaces featuring speech input, tactile feedback, virtual reality, head-mounted displays etc.).

Specification

Implementing a user interface can start with a fixed and precise specification. However, precise specifications are rare in software development in general. Especially in user-interface design, alternative approaches like throw-away prototyping or evolutionary design are popular because determining in advance which user-interface suits the application demands is hard. In contrast to throw-away prototyping, evolutionary design means developing a user interfaces in several steps, starting with very limited functionality and gradually adding features and improving usability.

System support

Levels of abstraction

Multithreading (being able to issue commands to a user-interface and the underlying application while previous commands are still processed) is a feature that can improve usefulness and also usability significantly. It requires multithreading/multitasking support or at least a limited form of preemption in the operating system. Fortunately, operating systems that meet these requirements have taken over a large part of the low-cost computer market and are available even on special-purpose devices like handheld computers.

In addition, these operating systems provide at least an abstraction from the basic hardware layers in form of a windowing system API (or abstract text terminals for less sophisticated interfaces). However, user interfaces programmed along these APIs are not portable to other operating systems. Portability can be achieved by building on a higher layer of abstraction, the client-server interface. The most prominent example is X-Windows ([2]). The X-Windows server controls one or more hardware interfaces consisting of screen, keyboard and various pointing devices. A large set of window operations and drawing operations within windows is provided. Events like keys being pressed or the mouse being moved are communicated back to the client (application and user-interface). X-Windows allows server and client to reside on different machines and communicate over a network which is extremely important for environments with several different computer architectures. The more, many tasks like distributing events to widgets (parts of a user-interface like a single button) are simplified.

X-Windows servers are available on almost any UNIX clone. In addition, there are many commercial servers for Windows 95 and Windows NT that build on the Windows APIs. Thus, building interfaces based on X-Windows guarantees portability across the most important computer platforms. There is no real need to base user interfaces on platform-dependent APIs any more except for operating system services like printing or network communication, let alone write special purpose hardware drivers for particular devices.

Abstraction primitives

The wealth of primitives the X-Windows system or the various Windows APIs provide for user interface programming are not without alternatives. Parts of them have been criticized for their complexity and lack of flexibility. For drawing operations, PostScript is an interesting alternative. PostScript is a full-fledged stack-oriented programming language (derived from Forth) originally developed by Adobe as the basis for a portable document format for high-quality printers. The screen is modeled as a set of infinitely thin contours that surround areas filled with various colors or patterns. Fonts and text are described in this way as well as images and drawing. PostScript is renowned for its simplicity. It was adapted for the NextStep operating system's graphics API. Extensions exist for combining input primitives. PostScript based interfaces might be used more widely in the future.

User interface programming paradigms

Many user interfaces belong to the input-action-output loop category. This paradigm is very common for command-line interfaces, but occurs also in GUIs. Apart from its simplicity, it has some disadvantages. It is not very well suited for user interfaces that support various degrees of multithreading. In addition, much code has to be written in order to properly distribute input events to various parts of the interface.

Another successful paradigm is notification-based programming. The parts of the interface register callback functions. A notifier function receives input events and calls those callback function that match the event. Selecting callback functions can be based on

One of the drawbacks of notification-based architectures is that they do not enforce a clear hierarchical structure by themselves and therefore require more careful program design. In addition, input-action-output architectures support the concept of interface modes more readily. For example, an interface could switch to error mode if an error conditionoccurs in the application. In error mode, the set of actions available to the user might be radically different from the previous mode. Notification-driven architectures require a lot of callback function dis- and enabling while input-action-output programs simply change to another loop.

An important design model for user interface implementation is the application-control-interface model that appears in various flavors throughout the HCI literature. This model separates the user interface strictly from the application. Keeping up this separation in the interface implementation has several advantages:

There are many examples of systems that were developed with respect to this paradigm and its benefits. One example is the Emacs editor available for the UNIX operating system. Lower levels of Emacs are implemented in C (most likely, for speed and convenience reasons). Emacs contains a Lisp interpreter and exports a set of editor operations as Lisp functions. Apart from this Lisp interface, Emacs also provides a standard graphical user interface.

The graphical interface provides basic editor functions without requiring a lot of user training. The Lisp interface is more powerful in cases where a complex, custom operation has to be performed on a text. A large part of higher-level Emacs functionality is implemented in Lisp. Lisp is certainly not the language for allowing non-expert users to extend a user interface, but the fact cannot be denied that the simplicity of the Lisp interface has allowed many programmers to contribute to Emacs by writing own custom Lisp programs for particular purposes (e.g. programming, reading mail, viewing HTML files, ...).

The Emacs example can be easily extended to other applications. For example, in my opinion vector graphics drawing is very well suited for combining a graphical interface with a powerful programming language (here, a functional and object-oriented language would be appropriate). The programming facilities could be used to support fast creation of complex drawing while the user interface can be used for simple drawings and also for convenient input of point positions to the programming engine.

Other important advantages of interface-application-separation are

Programming languages

Choosing the programming languages for an interface implementation is an important decision. User interfaces are unusual software objects: Time and space efficiency have relatively low priority. This allows for using interpreter languages instead of compiler languages. Some advantages of interpreter languages: Apart from Emacs Lisp described above, another important example of a GUI programmed with an interpreted language are the Tcl script language and the Tk toolkit (see
below).

User interface programming is a stronghold of both compiled and interpreted object-oriented languages. This is due to the fact that inheritance and polymorphism occur naturally in many aspects of user interfaces. As an example for inheritance, consider a class of buttons with label text, derived from a class of mere buttons, derived from a class of invisible screen-coordinate rectangles that receive all input events that occurred when the mouse pointed into them. The most prominent example for polymorphism are the event handling methods of objects (which correspond to the callback functions described above). All the notifier has to know is a reference to the event handling method. Each class of interface objects provides its own implementation of this method. Obviously, object-oriented languages provide for a tremendous degree of code reuse. A closer look at most toolkits based on non-object-oriented languages like C (e.g. Motif) reveals that they use some object-oriented ideas, too, in a less explicit manner.

Important examples of object-oriented languages used in user-interface design are

When choosing languages for interface design, some general software engineering principles apply. Interpreted script languages like Tcl, Lisp dialects or NewtonScript often have weak or no typing, poor modularization support and tend to allow the programmer to do everything. Since user interfaces can become very complex, finding errors in programs written in languages with these features can be extremely difficult. Debugging time is a crucial cost factor in programming.

User interface toolkits

There is a wealth of commercial and freeware user interface toolkits. Each toolkits has its own advantages and disadvantages. Almost all toolkits enforce using a particular programming language (although some allow overcoming these limitations with moderate effort). Likewise, almost all toolkits enforce a particular implementation paradigm.

An interesting example is the Tk toolkit with its many extensions. I will describe only a subset of its many characteristic, important features in order to give an idea of the support toolkits can give in interface programming. Tk and the script language Tcl were designed by John K. Ousterhout (Sun Microsystems, formerly University of California at Berkeley). The Tk toolkit itself is programmed in C, building on X-Windows and alternatively Windows APIs. Thus Tk-based interfaces have the important property of portability.

Tk provides a set of Tcl functions that allow for fast design of user interfaces. (The Tk toolkit has also been adapted for programming using various Lisp dialects like Scheme because many people felt that, from a software engineering point of view, Tcl did not provide enough support for structured and modular programming).



Tk packer example: "Select" button x-stretchable,
Scrollbar y-stretchable, Listbox xy-stretchable.


A central part of the Tk toolkit is the packer. A significant part of GUI programming time is often consumed by arranging dialog elements in a window and determining proper sizes for them. Tk makes this complex task easier. The programmer specifies widgets (Tk notion for interface elements) to be either rigid (e.g. a button) or stretchable in the x and/or y direction (e.g. text editors or scroll bars). In addition, he specifies a certain order in which the widgets are arranged horizontally or vertically. If a widget occupies less space than available, he can choose to center it or align it to any space boundary. Tk takes care of all coordinate computations and pays respect to window boundaries (like button shadows). It also takes care of resizing widgets when a whole window is resized.

When programmed in Tcl, Tk allows for binding arbitrary Tcl functions to various X-Windows events. The events can be selected by type, parameters and target widget. Example:

bind .listbox  {
     user_selected_beverage [.listbox get curselection]
}
When the user presses the left mouse button over the Listbox .listbox, a handler function (defined in between {}). This is a striking example of the simplicity of programming notification-based interface architectures.

The third and last feature I am presenting here is the Xf tool. Xf (which, with due respect to its beta version status, is not an example of good interface design) provides functionality common to many user interface development systems: the programmer can layout the application in a WYSIWYG manner rather than cycling in the usual slow programming-testing loop.


Interface

Xf controls

Xf: configuring the packer parameters for a scrollbar


Conclusions

This essay attempts to cover the whole range of problems arising in interface design: Due to time and space limitations, only a selection from many interesting aspects was covered. This essay does not represent a comprehensive overview of the field of interface implementation. However, I think that it is interesting because of thoughts and encountered problems from my experience of programming user interfaces and using various ones I mixed in. I tried to present my view of what the user interface implementation process could look like in the future. I hope that this text has the potential of stirring up more thoughts and discussions among eventual readers of this essay.


References

[1]
A. Dix, J. Finlay, G. Abowd, R. Beale, Human computer interaction, Prentice Hall Europe, 1993

[2]
R. Scheifler, J. Gettys, The X Window System, Software - Practice and Experience, Volume 20/S2 (The X Window System, Version 11), 1990

Page created 12/3/97 by Volker Elling. Small design changes 12/10/97.