User Interface Design: The WHO, the WHAT, and the HOW Revisited

Size: px

Start display at page:

Download "User Interface Design: The WHO, the WHAT, and the HOW Revisited"

Frank Rogers
5 years ago
Views:

1 User Interface Design: The WHO, the WHAT, and the HOW Revisited Chris Stary T-Group at the University of Technology Vienna CD-Lab for Expert Systems and Department for Information Systems Paniglgasse 16, A Vienna, Austria phone , stary@dbai.tuwien.ac.at Abstract As soon as user interface design is seen as an integral part of business- and user-oriented software development, a framework and a methodology are required for development support. The hereby introduced TADEUS-approach provides both, and is currently being implemented, in order to provide developers with a corresponding environment. The approach is dedicated to the integration of the specification of interacting users (WHO) allowing individual perspectives, as well as the specification of a system s functionality in a declarative (WHAT) and procedural way (HOW). The design methodology is model-driven and objectoriented. It supports the specification and integration of business models, user models, interaction models, and data models. Any specification may be reused for prototyping and further application development. 1 Open Problems On one hand, software engineering is still considered as a mostly data-driven process or at least as a process where user interface belongings are handled separately as long as possible, finally neglecting the integration of previously isolated parts. On the other hand, structured user interface design is still foused on the isolated treatment of a so-called application component and an interaction component, but under control of a so-called dialogue control component. The latter approach, and in particular, the control component for integrating data and interaction handling, provides an architecture for so-called User Interface Management Systems (UIMSs), such as UIDE [3]. There are major deficiencies in the software engineering as well as in the dialogue engineering approach: 1. both do not provide techniques for integrating dialogue and data handling, although the dialogue engineering approach provides a structured architecture for interactive systems. However, recognizing the need for control knowledge does not imply necessarily to know how to acquire and to represent this knowledge. 2. both are incomplete, neglecting the essential context of any interactive system: tasks (including workflows), and users. We consider all those individuals to be users (the WHO) of an interactive system that manipulate interaction devices and problem domain data at the user interface of a computer system. They may have different levels of experience in accomplishing their problemdomain tasks as well as different skills in handling interaction devices. User perform tasks along business workflows. These establish the WHAT an interactive system has to support, i.e. the functionality of the interactive system (the operations on problem domain data). The second part of control knowledge is the HOW, namely how task- and user-oriented interactive support can be achieved. First steps to overcome the addressed deficiencies have been made in the context of second-generation UIMSs. Some of them provide abstract representation mechanisms, such as General Object as superclass of Application Object and Interface Object [3]. Others pursue the direction of extending specification languages with causal and temporal relationships between application and interface objects [4]. However, a general object hierarchy or a comprehensive specification language does not provide knowledge which steps the designer should perform when specifying a userand business-oriented interface. Thus, the crucial issue for methodological support when designing taskand user-relevant interfaces is to tell the designer not only how to represent the results from business- and user analysis, but also which activities to perform in the design process. The TADEUS (Task Analysis/Design/End User Systems) - approach that is discussed in the following provides a framework, a methodology, and a corresponding environment. Proposed by the T (TAsks and Users) - group, an object-oriented concept for the integrated representation of the results of user and business-analyses is introduced as well as a generic strategy to follow in order to complete a specification by handling and relating several software components. We call these components models. In contrast to existing approaches TADEUS captures the relevant knowledge for interactive-software development, since it takes into account the actual context of user interfaces explicitly, namely tasks and users. The second major difference to most of the existing development /95 $ IEEE 178

2 paradigms is the model-based strategy. It allows the mutual refinement of the components (models) in the same way as design occurs in reality, namely as some kind of 'jumping' between several views, layers of abstraction, and details. 2 The TADEUS-Solution The understanding of end users and their organization of work requires a design framework of contextsensitive components for interactive systems. In the TADEUS framework we put the following components into mutual context [2]: business model, data model, user model and interaction model. The business model comprises the decomposition of end user tasks according to the business processes as well as the qualifications and perspectives of employees accomplishing tasks. The data model provides the static and dynamic information about the functionality of the system and has to be derived from the business model. The interaction model captures all devices and styles that are required for users in the course of interaction. In relation to the business- and the data model all presentation and manipulation issues concerning tasks, functions, and data structures have to be specified in the interaction model. The user model details the individual perception of tasks, data structures and interaction devices, such as personal experiences and preferences, access modalities to tasks and data, individual task organization, and conventions. Since the framework is model-driven, designers may handle interaction and data modeling separately as long as required. Model-driven in contrast to methoddriven approaches do not force designers to follciw a predefined sequence of steps (eventually using different notations), but keep them directed to the main components of system specification. However, fin ally a single (object) architecture remains that is the result of several modeling steps. The design process is t,hen a loose order of specification and mutual adaptation and consistent integration steps along the four models. The major improvement in design is the use of an object-oriented notation, namely the one proposed for Object-Oriented Systems Analysis OSA in [l], through the entire development process. Hence, the knowledge about what is going on in a system, and how tasks are accomplished using an interactive system can be kept encapsulated throughout analysis, design and implementation. Moreover, since the design is specified in an object-oriented notation, code can automatically be generated according to the models and the integration steps that have to be performed in the design phase. In the TADEUS-environment, this feature facilitates prototyping. In the following subsections we will detail the design activities starting with business modeling, (and ending design with a comprehensive specification of the resulting system's behaviour. We will not cinly demonstrate the usability of the approach for decomposing a system, but mainly for integrating isolated parts - the activty that has been the most neglected one in design up to now. Manager Figure 1: ORM of a Consultant Agency 2.1 Business Modeling Usually, the starting point for design is a proper representation of the knowledge acquired through business and user analysis. TADEUS supports the representation of enterprise models comprising the static organization of tasks, work flows, positions and roles of people involved in task accomplishment. Figure 1 shows part of a sample high level static enterprise model. In the ORM (IObject-Relationship Model) rectangles are symbols for classes, triangle relationships denote superclass-subclass relationships, such as between 'Employee' and 'Consultant'. The symbol besides the triangle in Figure 1 restricts roles of subclass elements: It allows an employee only to be either a manager or a clerk or a consultant. The static part of a business model has to contain: 1. identification of problem domain (type of business, such as 'Consultant, Agency'). 2. the entities to be processed, e.g. 'Request'. 3. functions/roles of employees required for task accomplishment, e.g. 'Consultant'. 4. relationships between the entities to be processed and the functions of people, such as 'handles' between 'Consultant' and 'Request'. Figure 2 shows the high llevel view of the dynamic specification of request handling by a state net diagram, i.e. the Object-Behaviour Diagram OBM of the business model. States are represented by rounded rectangles with a state name. Each state-net diagram is related to a class by putting, the diagram into a tagged rectangle. Transitions are also represented as rectangles, but are always located between states. The top section contains a trigger description. A trigger (in case of an event denoted "62') provides the condition that, if met, causes the transition to fire. The bottom section of the transititon triangle contains the actions that are performed when the transition fires. An action may be composed of several operations. 179

3 0 received selected to be I w passe Figure 2: OBM for the Workflow of a Request Consul- received check schedule constraints can be met Figure 3: A Part of the OBM for Task Modeling The high-level OBM in Figure 3 shows a consultant s work flow. He/She checks a request before being able to process it. It is an example for the steady adaptation process required for the design of task- and user-oriented systems. In this case, the official workflow as well as the organization of task from the employees (users ) point of view have to be synchronized twofold: First, the management s perspective has to be matched with the employees intentions or the reality, how tasks are actually accomplished; Secondly, different user skills, preferences and experiences in the organization of tasks have to be checked against the organizational requirements to deliver a product or provide a service. Successful matching of both interests ensures a maximum of individual flexibility as well as high productity. In our case study, the shown OBM-parts present a consensus between the individual organization of work and the commonly accepted work flow for handling requests. For instance, when a consultant has decided of being able to handle a request (state transition select to process in Figure 3) a consistent state in the work flow for processing requests, namely selected to be processed in Figure 2 can be identified. In addition, the top level view in the shown OBMs, in which all parties involved in task accomplishment have to agree upon, allows to develop a variety of individual models to process requests at an underlying level of abstraction. In this sense, the adaptation process has to be understood to be an integration of the business model and the user model (see also 2.4). The synchronization procedure mentioned above is part of the development of an organization using interactive systems. It has to be undergone by the management and the employees before a system is installed permanently. This step, however, may require experiments concerning the organization of work. &om the methodological point of view, both the ORM and the OBM of each business task provide the basis for further refinements in design. According to the model-based framework we will give examples for the data, interaction, and the user model that have to be integrated finally. 2.2 Data Modeling A data model is understood to be a structured set of data (e.g. bank account) and elementary operations (e.g. increase account) in a problem domain (e.g. banking) on which user tasks, such as making deposits, are operating. Figure 4 shows the static part of the derived data model for our example. Requests can either be requests for analysis or for design tasks. Both types of requests are related to analysis and design documents. The Analysis Document -class is required to store analyses as well as to start designing a business or an information system. The Design Document - class is required to file the design information. Note, that the data model has to be consistent with the business model, in order to integrate it with the customized interaction model (see 2.3). 180

4 Analvsis A is based on Request Check Search for Schedule Analysis D. I+) is assigned to Figure 4: ORM of the Data Model Figure 5: Interactive Handling of Tasks (ORM) 2.3 Interaction Modeling Interaction modeling is the crucial part in user interface design. An interaction model does not exist isolated. It is steadily modified, according to business, user, and data modeling requirements. However, the most promising candidate to start interaction modeling is a comprehensive interaction model, containing already modeled interaction styles and implemented class hierarchies (like graphical user interface builder). Such a generic model should allow extensions with application-specific interaction modalities (integrating several interaction devices). Consultant Form Interactive Handling of Tasks The first activity in interaction modeling concerns the assignment of tasks, such as Design Request to1 interaction facilities. This adaptation of the generic interaction model is performed first through the static integration of the general interaction model with the business model. The second adaptation step concerns the flow of work that is handled after incorporaiting the user model (see 2.6). In Figure 5 the business model is integrated with the generic interaction model. The figure shows a part of the ORM for the assignment of tasks to interaction media, namely, the menu-driven selection of tasks (and subtasks. The generic menu structure ( Name, Item ) is adapted towards the task structure at hand: Request, and Design Request related to the subtasks Check Schedule and Search for Analysis. Note, that Design Request can be a menu item (in case of being a subtask of Request ) as well as a menu name (in case of naming a menu containing the subtasks of handling a Design Request ). Subtasks can either remain abstract classes, namely, if they are refined to elementary operations, such as Insert Date, or they can be methods of class description, if they are not refined further on and are considered to be elementary operations..-) is assigned to Figure 6: Interactive Data Manipulation (ORM) Interactive Handling of Problem Domain Data Another activity in the continuous adaptation process of the generic interaction model is the assignment of interaction modalities to those elements of the data model that are displayed for users, and/or have to be manipulated interactively for task accomplishment. It is performed the same way already described in for assigning interactive tasks to the generic interaction model. In Figure 6 part of the consultant s work space is described by handling a form when a Design Request is processed. Request details are assigned to fields of the form. Such an assignment has to be performed for all elements required for interactive task accomplishment. The consistency with previous specifications, e.g. interactive handling of tasks, is maintained automatically in the TADEUS-environment (see 2.7). Up to now, the business maldel and the data model have been integrated statically with the interaction model. Before the designer is enabled to specify the 18 1

5 Consultant MANIPUL. has BOARD... Figure 7: A Part of the ORM of the User Model behaviour of the application (see 2.6), the user model (in 2.4) and its relationships to the interaction model have to be specified (in 2.5). 2.4 User Modeling In contrast to conventional user models we understand a user model to be an integrated representation of several dimensions of user interaction. These dimensions are related to tasks, data, and interaction devices and modalities. They do not only concern the access rights assigned to organizational functions of a user but also the degree of freedom the user is enabled to individualize his/her interactive work space, e.g. the arrangement of data on the screen, without disturbing the global workflow. As a consequence, for the specification of the user model, the designer has to jump to the business model (Figure l) again. From there operations for adapting tasks and data, such as Set Display Variables of Analysis Request and Analysis Document in Figure 7, can be derived. If general set-up features, e.g. for a graphical user interface, are required, elements from the first versions of the customized interaction model (see and 2.3.2) may also be incorporated. Note, that the task- and data-assignment to operations from the user model implies that all forms of displaying tasks and data can be modified by users. Hence, if it is possible to display a task through a command or an icon (expressed in the customized interaction model), both, the command and the layout of the icon can be modified by each user. The second dimension represented in a user model addresses control information that is usually part of a user profile: user identification, password, quota, etc. Since it has also to be considered to be part of any user work space, it has to be modeled for all user groups. The ORM in Figure 7 shows both dimensions of user modeling. It exemplifies the handling of the password one hand, and the handling of task- and data-displays on the other hand. ANALYSIS i REQMENU 1 DESIGN 1 REQ.MENU I Figure 8: ORM-Part of the Customized Interaction Model 2.5 The Customized Interaction Model A customized interaction model provides a complete overview of the modalities and devices to be provided for the system at hand. It comprises only the relevant part of a(.) (UIMS-)class hierarchy that actually should be available for interaction. The customized interaction model is the one and only model that is relevant for the last activity before functional specification, namely the dynamic (behaviour) specification of the target application. The class hierarchy for the interaction model in Figure 8 shows the direct manipulation interface part of the application. Subclasses of Menu and Form correspond to the tasks, subtasks and problem domain data. The entire business, data and user model have to be incorporated into this hierarchy, as soon as presentation or user manipulation may occur. 2.6 Dynamic Specification After having customized the interaction model the designer is enabled to specify the workflow, in order to provide an impression about the overall behaviour of the specified system. In general, two issues for dynamical specification have to be taken into account: 1. the synchronization of operations of the interaction devices and user tasks with the operations on the problem domain data. Then, the actual workflow can be specified. 2. the work space of each user (group), i.e. all tasks and operations including the degree of freedom to rearrange tasks and problem domain data for each user (group). Figure 9 exemplifies a synchronization step between a business-obm and an interaction-obm. It shows a 182

6 Figure 9: Interactive Task Handling (OBM) or enters oece refer to clerk initializatioi set password r sick 1 acquire requ. 1 Figure 10: The Consultant s Activity Space part of the synchronization of Analysis Request Form with Acquire Analysis Request. The interaction is expressed through an Object-Interaction Model OIM. When a clerk starts the acquisition of analysis-request data uttered by a customer, a corresponding request form is created on the screen. The synchronizedl interaction is expressed through a zigzag arrow between two states. In order to demonstrate the second issue for integration Figure 10 shows a part of the activity space for consultants in an OBM. The specification integrates task- and user-related features provided for oonsultants handling analysis- and design requests. Pinalogous to the static specification elements from the task-, user-, data- and the user model are combined. After completing the overall behaviour specification of the interactive system and the work spaces for all user groups, the functional specification can be started. 2.7 The TADEUS-Enivironment The TADEUS (Task Analysis/Design/End-User System) - environment is currently being implemented to allow designers to specify the acquired knowledge, comprising tasks, users and their refinements. In addition it will support the automatic generation of code, thus, supporting prototyping. The front-end of the TADEUS-environment for developers is a set of editors. They support the specification of the business, data, interaction, and the user model. For each of the models, OBMs and ORMs may be specified. In order to support the integration of the models according to the methodology, TADEUS support the incorporation of the business, data and user model into the interaction model, as well as the creation of OIMs in order to model the workflow and the users activity spaces. The developer s work space is implemented in TCL/tk under X, C, and Smalltalk for managing large object repositories required to store and retrieve the models. 3 Conclusions Revisiting the WHO, the WHAT and the HOW has become a must, since user interface designers are still struggling for a structured representation that takes into account all knowledge relevant for task- and useroriented user interface development. TADEUS (Task Analysis / Design / End User Systems) provides an integration scheme for the specification of the users (WHO) of an interactive system and its functionality in a declarative (WHAT) as well as procedural way (HOW). TADEUS has finally become an environment providing the construction of several models: business-, user-, data-, and interaction model. Hence, comprehensive specifications can be developed. Designers are provided with a notation that allows static and dynamic specification arid mutual adaptation of the models at several layers of abstraction. Finally, designers are able to keep the rielationships between the models as loose or tight as he/ she feels to be adequate, without loosing different perspectives and consistency of the specification. Using TADEUS, consistent and context-sensitive user interface development as it occurs in reality of software development is supported. References [l] Embley, D.W., Kurtz, B.D., Woodfield, S.N. Object-Oriented Systems Analysis. A Model- Driven Approach. Yourdon Press, Englewood Cliffs, New Jersey, [2] Stary, Ch. Basic Models ifor User Interface Development: Tasks, Users, Data, and Devices, Proc. HC1 95, Yokoama, July 1!995. [3] Sukaviriya, P.N., Foley, J.lD., Griffith, T. A Second Generation User Interface Design Environment, Proc. INTERCHI 93, ACM/IFIP, 1993, pp [4] Szekely, I?., Luo, P., Neches, R. Beyond Interface Builders, in Proc. INTERCHI 93, ACM/IFIP, 1993, pp

COMMIUS Project Newsletter COMMIUS COMMUNITY-BASED INTEROPERABILITY UTILITY FOR SMES

COMMIUS Project Newsletter COMMIUS COMMUNITY-BASED INTEROPERABILITY UTILITY FOR SMES Project Newsletter COMMUNITY-BASED INTEROPERABILITY UTILITY FOR SMES Issue n.4 January 2011 This issue s contents: Project News The Process Layer Dear Community member, You are receiving this newsletter