################################################ # # # ## ## ###### ####### ## ## ## ## ## # # ## ## ## ## ## ### ## ## ## ## # # ## ## ## ## #### ## ## ## ## # # ## ## ###### ###### ## ## ## ## ### # # ## ## ## ## ## #### ## ## ## # # ## ## ## ## ## ## ### ## ## ## # # ####### ###### ####### ## ## ## ## ## # # # ################################################ The following paper was originally presented at the Third Annual Tcl/Tk Workshop Toronto, Ontario, Canada, July 1995 sponsored by Unisys, Inc. and USENIX Association It was published by USENIX Association in the 1995 Tcl/Tk Workshop Proceedings. For more information about USENIX Association contact: 1. Phone: 510 528-8649 2. FAX: 510 548-5738 3. Email: office@usenix.org 4. WWW URL: https://www.usenix.org ^L A Table-based Layout Editor George A. Howlett ghowlett@fast.net Abstract This paper describes a user-interface layout editor built upon the BLT library. It offers a drag-and-drop graphical model where new layout designs can be created or existing designs can be tuned. Introduction One reason why graphical user interfaces (GUI) are so hard to design and implement is that their requirements are so hard to pinpoint. Initial specifications are usually insufficient or wrong and correct specifications only slowly become apparent through usage. Interface design, implementation, and testing phases become intertwined. The traditional "waterfall" approach to software engineering fails as there is a need to succes- sively iterate through design, implementation, and test- ing. "The only reliable way to get good interfaces is to iteratively re-design (and therefore re-implement) the interfaces after user-testing, which makes the imple- mentation task even harder."[1] The Tk[2] toolkit's use of a high-level programming lan- guage (Tcl[3]) has several features which benefit itera- tive design. Tcl is interpreted so there is no compilation or linking, thus shortening the iterative design cycle. In Tk, all widget resources and toolkit intrinsics (e.g. geometry managers) are available at the Tcl program- ming level. This means that the entire interface can be dynamically queried and modified from the interpreter while the application is running. In addition, these changes can be made from another program using Tk's "send" facility, which allows Tcl commands to be exe- cuted in another interpreter. Successive iterations of the design cycle can be performed without terminating and restarting the application. The best example of such a development tool is the widget resource editor HierQu- ery[4]. However, the problem with a strictly language-based approach is that not everyone is a programmer. An application's interface may be designed by graphic art- ists or human-computer interface specialists. Even for programmers, there is a great deal about placement, for- mat, and design of the user interface which must be specified. Re-programming the user interface (via Tk commands) can quickly become tedious. Interface designers and end users need a simpler design mecha- nism. The following describes a window layout design tool, built upon the BLT library, called Ted (Table EDitor). It attempts to address the iterative design problem by mar- rying a layout model (table-based geometry manager) with a direct graphical specification (i.e. drag-and-drop) paradigm. New and existing GUI layouts can be manip- ulated and modified by the mouse, while instantaneous feedback is provided. Designers can create new inter- faces by simply dragging and dropping Tk widgets (windows) onto a grid. Like HierQuery, Ted exploits Tk's powerful send mechanism so that existing designs can be iteratively tuned and modified. Ted is not (yet) a full-fledged interface builder. There are a number of open problems regarding interface builders. While an interface builder may be useful for generating dialogs and menus, it is not practical for specifying interfaces beyond the widget level. For example, a builder would not normally help with the design of the contents of a canvas widget. A bigger problem is how the new interface is incorporated into the existing appli- cation. Does the application need to be restarted to view the changes? Is easily is the code generated by the builder merged with the existing application, or is pro- gramming necessary? How is consistency maintained? The much more modest task of Ted is to edit window layouts. Its main focus is on existing applications, to assist iterative design by making it simple to experiment with different window layouts on running applications. The goal is to provide much more than a graphical rep- resentation of the table geometry manager, but a higher level view of layout design to make it easy to create, save, and apply new layout designs. Ted is more than a wrapper for table configuration options. The above figure displays Ted and a simple window lay- out generated from it. Tk widgets have been dragged from the palette (listbox) of simple widgets and dropped on the 3x3 grid. Windows are arranged onto a grid rep- resenting the rows and columns of the table. Windows may also span multiple rows or columns. Grid configu- ration and window alignment is controlled from the lower panel. This too works by drag-and-drop. Table-based Model The most interesting aspect of Ted is how it embraces the use of the table geometry manager[5] from the start. Many interface builders give the user too much freedom in window placement. They ignore geometry manage- ment issues, simply positioning windows at specific screen coordinates. While this is sufficient when it can be assumed that window sizes will never change, the diversity of screen sizes and resolutions today make it unrealistic that "one size will fit all". In addition, because there is no underlying geometry model, the interface builder does nothing to repair or improve the user's design. An alternative approach is to retrofit the placement of a set of windows to a particular layout mode after the user has arranged them. But this can easily be a source of confusion, especially when the layout model fails to accurately reflect the actual design problem. It is impor- tant that the model be clear to the interface designer as to how it will affect the design. The model's layout poli- cies should be intuitive and its design constraints obvi- ous, so that the expected results occur when windows are resized. The layout model at the same time must be flexible and powerful enough to design almost any lay- out. Ted utilizes the layout model of the BLT table geometry manager. The table geometry manager has several char- acteristics which make it highly suitable for this pur- pose. 1. Gridding A table-based geometry manager naturally supports gridding. Gridding is a common tool, ubiquitous in graphical design. It is extremely useful for defining rela- tions among graphical components. These relations include balance, symmetry, grouping, and scale. Unlike more complicated "spring" models, gridding should be well understood by most interface designers. 2. Flattened Hierarchy The logical view of a graphical interface is flat and 2- dimensional. It is much easier to work with a layout design which is essentially flat. The table layout model makes it easy to align windows without resorting to cre- ating layers of window hierarchy (e.g. a frame used to position windows in a column). 3. Layout Description The simplicity of the table layout model has several advantages. Layouts can be described compactly. The entire table arrangement can be described in a single Tcl command. Parts of the table can be reconfigured without re-specifying the entire layout description. This is important because the table layout may change many times during an editing session. Ted saves "undo" and "redo" information for each edit- ing operation so it is necessary that the state of the table is easily queried and the description can be compactly saved. The table geometry manager has several options to query how the table is configured and what windows are arranged inside of it. Ted extracts this information to construct each view of the table grid. 4. Order Independence The order in which windows are packed and repacked should not affect their final layout. The packing order of windows may change many times in the process of edit- ing a layout. It is too difficult for the end user to rede- sign a layout while considering how reordering slave windows will change the packer's eventual layout. This was the major reason why the Tk packer geometry model was not used. Editor Output The output of Ted is Tcl code. Since the major focus of Ted is for redesign of the layouts of existing applica- tions, it can not be assumed that they will contain any extra code to process layout information. Ted interacts with the application's table geometry manager to update the layout. An open issue in Ted is how to merge the new Tcl code with the application when the new interface is finally saved. Tcl does not maintain the line numbers of the code as it is executed. It is not possible to know where in what file the table geometry manager was created. Ted saves the Tcl code in a separate file. It is left for the user to integrate the saved piece of code with the origi- nal files. Conclusion Ted is an layout design tool which provides a graphical interface to create layout designs and edit existing table- based designs. Its modest goal is to provide a platform for iterative design of window (widget) layouts. It embraces a table-based geometry model which com- bines simple and intuitive layout policy with the power and flexibility to describe most layout designs. Ted will hopefully evolve into a full-fledged interface builder. References 1. B. A. Myers, User Interface Software Tools, 1994. 2. J. K. Ousterhout, An X11 Toolkit Based On the Tcl Language, Proceedings of the 1991 Winter USENIX Conference, 1991, pp. 105-115. 3. J. K. Ousterhout, Tcl: An Embeddable Command Language, Proceedings of the 1990 Winter USENIX Conference, 1990, pp. 133-146. 4. D. Richardson, Interactively Configuring Tk-based Applications, Proceedings of the 1994 Tcl/Tk Work shop, New Orleans LA, pp. 21-22. 5. G. A. Howlett, A Table Geometry Manager for the Tk Toolkit, Proceedings of the 1993 Tcl/Tk Work- shop, University of California at Berkeley, pp. 27-30.