User Interface Reverse Engineering

Transcription

1 User Interface Reverse Engineering Laurent Bouillon & Jean Vanderdonckt Université catholique de Louvain (UCL) School of Management (IAG) Unit of Information Systems (ISYS) Belgian Laboratory of Computer-Human Interaction (BCHI) Place des Doyens, 1 B-1348 Louvain-la-Neuve (Belgium) {bouillon,vanderdonckt}@isys.ucl.ac.be Abstract Reverse engineering transforms a final user interface into a logical representation that is manipulable enough to allow forward engineering to port a UI from one computing platform to another with maximum flexibility, minimal effort. 1 Introduction Portability of a User Interface (UI) generally refers to the capability of a UI to be ported from one computing platform to another with an effort that remains minimal. Galaxy ( enables developers to design a UI on one platform, say MS Windows, and to export it without any change to other platforms, e.g., Mac OS X and Linux. The individual UIs then adhere to the Look and Feel that is proprietary to the respective platforms. The development of a UI does not frequently bear in mind the future wish of portability. Consequently, when then need arises to port a UI from one platform to another, it is rather difficult to support this porting. Developers do not necessarily want to start again from scratch to design a UI for a new platform since a UI already exists that could make a potential source of inspiration, if not a starting point. In this second case, transcoding tools automatically transform a UI code from the original platform to a new UI code for the target platform. This transformation can occur at design-time (i.e., the transformation is made one for all and re-inserted for the new platform) or at run-time (i.e., the transformation is performed on demand when the UI is requested). Any HTML page can be transformed into a WML (Wireless Markup Language) deck of cards on the fly when the mobile phone user accesses a web page (Kaasinen, Aaltonen, Kolari, Melakoski, & Laakko, 2000). Portability and transcoding tools suffer from shortcomings: the former only produces the same UI layout for all platforms while the latter only apply code to code transformation tat are peculiar to any couple (source platform, target platform). Both remain inflexible (no design alternatives), uncontrolled (no human intervention to fine tune the transformation), and very specific (hard to generalize to other couples). They do not necessarily consider constraints imposed by the target platform such as: operating system, programming language, screen resolution, interaction capabilities. To overcome these shortcomings and to address the needs of UI portability, we argue that a UI reverse engineering process can be combined with UI forward engineering process to produce not only more usable UIs in a logical way, but also to take benefit from the reverse engineering to port a UI to any other target platform.

2 2 User Interface Reverse and Forward Engineering The Cameleon Reference Framework locates UI development steps for context-sensitive interactive applications (Calvary, Coutaz, & Thevenin, D. (2001). A simplified version (Fig. 1) structures development for two contexts of use, here for two platforms: the left one represents the source whereas the right one represents the target. The development process in decomposed into three steps: 1. Task and concepts: describe the various tasks to be carried out and the domain-oriented concepts as they are required by these tasks to be performed. 2. Logical UI: defines working spaces by grouping subtasks according to various criteria (e.g., cognitive load, semantic relationships, shared concepts), a navigation scheme between the working spaces and selects Abstract Interaction Objects (AIOs) (Vanderdonckt Bodart, 1993) for each concept so that they are independent of any target computing platform. 3. Physical UI: concretises a logical UI for a given context of use into Concrete Interaction Objects (CIOs) (Vanderdonckt & Bodart, 1993) so as to define widgets layout and interface navigation. 4. Final UI: is the operational UI represented by its full code that is compilable and executable or interpretable. å Task & Concepts ƒ Task & Concepts Logical UI ñ Logical UI ê Physical UI ò Physical UI Final UI ô Final UI Source platform Target platform Figure 1: The Cameleon Reference Framework (simplified version). Not all steps should be achieved in a sequential ordering dictated by the levels. Instead, locating what steps are performed, when, from which entry point and toward what subsequent step is important. In Figure 1, transcoding tools start with a final UI for a source platform ( ) and transforms it into another final UI for a target platform (ô). Similarly, portability tools start with a physical UI for a source platform (ê) and transforms it into another physical UI for a target platform (ò), that in turn leads to a new final UI for that platform (ô). To overcome shortcomings identified for these tools, there is a need to raise the level of abstraction namely by working at the logical level. UI Reverse Engineering abstracts any initial final UI ( ) into concepts and relationships denoting a logical UI ( ), which can then be translated into a new logical UI (ñ) by taking into account constraints and opportunities for the target platform. UI Forward Engineering then exploits this logical UI to regenerate a new UI adapted to this platform. This is part of a larger problem of producing multiple user interfaces for multiple contexts of use (including multiple

3 platforms) in forward engineering (Eisenstein, Vanderdonckt, & Puerta, 2001) (Mori, Paternò, & Santoro, 2003). 3 Tool Support for Reverse Engineering VAQUITA (reverse engineering of Applications through QUestions, Information selection, and Transformation Alternatives see reverse engineers any HTML page into a logical UI expressed in XIML (Puerta & Eisenstein, 2002), which is a representational notation for describing any UI in terms of elements and relationships that is technology and platform independent. This process can be governed by various options and heuristics: Objects, tags, and elements filtering: positive filtering includes any HTML item with given properties (e.g. the developer wants to keep all control widgets) while negative filtering discards it (e.g., no banners). Layout options: various layout heuristics establish layout relationships (e.g., alignment, centering, balance) depending on positions of objects in the page. Each heuristic can then be controlled by the developer. Associations and dissociation: heuristics group objects that are close to each other because they are semantically related (association) and ungroup objects that are isolated without any connection when they are unrelated. Contents heuristics: heuristics handle sentence folding or elision, table consideration ordering, etc. Figure 2: Reverse engineering with VAQUITA.

4 Fig. 2 shows a typical VAQUITA interactive session where the screen is divided into three regions: the original HTML code above, the hierarchical decomposition of reverse engineered objects in the bottom left window, and their properties in the bottom right window. Clicking in any of the thee frames is automatically reflected in the other co-ordinated frames to show the corresponding elements or piece of code or property. Figure 3: Results from re-engineering The logical translation is then supported by choosing any set of transformations depending on target platforms. This may lead to reshuffling presentation into more or less levels. Forward engineering is then supported to transform the XIML specifications resulting from the reverse engineering to a final UI. Fig. 3 shows a conference registration form resulting from the forward engineering for a WAP-enabled mobile phone and a Handheld PC. The combination of reverse and forward engineering thus closes the loop to obtain re-engineering. 4 Conclusion Advantages resulting from composing UI reverse engineering, logical translation, and forward engineering are: Generality: once a logical UI is obtained, it can be submitted to any set of transformations in the logical translation to accommodate the target platform. This process is no longer specific to any pair (source, target). Flexibility: the reverse engineering process can be parameterized to reverse engineer only those UI elements of interest and rejecting those out of concern. Controllability: the developer can control the process both in the reverse engineering and in the translation. Reusability: the reverse engineering needs to be operated once. The resulting UI can then initiate as many transformations as there are needs to port it so as to create a new UI for any newly considered platform. Abstraction: the UI is logical and can be treated in many ways that are more logical than at the code level, thus allowing designers to explore alternative design options that would be otherwise impossible to cover at the code level.

5 Acknowledgments We gratefully acknowledge support from the European Commission through the CAMELEON (Context Aware Modelling for Enabling and Leveraging Effective interaction) IST V project ( or cameleon.html). The goal of this project is to support design and development of highly usable context-sensitive interactive software systems mainly by: Producing a development framework that incorporates and structures the development process using our models, techniques, architectures and tools. Providing the means to express context-dependent information in a set of models usable at design-time by developers and at run-time by dynamically reconfigurable systems. Identifying criteria, methods and techniques for using information in abstract representations to drive the design and development of the concrete interface of heterogeneous devices while preserving usability. Developing tools and components that allow designers to obtain systems represented in the above models. References Calvary, G., Coutaz, J., & Thevenin, D. (2001). A Unifying Reference Framework for the Development of Plastic User Interfaces. In Proceedings of IFIP Conf. on Engineering Human- Computer Interaction EHCI 2001, pp Einsenstein, J., Vanderdonckt, J., & Puerta, A. Applying Model-Based Techniques to the Development of User Interfaces for Mobile Computers, Proceedings IUI'01: International Conference on Intelligent User Interfaces (Santa Fe, January 14-17, 2001). New York: ACM Press, pp Kaasinen, E., Aaltonen, M., Kolari, J., Melakoski, J., & Laakko, J. (2000). Two Approaches to Bringing Internet Services to WAP Devices. In Proceedings of 9 th International World-Wide Web Conference WWW 9 The Web: next generation (Amsterdam, May 2000). Accessible at Mori, G., Paternò, F., & Santoro, C. (2003). Tool Support for Designing Nomadic Applications. In Proceedings of 8 th ACM International Conference on Intelligent User Interfaces IUI 03 (Miami, January 12-15, 2003), New York: ACM Press, pp Puerta, A., & Eisenstein, J. (2002). XIML: A Common Representation for Interaction Data. In Proceedings of 7 th ACM International Conference on Intelligent User Interfaces IUI 2002 (San Francisco, January 13-16, 2002). New York: ACM Press. Accessible at Vanderdonckt, J., & Bodart, F. (1993). Encapsulating Knowledge for Intelligent Automatic Interaction Objects Selection. In S. Ashlund, K. Mullet, A. Henderson, E. Hollnagel & T. White (Eds.). Proceedings of ACM Conference on Human Factors in Computing Systems INTERCHI'93 (Amsterdam, April 1993). New York: ACM Press, pp Accessible at p424-vanderdonckt.pdf