GUI Generation from Annotated Source Code

Transcription

1 GUI Generation from Annotated Source Code Josef Jelinek Czech Technical University in Prague Karlovo Namesti 13, Praha 2 jelinej1@fel.cvut.cz Pavel Slavik Czech Technical University in Prague Karlovo Namesti 13, Praha 2 slavik@fel.cvut.cz ABSTRACT Creating user interfaces is a common task in application development. It can become time and money consuming if the same application is to be run on more platforms with different restrictions and requirements. To reduce the development cost and time the user interface can be defined on an abstract level in the form of a task model. Explicit defining and maintaining the task model can complicate the development especially in its early stages when application prototypes are built. We present a way to define a user interface on an abstract level without explicit definition of the user interface module while keeping it transparent, thus reducing the work required to make functional application prototypes. Our approach is based on derivation of a user interface module directly from an application source code enriched by abstract commands of user inter to control the generation of the user interface. Author Keywords Automatic GUI generation, visual programming. The explicit definition of a user interface can increase the amount of work required, especially in the early stages of development when only a functional application prototype is made. Here a lot of work is spent on the user interface definition and consequent binding with the logic of an application. The aim of our approach was to simplify the GUI definition in such cases by automated GUI generation from a source code enriched by additional GUI inter elements. Advantage is that programmers need not specify many concrete aspects of a user interface explicitly or cooperate with a GUI designer, but enrich the source code when they realize that a GUI element should be used for user inter. The effect is similar to definition of application logic and the corresponding task model separately only that the task model is not defined explicitly, but rather generated from the annotated source code. Problem Description To be more specific, let us suppose the following example program to add two s. The following Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. TAMODIA 04, Prague, Czeck Republic. Copyright 2004 ACM /04/0011 $5.00 ACM Classification Keywords D.1.7 [Visual Programming]; D.2.2 [Design Tools and Techniques]: User Interfaces; H.5.2 [User Interfaces]: User Interface Management Systems (UIMS). INTRODUCTION Most of current systems aimed at the easier generation of graphical user interfaces use either the interactive graphical editing of GUI elements bound to the s and data types in an application (e.g. most of current commercial visual integrated development environments), or semi automated GUI generating from a kind of task model [1][2][5][6]. The task model is a way of modeling a user interface based on identifying the tasks a user may encounter when trying to accomplish a certain goal while using a system. A common disadvantage of both mentioned ways is the fact that the user interface is defined explicitly and separately by a GUI designer. code is roughly equivalent to the code in common languages like C/C++, Java, etc. and it represents a program to compute the sum of two s specified by a user: Program Sum Main() // initialize GUI create NumberField1( first ) create NumberField2( second ) create Button( Add ) create Form( Sum ) Form.add(NumberField1) Form.add(NumberField2) Form.add(Button) Form.doLayout(vertical) HandleButton() // handle button event sum = NumberField1.value + NumberField2.value create Dialog( Sum is + sum) show Dialog exit Program The GUI initialization part of the program, that creates and displays all the necessary GUI elements, could be written manually or generated by a visual tool to draw GUI elements on a screen. Both ways need explicit GUI definition. The question is: Is not there a way to omit this explicit GUI definition? Only the HandleButton part of the previously shown example is interesting and contains nearly all information about a GUI (that there are two fields that are processed upon the button 129

2 press). Our approach tries to omit such explicit GUI definition part. The equivalent code using our approach would look this way (Action Add corresponds to the user event): Program Sum Action Add // handle Add sum = NumberInput( first ) + NumberInput( second ) Report( Sum is + sum) exit Program All the GUI definition parts are let to be automatically derived by an automated system according to the program source code analysis. The approach presented is targeted especially for application prototyping where the main requirements are creating a functional application prototype with a functional GUI. The aesthetic properties of the GUI, that can be currently successfully accomplished only by manual editing are not of a top priority for such prototypes. The prototype can be used to evaluate the application usability. After user evaluation of the prototype, the GUI can be created manually with respect to the user comments. Related Work There have been several systems developed to generate user interfaces from a kind of an abstract UI description, (from a task model in particular). They are aimed at generating UI for various devices (desktop computers, Java-enabled cell phones, PDAs, etc.) where each device implies a different set of restrictions put on a user interface. These systems try to overcome problems of cross-platform UI development and to reduce the cost of creating a separate user interface for each device manually. The simplest way to create multiplatform UI is to use a portable language containing standard UI libraries (e.g. Java, HTML). However, the basic problem of different devices with different capabilities is not solved. Generally, each device would require redefining a user interface. Currently, several (mostly XML-based) user interface description languages are in use (e.g. XIML [10], UIML, AUI [11], XForms, etc.). These languages describe a user interface on a more abstract level and leave the concrete platform dependent user interface rendering on an (at least partly) automated system. Defining an abstract user interface is similar to defining a concrete user interface only on more abstract level. Such UI definition requires a complete explicit specification of abstract UI elements and their properties. Model-Based User Interface Design (MBUID) is the closest to our approach [1][2][6]. This approach uses various models to generate the user interface: task models, domain models, presentation models, dialog models, etc. The advantage is that the model used gives information not only about the form of the user interface but also about its semantics that can be taken into account during the generation of a concrete UI. Because of its abstractness the model can be used also in other stages of application development to provide information about the user inter. Dygimes framework [1] uses an annotated task model (using the ConcurTaskTrees [5] task model notation) for automatic generation of GUI for various devices. The TERESA tool [6] is another system to generate GUI using the ConcurTaskTrees notation. This notation allows a programmer to specify hierarchical task model graphically using several predefined task categories (abstract task, user task, inter task, and application task) and temporal relations (operators). Despite the mentioned advantages of such designs there are also several drawbacks. In the early stages of application development the specifications and requirements changes a lot. To be able to test application prototypes, big part of the user interface needs to be redone each time a change occurs. The application and the corresponding model need to be kept consistent, so each change in the application should be propagated to the model and vice versa. This requires a lot of additional work and is error prone. Maintaining a concrete GUI is generally even less effective. Our approach omits maintaining user interface separately by keeping UI defined in the source code of the application on an abstract level while providing ways to distinguish and manipulate the logic and inter parts. Addressed Problems During the development of our approach we have identified the following problems that we address in this paper: In order to analyze the annotated source code the programming language cannot be arbitrary and requires extensions. The main limitation is on the language structure, that must be easy to analyze in order to determine where the user application inter occurs. The language should be easy to extend with the additional GUI controlling directives. Because a programmer writes a source code with additional GUI controlling directives, the directives can make the program more difficult to read in spots of heavy user inter. Since our approach uses a kind of the task model implicitly it inherits some features and problems of the model based user interface design (e.g. problems with optimal GUI layout, optimal concrete GUI elements selection, etc.). Solutions to the mentioned problems are described in this paper. Contents of Following Sections The remaining part of this paper is structured as follows. First we will describe what abstract GUI elements we use and what they represent. We describe the chosen example programming language and its properties in the following section. Then a suitable program representation using a 130

3 graphical notation is described, which is to be used to distinguish, filter, and highlight different semantic parts of the program, particularly the GUI directives and the application logic. Consequently the GUI generation process from the annotated source code is shown. The last section summarizes the results and proposes future work. SOURCE CODE ANNOTATION Our approach is close to standard specification of the task model. The main difference is that the task model is usually specified explicitly, independently of the logic of an application [1] while our approach defines the task model implicitly in the program source code in a form of the program structure and additional GUI controlling directives (annotation). However, it does not mean that the GUI definition is not separated from the program logic, because the UI module is generated automatically (thus separately) from the abstract user inter elements in a program. Our approach does not violate concepts of GUI separation used (e.g. Seeheim[9]). The abstract GUI inter objects used are specified as special program elements with respect to the inter type to be performed in a specific location of the program. The basic types supported are roughly equivalent to some existing environments for task model based GUI generators (e.g. ConcurTaskTrees Environment (CTTE) [6]) and can be divided into two basic groups: event objects and data transfer objects. The event object corresponds to an entry point of part of a code that is to be invoked upon this event and is mapped e.g. to pressing a button. The data transfer abstract GUI objects are mapped respecting the type specified in the source code into e.g. a text field, choice, item list, etc. The types of data transfer GUI objects chosen are the following: text input to input general text (usually mapped to a text field or text area); it is characterized by its name, default value, and expected typical size input to input a (can be mapped either to a text field or to a slider, etc.); it is characterized by its name, default value, and allowed range single item selection to select one item from the fixed set of possibilities; it is characterized by its name, available possibilities, and default value multiple item selection to select a subset of items from the fixed set of possibilities; it is characterized by its name, available possibilities, and default value set monitoring to give a feedback about a specified state or change; it is characterized by its name, type, and default value responding to alerts to notify a user about an important event; it is characterized by its name, message, and possible s (set of names) other GUI elements element that requires special handling of input and output and has to process events from mouse and keyboard on its own The name of each element can contain also group names to express an element hierarchy explicitly. This list of abstract GUI objects is sufficient for the simplest applications processing basic user specified data. In future, specific elements required can be added by specialization of one of the given elements. PROGRAMMING LANGUAGE The programming language used should allow easy analysis of program execution paths in order to retrieve the information, where the particular GUI s (events, user data input) are performed. The abstract GUI objects are specified explicitly in the source code in the form similar to objects defined in some existing task model editing environments (e.g. the ConcurTaskTrees Environment [6]). Thus the programming language to be used should be easy to extend to cover both a general programming language and a task model specification language. From these requirements currently only parts of the most abstract programming languages currently in use are suitable (excluding parts added to these languages e.g. to improve efficiency, that complicates the code analysis). The most common kinds of such languages are functional (e.g. Lisp, Scheme) and logical (e.g. Prolog) programming languages. We have chosen yet another programming language concept for demonstration tree rewriting described in the following subsection. A language based on tree rewriting was chosen mostly because of its simple easy to analyze structure. However, the design of the used example language is not in the scope of this paper. The principles shown should apply to other suitable languages as well and are independent of them as long as the program structure is possible to be analyzed. Tree Rewriting Tree rewriting is a model of computation which is used in a variety of applications within computer science. Although it is rarely used as a base for programming languages there have been some attempts. One of the earliest attempts is an equational logic [7]. Another more recent attempt is the implementation of the Aardappel language described in [8]. From the current widely used languages XSLT language [17] is also based on a form of tree rewriting. Tree rewriting is a very simple and orthogonal way of data transformation specification the language elements are tree structured. It is closely related to graph/icon rewriting (e.g. PROGRES [13], KidSim [15]). To write a program a programmer defines a set of rules, each of which say: if anywhere a (sub) tree of this shape is found then replace it with a tree of the following shape. If a tree is given as the input of the program (it corresponds to the program starting point) then the program tries to apply as many rules as possible until the 131

4 tree is rewritten into a shape to which no rules apply (called a normal form). An example of tree rewriting is shown in Figure 1. There are three rules in the figure that are displayed both textually and graphically for bigger comprehensibility. An example transformation process transforming the initial tree a(b(1),f(2)) is shown also in both representations. The initial tree represents a data structure. All matching rules are sequentially used to transform the tree to another one until no rule can be used anymore. Rules use variables to match data structures more flexibly (they are shown with a darker background) that can represent any object in a tree. rules: a(b(x),y) c(y,d(x)) d(y) e(y) c(x,e(y)) a(x,y) b x a y d y c x e y c y d x e y a x y transformation of a(b(1),f(2)): a(b(1),f(2)) c(f(2),d(1)) c(f(2),e(1)) a(f(2),1) initial tree b 1 f 2 a f 2 c e 1 f 2 c d 1 a f 1 2 Figure 1. An example of tree rewriting normal form The tree rewriting has many advantages to be used as an underlying programming language. The program execution paths are relatively easy to analyze and it is on such a high level of abstr that it can be annotated in a consistent way that does not require changes to the language itself. The program in a tree rewriting based system can use various visualization techniques to customize its representation because of its simple and consistent tree based program structure. The customizable representation using highlighting and filtering of particular program parts is important because of intermixed program logic and GUI definition in the source code, that can make the particular part of the source code more difficult to read. The GUI directives can contain many additional parameters that specify various properties of the GUI element and can occupy a lot of space in the source code (displayed on a screen) spreading parts of the algorithm to a wider area and eventually out of screen. PROGRAM REPRESENTATION The approach presented specifies the user inter directly in the program on an abstract level. Although the inter directives are bound tightly to the source code, the approach does not violate the concept of GUI separation, because the module of user interface is generated automatically according to the program structure and abstract directives used. The GUI elements are resolved and instantiated in the later stages of program processing and there is no explicit GUI definition. Despite the mentioned facts the interleaved program and user inter directives can be still considered to be a disadvantage because it may decrease the legibility of the program when the directives contain a lot of additional information. So as to address this drawback we can utilize the specific properties of the programming language used, that were discussed in the previous section. The most remarkable property is a simple tree based program structure that can be quite easily visualized using various tree visualization techniques [16] and the language is a kind of visual language [12]. In our implementation the following primitives and their graphical representations are used. They can be combined together to create complex data structures. simple with a value 10 simple string with a value A string variable that can be bound to another object tree parent consisting of two subtrees; the first subtree child1 has no children, the second subtree child2 has one child named grandchild GUI directive with type guidirective and one parameter name Since the program can be analyzed and its syntax easily mapped to a visual representation, several visual extensions can be used to distinguish, highlight, and/or suppress various aspects of the program like the GUI parts and parts to perform computation. The GUI part can be partially filtered to improve legibility of program logic as well as highlighted with simultaneous simplifications of the logic part to enhance the GUI usage structure in the program. Let us suppose an example program to compute an average from the specified initial average and of items used to compute it, and repeatedly specified new items to be included to the average. The program in its full graphical form is shown in Figure 2 and its function is described in the following section. The boxes with the darkest title background correspond to the GUI directives. There are,, label, and alert directives in the program. Trees in the program rules are visualized as nested boxes using tree map representation [14]. For example the expression in the third rule that computes the updated average corresponds to the following expression: (Average*Number+[input ])/(Number+1). Different graphical representations of the same program from Figure 2 are shown in Figure 3. Figure 3a shows the graphical representation after the most of the program logic was suppressed and all GUI directives are shown in detail. Figure 3b shows the opposite situation where the 132

5 Figure 2. A simple program to compute averages program logic is fully shown but the GUI directives are represented only by its type and all other details are hidden (folded). The types of such possible transformations are predefined in the system according to the supported language features. GUI GENERATION Generating a GUI can be divided into two basic steps. The first step is the source code analysis to obtain the structure of the program concerning the spots where user inter may occur. The retrieved information is used to construct a dialog model between a user and an a) b) Figure 3. Different graphical representations of the same program a) program logic suppressed b) GUI directives suppressed application. The second step is aimed at generating a concrete GUI. All abstract GUI elements are mapped to concrete platform specific GUI elements and (sub) optimal layout is computed in order to spread the elements onto forms and windows. Program Analysis The first step of the GUI generating process is to retrieve all necessary information about the GUI from the source code. In this step the source code is analyzed and transformed into a different model with respect to the program structure and GUI directives found. Loops in the program are determined as an iteration and the corresponding GUI elements (if any) are placed to one group invoked repeatedly by an event (mapped e.g. to a button). Branching in the source code is interpreted as alternatives in the GUI element groups that are mapped to more groups considering duplicities in the branches. As an example, a simple program to compute an average from a specified initial average and of items used to compute the initial average is shown in Figure 2: The initial Average and Number s are obtained from a user during the execution of the first rule invoked upon the Compute. The third rule is called from the first one and is used for repeated specification of a new to be added to the current average. There are three GUI directives in this rule: the Add:Result label directive is used to modify the text of a label shown to the user, the Add:Add directive is used as a choice point between this branch and the application of the second rule, the nested directive is used to obtain a new to be added to the average. The second rule invoked upon the Add:Finish is an alternative to the Add:Add program branch specified in the third rule. This rule is used to finish the program. The correspondence between this rule and the Add:Add of the third rule is determined using the prefix Add. To derive all necessary information from the source code to generate the GUI automatically the source code analysis has to be performed. The result of such an 133

6 analysis is a directed graph representing control and data flow in the program with respect to the GUI directives used. Nodes of this graph correspond to spots in the program and GUI inters, edges correspond to their temporal dependencies. For this analysis the program logic need not be fully analyzed, the only important parts of the program logic are the commands affecting the paths of the program execution. Compute AddNumber Average label Add:Result Number Add:Finish Add:Add alert Done Number Figure 4. Data and control flow in the example program The Figure 4 shows the corresponding directed graph of data and control flow of the example program. The graph was created automatically by the program analysis and is used internally to retrieve important properties of the GUI to be generated. All GUI inter elements have the darker background; full arrows show the control flow and the dotted arrows the possible use of GUI elements. The following properties can be derived from the graph: It can be seen that there is one inaccessible node in the program graph corresponding to the Compute and it is set as a starting point of the program GUI inter. There is one branching in the graph where the decision between Add:Add and Add:Finish s is made and it should be mapped to a user s choice in the GUI. There is one cycle in the graph corresponding to the recursive application of the AddNumber rule. The GUI elements in the cycle are to be used repeatedly and should be put together. The Done alert is the only node that does not continue to other nodes and the program is terminated after processing this alert. One thing in the graph is worth a note: Although the label directive does not provide any data to the program and receives the text to be displayed, the arrow is directed out of the label node because it corresponds to the usage or dependency of the label and not to the real data flow. Generally, the following properties of the program graph are retrieved in order to get all necessary information for generating the GUI: All inaccessible nodes of the graph are considered to be starting points of the GUI inter and are made accessible to the user as a kind of GUI elements (e.g. buttons, menus, etc.) All temporal dependencies and concurrent occurrences of the GUI inters are determined in order to be mapped to sequences of elementary dialogs, which can be combined into more complex ones. Element name prefixes are also used to get dependencies; this is important especially for the concurrent s represented by more rules (e.g. Add:Finish and Add:Add s in our example). All cycles or independent cycle parts are determined in order to get temporal dialog hierarchies. These cycles have an influence on the repeated appearances of the nested dialogs in the enclosing ones. In addition, all necessary s to setup GUI elements when they are displayed (even repeatedly) are determined. In the given example, label and directives contain parameters to set their default values each time the GUI element is activated. The sequence of derived elementary dialogs for the previous example is shown schematically in Figure 5. Each elementary dialog corresponds to a unit of the user s inter performed concurrently (inters that are accessible at the same moment). These elementary dialogs are a result of the automatic analysis of the source code graph (see Figure 4) and are used internally as more concrete (although still abstract) internal user interface definition. Each box represents an elementary dialog. The arrows connecting boxes are used to show temporal dependencies of the dialogs. The contents of each box correspond to the concurrent (accessible at the same time) GUI elements for the particular dialog. The concrete mapping of the elementary dialogs and GUI elements to a platform-specific GUI is discussed in the following section. This process does not necessarily generate the GUI as a direct consequence of the program, because the analysis is performed globally on big part of the source code and the result follows the logical structure, not the program one. Average Compute Number label Add:Result Add:Finish Number Add:Add alert Done Figure 5. A sequence of derived elementary dialogs for the given example Generating Concrete GUI The platform specific GUI is generated in a way similar to generating GUIs from task models annotated by additional GUI related information [1][2] or abstract GUI description languages. It requires mapping the abstract GUI elements to concrete GUI elements supported by a given platform, and performing computations of (sub) optimal layout of the GUI elements including splitting the elements into groups that may not be visible simultaneously. There are several approaches to solve this problem with various advantages and drawbacks. 134

7 Abstract item text input input single item selection multiple item selection monitoring responding to alerts Possible mappings text field, text area, text field, slider, scroll bar, spin, combination of elements, radio buttons, combo box, list, text field, check boxes, list, gauge, label, status bar, modal dialogs, alerts, Table 1. Possible mappings of abstract items Since we are not focused on optimal GUI layout we use a simple ad hoc technique that in its basic form puts elements mostly vertically and eventually splits the form into several tabs to fit to the window if necessary. Particularly, this technique is sufficient for the defining the GUI for mobile devices where there are no complex layout managers. However, we can utilize even more sophisticated approaches (e.g. [4]) in the future and use customized managers for different devices such as mobile devices (e.g. using more low level inter), etc. Various possible mappings between the data transfer abstract GUI elements and concrete platform dependent GUI elements are shown in Table 1. Various alternatives can be considered with respect to additional optional parameters of an abstract GUI element in the source code. For example, if we expect a text input to be used to specify a name we can specify a text input abstract element with a numeric parameter 20 specifying that we expect approximately 20 characters, which is suitable to be mapped to a simple text field. For longer textual data a bigger value should be used and it will be likely mapped to a more complex text area. Important part of the GUI generation is splitting elements into separate groups. GUI elements in a group are displayed together and the groups can be switched either sequentially or in random order on a user request with respect to a source code temporal analysis. The sequential switching can be mapped to a sequence of events (invoked by e.g. a button Next ). The random concurrent switching of groups can be mapped to e.g. a tab GUI element. Other mappings can use e.g. dialogs invoked by buttons, etc. The Figure 6 shows a sequence of automatically generated dialogs with automatically generated GUI contents that corresponds to the program example in Figure 2 and the derived elementary dialogs shown in Figure 5. In this example, each elementary dialog is mapped to a separate window and contents of an elementary dialog to concrete contents of the corresponding window. a) b) c) Figure 6. Automatically generated dialogs from the program example (for Java AWT GUI toolkit) The dialog in Figure 6a is the initial dialog to be displayed at the beginning of the program and disappears as soon as the Compute button is pressed. Consequently the dialog in Figure 6b appears. Since this dialog is in the cycle repeated by the Add button, its nested GUI elements are updated in each cycle (when Add is pressed) to match the current state. As soon as the Finish button is pressed the dialog disappears and the last dialog from in Figure 6c is displayed until the OK button is pressed. Then the program is terminated. The same process has been used to generate a program with a GUI for different target devices. Figure 7 shows a sequence of generated dialogs as they appear on a screen of a mobile device (a Java-enabled mobile phone in this case). The GUI shown corresponds to the one from Figure 6 only the GUI elements are mapped to the different concrete elements according to the mobile device GUI specifications and limitations. a) b) c) Figure 7. Automatically generated dialogs for a Javaenabled mobile phone Both user interface example designs shown in Figure 6 and Figure 7 were generated automatically from the same source without any custom modifications of the source code for different target platforms. More complex examples that did not fit into the paper can be found at: CONCLUSION We have presented an approach to automatic generation of user interfaces from an annotated program source 135

8 code. This approach omits the explicit GUI definition either in a form of specifying concrete GUI elements and their layout or in a form of an explicit abstract GUI model definition or a task model. The approach presented is targeted especially for the application prototyping where the fast iterative development of functional application prototypes with functional and consistent GUIs associated is important. The GUI definition is made transparent using source code annotations in a form of user inter directives. The user interface module (separated from the application) is generated automatically from the annotated source code using source code analysis. In the early stages of the application development the application and its GUI change a lot. This approach enables programmer to keep the application and GUI consistent with no additional effort. To be able to analyze the annotated source code and generate the GUI with no additional help from a programmer we decided to use a variant of a tree rewriting based programming language. This choice enabled us to simplify the source code analysis and removed some ambiguities that appear in other commonly used languages. We have presented a graphical representation of the annotated program that helps a programmer to highlight or suppress various parts of the program such as the logic part of the program, details of the GUI directives, etc. FUTURE WORK During the work on this approach of automatic GUI generation we have identified several possible modifications and extensions that are worth further exploration. The decision to use the particular language based on tree rewriting was made in order to greatly simplify the program analysis and visualization. However, for practical reasons this system should be incorporated to a commonly used language. Using another widely used language complicates the program analysis and possible ways should be explored and problems have to be identified in more detail. The presented system currently generates an application with a GUI directly. However, for a further analysis of the task/dialog model of the application it should be possible to generate the models in addition to generating the application directly. There is a lot of work to be done in part of platform specific GUI generation. Currently, the element mappings and used layout managers are rather simple. Other more sophisticated methods to perform these mappings and (sub) optimal layout computations are to be considered. Precise evaluation methods and usability tests of such a system should be found in order to objectively evaluate the usability and limits, especially, with respect to the classic methods of GUI design for similar purposes. REFERENCES 1.Clerckx, T. and Coninx, K. Integrating Task Models in Automatic User Interface Generation. Technical Report TR-LUC-EDM-0302, EDM/LUC Diepenbeek, Belgium, Baron, M. and Girard, P. SUIDT: A task model based GUI builder. Proc. TAMODIA 2002, Inforec Printing House (2002), Eisenstein, J., Vanderdonckt, J., and Puerta, A. Applying model based techniques to the development of UIs for mobile computers. Proc. IUI2001, ACM Press (2001), Gajos, K. and Weld, D. S. SUPPLE: Automatically Generating User Interfaces. Proc. IUI2004, ACM Press (2004), Mori, G., Paterno, F., and Santoro, C. CTTE: Support for Developing and Analyzing Task Models for Interactive System Design. IEEE Transs on Software Engineering, Mori, G., Paterno, F., and Santoro, C. Tool Support for Designing Nomadic Applications. Proc. IUI2003, ACM Press (2003), O Donnel, M. J. Equational logic as a programming language, MIT Press, Oortmerssen, W. v. Concurrent tree space transformation in the Aardappel programming language. PhD thesis, University of Southampton, Pfaff, G. and Hagen, P. (Eds.) Seeheim Workshop on User Interface Management Systems, Springer- Verlag, Berlin, Puerta, A. and Eisenstein, J. XIML: A Common Representation for Inter Data. Proc. IUI2002, ACM Press 2002, Schneider, K. A. and Cordy, J. R. AUI: A Programming Language for Developing Plastic Interactive Software. Proc. HICSS , 281b (10 pp). 12. Shu, M. C. Visual Programming. Van Nostrand Reinhold, Schurr, A. Progres, a visual language and environment for programming with graph rewrite systems. Technical report, RWTH Aachen, Shneiderman, B. Tree visualization with tree maps: 2D space filling approach. ACM Transs on Graphics, 1992, Smith, D. C., Cypher, A., and Spohrer, J. KidSim: Programming agents without a programming language. Communications of the ACM, July Spence, R. Information Visualization. Addison Wesley (ACM Press), W3C. XSL Transformations (XSLT) Version