Proc. 33rd Australasian Computer Science Conference (ACSC 2010), Brisbane, Australia Improving End-User GUI Customization with Transclusion Lung-Chen Lee Christof Lutteroth Gerald Weber Department of Computer Science The University of Auckland 38 Princes Street, Auckland 1020, New Zealand Email:
[email protected],
[email protected],
[email protected]Abstract of another document by reference. In AIM, transclu- sion can be used to decompose GUI specifications, Usually the possibilities for end users to customize and to use and adapt specification parts in a different GUIs to their requirements are limited. We present context. From a developer’s perspective, this facili- a GUI specification and customization system, the tates reuse and maintenance. From an end-user per- Auckland Interface Model (AIM), that represents spective, this facilitates end-user development, consis- GUIs as documents that can be loaded, saved and tency among GUIs, and scoping of application data. changed by the end user during runtime. GUI layout This paper begins with a discussion of the bene- and GUI content can be customized independently, fits and the current limitations of GUI customization. and GUIs can be decomposed using transclusion. In The following section introduces the concepts and ad- this paper, we explain why transclusion is an impor- vantages of the document-orient approach as well as tant feature for GUI customization that does not only its implementation in the Auckland Interface Model, facilitate the maintenance of a GUI, but also supports followed by a discussion of how document decomposi- its consistency and clarity. Transclusion makes it eas- tion with transclusion improves the maintenance and ier to reuse GUI specifications, and support different the clarity of GUIs. Finally, our approach is evaluated customization scopes. AIM was implemented on sev- with the Cognitive Dimensions framework. eral platforms and evaluated using the cognitive di- mensions framework. 2 RELATED WORK Keywords: Transclusion, GUI customization, end- user development. 2.1 Findings on End-User Customization Different users may have different requirements for 1 INTRODUCTION the user interface of an application. Although a GUI designer may capture the common requirements for Graphical user interfaces (GUIs) are the most com- most users, it may satisfy users’ individual needs mon type of user interface in modern software appli- much better by allowing the users to customize the cations. Developing a good GUI requires a significant application. A study by Findlater et al. (Findlater amount of work because of usability considerations & McGrenere 2004) showed that the users were able such as learnability and suitability for a particular to customize the user interface to increase the effi- task. It is usually hard to understand the exact re- ciency. The majority of users also preferred a per- quirements of users upfront. As a result, it benefits sonalized interface. A later study (McGrenere et al. both developers and end-users if a GUI can be cus- 2007) on user’s customization on a word processing tomized easily. Developers can use GUI customiza- software with two types of menu interfaces also shows tion as a rapid development tool, i.e. to react to user the users do customize effectively when they are pro- feedback quickly. End-users can use GUI customiza- vided with an easy to use customization mechanism. tion to satisfy special requirements, such as simplified The users prefer the adaptable menu system which GUIs for novice users or larger widgets for users with they can control over the system-controlled adaptive visual impairments. However, most GUI applications menu system. offer only limited customization options. Making a Page et al. (Page et al. 1996) presented a study on GUI customizable usually involves significant extra the how users customize a word processor. The study work for the developers. finds that 92% of the participants customize the soft- In this paper we describe how GUI customization ware in some aspects. It indicates that users do cus- can be improved by supporting transclusion of GUI tomize software applications when they are presented specification parts. We describe a document-oriented with the options. The results show that the users tend GUI customization system (Draheim et al. 2006), the to customize the application more if they use the soft- Auckland Interface Model (AIM) (Lutteroth & We- ware more. The work they surveyed suggested that ber 2008), which has been implemented on the Java, the common obstacles to customizing software were .NET, and Haiku platforms. Document orientation the lack of time and the difficulty to customize the means that GUIs can be treated like documents, i.e. application. The study recommends a mindset of ex- they can be modified, saved and loaded at runtime. pecting the users to customize the software. The cus- Transclusion means that a document includes parts tomization should be made easy for them to use. The users should be able to switch between normal task Copyright 2010, c Australian Computer Society, Inc. This and the customization activities with little disruption. paper appeared at the Thirty-Third Australasian Computer Science Conference (ACSC2010), Brisbane, Australia. Con- In the discussion about the past, present and fu- ferences in Research and Practice in Information Technology ture of user interface software tools presented by My- (CRPIT), Vol. 102, B. Mans and M. Reynolds, Ed. Reproduc- ers et al. (Myers et al. 2000), it was suggested that a tion for academic, not-for profit purposes permitted provided “gentle slope system” that the user only needs to learn this text is included. incrementally would attract more users to overcome 163 CRPIT Volume 102 - Computer Science 2010 the initial threshold of customization. It also pro- known examples are Mozilla XUL (Cheng 1999) and posed that these capabilities should be supported by Microsoft XAML (Bishop 2006). There are other the underlying toolkit instead of by the individual ap- user interface languages such as UIML (Abrams et al. plications. This is in line with the Auckland Interface 1999) that have been developed but never gained Model, which provides the customization capabilities broad acceptance. All these approaches use docu- to all applications that use this system. ments – typically XML – to specify a GUI, therefore The studies above indicate that the users indeed we call them document-based. customize the user interfaces of the applications and In principle a document-based GUI is amenable it helps their efficiency and satisfaction of using the for end-user development, if end-user development is software application. However, at present, many ap- understood as development through a highly skilled plications provide the end-users a small degree of GUI power user. It is possible for power end-users to customization. The customization is usually limited edit the documents of GUI descriptions to change and may not persist between sessions or it may have the GUI. In the case of the code-based GUI, the cus- troubles in a multi-user environment (Kim & Lut- tomization may involve changing the code and recom- teroth 2009). Providing graphical user interface cus- pilation, which even a power end-user typically can- tomization functionalities in the application requires not do. The focus of the current GUI specification the developers to spend a significant amount of effort. technologies is on improving the GUI construction The traditional approach of developing the GUI of and maintenance for UI designers and programmers. a software application is to include the GUI as code in the program, which is mixed with the code for other 2.4 Transclusion functional parts of the program. There are some lim- itations with this approach. It is more difficult to de- The general concept of transclusion is to include one velop and maintain the program logic and the user in- document into another document by reference. In terface independently. It may cause difficulties for the this discussion, the document that includes another programmer and the user interface designer to work document is referred to as the transcluding document on their parts separately. It also makes it hard to cus- or the transcluding page. The document that is in- tomize a user interface. As the user interface is repre- cluded into another document is referred to as the sented as code, the customization requires changing transcluded document or the transcluded page. the code and recompiling the program. Furthermore, The term “transclusion” was coined by Ted Nel- because the user interface is described in a general son. He proposed a comprehensive system of view- purpose programming language, it is possible that the ing and sharing digital documents, known as Project user interface is generated by a complicated section of Xanadu (Nelson 1981, 2007). Transclusion specifies code. It is difficult for the developers to maintain and how documents are stored, addressed and edited to modify as it is hard to statically analyze the GUIs by construct different versions. It emphasizes that the only reading the code without executing the program. connection between the transcluding document and the transcluded document must be maintained. 2.2 End-User Customization Technology Ted Nelson’s idea is that of a “docuverse” that en- hances the viewing, editing and sharing of digital doc- Systems with various aims have been developed to en- uments more than merely imitating paper (Simpson hance the editing of the GUI and they have varying et al. 1996, Nelson et al. 2007). It provides a visu- effects on GUI customization for the end-users. Ex- alization of documents that indicates the connection isting approaches for GUI customization work either between the quoted content and the original context, in the windowing system, or rely on special widget and allows readers to view the original context. Con- toolkits. tent is reused by referencing the original source with- Implementing customization features into the win- out explicit copying of the content (Nelson 1995). A dowing system has the advantage that all applica- document is made of a sequence of global reference tions can be customized. However, customization is pointers that point to segments of content (Nelson very generic and does not take into account the ex- n.d.). Changing a document is regarded as creating act structure of a GUI. For example, User Interface a new version of the document and is done by edit- Fa¸cades (Stuerzlinger et al. 2006) is a system that al- ing the list of reference pointers to point to a new lows the user to copy and paste screen regions to du- sequence of segments. The characters at the existing plicate the GUI controls and arrange them for their content addresses never change. convenient use. Later approaches by other research groups adopt Using special widget toolkits drastically restricts the main feature of maintaining the connection be- the number of applications that can be customized, tween a transcluding and a transcluded document, but customization features can be closely integrated but support only some of the features of Nelson’s with the structure and logic of a GUI. For example, original transclusion idea. For example, Di Iorio EUPHORIA (McCartney et al. 1995) is a user inter- and Lumley investigated adding transclusion to XML face management system that allows the end-user to (Di Iorio & Lumley 2009). It attempts to add an construct the user interface of distributed multimedia transclusion mechanism to XML without building an applications with custom widgets. entirely new system like Project Xanadu. Another example is Krottmaier proposed a system to perform 2.3 GUI Description Languages transclusion for LaTeX documents to enable the in- clusion of content by reference (Krottmaier 2002). The main benefit of using separate languages to spec- The transcluding document embeds a macro, and a ify GUIs is the separation of concerns (Draheim et al. server processes the macro to compose the document 2006). Separating the specification of the GUI from with the transcluded content before sending it to a the program logic makes the structure of an applica- client. tion clearer, and allows developers to edit the GUI without navigating the program logic. As such, GUI 3 DOCUMENT-ORIENTED GUIS description languages are a software engineering tech- nique more than an interaction principle. The document-oriented approach views a GUI as a Many GUI description languages have been de- structured document analogous to forms that can be signed to specify GUIs declaratively. Two better created in office applications (Draheim et al. 2006). 164 Proc. 33rd Australasian Computer Science Conference (ACSC 2010), Brisbane, Australia Many capabilities of the GUI can be explained in lists, check boxes or radio button groups, or numer- terms of this metaphor. For example, the ability of ical values in sliders. The data in such widgets are the user to interact with many typical controls such stored as widget properties in an AVM description. as text areas and check boxes is analogous to filling By loading and saving AVM specifications, users can out a predefined form. manage, reuse and share the data represented in a Document-orientation means that the UI render- GUI. ing infrastructure incorporates editing functionality, and therefore GUIs can be edited directly by end- users. The GUI framework behaves like a WYSIWYG 4 DECOMPOSITION OF GUIs office application. Since customization will typically Document-orientation supports the decomposition of be viewed as a separate activity from actually using GUIs, similar to the way it is done for other types of the GUI, the GUI framework distinguishes an edit documents. GUI specifications in AIM are composed mode, where the GUI can be directly edited, and an of parts such as layout areas and constraints in ALM operational mode. The developers can give editing layout specifications, and widgets with properties and access rights to end-users, and hence control the level data values in AVM content and data specifications. of customization that is allowed. In order to reuse GUI specification parts, transclusion In AIM, our implementation of a document- is employed. oriented system, the customization function is inte- When a change is made to a part, the change is re- grated into a layout manager. As a result, customiza- flected in all documents using the part. This is similar tion is available in every GUI that uses the layout to the way a change in a style sheet affects all the doc- manager, without additional development effort. Af- uments that use the style sheet. It enables centralized ter switching to the edit mode, parts of the GUI can maintenance, while still enabling special customiza- be visually rearranged, removed or replaced. This is tions in individual user documents. If transclusion is supported by direct manipulation, e.g. users can drag not used and the same part is duplicated in multiple and drop parts of the GUI. More information about documents, changes would have to be made to all the the edit mode of AIM can be found in (Lutteroth & individual documents, which would frequently lead to Weber 2008). inconsistencies. The following sections discuss advan- AIM supports a particularly strong separation of tages and usage scenarios of GUI decomposition using concerns in GUI applications. Whereas other tech- transclusion. nologies support only a separation of user interface and application logic, AIM further separates parts of the GUI: it is possible to separate the GUI layout 4.1 Sharing and Reuse from the GUI content and the GUI data. GUI con- tent refers to the widgets in a GUI, and GUI data to AIM documents can easily be copied and shared. The the data values that are represented in the widgets. capability to share and reuse a customized GUI is The different concerns of GUI specification in AIM a useful feature for end-users as well as for devel- are described in the following. opers. For example, if one person in an office cus- tomizes the GUI appearance and the program set- tings of an application to be convenient for the tasks 3.1 GUI Layout performed in that person’s team, it would be great for other team members to have the same adjustments to The Auckland Layout Model (ALM) is a mathemat- their GUI. Without document orientation, the per- ical model that allows precise, platform independent son would have to repeat the customization steps on specification of GUI layouts, i.e. the visual arrange- each of the team member’s computers. Naturally, it ment of widgets in a GUI, and their dynamic behav- is much easier if the customized GUI can directly be ior, i.e. how they change under resizing. The layout of shared with the other team members. Team members a GUI is described by specifying horizontal and verti- benefit from the customization, and retain the flexi- cal tabstops – grid lines that are used to align widgets bility to perform individual adjustments. For devel- – and linear constraints. Each widget area is bound opers the concept of reuse is very common, and in fact by a pair of x-tabstops and a pair of y-tabstops. ALM an essential principle of software engineering. Hence, uses linear programming to compute the layout of a having a reuse mechanism for GUI parts makes GUI GUI. development easier. GUI layouts can be loaded and saved in a platform- independent specification language. This language refers to the widgets in a layout by symbolic names. 4.2 Consistency This means that the layout can be specified indepen- dently from the widgets and their content. A main application of GUI transclusion is to ensure consistency in GUIs. This may be consistency in the layout, the widget appearances, or the GUI data. 3.2 GUI Content The GUI content of AIM is handled by the Auck- 4.2.1 Consistent GUI Appearance land Value Model (AVM). AVM provides a descrip- tion language to specify the GUI content, i.e. all When GUI designers develop a GUI, they usually the widgets in a GUI and their properties. AVM want it to look coherent overall. They are likely to is platform independent, i.e. it defines abstract wid- design similar widgets so that they have a common get types. When an AVM specification is loaded, style. For example, buttons should typically have the platform-specific adapters are used to instantiate and same background color, and textboxes should use the configure widgets so that they match the specifica- same font. This is similar to the use of style sheets tion. AVM supports loading as well as saving. as commonly used in word processing documents and web user interfaces. In AIM, designers may create template widgets for 3.3 GUI Data a GUI, e.g. a template button with a particular color and font. If the buttons on the GUI all transclude the AIM also enables the data that are presented in the template button, they have the same appearance as widgets of a GUI to be customized. For example, such default because the buttons reuse the properties of the data could be strings in textboxes, selected items in template button. When the UI designers or the users 165 CRPIT Volume 102 - Computer Science 2010 change the template button, all buttons change to 4.4 Scoping the new appearance. As the designers frequently edit the user interface to try out new styles, it is easy to Document-orientation makes it possible to customize make a global change. It is less likely that individual GUIs in different scopes, such as between sessions or widgets are forgotten and end up having inconsistent across different applications. For example, an appli- appearances. cation may hold the only copy of a particular print A similar approach can be taken with GUI lay- dialog window specification. The same dialog window outs. Sometimes features of a layout are reused. For is displayed to all users because the same GUI spec- example, many layouts have toolbars at the top and ification is used application-wide. GUI declaration a status bar at the bottom. By reusing layout parts, units can also be specified in user-specific documents, consistency can be achieved more easily. For exam- thus allowing different users to have different dialog ple, a GUI designer may decide to locate the toolbars windows. Separate copies of GUI specifications for at the side instead of the top. With the proper use of the same dialog window enable individual users to transclusion, such a change can automatically adjust have customized user interfaces for the same applica- all the GUI windows of an application suite accord- tion, while some parts of a GUI can stay the same for ingly. all users. Typical scopes would be user, organization, application, platform, session, and document. The decomposition mechanism allows different 4.2.2 Consistent Program Settings scopes of customization to suit different roles. For Transclusion of GUI data is useful for options and example, the system administrator is able to change preferences dialogue windows, where frequently differ- some settings on an application, and the change takes ent sets of settings need to be managed. For example, effect for all users when they use the application. Indi- a user may want to use the same print dialogue set- vidual users may customize their own UI to suit their tings in a web browser, a word processor and a PDF individual needs. The decomposed GUI declaration document viewer. Using AIM, different applications units are stored at appropriate locations to enable the can use the same data for the settings in a dialogue. different roles to access them. The settings are stored as properties of widgets in For example, an IT administrator may supply de- an AVM description. The user can set an application fault print settings to all users. As AIM supports to use the same AVM description for a part of the different scopes of customization, when the IT ad- GUI as another application. Consequently, different ministrator wants to change the default values for all applications can present the same print settings to users, she can edit the values contained in the AVM the user. description of the print dialogue. The change affects AIM can also be used to manage different sets of all users. If an individual user wants settings different data that are used in different contexts. For example, from the default settings, the user can edit the AVM if the user needs different settings for printing photos description that is used only by the user. than for printing presentation slides, the user may Not all document concepts support fully recur- load different AVM descriptions of the print dialogue sive transclusion. HTML notoriously did not do so with different values of the GUI widgets. from the start. In contrast, in our implementation Managing program settings in the GUI is also use- of the document-oriented approach, we support full ful for system administrators. If the users’ GUIs tran- transclusion, as well as standard document locations. sclude the settings from the system wide setting, all This allows the user or application designer to store users would have the same settings by default. When information per application, per user or per file. The a system administrator changes a particular system- concept of the scope of a GUI customization is thus wide setting, all users get the new default setting. It mapped to the concept of a file location, a good ex- avoids the possible inconsistencies when settings are ample, how the document metaphor is mapping the changed individually for each user. An administra- semantics of the customization to familiar concepts. tor can also use this mechanism to manage different settings for different groups of users. 4.5 Scope Visualization This approach also motivates a refinement of transclu- 4.3 Overriding sion: the location of the data is not hidden from the Transclusion allows different users to reuse the same user, as it would happen in most other approaches, GUI parts. In AIM, users can also customize the but actually displayed to the user; moreover it can transcluded parts without breaking the relationship be changed by the user. Since this location informa- between the transcluder and the transcludee. Indi- tion is chiefly logical and non-obfuscated (i.e. it says vidual properties of a transcluded part can be over- “scope: user bert” or “scope: application myEdit- ridden in the transcluding document. For example, Pad” instead of a URL or an equally opaque UNIX file a user may transclude all the system-wide print set- path) it enhances documentation and transparency of tings, but override the default paper size. The user the user interface. This is in stark contrast to many may later discard their individual program settings to auxiliary documents in standard office applications, use the system-wide settings again. To do this, the where the scope of a setting is very unpredictable, user only needs to remove the personal settings that sometimes being the file, sometimes the office suite, override the system-wide settings, i.e. the transclusion sometimes the session, and this scope is not made from the system-wide settings will still work. explicit to the user, let alone being configurable. Fi- In comparison, Cascading Style Sheets (CSS), nally, the fact that we see GUIs as documents editable which is used for web user interfaces but not for stan- by a WYSIWYG editor gives the user full control over dalone applications, also offers overriding of UI ap- GUIs. pearance to a limited extent. The difference is CSS In our design, using transclusion enables the sys- does not allow as fine-grained customization as AIM tem to provide the information about the scope of does. CSS style sheets can only import other style setting the value of a component on the interface. An sheets as a whole; it is not possible to import only example is for changing the settings in the print di- parts of another style sheet, whereas AIM specifica- alogues of various software applications. Some appli- tions can transclude individual widgets selectively. cations like the Microsoft Office applications use the same print dialogue for all open instances of the same application. If the users change the option to turn 166 Proc. 33rd Australasian Computer Science Conference (ACSC 2010), Brisbane, Australia on double-sided printing on one MS Word window, and then switch to another instance of Word to print, the second instance also has the double-sided print- ing turned on. Other applications may behave dif- ferently when print settings are changed. For exam- ple, OpenOffice.org Writer is another word processing application. When the print settings are changed, the changes only affect this instance of the applica- tion. Print settings in other instances of OpenOf- fice.org Writer are not affected. The inconsistent scope of changes in different applications may con- fuse the users. Figure 2: A print dialogue with the scope of the paper size setting as file-specific the scope of GUI controls when the GUI is in the edit- ing mode. There are several proposed ways of chang- ing the scopes and they will be investigated in our research. As AIM allows the users to move the GUI controls when it is in the editing mode, one possible way to change the scope of a GUI control is to sim- ply move it to inside of the container of the desired scope. Another possibility is to drag and drop the edge of the group container to include new widgets. Figure 1: A print dialogue consists of options of dif- For example, Figure 2 shows that the scope container ferent scopes, which are indicated by the descriptions for the file has been expanded to include the paper of the group boxes size setting as a setting for only this file. When transclusion is used, the UIs of the settings 5 IMPLEMENTATION are loaded from different settings files, which contain the values hold by the components. The resulting The GUI content of AIM is handled by the Auckland UI may be composed of components from different Value Model (AVM) component. AVM provides a scopes. An example of a print dialogue is shown in content description language to specify the GUI wid- Figure 1. The system knows which GUI control is gets and GUI values, i.e. all the widgets in a GUI and from which UI document file and can use this infor- the values they hold. mation to inform the users about the different scopes An engine called the AVM Engine processes the of the controls. Extra visual elements are introduced content description language. It facilitates instantiat- in the GUI to convey this information. ing widgets from the content specification, and saving One possible way to indicate the scopes of the dif- widgets to the content description. A current imple- ferent GUI controls is to decorate controls individ- mentation of the AVM Engine is written in the Java ually. Another way is to use visual containers to programming language. It converts widgets between separate the controls in different groups. A visual the AVM description and the Java Swing GUI compo- container encloses the UI components that are con- nents. It also handles the transclusion of the widgets. cerned with settings that affect only this particular file, and another container encloses controls that be- long to another scope. In the example shown in Fig- 5.1 AVM Specification ure 1, a group box is used to enclose the components. AVM uses PDStore as its data access layer and it de- The caption of the container indicates the scope of fines the model of the AVM specification. PDStore is the settings that are inside this container. In this ex- a structured database system that uses GUIDs (glob- ample, the Printer setting is for this particular file, ally unique identifiers) for all data instances. An as- MyDoc1.odt. If the user edits this setting, it does sociation between instances also has a GUID, which not affect the same print dialog setting used in other is the role ID that is used to find the associated in- files. stances of an instance. An example in the AVM spec- The example has another container that contains ification is that a button has a role ‘background’. We the settings for the particular user’s files that are may use the ID of the ‘background’ role to access the opened by this application. The settings ‘Paper size’ instance in PDStore that represents the background and ‘Orientation’ are inside this container. If the user value of the button. PDStore allows the AVM En- James changes the paper size from A4 to A3, the other gine to access the AVM specification stored in the files James opens using the same application Open- database in a more object-oriented manner. text will also have the paper size as A3 when he opens An AVM specification is defined as having a num- the print dialogue. The extra visual elements clarify ber of widgets. A widget has a value, which repre- which settings have which scopes of effect. The users sents the value held by a widget such as the text of are better informed when they use this GUI and they a text box. It also has a transclusion associated with are more confident that the changes they make will it to specify which widget it transcludes. A widget not cause unintentional changes. is associated with an instance of a particular type of The user interface also allows the user to change widget, e.g. a text box or a button. This concrete 167 CRPIT Volume 102 - Computer Science 2010 type of widget has a number of property values. This the transcluded faculty-wide widget, which contains is summarized with the following diagrams. Figure 3 the value A4. in the end, the AVM Engine uses A4 in is a trimmed down model of the AVM specification the paper size text box for the user’s print dialogue. showing two types of widgets each with two proper- A case could be the department finds that printing ties. Figure 4 is a sample of two instances of AVM on the larger A3 paper is the norm for this depart- specifications. ment, and decides to change the default paper size for all users in the department. It then replaces its the null value of the paper size widget to A3. The AVM Engine looks for the value in the transcluded widget, it finds A3 and uses it. Figure 3: PD model of AVM specifications. Figure 5: The widget PaperSize in UserSpec tran- scludes the value ‘A4’ from PaperSize in FacultySpec. The following pseudo-code describes loading of transcluded widget values: 1: while value = null and current widget 6= null do 2: Read the value of the current widget 3: Find the transcluded widget and make it the current widget for subsequent processing 4: end while 5.3 Transcluding Widget Properties The widget properties, which determine the appear- ance of the widget, may also use the property values of the transcluded widget. For example, a GUI de- signer makes a button of light green background and dark blue text and wants it to be the default style of the buttons of the GUI. The designer edits all the Figure 4: Two AVM specifications. Widget2 tran- buttons to transclude this button and leaves all prop- scludes Widget3. erty values as null. Figure 4 is an example. When the AVM Engines loads a button, it looks for the property values. It records all properties that have values. There is none in this case. It then finds the 5.2 Transcluding Widget Values transcluded widget. It checks the widget is of the A widget may hold its own value, in which case this same type, i.e. a button. The AVM Engine then read value is used. If the value of a widget is null, the property values for properties that do not have val- widget uses the value of the widget it transcludes. If ues yet. In this case, it records all the property values the transcluded widget does not hold a value, either, of the template button. As it has collected non-null it in turn finds its transcluded widget and uses the values for all properties, the search for transcluded value of that widget. The search ends when it finds a property values is complete. The AVM Engine uses value. the collected property values to set the appearance of The following shows an example of the text box the instantiated widget. For this example, the but- that holds the value of the paper size in a print dia- ton would have the same appearance as the template logue. The text box in the user’s AVM specification button. trancludes the paper size text box in the department- The following pseudo-code describes loading of wide AVM specification of the print dialogue. It in transcluded widget properties: turn transcludes the size text box in the faculty-wide 1: Get the set of widget property role IDs of this AVM specification. When the AVM Engine loads the type of widget from the widget adapter paper size text box, it finds the its value is null. So 2: while set of property role IDs is not empty and it looks for the transcluded department-wide widget, the current widget is not null do which does not contain a value, either. It then finds 168 Proc. 33rd Australasian Computer Science Conference (ACSC 2010), Brisbane, Australia 3: for each property that has not obtained a 5.4 Changing Widget Values value do 4: Use the property role ID to access the When the user uses a new value for a widget that cur- property value of the current widget rently uses a transcluded value, the widget replaces 5: if the value is not null then the null value with the new value. The widget uses its 6: Record (role ID, value) in the hash ta- own value and properties it holds, while using tran- ble for property values scluded values for other properties. Effectively, the 7: Remove the role ID from the set of widgets’ own values override the transcluded values. property role IDs If the user later decides to change back to using the 8: end if transcluded value, it is done by changing the value to 9: end for null to specify the value is be found in the transcluded 10: Find the transcluded widget and make it the widget. current widget for subsequent processing 11: end while 5.5 Widget Adapters 12: for each property remaining in the set of property role IDs do The AVM Engine uses a set of widget adapter classes 13: Set the property to its system default value to process the various types of widgets. A widget 14: end for adapter provides a standard API that allows AVM 15: for each property in the hash table do Engine to access the properties of a particular type of 16: Retrieve its value and use the widget adapter widgets. The API wraps the actual platform specific to set the corresponding property of the instanti- calls that access the widget properties. Therefore, ated widget the AVM Engine is not concerned with platform spe- 17: end for cific details. New widget adapters can also be easily added to the AVM Engine to provide the processing Suppose the designer wants a few buttons for a capability for a new type of widgets. particular section of the GUI to have a bright yellow A widget adapter provides a standard API that background. The designer creates a new widget of allows the AVM Engine to access the properties of a the button type in the AVM specification. The new particular type of widgets. The API of the widget button has yellow as its background color and holds adapter is as the following: null for all other property values. It transcludes the template button. The designer edits the buttons of 1 public interface WidgetAdapter { the particular section to transclude the new button. 2 JComponent New(); When the AVM Engine loads a button, it again does 3 GUID getTypeId(); not find any property values in the button itself. It 4 GUID getWidgetRoleId(); goes to the transcluded widget and finds the newly 5 created button holds the value of the background 6 Object getValue(JComponent widget); color. It records yellow as the background color and 7 void setValue(JComponent widget, goes to the transcluded widget to find other property 8 Object value); values. It records the values of other properties of the 9 template button. The AVM Engine uses the property 10 GUID[] getAllPropertyRoleIds(); values to instantiate a button that has the appearance 11 String getPropertyType( of the template button except the background color 12 GUID propertyGUID); is yellow. The text is dark blue as it uses foreground 13 Object getProperty(JComponent widget, value of the template button but it has yellow as the 14 GUID propertyGUID); background value comes from the new button. The 15 void setProperty(JComponent widget, AVM specification is shown in Figure 6. 16 GUID propertyGUID, Object value); 17 18 Object getPropertyDefaultValue( 19 GUID propertyGUID); 20 boolean hasPropertyDefaultValue( 21 JComponent widget, GUID propertyGUID); 22 void resetPropertyToDefaultValue( 23 JComponent widget, GUID propertyGUID); 24 } The method New is used for instantiating an ac- tual widget in the program. The type of widget adapter determines the type of widget that is cre- ated. The getTypeId and getWidgetRoleId methods are used to tell the AVM Engine the type ID and role ID of this type of widget in the PD model. It en- ables the AVM Engine to retrieve the corresponding instance of this type of widget in the AVM specifica- tion. getValue and setValue provide access to the prop- erty that is considered as the value of a particular type of widget. For example, the text inside the text box is considered as the value of a text box. getAllPropertyRoleIds tells the AVM Engine all Figure 6: Widget1 uses the background color from the properties in a type of widget. getPropertyType YellowButtonWidget and uses the foreground color indicates the value type of a property, so the AVM from ButtonWidget. Engine knows how to parse the property value. The property value is accessed by using getProperty and setProperty. 169 CRPIT Volume 102 - Computer Science 2010 For a property, getPropertyDefaultValue, 6.0.4 Diffuseness / terseness hasPropertyDefaultValue, and resetProperty- ToDefaultValue allow the AVM Engine to retrieve The transclusion concept presented here needs very the default value, check whether a widget holds the little symbols, as is evident from the examples. The default value, and set it to the default value for the only symbol necessary is a group box, and the syntax widget respectively. of the context, consisting of the colon separating the The API encapsulates the platform specific calls context type and the context instance (user: Pat) and that access the widget properties. Internally, the the comma separating different context specifications. widget adapter translates the standard call from the The standard context types which will appear in AVM Engine to an actual method call on a GUI most cases, such as user, organization, and perhaps component instance in the underlying GUI plat- file, have a middle position between being elements form. For example, the text of a text box is con- of the notation itself, or being just applications of the sidered the value of the text box widget. When notation, albeit in widespread use. setting the text of a text box, the AVM Engine calls: adapter.setValue(nameTextBox, “Robert”); 6.0.5 Error-proneness The TextBoxAdapter then translates it into: name- TextBox.setText(“Robert”); The transclusion approach cannot prevent all errors, New widget adapters can be developed by imple- but it is not specifically error prone. The main errors menting the API. The new widget adapters can be that can be ascribed specifically to the transclusion added to the AVM Engine to enable it to process more approach are errors in the chosen context. A context types of widgets. too wide might create unwanted effects. This is usu- ally prevented by access rights, i.e. the settings for the organization context can be used, but not changed 6 EVALUATION by all users. We used the Cognitive Dimensions framework (Green & Petre 1996) to evaluate the use of the transclusion 6.0.6 Hard mental operations mechanism within the document-oriented paradigm. The hard mental operations are not on the notational This framework allows us to qualitatively evaluate level. On the semantic level, it sometimes needs some our approach against a set of standard dimensions, thought where from to transclude a setting, but it is and to find issues with the approach. This framework our impression that this is a direct consequence of the has been used successfully in the past (Reid & Plim- desired outcome. The lack of flexibility of current sys- mer 2008). We used the print-dialogue and the page tems however, where one simply has no choice, seems settings dialogue in text processing applications, and hardly to be an advantage. compared their implementation in standard text pro- cessing applications with a mock-up implementation based on AIM. Dimensions that are not yet addressed 6.0.7 Hidden dependencies are: progressive evaluation, viscosity, visibility and Through the context path, the transclusion approach role-expressiveness. clarifies dependencies that are normally hidden in GUIs. 6.0.1 Abstraction Gradient Abstraction is a central feature of the transclusion 6.0.8 Juxtaposability mechanism. Through transclusion, sets of parameter An element of juxtaposability is planned for later ver- settings can be reused, for example as default settings. sions. It should then be possible to see for one value Through this reuse, the individual places where this that is overridden both, the current overriding value reuse happens can be oblivious to the details of those as well as the overridden value. parameter settings. 6.0.9 Premature commitment 6.0.2 Closeness of Mapping In the normal editing process, if a transclusion path is The transclusion mechanism is a direct and immedi- changed and a value is overridden with an overriding ately understandable representation of practices that value, the overridden value cannot be changed at this can be found in every workplace even beyond the IT position. Another timing issue that is in connection world. The idea that a certain assumption is by de- with error-proneness is related to the scope of change. fault valid for a large social context, and local devi- We consider the print dialogue and assume the pa- ating rules are explicitly stated, is a widespread no- per size has currently the transclusion context “file”. tion. A typical example would be speed rules in traf- Now we want to do two changes: change the paper fic. There are rules by default, and these rules can be size and change the transclusion context to “user”. overridden by local changes. Here a timing issue can arise. If one first changes the paper size and then changes the context, then this is 6.0.3 Consistency not equivalent to first changing the context and then changing the paper size. In the first case we change a The central consistency question is the scope of setting in a context and then immediately leave that changes to parameters. In conventional GUIs, as out- context, thus the changed setting is not used. In- lined by the examples, the scope of changes is often tuitively this is likely an error. One of the features not explained and moreover counterintuitive. In our that is planned but not yet implemented is a “did approach, once a number of individual scopes have you mean” warning in this case. If the user actually been encountered, such as “settings for department”, meant to do it the other way round and do the change “settings for file myfile.txt”, the user will understand in the new context, the system offers the possibility easily notions such as “settings for user Pat”. to bring things in order. 170 Proc. 33rd Australasian Computer Science Conference (ACSC 2010), Brisbane, Australia 6.0.10 Secondary notation and escape from appliance-independent XML user interface lan- formalism guage’, Computer Networks 31(11), 1695–1708. Certain mechanisms of the transclusion approach can- Bishop, J. (2006), Multi-platform user interface con- not be replaced by informal notions, since they are struction: a challenge for software engineering-in- immediately evaluated in the running system. The the-small, in ‘ICSE ’06: Proceedings of the 28th transclusion path itself has to refer to an existing con- international conference on Software engineering’, text or a new context has to be created. Secondary ACM, pp. 751–760. notation can take several forms in GUIs, and some of them, such as help systems, are beyond this presen- Cheng, T. (1999), XUL – creating localizable XML tation. The notation can in principle be enriched, for GUIs, in ‘Proceeding of the 15th International Uni- example with icons for contexts, however this requires code Conference’. changes to the framework. A further secondary notation that is of interest Di Iorio, A. & Lumley, J. (2009), From xml inclusions here and that is readily available in the framework is to xml transclusions, in ‘HT ’09: Proceedings of the textual comment by the individual user, directly in 20th ACM conference on Hypertext and hyperme- the user interface. This is certainly not possible in dia’, ACM, New York, NY, USA, pp. 147–156. conventional GUIs. In AIM this is right away pos- Draheim, D., Lutteroth, C. & Weber, G. (2006), sible. Every AIM GUI comes with an inbuilt edi- Graphical user interfaces as documents, in ‘Pro- tor, which allows end users for example to add la- ceedings of CHINZ 2006 – 7th International Con- bels. The user can annotate for example the paper ference of the ACM’s Special Interest Group on size input field with comments on important usages. Computer-Human Interaction’, ACM Press. These comments again are stored in transcluded con- texts and this determines the visibility of the informal Findlater, L. & McGrenere, J. (2004), A comparison comment. Therefore AIM acts additionally as a tool of static, adaptive, and adaptable menus, in ‘CHI support for the dissemination of secondary notation, ’04: Proceedings of the SIGCHI conference on Hu- without losing informality. man factors in computing systems’, ACM, pp. 89– Informal content is currently boxed, i.e. the com- 96. ment takes the form of labels (the borders are however invisible) that are placed at certain points. This hints Green, T. R. G. & Petre, M. (1996), ‘Usability anal- at further work, where more general annotations with ysis of visual programming environments: A ’cog- a transparent pane would be thinkable. nitive dimensions’ framework’, Journal of Visual Languages and Computing 7(2), 131–174. 6.1 Summary of Evaluation Kim, J. & Lutteroth, C. (2009), Multi-platform document-oriented guis, in ‘AUIC ’09: Proceed- The evaluation through the cognitive dimensions ings of the 10th Australasian User Interface Con- framework allows us to attribute features of the tran- ference’, ACM. sclusion approach to standard dimensions. With this method we have found issues where further work is Krottmaier, H. (2002), Transcluded documents: warranted, namely in the dimensions of juxtaposabil- Advantages of reusing document fragments, in ity, secondary notation and premature commitment. ‘ELPUB’. While the first two dimensions have hinted us at in- teresting nice-to-haves for further work, the last di- Lutteroth, C. & Weber, G. (2008), End-user GUI mension, premature commitment showed us a more customization, in ‘Proceedings of CHINZ 2008 - important issue that should be addressed with more 9th International Conference of the ACM’s Special urgency. Interest Group on Computer-Human Interaction’, ACM Press. 7 CONCLUSIONS McCartney, T., Goldman, K. & Saff, D. (1995), ‘EU- PHORIA: End-user construction of direct manipu- Current GUI customization technologies are limited lation user interfaces for distributed applications’, and do not take advantage of decomposition mecha- Software - Concepts and Tools 16(4), 147–159. nisms such as transclusion. The Auckland Interface Model (AIM) is an open-source, cross-platform tech- McGrenere, J., Baecker, R. M. & Booth, K. S. nology that uses the document orientation to provide (2007), ‘A field evaluation of an adaptable two- easier and more comprehensive customization for end- interface design for feature-rich software’, ACM users. AIM separates the concerns of GUI layout, Trans. Comput.-Hum. Interact. 14(1), 3. GUI content and GUI data, and enables end-users to Myers, B., Hudson, S. E. & Pausch, R. (2000), ‘Past, treat GUIs as documents. This makes it possible to present, and future of user interface software tools’, customize GUIs and decompose them using transclu- ACM Trans. Comput.-Hum. Interact. 7(1), 3–28. sion. The use of transclusion has advantages for GUI developers and end users: it facilitates reuse, con- Nelson, T. H. (1981), Literary Machines, Mindful sistency, introduces different scopes of customization, Press. and clarifies to the end user where values in a GUI are actually stored. AIM was evaluated using the cogni- Nelson, T. H. (1995), ‘The heart of connection: hy- tive dimensions framework, and we could identify the permedia unified by transclusion’, Commun. ACM dimension premature commitment, for instance, as a 38(8), 31–33. potential issue that should be addressed in further work. Nelson, T. H. (2007), ‘Transliterature: A human- ist format for re-usable documents and media’. http://transliterature.org/. References Nelson, T. H. (n.d.), ‘Xanalogical structure, needed Abrams, M., Phanouriou, C., Batongbacal, A., now more than ever: parallel documents, deep links Williams, S. & Shuster, J. (1999), ‘UIML: An to content, deep versioning, and deep re-use’, ACM Comput. Surv. p. 33. 171 CRPIT Volume 102 - Computer Science 2010 Nelson, T. H., Smith, R. A. & Mallicoat, M. (2007), Back to the future: hypertext the way it used to be, in ‘HT ’07: Proceedings of the eighteenth conference on Hypertext and hypermedia’, ACM, pp. 227–228. Page, S. R., Johnsgard, T. J., Albert, U. & Allen, C. D. (1996), User customization of a word proces- sor, in ‘CHI ’96: Proceedings of the SIGCHI con- ference on Human factors in computing systems’, ACM, pp. 340–346. Reid, P. & Plimmer, B. (2008), A collaborative mul- timodal handwriting training environment for vi- sually impaired students, in N. J. Bidwell, ed., ‘OZCHI’, Vol. 287 of ACM International Confer- ence Proceeding Series, ACM, pp. 195–202. Simpson, R., Renear, A., Mylonas, E. & van Dam, A. (1996), ‘50 years after “as we may think”: the brown/mit vannevar bush symposium’, inter- actions 3(2), 47–67. Stuerzlinger, W., Chapuis, O., Phillips, D. & Rous- sel, N. (2006), User interface fa¸cades: towards fully adaptable user interfaces, in ‘UIST ’06: Proceed- ings of the 19th annual ACM symposium on User interface software and technology’, ACM, pp. 309– 318. 172