A Unified Process Supported by a Framework for the Semi-Automatic Generation of Multi-Context UIs Kenia Sousa and Elizabeth Furtado University of Fortaleza - UNIFOR Washington Soares Avenue, 1321- 60.811-905, Brazil {kenia, elizabet}@unifor.br http://www.unifor.br

Abstract. This paper presents a unified development process for interactive systems that integrates artifacts, professionals, and techniques from Software Engineering and Human-Computer Interaction supported by a framework that semi-automatically generates UIs adapted for users’ characteristics, environment, and platform they are interacting with. The main goal is to contribute with these two areas of study in order to facilitate the application of the process by multi-disciplinary working groups and develop usable and useful interactive systems, thus satisfying customers and users.

1 Introduction As an increasing number of software organizations have started to apply software development processes, users’ needs became more specialized. Therefore, users started to make demands for systems that have the functionality they require, but also systems that are easy to use and learn, that is, users are also feeling the need for usability. Users no longer accept errors, lack of visual standards, confusing messages, difficult navigation, among other aspects that make their interaction with the system less productive or pleasant. In addition, they also want to interact with systems that consider aspects pertaining to individuals, such as their personal characteristics, the physical environment where they are located, and the platform that they are using; which characterize users’ context of use. These needs for quality and usability lead to the identification of certain gaps in processes from Software Engineering (SE) and Human-Computer Interaction (HCI). In order to contribute to the integration of these areas, we have defined a Unified Development Process for Interactive Systems and modeled a tool to support the application of the process. The Unified Development Process for Interactive Systems, or UPi [14], has disciplines, phases, activities, artifacts, and roles based on the IBM Rational Unified Process (RUP) [8] and on various HCI methods, such as [2] and [3]. The tool supports software engineers and HCI engineers during the executions of UPi activities in order

to produce artifacts in each phase of the process. The tool aims at generating systems with Interaction based on the Knowledge of the User (specialized in UI design, considering users’ context of use) and it is called IKnowU [5]. Our main intention with this work is to define a process and a tool to help professionals in designing UIs with usability in a way that such professionals can find it easy to apply the process by using the tool. The paper is structured as follows: section 2 presents related works; section 3 specifies the process phases; section 4 explains the framework scope and components; section 5 shows an example; and section 6 concludes this work.

2 Related Work In this section, we report on initiatives that integrate HCI and SE works related to the generation of multiple UIs, and User Interface Description Languages (UIDL).

2.1 Processes Phillips [11] suggests the use of tabular representation of use cases in order to describe the flow of events, and the use of UI element clusters, which can be used as references to the UI prototype. Tabular use cases separate user and system actions. Lauesen [9] argues that separating users' and systems' actions as early as in requirements may be a barrier for future decisions in the project. Therefore, he suggests the use of task descriptions, which specify what the users and the system shall do, not dividing the work between them. Constantine & Lockwood [3] focuses on preparing task cases that address users' intentions rather than their actions and on system responsibilities instead of on responses. This approach offers a requirement modeling more technology independent, providing designers the flexibility related to the actual interface components. When the requirements are defined, users, clients, and designers define the UI abstract prototype (non-operational prototype) using post-it notes on a white board. After that, the interactive prototypes are built. Kruchten [8] presents the concern on UI design in the RUP by including the worker UI Designer, responsible for performing the activities UI Modeling and UI Prototyping in the Requirements Workflow. In the activity UI Modeling, the UI Designer analyzes the use case model, and creates a use case storyboard. In the activity UI Prototyping, the UI Designer designs and implements the UI prototype, then obtains feedback from other project members, external usability experts, and users.

2.2 UI Generation We now compare works on model-based UI generation. The Reference Framework for multi-target UIs [2] uses three classes of models (e.g. domain, context of use, and

adaptation models) that may be ontological, archetypal or observed. Domain models cover domain concepts and user tasks; context of use models describe the user, platform, and environment [2]; and adaptation models cover evolution and transition of the UI. Adaptable User Interface Technology (AUIT) [6] is a device-independent mark-up language useful to build adaptable UIs that augments current JSP web server implementations. It generates a thin-client UI adapted for the user, their current task context, and their display device characteristics. The adaptive task modeling [4] proposes two specification techniques. The first one is an adaptation mechanism for task models and the second one is the process that makes a transformation of an abstract interaction model into a device-dependent specific UI representation. We decided to use the Reference Framework [2] as a foundation for the definition of our process and the architecture, presented in sections 3 and 4, respectively.

2.3 User Interfaces Description Languages Among the researched UIDLs, there are: User Interface Markup Language (UIML), Extensible Interface Markup Language (XIML), and User Interface Extensible Markup Language (USIXML). UIML [1] is a UIDL for multiple devices emphasizing the separation of concerns of an interactive system in a platform-independent way. XIML [12] is a universal representation for UIs that can support multiple UIs at design time and at run-time. It is an organized collection of interface elements that are categorized into five components: task, domain, user, dialog, and presentation. USIXML [10] was chosen as the foundation for our work because it is equipped with a collection of basic UI models: task, domain, Abstract UI (AUI), Concrete UI (CUI), context, transformation, and mapping, and it is adaptable to the Reference Framework because of the definition of the UI in abstraction levels.

3 The Process UPi [14] has four process phases: inception, elaboration, construction, and transition, as depicted in Figure 1. In the inception phase, the Project Manager conceives the project with representatives of the client and of users, and as soon as the project is approved, the System Analyst starts analyzing the problem focusing on understanding users’ context of use and needs (as detailed in [13]). The Quality Analyst works with the HCI Architect in the preparation of the environment (e.g. definition of tools, process, and HCI knowledge base). The Project Manager plans the project so the System Analyst can define and refine the system, with use cases, task modeling, usability requirements specification, and AUI, until it is approved by the clients and users’ representatives. Meanwhile, the Quality Analyst defines the evaluation mission identifying usability evaluation techniques and tools, and the Configuration Manager plans or adapts the configuration and change control process.

Fig. 1. UPi

In the elaboration phase, the System Analyst analyzes the behavior of the system by generating UML diagrams so the Designer can generate UIs to be evaluated by the HCI architect in terms of the application of interaction patterns. After that, the Technical Writer and the Designer start developing the support material (e.g. end-user manual) based on the generated UIs while the Test Designer designs test components, the Database Administrator designs the database, and the System Analyst plans the integration of the components to be implemented in the next phase using the Integration Plan. The Quality Analyst and the HCI Architect verify the test approach by specifying test cases (interaction procedures to be followed in test activities) with usability criteria, specified as users’ needs in requirements elicitation. In the construction phase, the Developer implements components, including the UI, and validates the stability of such components concerning functionality with System Analysts and usability with clients and users. After the components are considered stable; the Integrator adds components until the system is integrated according to the Integration Plan; the Technical Writer and the Designer improve the support material; the Quality Analyst tests and evaluates the system according to test cases and usability criteria; and the Deployment Manager plans the deployment of the final product. In the transition phase, the Quality Analyst manages acceptance tests in the development site with clients and users’ representatives until the final product attends the expected quality criteria concerning functionality and usability. When the clients and users’ representatives formally accept the product, the Deployment Manager produces the deployment unit and makes it available for deployment as a package. After that, the System Analyst trains final-users in using the system aided by the support material. Throughout all phases, the Configuration Manager manages baselines and releases by comparing and merging changed UML diagrams, documents under version control, and components; and the Project Manager monitors and controls the project. At the end of each phase, the Project Manager is responsible for closing out the phase and in the last one for closing out the project.

4 The Framework With the definition of the process, we envisioned the need to support SE and HCI professionals in generating interactive systems in order to save design and development time. Therefore, as we mentioned before, we defined IKnowU, which semi-automates the generation of UI models and assures consistency among different platforms with the application of such models. In addition, we defined a KnowledgeBased System (KBS), called KnowiXML framework [5], to support IKnowU in processing rules that concern usability requirements in order to provide designers and developers a framework that formalizes the generation of UIs. This environment is specified in [15].

In order to associate how IKnowU helps professionals in applying UPi, we make the following descriptions: definitions of usability properties (since the other models have already been defined in USIXML); actions performed by professionals (e.g. HCI Architect, System Analyst, Designer, Programmer, and Quality Analyst); and the automation provided by the framework. Usability requirements represent users’ preferences or constraints that could or should, respectively, be attended in the AUI generation. Usability patterns represent best design practices that are solutions for known usability problems; they are applied in CUIs varying their types depending on environment and platform constraints; and are associated to one or more usability requirements. Architectural patterns represent a transformation of usability patterns into architectural ones that must be present in Final User Interfaces (FUIs) varying their types depending on programming language restrictions. Associating usability properties to UI levels (abstract, concrete, and final), we have defined the following configuration: usability requirements are represented in the abstract level; usability patterns represent usability requirements in the concrete level; and architectural patterns represent usability patterns in the final level. For in stance, the usability requirement ‘provide feedback’ is mapped to the usability pattern ‘progress indicator’, which is mapped to the architectural pattern ‘feedbacker.class’ [7]. Concerning the project style guide (definition of the look & feel of the UI), when the HCI Architect and the Quality Analyst prepare the environment for the project in the inception phase, they are selecting a standard style guide composed of information concerning usability and architectural patterns in the knowledge base to be used as a foundation for the next phases. Following, when the usability requirements are selected and the context of use is defined in the inception phase, the designer has a style guide instantiated for the project with associated usability requirements, usability patterns, and architectural patterns that can be applied during UI generation. The HCI Architect is responsible for executing the following five activities concerning the creation of the knowledge base: (i) define usability requirements; (ii) define usability patterns; (iii) define architectural patterns; and (iv) define transformation rules; and (v) associate usability requirements to usability patterns and the latter to architectural patterns. The System Analyst is responsible for executing the following eight activities concerning requirements elicitation through models instantiation, using IKnowU: (i) generate use case model; (ii) specify task model; (iii) request the translation of the task model into USIXML task model; (iv) specify context of use model; (v) generate class diagram; (vi) request the translation of the class diagram into USIXML domain model; and (vii) elicit usability requirements based on a pre-defined list of usability requirements (previously defined by the HCI Architect); and (viii) associate the instantiated models. The UI Designer is responsible for executing the following two activities concerning the UI generation: (i) generate AUIs; and (ii) generate CUIs. The Programmer is responsible for generating the FUIs. The Quality Analyst is responsible for performing functionality and usability evaluation on the system.

In Figure 2, we envision how IKnowU works in terms of its components, which are organized five different types: UI models; application classes and database; KnowiXML framework; external artifact; and external translator. The KnowiXML Analysis Translator receives use case, task, domain data, context of use (concerning users’ characteristics) models and usability requirements as input from the System Analyst in order to analyze them according to a set of pre-defined rules to generate AUIs. The KnowiXML Design Translator is the module responsible for analyzing the context of use model, AUIs, and usability patterns to generate CUIs that attend environment and platform constraints, as specified in the context of use model.

Fig. 2. IKnowU

The KnowiXML Java Implementation Translator performs three main activities: (i) transforms the domain model into the application persistence layer, which is composed of persistence classes and business classes; (ii) transforms the AUI into the control layer, which is composed of control classes for business classes and for architectural patterns; (iii) transform CUIs and architectural patterns into FUIs, which is composed of the view layer that contains boundary classes and JSPs. The Database Translator (external translator integrated with the framework) transforms the persistence layer into an entity relational model. The KnowiXML Test Translator transforms AUIs and UI requirements models (use case, task, domain models and usability requirements) into Test Cases (artifact external

to USIXML). They are based on: (i) use cases and task models in order to define interaction steps; (ii) domain model to specify a set of test data useful as input for the interaction steps; and (iii) usability requirements to specify usability criteria.

5 An Example In a simplified example about postal box, we present the definition of usability requirements, organized in preferences and constraints, which are associated to one use case, in order to specify its alternatives of AUIs. Figure 3 depicts the definition of the ‘view list of messages’ use case and the specifications of users’ usability requirements, which are: (i) constraint: easy navigation among messages in the inbox; and (ii) preference: allow multiple configurations of how to view messages. This use case is composed of the following tasks: view list of messages, navigate among messages, read a selected message, delete selected messages, and write a new message. AUIs are generated based on the task model, that is, the more important and structured task (view list of messages) generates a new abstract container, while the other tasks generate abstract individual components in this container. The decision to show information on the container (through output comp onents) is based on the existence of attributes in the domain model related to the task model (associated by the System Analyst) and other attributes related to the task model, such as if the task is activated by the user or by the system; and to go to other containers (through navigation or control components) is based on the existence of methods in this same domain model and on other aspects related to the task model, such as if the task has different semantic meaning compared to the previous one. To take into account usability requirements during this generation process, the following usability patterns associated to these requirements are analyzed: (i) navigation buttons that go forward and backward (for the constraint); and (ii) choice for obtaining more or less messages on the screen and use of scroll bar (for the preference). These usability patterns are previously associated to usability requirements, and when the usability requirements are selected, the associated patterns are presented as options for the UI. The application of these patterns allows the analysis of two alternatives of AUIs, which were generated by IKnowU and illustrated using IdealXML (Figure 4). Both AUIs have: four output abstract individual components (sender, subject, date, and size), one navigation abstract individual component (select message to read) and two control abstract individual components (select message to delete, write message). The difference between them is that the first one only satisfies the constraint and has one more navigation abstract individual component to navigate among messages. On the other hand, the second one also satisfies the preference and has one more control abstract individual component to configure the number of messages on the screen and another navigation abstract individual component to view all the messages shown.

Fig. 3. Definitions of Usability Requirements in IKnowU

The most appropriate choice depends on other information that will be obtained during the CUI generation (e.g. which architectural patterns to apply) and during the execution of the system (e.g. which platform is being used).

Fig. 4. Two options of AUIs

Figure 5 depicts a list of messages following the first and the second usability patterns (many messages with scroll bar and navigation buttons dividing the messages in pages), thus, satisfying both users’ constraints and preferences elicited during requirements. It is very important to perform adjustments on CUIs depending on the device because it is very clear on Figure 6 that the lighting environment reflects on the middle of the device (Digital TV) and makes the user interaction a difficult task. We noticed that the objects are bigger in order to be seen by users from a distance,

but that makes them occupy more space on the screen (more than one line) and makes the visualization more difficult. We also noticed that stronger colors (e.g. dark blue) are not clearly shown on the Digital TV, for instance, on the top web mail menu and on the navigation buttons.

Fig. 5. CUI for Messages in a Desktop

Therefore, some objects (e.g. navigation buttons) were imperceptible and the navigation among pages was affected by that. As a result, users were forced to use the ‘Options’ link to choose the number of messages to see at the same time, thus, not satisfying one of users’ constraints (navigate forward and backward). These aspects (environment, space and color problems) make the system usability worse than in the device on Figure 5 because of the lack of application of usability patterns according to the context of use. In this case, environment lightning and screen size are aspects to be considered when analyzing the context of use to apply appropriate usability patterns (concerning objects’ size, color, for instance). It is important to notice that this page in Figure 6 is divided in two spaces: one on top for the messages and one on the bottom to insert a new URL. Therefore, at this point it is not possible to see the list of messages, which are hidden by the URL space. Based on the need to make adjustments according to the context of use, the style guide, which was instantiated during the preparation of the project environment, is analyzed according to its usability patterns. This is important in order to apply the most appropriate architectural patterns in the CUI based on the usability requirements selected by users and on the context of use. The association of the elements in the style guide to usability patterns (extracted from the KB), facilitates the application and reuse of usability patterns in the CUI, and consequently of architectural patterns in the FUI.

Fig. 6. CUI for Messages in a Digital TV

6 Conclusion With this research work, we intend to make two main contributions. The first one is to contribute with software organizations and academic institutions with a software development process that integrates the best practices from both SE and HCI in order to help practitioners, researchers, and professors in teaching how to generate or in generating interactive systems with quality, usability, acceptability, and accessibility. First, quality can be achieved by providing to users the functionality they have required without errors, or at least, with a minimum number of errors. Second, usability is acquired by designing UI models that focus on facilitating the use of the system. Finally, acceptability and accessibility are provided with the concern on developing systems adaptable for multiple contexts of use. The second contribution is for software engineers and HCI engineers during the application of the process by facilitating their understanding and communication through the automation of various activities throughout the process.

References 1.Ali, M.F., Pérez-Quiñones, M.A., and Abrams, M. Building Multi-Platform User

Interfaces with UIML. In A. Seffah & H. Javahery (eds.), Multiple User Interfaces. John Wiley & Sons, New York, 2004, 95–117.

2.Calvary, G., Coutaz, J., Thevenin, D., Limbourg, Q., Bouillon, L. and Vanderdonckt, J. A Unifying Reference Framework for Multi-Target User Interfaces. Interacting with Computers 15, 3 (2003) 289–308. 3.Constantine, L. and Lockwood, L. Software for Use: A Practical Guide to Models and Methods of Usage-Centered Design. Addison-Wesley, Reading, 1999. 4.Forbrig, P., Dittmar, A., and Müller, A. Adaptive Task Modelling: From Formal

Models to XML Representations. In A. Seffah & H. Javahery (eds.). Multiple User Interfaces. John Wiley, New York, 2004, 171–192. 5.Furtado, Elizabeth; Furtado, Vasco; Sousa, Kênia Soares; Vanderdonckt, Jean; Limbourg, Quentin. KnowiXML: A Knowledge-Based System Generating Multiple Abstract User Interfaces in USIXML. In: Task Model and Diagrams for User Interface Design (Tamodia), 2004, Prague. Task Model and Diagrams for User Interface Design. 2004. 6.Grundy, J. and Zou, W. AUIT: Adaptable User Interface Technology, with Extended Java Server Pages. In A. Seffah & H. Javahery (eds.). Multiple User Interfaces. John Wiley & Sons, New York, 2004, 149–167. 7.Juristo, N.; Lopez, M.; Moreno, A.; Sánchez, M. Improving Software Usability through Architectural Patterns. In: International Conference on Software Engineering (ICSE),

2004, Scotland. 2004, pp. 12-19. 8.Kruchten, P. Ahlqvist, S., and Bylund, S. User Interface Design in the Rational Unified Process. Object Modeling and User Interface Design. Addison-Wesley, 2001. 9. Lauesen, S. Task & Support - Task Descriptions as Functional Requirements. Proc.

of AWRE’2001. Centre for Advanced Software Engineering Research, Univ. of New South Wales, Sydney, 2001, pp. 83-91. Accessible at http://www.itu.dk/people/slauesen/Papers/ TasksSupportAWRE.pdf 10. Limbourg, Q., Vanderdonckt, J., Michotte, B., Bouillon, L., Florins, M. and Trevisan, D. USIXML: A User Interface Description Language for Context -Sensitive User Interfaces. Proc. of the AVI’2004 Workshop “Developing User Interfaces with XML: Advances on User Interface Description Languages” UIXML’04 (Gallipoli, 25 May 2004). EDM-Luc (2004), 55–6. 11. Phillips, C. and Kemp, E. In Support of User Interface Design in the Rational Unified Process. Proc. of the Third Australasian User Interface Conf. 2002, 21–27. 12. Puerta, A., Eisenstein, J. XIML: A Multiple User Interface Representation

Framework for Industry. In A. Seffah & H. Javahery (eds.). Multiple User Interfaces. John Wiley & Sons, New York, 2004, 119–148. 13. Sousa, K. and Furtado, E. An Approach to Integrate HCI and SE in Requirements Engineering. In M.B. Harning & J. Vanderdonckt (eds.). Proc. of Interact’2003 Workshop on Closing the Gaps: Software Engineering and Human-Computer Interaction (Zürich, 1 September 2003). 81–88. 14. Sousa, Kênia Soares; Furtado, Elizabeth. UPi - A Unified Process for Designing Multiple UIs. In: International Conference on Software Engineering (ICSE), 2004, Scotland. 2004, pp. 41-48. 15. USIXML – Home of the User Interface Extensible Markup Language. Available at: < http://www.usixml.org >. 2005.

A Unified Process Supported by a Framework for the ...

professionals in designing UIs with usability in a way that such professionals can find it easy to apply the .... HCI architect in terms of the application of interaction patterns. After that, the .... CUI for Messages in a Desktop. Therefore, some ...

327KB Sizes 0 Downloads 190 Views

Recommend Documents

Linear Network Codes: A Unified Framework for ... - Semantic Scholar
This work was supported in part by NSF grant CCR-0220039, a grant from the Lee Center for. Advanced Networking, Hewlett-Packard 008542-008, and University of ..... While we call the resulting code a joint source-channel code for historical ...

A Unified Framework and Algorithm for Channel ... - Semantic Scholar
with frequency hopping signalling," Proceedings of the IEEE, vol 75, No. ... 38] T. Nishizeki and N. Chiba, \"Planar Graphs : Theory and Algorithms (Annals of ...

A Unified Framework for Monetary Theory and Policy ...
Hence, if real balances are at least φm* the buyer gets q*; otherwise he spends all his money and gets bq(m), which we now show is strictly less than q*. Since u and c are Cn the implicit function theorem implies that, for all m < m*, bq is Cn-1 and

A Unified Framework for Monetary Theory and Policy ...
of monetary exchange. Why? ..... Solution to the Agent's Problem in the Centralized Market ... Thus the FOC has a unique solution, which is independent of m. ⇒.

Towards a Unified Framework for Declarative ...
In a second stage, the customer uses an online broker to mediate between him ... Broker = accept ob(k) given m ≤ 500ms in ( .... closure operators for security.

A Unified Framework for Semi-Supervised ...
Jan 14, 2008 - Email address: [email protected] (Yangqiu Song). Preprint submitted to ... regularized least-squares, we add a regularization term to the original criteria of LDA and ...... http://www.ics.uci.edu/ mlearn/MLRepository.html. 16 ...

A Unified Framework and Algorithm for Channel ...
Key words: Wireless networks, channel assignment, spatial reuse, graph coloring, .... Figure 1: Max. degree and thickness versus (a) number of nodes, with each ...

Linear Network Codes: A Unified Framework for ... - Caltech Authors
code approaches zero as n grows without bound for any source U with H(U) < R. The fixed-rate, linear encoder is independent of the source distribution; we use distribution-dependent typical set decoders for simplicity. Let an be an ⌈nR⌉ × n matr

Linear Network Codes: A Unified Framework for ... - Semantic Scholar
Page 1 ..... For any n × ⌊nR⌋ matrix bn, we can build a linear channel code with .... For any n × n matrix cn, we can build a joint source-channel code for the.

A Unified Framework for Dynamic Pari-Mutuel ...
low us to express various proper scoring rules, existing or new, from classical utility ... signed for entertainment purposes. .... sign of new mechanisms that have desirable properties ...... the 2006 American Control Conference, Minneapolis,.

A Unified Process for Interactive Systems
Interactive Systems, Software Development Process, RUP. INTRODUCTION. Most SDP .... Management, Business Modeling, Configuration and. Change Management .... order to generate concrete interaction objects, and SIERRA organizes ...

the creative design process supported by the ...
approach. These designs also lacked detailed bioclimatic considerations, mostly due to the adoption of curvilinear ... unstructured discussions concerning the ...

Towards a Framework for Business Process Compliance
organizations and software engineers assess the compliance of business .... to capture legal requirements and analyze business process compliance with ...

A Process-Theoretic State-Based Framework for Live ...
(3) the supervised system, where in order to ensure safety, the synthesis procedure ... using a process theory that uses signal emission [6] to specify the state-based ... the prominent (state-based) model checker UPPAAL [10]. To couple both ...

A Unified SMT Framework Combining MIRA and MERT
translation (SMT) adopts a log-linear framework to ... modeling, the unified training framework and the .... scalable training methods are based on the n-best.

A Unified Framework of HMM Adaptation with Joint ... - Semantic Scholar
that the system becomes better matched to the distorted environment. ...... Incremental online feature space MLLR adaptation for telephony speech recognition.

A Unified Shot Boundary Detection Framework ... - Semantic Scholar
Nov 11, 2005 - Department of Computer Science and. Technology, Tsinghua University ..... the best result among various threshold settings is chosen to.

A Unified Framework of HMM Adaptation with Joint ... - Semantic Scholar
used as a simple technique to reduce additive noise in the spectral domain. ... feature space rotation and vocal tract length normalization to get satisfactory ...

Using the OPEN Process Framework to Produce a ...
Aug 29, 2005 - It is thus difficult to write down a generic sequential plan of tasks that ..... some kind of database that can be used not only to generate the .... How quick was it to construct the tailored process – was it overly labour intensive

RUPi – A Unified Process that Integrates Human ...
Rational Unified Process for Interactive Systems, called. RUPi. The RUP is a well-established SDP that intends to ... comparison between these artifacts will make it possible for us to envision the benefits of applying a SDP that ..... model for a pr