builder

This paper describes Visual Obliq, a user interface development environment for constructing distributed, multi-user applications. Applications are created by designing the interface with a GUI-builder and embedding callback code in an interpreted language, in much the same way as one would build a traditional (non-distributed, single-user) application with a modern user interface development environment. The resulting application can be run from within the GUI-builder for rapid turnaround or as a stand-alone executable. The Visual Obliq runtime provides abstractions and support for issues specific to distributed computing, such as replication, sharing, communication, and session management. We believe that the abstractions provided, the simplicity of the programming model, the rapid turnaround time, and the applicability to heterogeneous environments, make Visual Obliq a viable tool for authoring distributed applications and groupware.

We describe a set of application frameworks designed especially to support information-intensive applications in complex domains, where the visual organization of an application's information is critical. Our frameworks, called visual formalisms, provide the semantic structures and editing operations, as well as the visual layout algorithms, needed to create a complete application. Examples of visual formalisms include tables, panels, graphs, and outlines. They are designed to be extended both by programmers, through subclassing, and by end users, through an integrated extension language.

This paper presents a demonstrational interface builder with improved reasoning capabilities. The system is comprised of two major components: an interactive display manager and a rule-based reasoner. The display manager provides facilities to draw the physical appearance of an interface and define interface behavior by graphical demonstration. The behavior is defined using a technique of stimulus-response demonstrations. With this technique, an interface developer first demonstrates a stimulus that represents an action that an end user will perform on the interface. After the stimulus, the developer demonstrates the response(s) that should result from the given stimulus. As the behavior is demonstrated, the reasoner observes the demonstrations and draws inferences to expedite behavior definition. The inferences entail generalizing from specific behavior demonstrations and identifying constraints that define the generalized behavior. Once behavior constraints are identified, the reasoner sends them to the display manager to complete the definition process. When the interface is executed by an end-user, the display manager uses the constraints to implement the run-time behavior of the interface.

Direct-manipulation editors for structured data are increasingly common. While such editors can greatly simplify the creation of structured data, there are few tools to simplify the creation of the editors themselves. This paper presents Citrus, a new programming language and user interface toolkit designed for this purpose. Citrus offers language-level support for constraints, restrictions and change notifications on primitive and aggregate data, mechanisms for automatically creating, removing, and reusing views as data changes, a library of widgets, layouts and behaviors for defining interactive views, and two comprehensive interactive editors as an interface to the language and toolkit itself. Together, these features support the creation of editors for a large class of data and code.

Conventional interface builders allow the user interface designer to select widgets such as menus, buttons and scroll bars, and lay them out using a mouse. Although these are conceptually simple to use, in practice there are a number of problems. First, a typical widget will have dozens of properties which the designer might change. Insuring that these properties are consistent across multiple widgets in a dialog box and multiple dialog boxes in an application can be very difficult. Second, if the designer wants to change the properties, each widget must be edited individually. Third, getting the widgets laid out appropriately in a dialog box can be tedious. Grids and alignment commands are not sufficient. This paper describes Graphical Tabs and Graphical Styles in the Gild interface builder which solve all of these problems. A “graphical tab” is an absolute position in a window. A “graphical style” incorporates both property and layout information, and can be defined by example, named, applied to other widgets, edited, saved to a file, and read from a file. If a graphical style is edited, then all widgets defined using that style are modified. In addition, because appropriate styles are inferred, they do not have to be explicitly applied.

Conventional windowing environments provide separate classes of objects for user interface components, or “widgets,” and graphical objects. Widgets negotiate layout and can be resized as rectangles, while graphics may be shared, transformed, transparent, and overlaid. This presents a major obstacle to applications like user interface builders and compound document editors where the manipulated objects need to behave both like graphics and widgets.

Fresco[1] blends graphics and widgets into a single class of objects. We have an implementation of Fresco and an editor called Fdraw that allows graphical objects to be composed like widgets, and widgets to be transformed and shared like graphics. Performance measurements of Fdraw show that sharing reduces memory usage without slowing down redisplay.