Education

The Enabling States Approach: Designing Usable Telecommunications Services

Description
The Enabling States Approach: Designing Usable Telecommunications Services
Categories
Published
of 7
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Share
Transcript
  524 IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS. VOL. 9. NO 4. MAY 99 The Enabling States Approach: Designing Usable Telecommunications Services Paul Byerley, Jon May, Andy Whitefield, and Ian Denley Abstract-Unless it is possible to use a broadband communi- cations terminal for directly engaging in the tasks and activities which are important to the user, without the necessity of learn- ing complex skills like those all too often required to operate today’s workstations, uptake will be restricted and usage will he inefficient. The enabling states approach distinguishes be- tween the users’ goal tasks, the states of the communication sys- tem which enable the performance of those tasks, and the en- abling tasks required to create such enabling states. The intention is to improve usability and hence both uptake and usage) by designing interfaces that automatically identify and create the appropriate enabling states, allowing the user to con- centrate upon their goal tasks rather than the enabling tasks. The approach is illustrated and discussed in the context of IBC systems. I. INTRODUCTION N contemporary computer and telecommunication users I nterfaces, the user must perform many tasks which are not directly related to their main goals. Such tasks include acquiring knowledge of available facilities, matching those facilities against the task requirements, choosing a facility, and invoking and maintaining the facilities needed. Although these tasks are not directly involved in reaching the user’s goals, they must be carried out in or- der to enable the performance of the directly goal related tasks. This paper introduces an approach which tries to distin- guish these two classes of tasks during the development of a system. As a minimum, this ought to allow both a better focus on exactly what goals the user is trying to achieve and a clearer basis for allocation of function de- cisions; at best it might be possible to develop interfaces which can themselves identify, and as far as possible un- dertake, the nongoal tasks, leaving the user to concentrate on their goals. The paper discusses the approach in the context of in- tegrated broadband communication (IBC) systems, since that is the concern of the project on which the work has been done. The approach itself, however, is general and not particular to IBC. Manuscript received September 12, 1990; revised February 4, 1991. This paper has been supported by RACE Project RI067 GUIDANCE, which comprises SEL, AG, the University College London Ergonomics Unit, Roke Manor Research Ltd., British Telecom Research Laboratories, and Televerket. P. Byerley and J May are with the Standard Elektrik Lorenz, D-7530 Pforzheim, Germany. A. Whitefield and I Denley are with the Ergonomics Unit, University College London, London, UK WClH OAP. IEEE Log Number 9144453. n ravel Aeent databasen I W Head office manager locauon c) Videotelephone Head office manager locauon c) Customer Customer location a) location a Fig. 1. An interactive IBC work system. Circles represent entities (hu- mans, software, machines, etc.), and lines represent communication chan- nels. Italics describe the variety of forms the communication tasks can take. A. IBC Work Systems The analysis of usability requirements for the integra- tion of broadband services begins with the concept of an interactive IBC work system, or IIWS. This consists of communicating entities (such as humans, databases, and network management systems) and the communication channels between them (Fig. 1). An IIWS exists within a work domain, in which it op- erates to bring about changes. Note that a work domain includes all communication tasks of potential IBC users, whether in the domestic or business sectors, together with the objects on which tasks are performed. IBCN designers face the problem of specifying and implementing the be- havior of the communicating entities and channels such that their interactions achieve the intended changes in the work domain with adequate performance. Within this concept of the work domain, an application can be de- scribed as a set of related tasks for which human users have goals (e.g., shopping, document preparation, med- ical diagnosis). User services, whether telecommunica- tion or otherwise, support applications-for example, a videotelephony service might support the application of medical diagnosis by hospital consultants. B. Goal Tasks, Enabling States, and Enabling Tasks Consider a task which would be quite typical within an IBC environment, the creation of multimedia virtual doc- ument by several authors located at different sites. For 0733-871619110500-0524 01 OO 991 IEEE  BYERLEY et al : THE ENABLING STATES APPROACH 525 example, some experienced subeditors may have the task of agreeing changes to a video segment of a multimedia document within a few hours. These authors will use telecommunication services to complete their task, and the services that they will need vary from time to time, depending on task requirements. They are not interested in the service per se, but in such task components as sgreement on what the main elements of the task are, what should be tackled first, the reasons for changes, expression of the proposed changes, confer- ring about the proposed changes, expression of approval/ rejection of the proposed changes, and so on. This is the task seen from the authors’ point of view. It does not in- clude components associated with setting up a telecon- ference, file accessing, security authorization, bandwidth allocation, service allocation/deallocation, and so on, even though these tasks are all necessary to enable them to be able to perform their goal tasks. This raises an important distinction. Tasks can be di- vided into two distinct classes: goal tasks and enabling tasks. Given this approach, the state which the commu- nication system (terminals, telecommunication service, the user, and other users) must be in before the goal tasks can be carried out is called an enabling state, and the tasks which bring this state about are called enabling tasks. The central assertion of the enabling states approach to design is that users want to perform their goal tasks, and the fewer enabling tasks they have to perform the easier a product is for them to use. It follows from this that, in IBC, the communication system should be in an appro- priate enabling state for the particular combination of users, services, and applications concerned (or as close to such an enabling state as is possible). The problem for designers is how to identify these enabling states and to allow them to be reached, since they are by definition dy- namic, changing from application to application, from user to user, and from moment to moment. Goal tasks are declarative elements of the decomposi- tion of a user’s overall task, and have “enabling states” as preconditions, which are created by enabling tasks. En- abling tasks are not declaratively part of the goal task de- composition (that is, they do not form part of the defini- tion of users’ goals). In order to distinguish enabling tasks and goal tasks, the user’s goals must be defined very pre- cisely. This is all the more important since users’ goals vary and, thus, any task could, under some circum- stances, be a goal task and, under others, an enabling task. Within this distinction, it can be seen that goal tasks are those which affect the objects in the domain of the task which is being performed by the communications system rather than those which affect only the communication system itself. For example, given an overall task of edit- ing a text document, rewriting a paragraph is a goal task, because the resulting document will be different, but mov- ing the pointer to the location of the correct section would be an enabling task, because it does not change the doc- ument itself, but only the state of the communication sys- tem. In order to design software and hardware to allow the performance of goal tasks and enabling tasks, it is nec- essary to consider who or what performs these tasks. The goal task enabling task distinction described so far is in- different to the agent of the task. Early approaches to de- sign began with a system specification which excluded user concepts. A user interface would be designed after system specification, often leaving the user interface de- signer with insoluble problems. Currently, the notion of a system in many approaches includes user concepts, and system specification there- fore, right from the start, includes specification of users. System specification is, therefore, driven from applica- tion requirements. Although there is no necessary link between users and goal tasks, goal tasks will generally have the user as the agent. Enabling tasks, in contrast, require function allo- cation decisions since they may be conducted either by users or by other entities in the system. However, con- sistent with this user-centered approach, wherever possi- ble enabling tasks should not have the user as the agent. Since goal tasks and enabling tasks are distinct, distin- guishable in terms of their effects, and distinguishable in terms of their agents, they need to be designed differently. This is a radical position, since the application and user’s goal vary, and any task could be at different times either a goal task or an enabling task. Thus, human-computer interface design should allow tasks to be executed in dif- ferent ways depending on whether they are goal or en- abling tasks. 11. DESIGNING HE USER INTERFACE First, given an application such as flight booking, the characteristics of an IBC work system (communicating entities: terminals, databases, human end users, and com- munication channels) could be described to enable flight booking to be carried out at particular levels of reliability, cost, etc. The description of this work system would in- clude a description of the tasks that each communicating entity would have responsibility for. This, then, is a de- scription of operational requirements from an application perspective (described further in [ 11 . Second, given an application and description of a pro- posed work system for that application, a description can be made of the characteristics of the system which would enable human end users within it to complete the tasks for which they are responsible (such a user might be, in the above example, a travel agency clerk). This is thus a de- scription of operational requirements from a human end user perspective. The enabling states approach applies to the human end- user perspective. It assumes that an application-level based telecommunications work system has been described, and seeks to configure the user-service interfaces within that system to meet as far as is possible) the performance pa- rameters of the human users who are operating within it. It should, therefore, be noted that the focus of the en-  526 IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS, VOL. g, NO. 4, MAY I991 LiVsl and-userr Uur Characnristlss Seniw Amibum Pedormnw P iteration methods Fig. 2. The relationship between application-level operational require- ments, the context of use, and end-user operational requirements. abling approach is not on the specification of a system which supports an application, but on the application of system attributes which enable a user to complete their goal tasks, within a system which supports an application. The approach must thus be developed for a system spec- ification which includes users and hardware-software ele- ments, but the approach must begin with the user as the agent. This is an important distinction from the ways in which user concepts are included in other current ap- proaches. Fig. 2 shows the relationship between the ap- plication level and the end-user level perspectives. In designing a service to provide support for some of the tasks involved in an application, the designers must make recommendations about the states of some of the communicating entities and channels. However, deci- sions about one entity of the system cannot be made with- out considering the designs of the others. It is, therefore, appropriate for the design activity to address specification of the IIWS as a whole rather than of either the user or the machines in isolation. It is important to note that this approach explicitly rec- ognizes that IBC design involves recommendations for all components of the work system. Since the human users are seen as communicating entities within the system, this approach makes it clear that designers make recommen- dations about the states that the human users must be in to use a service-what knowledge or skills they must have, for example. From the discussion above, it can be seen that the prob- lem facing designers of the user-machine interface is that (in order to be usable) the design of the user-machine in- teractions must be consistent with the user’s goal tasks and with the domain in which they are performing their tasks. The enabling states that are required for the perfor- mance of the users’ goal task provide a set of constructs, objects, and actions (that is, those entities and channels within the IIWS which have a specified state or range of values for an enabling state). These constructs limit the representations that designers can invoke to structure in- teractions. Interactions can thus only use the concepts, actions, and objects that are used in the descriptions of the enabling states and cannot introduce new concepts which do not match the users’ goal tasks. This results in a difference between the way in which the design process must treat goal tasks and enabling tasks. Goal tasks are used to define the enabling states necessary for their performance, and so drive the gener- ation of the concepts used to describe the enabling states. They are thus of primary importance in the derivation of the conceptual language that is to be used throughout the design process. Enabling tasks, however, are derivedfrom the enabling states. They differ from goal tasks in that while goal tasks have a well-defined enabling state from which they are performed, enabling tasks are defined in terms of their end state and must function from several 1 a range of starting states. It follows, therefore, that en- abling tasks cannot influence the domain conceptual lan- guage of design. No new concepts can be introduced to satisfy the interactions for enabling task8. This last point has an important consequence. Since en- abling tasks can be performed by agents other than the human user, it might be argued that it is irrelevant what concepts are used in their performance because the human user need not be concerned with them. If this were so, however, the resulting service would embody concepts in its behavior that the human user had no information about, and so would be unable to use it to interpret the service’s behavior. The distinction between enabling tasks and goal tasks, then, ensures that the concepts used in the design of the user-machine interaction are open to modeling by the human user, an aspect which is of central importance in usability (see [3]). The analysis of goal and enabling tasks thus provides an organizational and conceptual language to guide the design of the user-machine interface. The designers are free to use this language to describe the interaction tasks and objects. This ensures that the interaction procedures and the device operations are also prescribed in terms of the users’ goals and the domain of their goal tasks. A. A Design Method for the Enabling States Approach The enabling states approach uses an analytical soft- ware-oriented design method, which is illustrated in Fig.  3.  The boxes in this diagram correspond to distinct stages in a specification process, with tables being completed at each stage. At each stage, the designer is supported by usability principles (which will be described in Section 11-B). The stages can be briefly described. Main Goal: The overall description of the task that is to be supported by the application, described from the end- user point of view. Subgoaf Tasks: The component subgoals that the end- users will work through in the completion of the main goal (identified through a task analysis) Enabling States: For each subgoal, the appropriate states of each of the entities and communication channels, such that the end-user can accomplish their subgoal. Enabling Tasks: For each enabling state, any tasks that must be performed to achieve the appropriate state of the entities or channels. Domain Objects: Objects in the task domain other than  BYERLEY et al.: THE ENABLING STATES APPROACH 527 I able 7 I I table lb abled table I phases I I I enabling stafe system function phase Fig. 3. The stages in the enabling states and system function phases o specification. the entities and channels which must be operated upon by subgoal tasks or enabling tasks. Subsystem: A high-level clustering of functionality that the telecommunication system must provide, correspond- ing to the actions an end-user will perform in accomplish- ing a subgoal. Toolbox: A collection of functions that will be used together by the end-user in peforming a particular aspect of a subgoal or in reaching the enabling state for that subgoal. Function: The lowest level description of functionality to be provided by the system, describing a single set of actions upon one or two domain objects. View: An interface description grouping together as- pects of the interface that require each other to be present (or available, i.e., pop-up menus). Generic Interaction Object: A collection of interface objects which always appear together as a group in fixed relation to each other, providing interactions with related functionality. Widget: The lowest level of interface object, each al- lowing one interaction (or at most a very small number). B. Usability Principles for Design Each usability principle is parameterized by the “con- text of use” of the end-user. The “context of use” con- sists of descriptions of the users’ goal tasks, the users’ characteristics, service attributes derived from the appli- cation-level perspective, and the desired end-user perfor- mance. This results in prescriptive principles of the form: If X = frz(T, U, S, Po then Y because R( Y = fn X)) with guarantee p > threshold where X is the triggering attribute set T is the task attribute set U is the user attribute set S is the services attribute set PD is the desired task performance Y is the prescription for design R is the rationale p is the probability that the prescription holds. To illustrate this, consider the following “generic prin- ciple” applicable over a range of applications: IF the task involves spatial designation and the users have experience with single services and the services involve more than one user service and the performance must be fast with minimal effort by the user, THEN (prescription) maintain common logical and functional relationships between objects manipulated under the various services Because (rationale) the user will be able to recruit the same knowledge to perform data entry actions under the different services with a guarantee equivalent to “highly probable. A specific principle derived from this generic one would instantiate it with respect to a particular application, such as multimedia multiauthor document production (MMMADP): IF the task requires designation of words expressed as text and the designation of graphical objects and the users are authors with experience of desktop publishing software with direct manipulation interfaces and the services include both text-processing and graphical design services and the performance must be at least as good as exhib- ited by the same users on the machines they are famil- iar with THEN (prescription) ensure that the spatial designa- tion device provided supports the same functions under the two services (e.g., designating and moving ob- jects), and that the same user actions are required to initiate functions (e.g., with respect to control/display movement relationships, and to the consequences of actions to designate objects). BECAUSE etc The generic principles can be classified according to the following high-level taxonomy. 1 Simplicity of Operation: If a user is to act with re- spect to a machine, then the number of complexity of ac- tions required to bring about a desired state of the ma- chine should be minimal and the effect of each action should be predictable. 2 Consistency: If a user acts with respect to the ma- chine, then the machine should always assume the same or an equivalent state in response to a particular action or action sequence. 3 Compatibility (Cognitive): If a user and a machine are to interact in the performance of a task, then the users  528 IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS. VOL 9. NO 4. MAY 1991 knowledge should support user behavior bringing about desired state changes in the machine. 4 Reversibility: If an action performed by a user brings about a state of the machine and of the domain, Select holiday for holidaymaker . ... then-there exists a user action that restores the preexisting states. , ,, U,. ..-. -. 5 Coherence: If the user acts with respect to the ma- chine, then the range of machine states that can be as- quences should form a meaningful set. sumed in response to a set Of actions Or Of action se- 6 Redundancy: If a high memory load is placed upon the user in performing a task, then the user should be pro- vided with summary information concerning the actions required to bring about the necessary machine states. 7 Salience: If the Cognitive State Ofthe User must be changed, then machine behavior must be sufficiently in- trusive to attract conscious attention. Fig. 4. A goal-task decomposition for the task select a holiday for a holidaymaker. B. Enabling States Analysis The highest level goal task of the work system, as spec- ified above, is to select a holiday for a holidaymaker. Given the description of the domain of work, this can be seen as identifying the attributes of the holidaymaker so 111. AN EXAMPLE PPLICATION F THE APPROACH This section reports a brief illustration of an enabling states analysis of a travel agency scenario. The scenario is defined as the selection (but not the booking) by a single holidaymaker of a suitable holiday. A. The Worksystem and the Domain A number of basic concepts need to be identified as a preliminary to the actual enabling states analysis. The work system comprises one human and one IBC terminal. The human is assumed to be an adult, but not necessarily one experienced in computer use. The termi- nal is as yet unspecified but is assumed to have multime- dia capabilities and to include one or more user services. The ultimate goal of the analysis is the design of this work system. The work to be achieved by the work system is identi- fying holidays suitable for a particular holidaymaker. (Note the work is not selling holidays, booking a holiday, or browsing the holiday database for information.) The high-level goal task is, therefore, to select a holiday suit- able or holidaymaker. Given the above definition of the domain of work, the objects in the domain can be identified as a holidaymaker and as a large (possibly infinite) set of holidays. Identi- fying the values for all the attributes of an object would completely describe the object (for the purposes of this work domain). The closer the attribute values of a holiday are to the attribute values of a holidaymaker's desired hol- iday, the more satisfactory that holiday will be. Holiday attributes would include aspects such as loca- tion, price, dates, accommodation type, weather facili- ties, sights, etc. A holidaymaker can similarly be de- scribed by a set of attributes: money, free dates, interests, special needs, travel history, desires about location, weather, accommodation, facilities, etc. It is clear that most of these attributes have a fairly close relationship with the attributes of the holiday. It is important to re- member, however, that they are not the same. that the attributes of the desired holiday can be inferred, and a suitable candidate(s) identified from the set of avail- able holidays. This highest level goal task can be decomposed into three subgoal tasks, each having two further subgoal tasks. This goal task decomposition is shown in Fig. 4. In construct set, a set of candidate holidays is prepared which match the attributes of the desired holiday. This comprises the two subtasks of identifiing desired holiday attributes and selecting candidates. In the task of explore set, a set of candidate holidays is examined to identify which are suitable for further consideration, and which are not (view candidates and assess candidates). The task of modifiing representation o holidaymaker(s) allows the worksystem to discover, correct, or further express its representation of the holidaymaker's attributes, so that a better definition of their desired holiday can be con- structed. This is accomplished by processing the assess- menfs the holidaymaker has made of the candidate set in order to establish the criteria they are using to select and reject holidays (this may even involve the use of direct questions, such as Are you only interested in skiing hol- idays? or So you want to go somewhere warm but not too sunny ) and by modifiing the holidaymaker s attri- butes. It is possible to see a simple progression through these tasks, with a set of candidates being constructed then ex- plored, resulting in changes to the representation of the holidaymaker's attributes, and thus enabling the construc- tion of a refined set, and so on, until the set is small enough to be acceptable or has been reduced to one. How- ever, it is important to realize that in principle any of the tasks could be performed first. The exploration could ini- tially occur upon the complete set of available holidays, or some preliminary information could be obtained about the holidaymaker to restrict the initial set of candidate holidays. Some of the six lower level subtasks will now be ex- amined in more detail, and their enabling states and en- abling tasks described. T
Search
Similar documents
View more...
Tags
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks
SAVE OUR EARTH

We need your sign to support Project to invent "SMART AND CONTROLLABLE REFLECTIVE BALLOONS" to cover the Sun and Save Our Earth.

More details...

Sign Now!

We are very appreciated for your Prompt Action!

x