Prototyping the GEMS User Interface Prototyping is an effective way of exploring design

alternatives in a software development project. Also, it is often the only way to pin down the requirements of a user who is not entirely sure a t the outset what functionality the system should have. Early software prototyping tools produced code so ineffi- cient that the prototype had to be thrown away after the user accepted it. This is no longer the case. Some current tools allow for evolutionary prototyping, where the prototype can serve as the seed for the final system.

The development of the user interface component of GEMS proceeded in several stages, each of which produced a proto- type version built on the knowledge gained from the previous prototypes. The first iteration of the user interface consisted of a set of sketches done by the graphical designer from Carnegie Mellon's Design Department, working directly with the client. The designer created a set of sketches illustrating a walk- through of what a GEMS user would see. An example of these original storyboards is shown in Figure A.

Both the software engineers and the clients were impressed with the quality (both in terms of the visual appearance and the usability) of the design produced by a "professional" designer as compared with their experiences in previous software devel- opment projects involving GUls built only by computer scien- tists. The problem now was to implement the conceptual design, which existed only as a series of artist's sketches. The chosen platform fcr the final system was X I 1 and the OSF/Mo- tif toolkit. The development team had little expertise in CUI de- velopment and X/Motif represented a sharp learning curve. It was decided that the graphical designer would continue mak- ing his ideas more concrete by using an animation tool, Macro- Mind Director, with which he was familiar and which was sup- ported by the Design Department. The second prototype of the interface'presented to the clients consisted of an animation running under MacroMind Director on an Apple Macintosh, which allowed navigation through the entire user interface but without any functionality "behind the scenes." An example view of a MacroMind screen is shown in Figure B.

In an ideal world it would be possible to generate the code for the final user interface directly from the MacroMind anima- tions. In fact, though, MacroMind Director does not create any executable code a t all. For this reason the animations became a set of "executable requirements" for the GEMS user interface- the interface would be built to match the look a d feel of the MacroMind animations, output from which hung on the wall while we developed the X/Motif code.

tions definitely served as the seed of the final system, in the spirit of evolutionary prototyping. Recent trends in user interface development systems have been toward tools that al- low the layout and the look and feel of an interface to be created in a graphics package and then transformed directly into executable code to use in the final system. This can greatly simplify the process of user interface building and will allow ef- fort ciurrently spent on implementing the user interface to be

Despite having to start from scratch with coding, our anima-

Figure B. Second-stage prototype of GEi%fS xw- iizteiface (I2.Ian~o.\.Iirzii animation).

redirected toward the creative aspects of making an interface pleasing and consistent. Both user interface builders and libraries of interface classes will become more prevalent and useful as the technology matures.

Since the overall GEMS framework is written in C++, the cur- rent user interface is built using a set of widget wrappers that provide a C++ interface to the underlying X and Motif toolkits. Figure 3 in the main text of the article shows a sample view of the actual working user interface. Figures A, B, and 3 show a clear progression from the initial concept on paper to the cur- rent working system.

FALL 1991 63