An Ontology-Based Method for Universal Design of User Conceptual Interfaces Using Scenarios Elizabeth Furtado and Kênia Sousa University of Fortaleza – UNIFOR Av. Washington Soares, 1321 Fortaleza, CE 60455770 Brazil + 85 477 30 79 [email protected] [email protected] ABSTRACT

Interactive systems are used to achieve the goals of the tasks users perform (called user tasks). Taking into account the advance of web systems, it is important to use the more accurate method and models capable of promoting universal access of User Interfaces (UIs). UI design requires designers to understand very well the user requirements and to model user tasks. The method proposed in this paper intends to apply graphical scenarios when defining the user requirements and task models. The goal is to help designers understand different contexts of use where multiple types of users may carry out multiple tasks in order to develop more usable and adaptable interfaces. Keywords

User tasks, interactive systems, ontology, and scenario. INTRODUCTION

There are some methods available, which are based on integrating human factors in the interface design process taking into account task characteristics in order to develop more usable and adaptable interfaces. In [3], human factors are closely linked to aspects obtained from cognitive models (e.g. tasks to perform, time to learn, procedure to repair errors) in order to help the designer define user tasks and strategies for error treatment. In addition, human factors are closely linked to ergonomic principles, which are applied on task characteristics in order to deduce some aspects of human-computer interaction. However, the existing design methods are not providing new facilities to obtain and define the users needs in order to design User Interfaces for All. The design of User Interfaces for All attempts to cover design issues in multiple contexts of use where multiple types of users may carry out multiple tasks, possibly on multiple domains of interest [4]. With all these multiple aspects, it is necessary to have new methods and tools, which help designers develop User Interfaces for All in different situations. Scenario is a modeling technique used to represent a specific situation experienced by a user when performing a

specific operation in a specific context of use with a specific goal in mind, as we can see in [7]. Scenario is a variation (instance) of a general situation that happens when a user interacts with an interactive system. In UML [8], general situations are associated to the notion of use cases. It is stated in [11] that a number of researchers report that creative insight and problem-solving related to modeling performance can be improved with appropriate visualizations. Regarding the visual representation of modeling problems, scenarios are used to help the interpretation of situations since there are fewer ambiguities in visual than in textual representations. To illustrate, the statement, “The user can not see the most relevant information on the screen.” tells us nothing about the cause of this fact. Now the visual representation of the screen and of the environment of use may show us that the user is accessing information through a cellular phone and the information was not properly formatted to be presented in such a platform. The new method proposed in this paper, MACIA*, intends to specify the user requirements with the UML notions of use cases and scenarios in order to generate UI specifications. Scenarios are used to express graphically the different ways in which a user can perform tasks associated to a specific use case. Its importance for the specification of UIs is that it can better represent some interactive aspects of the tasks performed by a user, e.g. error treatment, and environment conditions. In addition, scenarios are used as documentation to check the conformity of the tasks performed by the users with the ones identified during the specification phase of the interface design process. The MACIA* method is based on the methods presented in [3] and [5]. Our tool, which supports this method, aims at solving problems of designing User Interfaces for All (e.g., problems of accessibility, usability, and acceptability) taking into account the different contexts of use in which a user can perform tasks. We developed a sequence of editors based on the ontology notion in order to describe all

the characteristics (concepts) of the models and to generate the UI specification. We use multiple models (e.g. task model, user model, user interface model) during the software development in order to develop more matured systems, which take into consideration different aspects of the context of use [2]. The ontology notion comes from the Artificial Intelligence context where it is identified as the set of formal terms with knowledge representation, since the representation completely determines what “exists” in the system [6].

three main phases: task modeling, conceptual interface specification and real interface generation [3]. The main objectives of this method are to: i) decrease the interface design complexity by using a user interface hierarchical model where the specifications of the conceptual interfaces are made from an initial task model; and ii) increase the interface usability by defining the real interface aspects from ergonomic rules. This method takes into consideration the user needs and models the tasks performed by them in order to develop usable and adaptable UIs.

We only use designer throughout this paper as a choice to use one name for clarity, but we also take into consideration the importance of the software engineer during the entire software development process. We acknowledge that some of the phases are under the responsibility of the software engineer and others under the responsibility of the designer.

In the above contributions, we see the importance of having a structured way to capture, store, and manipulate multiple elements of the context of use, such as task, domain, and user. Although the above methods consider this kind of information, they do not represent the interactive situations in order to help the designer envision the tasks that will be performed by the users in a more realistic manner. The strategy presented in [1] proposes the representation of requirements with use cases and scenarios since the early phases of software development in order to lead to more complete software specifications. Even though, it provides a more complete set of requirements, it does not use any technique to illustrate the user requirements through images and it is limited to represent the scenarios in a textual manner.

The remainder of this paper is structured as follows: section 2 provides a state of the art of methods for developing UIs focusing on universal design from requirements, section 3 explains the method and how it was applied in a tool, and the last section summarizes the main points of the paper. RELATED WORK

There are some methods for UI generation, which enable the integration of usability issues into the software development process. The focus of these methods is to design usable interfaces, but the identification of requirements has to be integrated as an important part of the process. From this perspective, the first three methods listed below focus on UI generation and the last one extends itself to the Software Engineering notion of requirements. The Unified Interface Design Method [9] has been defined in order to: i) enable expression of the alternative enumerated designs of a user-adapted interface into a single unified form, without requiring explicit enumeration; and ii) provide a design model for organizing dialogue patterns which can be easily translated to a software organization model for the required interface implementation. The Ontology-Based Method presented in [4] takes advantage of considering any type of the information specified in the ontology hierarchy to produce multiple UIs depending on the varying conditions, e.g. the characteristics of the users and their tasks. This method is divided in three levels of abstraction, where it is possible to define concepts that can be instantiated and defined as models to be used in the creation of several UIs. The advantage of this method is that any change made at any level is instantly propagated to subsequent levels. MACIA is a method used during the interface design process to generate interface specifications taking into account a task model and ergonomic rules. This method has

MACIA*

The MACIA* is composed of representations and a process. Representations are used to express results, which will be used during the process. They can be graphical, textual, and diagrammatic. Models are examples of diagrammatic representations. The process describes the way that will help the designer model the user requirements, the tasks and the associated data in order to specify an interactive system. Before describing the process, we will show how an interactive system for any domain can be specified in multiple models based on the ontology notion. The Models

We propose a tool that enables a domain expert to define ontology concepts and relationships involved in the production of multiple models. The representation of the tool is depicted in Figure 1. The models that are considered in our method are: the domain model, the task model, the user model, the use case model, and the Conceptual Interface Model (MIC). The domain model defines the data that a user can view, access, and manipulate through a UI. The visualization can be displayed for the user in different media, e.g., text, sound, graphics, etc. Data and tasks are associated to interactive objects that can be presented through interactive spaces, which are defined in the MIC. The task model is composed of tasks, which can be represented by scenes, where each one has its sets of

characteristics, e.g., time, and location. A set of scenes composes a scenario.

The Process

The proposed method is presented in Figure 2, which depicts four phases. These phases are separated according to the non-interactive part of an interactive system (called application) and its interactive part (called user interface). The objective is to assure the independence between these parts in order to facilitate the maintenance of the system.

Figure 1 – The MACIA* models

As we have mentioned, a scenario is an instance of a use case, which may be split up into several specific use cases, which are represented by the use case model. The main component of use cases is an actor, who can be represented by the user model that consists of a hierarchical decomposition of the user population into stereotypes in order to change the interface based on the individual characteristics of the user. If the designer finds the need to consider more concepts and models, the predefined ontology (see Figure 1) can be updated according to the specific domain (we will show this in the next section). The designer responsible for generating the UI uses the models that have been already defined as a starting point to define attributes for the concepts in the models (such as task characteristics according to a specific task model).

Figure 2 – The MACIA* process Following, we describe each phase of the MACIA*. To illustrate our method, we will present, throughout these

phases, an example concerning the domain for book sales.

use case, for instance, if A includes B, it means that A’s behavior uses B’s behavior; ii) extend, which is used to show the exception behavior of a use case, for instance, if A extends B, it means that B’s behavior can be increased with A’s behavior; and iii) generalization, which refers to the heritage concept between use cases.

Figure 3. The instantiation of a typical case

The User Requirements Phase

In the user requirements phase, the user’s needs are identified and modeled in use cases. Use cases are used to express the user’s goals when interacting with the system by representing real situations faced by them. The ontology modeling process used to represent the use case model is based on the relations between use cases. Considering a use case A and a use case B, the relations between them can be the following: i) include, which is used to group similar behaviors of many use cases in one

Considering the use case model made by the designer in the domain of book sales, two use cases are identified: Orders Book and Searches for Book. The use case Orders Book starts when the customer selects one or more books, which are available for sale. During this selection process, the customer can look for other books and the use case Searches for Book starts. When the books are chosen, the customer finishes the order. In this example, the use case Orders Book includes the use case Searches for Book .

A use case may contain decision points. For example, in Searches for Book, the customer may choose to search for information accessing an on-line terminal, talking with a salesperson or reading a catalog. If one of these decision paths represents the entire typical case, and the other alternatives are rare, unusual or exceptional, then the typical case should be the only one written making references to the alternatives. A typical case may be composed of generic scenes. Figure 3 depicts how the ontology graphic editor can be used to instantiate the use case model concepts for this typical case. On the right side of Figure 3, the generic scene

The graphical nature of the editor improves the legibility and the communicability of information, while the information that cannot be represented graphically is maintained in text properties. In addition, multimedia files can be associated with each information item in the scene, which is a way to prepare the graphic scenario to a scene. The definition of use cases facilitates the participation of the user during the requirements phase in order to reduce the errors caused by requirements negligence and, therefore, minimize the time spent correcting them in later phases of the process. In addition, they are used as a guide to help the designer define to each use case, its associated tasks, data and users (actors). The Application Analysis and Modeling Phase

The application analysis and modeling phase can be divided in three steps: i) to adapt pre-defined models adding some attributes to represent the user, task and domain models of the domain in study; ii) to instantiate the user, task and domain models associated to each specific use case and; iii) to generate the scenarios, which are the variations of a typical case. These steps presented can be done sequentially, that is, the user, task and domain models can be used to help prepare the scenarios, but the definition of these models is not required to start the instantiation of scenarios.

Figure 4 – The different levels of the Models Customer selects book of the use case Orders Book is being specified. The information items of this case are instantiated in the left side based on the following sequence: actor + verb + complement. In the complement, the associated data and relations between use cases are included, one example may be a reference call to other typical cases, such as the one made to the use case Searches for Book.

Figure 4 illustrates these steps showing the models structured in three levels of abstraction. •

In the first level, each pre-defined model can now be completed with its own information and possible values. For instance, using the ontology editor, the designer defines any information as task parameters to represent a

specific task model. These parameters can be: name, subtasks, and relations between subtasks (constructor). To represent a user model, the designer can define as user parameters the following items: user task experience, system experience, and input preference with interactive devices. •

to maintain the user’s tasks and needs as a priority during the entire interface design process. Since scenarios are easy to understand, they can be validated and revised by users themselves [7].

The second level enables a designer to instantiate the information of each model associated to a use case, which has already been modeled. In the ontology editor, the designer can take the task buy book as an example and define its subtasks as show book and order book , and the user task experience of a customer (user) as high. A task model associated to a use case allows showing how the alternatives of a use case are treated and the moment of the integration between use cases.

For instance, as the use case Orders Book includes the use case Searches for Book, the task order book, associated to the use case Order Book calls the task search for book, before its subtasks execution. •

In the third level, the scenarios of each use case are generated.

A scenario is very important to express exceptions and errors treatment in the task model taking into account the user characteristics and the environment conditions. When defining the scenarios of a use case, the designer should take into consideration all the possibilities of exceptions and errors handling, which have not been treated in the typical case. The perception of these problems will help the designer during the validation of the UIs specified in order to avoid future problems for users when performing a task. For instance, if the designer prepares the following scenario: “The customer wants to buy a HCI book, but encounters some difficulties in finding it. The salesperson shows information for a list of HCI books to help the customer choose a book from the great variety of options”, it will be clearer for the designer that including in the user interface associated to the use case Orders Book a link for more information on each book will enhance the performance level of the task performed by the user. Using a scenario editor, the designer creates the scenario shown in figure 5, which corresponds to the second scene of the example in figure 4. To help the designer in generating scenarios, the creation of a scene can be partially automatic if the concepts used in a typical case have been defined in the second level with media (such as an image, e.g., file. jpg) associated to them. The designer can, from an image, represent a customer, define his/her particular characteristics, as feelings and corporal expressions, and/or reproduce it by creating a set of customers in different positions. The scenario editor is useful because it can better represent the reality of a situation faced by the users of the system being developed. The use of scenarios is important

Figure 5 – The scenario editor The Conceptual Interface Specification Phase The conceptual interface specification phase concerns the generation of the conceptual interface model (MIC). This model was elaborated to represent the interactive part of the system (such as, the different interactive spaces, their sequences and their interactive objects). MIC aims at showing the designer prototypes of interfaces that can be built, which are ergonomically evaluated in the semantic level of an interactive system. The MIC representation neatly fits the way that the designer thinks about how the user will interact with the system, because this representation is similar to most of the navigation structures of the systems. The MIC is generated by applying ergonomic rules, deduced from ergonomic recommendations, in the relationships among the use cases, the task characteristics and the scenarios. There are three types of ergonomic rules that were elaborated in order to: generate the MIC structure, generate the MIC behavior, and optimize the MIC structure. The rules that define the MIC structure generate interactive spaces and their interactive objects depending on the task characteristics and their data. These kinds of rules, obtained from [3], intend to define the division of tasks in an interactive space and the data of a task handled by the user that will be added to this interactive space based on the task relationship and the number of interactive objects that an interactive space has. The rules that define the MIC behavior generate the sequences among the interactive spaces, from the interactive sequences of the tasks, defined depending on their relevance to the system, and from the relations

between the use cases [5]. Figure 6 show the rule editor being used to define this type of ergonomic rule over the use case ontology. The advantage of the integration of rules with the model concepts is that new rules can be very easily defined when a new parameter is inserted in the models.

corresponding to the two use cases in study. After that, the rules to group the tasks are applied. In applying rules described in [3], which consider the semantic relations and the quantity of objects used by the tasks, the Show book task and the Order book task and its sub-tasks of figure 4 are grouped in the Order Book vision. This vision’s data are used by the customer to visualize the list of book, to require the execution of the tasks of the Search for book vision, to choose the books and to validate the order through the following interactive objects: book list, search, quantity and validate respectively. The Evaluation and Optimization Phase Finally, the designer can evaluate the results of earlier phases of the process and make changes in order to enhance the conceptual interface, and consequently, develop a more usable UI. One of MIC advantages is the opportunity it provides for the designer to make modifications during the interface specification phase, before the real interface is generated.

Figure 6 – Rule edition taking into account the ontologies

The rules that define the MIC optimization have the goal of reducing the interactive space numbers that the users have to navigate to execute a task and to avoid them to remember data shown on previous screens.

As in this paper we mainly intend to show the definition of UIs from the requirements phase and the application analysis phase, we are supposing that the designer, will be responsible to generate the real interfaces, but we have described an automatic process in [4]. After MIC is presented to the designer, an interface tool is used to develop the real interface taking into consideration the MIC specifications and the ergonomic rules, originated from [10] and defined in the rule editor, such as, graphical aspects of the interactive objects to use (e.g. color, size, position.), which interaction style to use, etc. CONCLUSION

Figure 7 – The MIC generated Figure 7 illustrates the MIC generated for the example of figure 4. In the beginning of this generation, there is a direct correspondence between each use case, which is attached directly to an actor and to an interactive space. In this example, we have two interactive spaces (or visions)

The goal of this paper is to present a new method capable of developing conceptual interfaces of interactive systems from requirements represented in a conceptual way by ontologies and in a graphical way by scenarios. A set of editors makes it possible to: i) enhance the domain analysis in order to identify Universal Access requirements and the dynamic tasks performed by users using graphical scenario and ontology editors; and, ii) integrate the ergonomic rules in the interface specification considering the requirements and the characteristics of the tasks using the ontology and rule editors. In summary, scenario is a structured way to capture, store, and manipulate multiple models of the context of use. Scenario is generated by associating concepts of multiple models to graphical representations taking into account different situations.

REFERENCES

1. Cysneiros L.M., Leite J.C.S.P. (2001). Driving NonFunctional Requirements to Use Cases and Scenarios. Simpósio Brasileiro de Engenharia de software. Pg. 81-91. Rio de janeiro. Outubro. 2. Forbrig, P., Dittmar A. (2001) Software Development and Open User Communities. Universal Access in HCI, Towards an Information Society for All, Vol. 3, pp. 165169. 3. Furtado, E. (1997). Mise en oeuvre d’une méthode de conception d’interfaces adaptatives pour des systèmes de supervision à partir des Spécifications Conceptuelles. Thèse de doctorat. França. Março. 4. Furtado E., Furtado V., Silva, W., Rodrigues, D., Taddeo, L., Limbourg Q., and Vanderdonckt J., (2001). An Ontology-Based Method for Universal Design of User Interfaces. Proceedings of Workshop on Multiple User Interfaces over the Internet: Engineering and applications Trends. France. Acessible in http://www.cs.concordia.ca/%7Efaculty/seffah/ihm2001/pr ogram.html. 5. Furtado, E., Simao R. (2001) A method of UI design respecting the principle of IHC dialog. IV workshop on

Human factors (IHC´2001). Florianopolis. Brazil. In press. Outubro. 6. Gruber, T. R. (1993). Toward Principles for design of Ontologies Used for Knowledge Sharing. Technical Report, Stanford University. 7. Monteiro C., Barbosa S., Souza C. (2000) The Role of Designer-Generated Scenarios in Developing Web Applications: A Case Study. In III workshop on Human factors (IHC). Gramado. Brazil. Outubro. 8. Rosenberg, D. Use Case Driven Object Modeling with UML: A Practical Approach. Addison-Wesley, 1999. 9. Savidis, A., Akoumianakis, D., Stephanidis, C., (2001). The Unified User Interface Design Method, Chapter 21, in "User Interfaces for All: Concepts, Methods, and Tools " C. Stephanidis (ed.), Lawrence Erlbaum Associates, Pub., Mahwah, pp. 417-440. 10.Vanderdonckt J. (2000). A Small Knowledge-Based System for Selecting Interaction Styles. In: TOOLS FOR WORKING WITH GUIDELINES, Biarritz. TFWWWG´2000 - Tools for working With Guidelines. London: Springer, v.1. pp.2472156. 11. Crapo A. W., Waisel L. B., Wallace W. A., Willemain T. R. (2001). Visualization and The Process of Modeling: A Cognitive-theoretic View. ACM. pp. 218-226.