Software tools for developing the user interface are among the most important aspects of the interface development process. Most tools currently available support implementation of the user interface. Tools are also among the most elusive and ephemeral aspects of the process; virtually weekly, some new software package claims that it will produce user friendly interfaces, or will produce the best user interface software. The spectrum of interface development tools ranges from libraries of device handling routines to toolkits to prototypers to user interface management systems.
In this report, I do not intend to present specific tools in detail, nor
to list the tools exhaustively. It is believed that there are literally
hundreds of tools available, both commercially and from research groups,
and the number is ever-increasing. This report
describes the GUI builder tools in the
broad context of user interface tools and
focuses on discussing the
characteristics of GUI builder tools in particular.
Four categories of GUI builder tools are distinguished based on the
analysis.
Two examples of GUI builder tools are given in some detail to give a feel
what they look like and what their features are.
Both the advantages and disadvantages of using GUI builder tools
are discussed.
At the end, a list of references and some web links are provided
for your convenience.
| Application |
| Higher-level Tools |
| Toolkit |
| Windowing System |
| Operating System |
A windowing system is a software package that helps the user monitor and control different contexts by separating them physically onto different parts of one or more display screens. When the programmer wants to draw application-specific parts of the interface and allow the user to manipulate them the window system interface must be used directly.
The X system divides the window functionality into two layers: the window system, which is the functional or programming interface, and the window manager which is the user interface. Thus the "window system" provides procedures that allow the application to draw pictures on the screen and get input from the user, and the "window manager" allows the end user to move windows around, and is responsible for displaying the title lines, borders and icons around windows.
A toolkit is a library of "widgets" that can be called by application programs. A widget is a way of using a physical input device to input a certain type of value. Typically, widgets in toolkits include menus, buttons, scroll bars, text type-in fields, etc.
Because the designers of X could not agree on a single look-and-feel, they created an intrinsics layer on which to build different widget sets, which they called xt. This layer provides the common services, such as techniques for object-oriented programming and layout control. The widget set layer is the collection of widgets that is implemented using the intrinsics layer. Multiple widget sets with different looks and feels can be implemented on top of the same intrinsics layer, or else the same look-and-feel can be implemented on top of different intrinsics.
Using a toolkit has the advantage that the final UI will look and act similarly to other UIs created using the same toolkit, and each application does not have to re-write the standard functions, such as menus. A problem with toolkits is that the styles of interaction are limited to those provided. In addition, the toolkits themselves are often expensive to create: "The primitives never seem complex in principle, but the programs that implement them are surprisingly intricate". Another problem with toolkits is that they are often difficult to use since they may contain hundreds of procedures, and it is often not clear how to use the procedures to create a desired interface.
Though there are many small differences among the various toolkits, much remains the same. For example, all have some type of menu, button, scroll bar, text input field, etc. Therefore, a number of systems have been developed that try to hide the differences among the various toolkits, by providing a virtual widgets which can be mapped into widgets of each toolkit. Another name for these tools is cross-platform development systems.
Since programming at the toolkits level is quite difficult, there is a tremendous interest in higher level tools.
Many higher level tools have components that operate at different times. The design time component helps the user interface designer design the user interface. For example, this might be a graphical editor which can lay out the interface, or a compiler to process a user interface specification language. The next phase is when the end-user is using the program. Here, the run-time component of the tool is used. This usually includes a toolkit, but may also include additional software specifically for the tool. There may also be an after-run-time component that helps with the evaluation and debugging of the user interface.
Among them, we are most interested in the run-time component. We define
GUI builder tool as any higher level user interface tool
with run-time component that help programmer/end-user build
graphical interface, which will be discussed in details in the
following sections.
GUI builder tools have the same goal of helping programmer build the graphical interface, but they come in a large variety of forms. One important way that they can be classified is by how the designer specifies what the interface should be. Some tools require the programmer to program in a special-purpose language, some provide an application framework to guide the programming, some automatically generate the interface from a high-lvel model or specification, and others allow the interface to be designed interactively. Based on the above analysis, four kinds of tools can be distinguished:
With most of the older user interface builder tools, the designer specifies the user interface in a speicial-purpose language. This language can take many forms, including context-free grammars, state-transition diagrams, declarative languages, event languages, etc. The language is usually used to specify the syntax of the user interface. Several representive tools are belong to this category.
VAPS [1] is a commercial system that uses the state transition model, and it eliminated the maze-of-wires problem by providing a spreadsheet-like table in which the states, events, and actions are specified. Transition networks have been thoroughly researched, but have not proven particularly successful or useful either as a research or commercial approach.
Sassafras [2] is an event language where the user interface is programmed as a set of small event handlers. The elements-events and transitions language provides elaborate control over when various event handlers are fired. Another event language is HyperTalk, which is part of HyperCard for the Apple Macintosh. Microsoft's Visual Basic also contains evnet-language features, since code is generally written as responses to events on objects.
Cousin [3] and HP/Apollo's Open-Dialogue [4] both allow the designer to specify user
interfaces in declarative language. The user interfaces supported are
basically forms, where fields can be text which is typed by the user, or
options selected using menus or buttons. There are also graphic output
areas that the application can use in whatever manner desired. The
application program is connected to the user interface through "variables"
which can be set and accessed by both.
After the Macintosh Toolbox had been available for a little while, Apple discovered that programmers had a difficult time figuring out how to call the various toolkit functions, and how to ensure that the resulting interface met the Apple guidelines. They therefore created a software system that provides an overall application framework to guide programmers. This was called MacApp [5] and used the object-oriented language Object Pascal. Classes are provided for the important parts of an application, such as the main windows, the commands, etc., and the programmer specializes these classes to provide the application-specific details, such as what is actually drawn in the windows and which commands are provided. MacApp was very successful at simplifying the writing of Macintosh applications. Today, there are multiple frameworks to help build applications for most major platforms, including the Microsoft Foundation Classes for Windows, and the CodeWarrior PowerPlant [6] for the Macintosh.
Unidraw [7] is a research framework, but it is more specialized for graphical editors. This means that it can provide even more support. Unidraw uses the C++ object-oriented language and is part of the InterViews [8] system. Unidraw has been used to create various drawing and CAD programs, and a user interface editor. The Amulet framework [9] is also aimed at graphical applications, but due to its graphical data model, many of the built-in routines can be used without change (the programmer does not usually need to write methods for subclasses). Even more specialized are various graph programs, such as Edge [10] and TGE [11]. These provide a framework in which the designer can create programs that display their data as trees or graphs. The programmer typically specializes the node and arc classes, and specifies some of the commands, but the framework handles layout and the overall control.
A problem with all of the language-based tools is that the designer must specify a great deal about the placement, format, and design of the user interfaces. To solve this problem, some tools use automatic generation so that the tool makes many of these choices from a much higher-level specification. Many of these tools, such as Mickey [12] , Jade [13] , and DON [14] have concentrated on creating menus and dialog boxes. Jade allows the designer to use a graphical editor to edit the generated interface if it is not good enough. DON has the most sophisticated layout mechanisms and takes into account the desired window size, balance, columness, symmetry, grouping, etc. Creating dialog boxes automatically has been very thoroughly researched, but there still are no commercial tools that do this.
UIDE (the User-Interface Design Environment) [15] requires that the semantics of the application be defined in a special-purpose language, and therefore might be included with the language-based tools. It is placed here instead because the language is used to describe the functions that the application supports and not the desired interface. UIDE is classified as a ``model-based'' approach because the specification serves as a high-level, sophisticated model of the application semantics. In UIDE, the description includes pre- and post-conditions of the operations, and the system uses these to reason about the operations, and to automatically generate an interface. One interesting feature of UIDE is that the pre- and post-conditions are used to automatically generate help.
Interface tools allow the designer to create dialog boxes, menus and windows that are to be part of a larger user interface. They allow the designer to select from a pre-defined library of widgets, and place them on the screen using a mouse. Other properties of the widgets can be set using property sheets. Usually, there is also some support for sequencing, such as bringing up sub-dialogs when a particular button is hit. The Steamer project at BBN demonstrated many of the ideas later incorporated into interface builders and was probably the first object-oriented graphics system [16]. Other examples of research interactive tools are DialogEditor [17] , vu [18] and Gilt [19]. There are literally hundreds of commercial tools. Just two examples are the NeXT Interface Builder [20] and UIM/X for X [21]. Visual Basic can also be considered as an interactive tool coupled with an editor for an interpreted language.
Interactive tools use the actual widgets from a toolkit, so they can be used to build parts of real applications. Most will generate C code templates that can be compiled along with the application code. Others generate a description of the interface in a language that can be read at run-time. For example, UIM/X generates a UIL description. It is usually important that the programmer not edit the output of the tools (such as the generated C code) or else the tool can no longer be used for later modifications.
Although interface builders make laying out the dialog boxes and menus easier, this is only part of the user interface design problem. These tools provide little guidance towards creating good user interfaces, since they give designers significant freedom. Another problem is that for any kind of program that has a graphics area (such as drawing programs, CAD, visual language editors, etc.), interactive tools do not help with the contents of the graphics pane. Also, they cannot handle widgets that change dynamically. For example, if the contents of a menu or the layout of a dialog box changes based on program state, this must be programmed by writing code.
Two of interactive tools will be discussed in some detail in the next section.
When UIM/X starts, it displays a single main window that is divided into sections for interfaces, palettes, and messages. The interfaces section contains an icon for each top-level window in your application. The palettes area holds commonly used widgets, and the messages section prints system messages and warnings.
You begin an interface by selecting a shell or container widget from the Create menu or palette. you then use the mouse to define the on-screen area for the widget. Next, you fill the container with any other widgets you need, such as the usual fare of push buttons and scrollbars.
For each interface in your project, you can use a browser window that gives you the choice of viewing the interface in tree or outline format. The browser supports the usual editing functions and gives you another opportunity to add widgets to the interface. For each widget - or group of widgets - in the interface, you can also invoke a property editor to change widget resources and attributes.
To help you organize resources, UIM/X imposes some structure on the resource list. You can choose to view core resources, those common to all widgets; resources specific to the widget in question; callback-related, declarative properties, such as widget name and parent; or all of the above. Astutely, UIM/X gives you the choice to define resource values in code to prevent users from changing them, or in the resource file to allow uses to customize them.
The dynamic behavior of an application is called the dialog component in UIM/X. The dialog component comprises the link between the interface and application. In UIM/X, you enter C code directly into a callback editor, and the system-integrated C interpreter automatically parses the code and reports errors instantly. It is an obvious improvement compared to dtbuilder.
UIM/X has two basic modes: design and test (same as dtbuilder). The
design mode is where you build the interface. Test mode uses the C interpreter
to test the entire application, including callbacks, which eliminates the
compile/link/debug cycle. As a result, you can only compule after you have
tested all components in the interpreter. UIM/X also provides an interpreter
window in which you can execute code fragments and get instant results.
Visual BasicVisual Basic is completely graphically oriented, so you'll be able to create directly windows, menus, buttons, etc. What you need to write are the codes that process system messages and events. The major disadvantage of Visual Basic is that you have to have add-ons to implement powerful features. These add-ons are called VBX files.
The Visual Basic IDE (Integrated Development Environment) looks intimidating,
but it is actually quite simple. Here is a figure labeling the basic parts of
the interface.
- Toolbox: all your VBX controls are contained on the toolbar. You use the buttons on the toolbar to draw controls on the form. When you add a VBX, its icon will appear here.
- Form: this is what the user sees. It contains controls, and its actions are defined by the code. Most applications have arround 5 - 6 forms, but there are obviously exceptions.
- Code Module: the code for the controls is defined in the code module. Notice the two combo boxes at the top of the code module. The left one shows the object whose code is being defined. The right one shows the Procedure, or event of the control which is being defined.
- Properties Window: properties for a control are set in this window, such as the control's color, dimensions, and opperations.
- Project Window: this is a representation of the .mak file which defines which files are to be used in the program. Every form, base code module, and vbx used with the .mak file is shown in this window.
The Code Module window is where you'll do all the coding. The two combo boxes are probably the most confusing part of VBasic for the beginner, but once you learn how the language is set up it's not so hard. Imagine a button, like the windows kind you see when you have a choice between "OK" and "Cancel." You can do different things to this button: you can click it, drag the mouse over it, or push a button while it is selected. These things that can happen are called events, and it is the programmer's job to write code for these events.
The interaction style of VBASIC is event driven.
The user can click the mouse anywhere on the screen,
or exit the program suddenly, or even call up another
program while the current one is running. You as the
programmer have to take all this into account.
Whenever the user does something in windows, like
click the mouse, move it, or click a button on a form,
window issues what is called a message. This message
is interpreted by visual basic as an event. Each control
in visual basic has several events, and you add code to an
event to make it do something when window issues the message.
Events of a control are also called that object's procedure,
as the menu boxes in the code module imply.
[1] Virtual Prototypes Inc. VAPS. 4700 de la Savane, Suite 300, Montreal, Quebec CAN, H4P 1T7, (514)341-3874. 1995.
[2] Ralph D. Hill. Supporting Concurrency, Communication and Synchronization in Human-Computer Interaction -- The Sassafras UIMS. ACM Transactions on Graphics (5) 3:179-210, July, 1986.
[3] Philip J. Hayes, Pedro A. Szekely, and Richard A. Lerner. Design Alternatives for User Interface Management Systems Based on Experience with COUSIN. In Human Factors in Computing Systems , pages 169-175. Proceedings SIGCHI'85, San Francisco, CA, April, 1985.
[4] Andrew J. Schulert, George T. Rogers, and James A. Hamilton. ADM-A Dialogue Manager. In Human Factors in Computing Systems , pages 177-183. Proceedings SIGCHI'85, San Francisco, CA, April, 1985.
[5] David Wilson. Programming with MacApp. Addison-Wesley Publishing Company, Reading, MA, 1990.
[6] Metrowerks, Inc. PowerPlant for CodeWarrior. 2201 Donley Drive, Suite 310, Austin, http://www.metrowerks.com/. 1996.
[7] John M. Vlissides and Mark A. Linton. Unidraw: A Framework for Building Domain- Specific Graphical Editors. ACM Transactions on Information Systems 8(3):204-236, July, 1990.
[8] Mark A. Linton, John M. Vlissides and Paul R. Calder. Composing user interfaces with InterViews. IEEE Computer (22)2 :8-22, February, 1989.
[9] Brad A. Myers, Alan Ferrency, Rich McDaniel, Robert C. Miller, Patrick Doane, Andy Mickish, Alex Klimovitski. The Amulet V2.0 Reference Manual . Technical Report CMU-CS-95-166-R1, Carnegie Mellon University Computer Science Department, May, 1996.
[10] Frances J. Newbery. An interface description language for graph editors. In IEEE Workshop on Visual Languages , pages 144-149. Pittsburgh, PA, October, 1988. IEEE Computer Society Order Number 876.
[11] Anthony Karrer and Walt Scacchi. Requirements for an Extensible Object-Oriented Tree/Graph Editor. In ACM SIGGRAPH Symposium on User Interface Software and Technology , pages 84-91. Proceedings UIST'90, Snowbird, Utah, October, 1990.
[12] Dan R. Olsen, Jr. A Programming Language Basis for User Interface Management. In Human Factors in Computing Systems , pages 171-176. Proceedings SIGCHI'89, Austin, TX, April, 1989.
[13] Brad Vander Zanden and Brad A. Myers. Automatic, Look-and-Feel Independent 7200 16641 MT Dialog Creation for Graphical User Interfaces. In Human Factors in Computing Systems , pages 27-34. Proceedings SIGCHI'90, Seattle, WA, April, 1990.
[14] Won Chul Kim and James D. Foley. Providing High-level Control and Expert Assistance in the User Interface Presentation Design. In Human Factors in Computing Systems , pages 430-437. Proceedings INTERCHI'93, Amsterdam, The Netherlands, April, 1993.
[15] Piyawadee Sukaviriya, James D. Foley and Todd Griffith. A Second Generation User Interface Design Environment: The Model and The Runtime Architecture. In Human Factors in Computing Systems , pages 375-382. Proceedings INTERCHI'93, Amsterdam, The Netherlands, April, 1993.
[16] Albert Stevens, Bruce Roberts, and Larry Stead. The Use of a Sophisticated Graphics Interface in Computer-Assisted Instruction. IEEE Computer Graphics and Applications 3(2):25-31, March/April, 1983.
[17] Luca Cardelli. Building User Interfaces by Direct Manipulation. In ACM SIGGRAPH Symposium on User Interface Software and Technology , pages 152-166. Proceedings UIST'88, Banff, Alberta, Canada, October, 1988.
[18] Gurminder Singh and Mark Green. Designing the Interface Designer's Interface. In ACM SIGGRAPH Symposium on User Interface Software and Technology , pages 109-116. Proceedings UIST'88, Banff, Alberta, Canada, October, 1988.
[19] Brad A. Myers. Separating Application Code from Toolkits: Eliminating the Spaghetti of Call-Backs. In ACM SIGGRAPH Symposium on User Interface Software and Technology, pages 211-220. Proceedings UIST'91, Hilton Head, SC, November, 1991.
[20] NeXT, Inc. NeXTStep and the NeXT Interface Builder. 900 Chesapeake Drive, Redwood City, CA 94063. 1991.
[21]
Visual Edge Software Ltd. UIM/X. 3950 Cote Vertu, Montreal, Quebec H4R 1V4.