Assessing Usability from Formal User-Interface Designs - CiteSeerX

Assessing Usability from Formal User-Interface Designs Andrew Hussey Ian MacColl David Carrington Software Verification Research Centre Department of Computer Science and Electrical Engineering The University of Queensland Brisbane, Qld, 4072, Australia E-mail: {ahussey, ianm, davec}@csee.uq.edu.au Abstract

systems by Sufrin [21] and Duke and Harrison [6]. In this paper we use Object-Z [7] for specification. Our approach differs from Z (and other state-based notations such as VDM) primarily because the object-oriented characteristics of Object-Z enable us to make full and direct use of user-interface components as a structural mechanism for our specifications. Such a description parallels the presentation of the interface and provides a convenient basis for design of the interface’s presentation. In section 2 we discuss the usability principles that we use to demonstrate usability analysis of formal userinterface designs. Section 3 provides an example of two small case study user-interfaces and section 4 describes how usability can be analysed from an Object-Z user-interface design. In section 5 we discuss applying the analysis techniques from section 4 to compare the case studies described in section 3. Section 6 describes how formal user-interface designs have been used as the basis of usability analysis.

In this paper we demonstrate usability analysis of Object-Z user-interface designs. Usability can be defined in terms of five salient properties of an interactive system: task efficiency, reuse, user-computer communication, robustness and flexibility. Formal user-interface designs have been touted as a basis for determining the usability of an interactive system prior to the expense of system development. However to date, a comprehensive demonstration of the utility of formal designs for this purpose has not been forthcoming. We show that formal user-interface designs provide a valuable basis for usability analysis.

1. Introduction In addition to the conventional problems of correctly implementing functional requirements, interactive systems must satisfy human factors requirements. Human factors requirements may be elicited from system users or may be mandated in the form of guidelines or standards. Formal methods are increasingly used to capture functional requirements. We define formal methods as mathematically-based techniques to describe system properties. They provide a framework for systematically specifying, developing and verifying systems. Formal specifications are precise, concise and abstract. The use of a mathematical notation enables rigorous analysis of requirements, such as user-oriented or safety properties before the expense of implementation. Research on formally based development of userinterfaces has been conducted at a number of centres, including the University of York (e.g., [5]) and at the University of Queensland (e.g., [11, 15]). The Z notation has been applied previously to the specification of interactive

2. Usability Mahemoff and Johnston [16] describe six properties that capture the essential qualities of a “usable” interactive system. Comprehensibility is really just a measure of task efficiency, reuse and user-computer communication and for the purposes of this paper has been removed from Mahemoff and Johnston’s original list. This paper demonstrates analysis of the usability of interactive systems from the remaining five properties described by Mahemoff and Johnston: Task Efficiency: Help users of varied experience levels to minimise their effort to perform their tasks. Reuse: Ensure that users can reuse existing effort and knowledge. Knowledge reuse is usually achieved via consistent look-and-feel. Reuse of effort requires mechanisms for saving and retrieving previous work. 1

User-Computer Communication: Facilitate collaboration between humans and computers by appropriately representing changes to the system (which have been instigated by humans or computers).

User-Computer Communication, Robustness and Flexibility, provide a meaningful, but potentially incomplete, measure of usability. Our argument is based on the observation that most other usability frameworks, such as that set out by Dix et al., can be mapped (with minor exceptions) to the framework provided by Mahemoff and Johnston.

Robustness: Minimise the likelihood of users misperforming tasks and facilitate recovery from errors when they do occur.

3. Case Study: A Language Translator

Flexibility: Account for users of different backgrounds and experience by allowing for multiple ways to perform tasks and by enabling user customisations of the system.

In this section we present a case study of a simple system for translating between English and French. We present two alternative user-interface designs for the system. The functionality of the example is deliberately a simple prototype, only able to correctly translate the pair (hello,bonjour), returning ce qui or pardon for all other words. We define the user-interface of a software system as the part that handles output to, and input from the person using the system. The rest of the system is called the application or functional core. The functional core specification for the system is as follows (we use a class String to model text strings, but elide its definition for brevity). We distinguish instances of class String corresponding to the required inputs and outputs.

Similar properties have been set forth by other authors. Laurel [14] compares the design of user-interfaces to the staging of theatre productions and describes several principles for good user-interface design. Laurel’s principles can be readily mapped to Mahemoff and Johnston’s properties. Laurel stresses that the computer is a medium for communication and that the interface should reflect the context of the world that is being represented by the interface rather than using obscure metaphors that tend to confuse learning and understanding. Laurel emphasises actions as the focus of design. Much of Laurel’s advice is clearly relevant to the User-Computer Communication property described by Mahemoff and Johnston. Shneidermann [20] offers eight golden rules of dialog design, that can be readily mapped to Mahemoff and Johnston’s properties: strive for consistency, provide shortcuts, offer feedback, ensure closure of tasks, avoid user errors, provide easy reversal of actions, support internal locus of control and reduce memory load. Usability has been described by Nocentini [17] as “the ability of a software product/prototype to interact easily and effectively with the user, in order to fulfill his/her needs and expectations”. Gimnich [8] has identified the following factors as important in measuring usability: learning time, peformance time, error rate, subjective satisfaction, and retention over time. Gimnich emphasises the need to integrate usability engineering as part of the software engineering process. Again, there is a clear mapping between the factors described by Gimnich and the properties given by Mahemoff and Johnston’s categories. Dix et al. [3] describe fourteen usability principles. All but the principle of Responsiveness can be mapped easily to Mahemoff and Johnston’s properties. Responsiveness is the rate of communication with the system perceived by the user (an aspect of Task Efficiency, but not one stressed by Mahemoff and Johnston). In this paper, to demonstrate analysis of usability from Object-Z specifications, we use the properties for usability described by Mahemoff and Johnston as set out above. We argue that the five properties, Task Efficiency, Reuse,

EMPTY , HELLO, BONJOUR, PARDON , CEQUI : String We define functions etof and ftoe to achieve the actual translation. Function etof (ftoe) returns CEQUI (PARDON ) for all Strings except HELLO (BONJOUR), for which it returns BONJOUR (HELLO). etof , ftoe : String → String etof = (λ s : String • if s = HELLO then BONJOUR else CEQUI ) ftoe = (λ s : String • if s = BONJOUR then HELLO else PARDON ) The TranslatorCore class is stateless and encapsulates operations to perform the required translations.

3.1

TranslatorCore FrToEn s?, s! : String

EnToFr s?, s! : String

s! = ftoe(s?)

s! = etof (s?)

User-Interface A

User-interface designs can be described formally in terms of a collection of user-interface components [11]. The first user-interface design consists of two labels (Anglais 2

and cbf are the clear buttons for the text fields. We focus on the user actions rather than the underlying event handling mechanisms.

and French), two corresponding text input fields, and four buttons (labelled down, up and two “clear” buttons, one for each text field, each labelled clear). A user enters a word into a text field, presses the ENTER key or the corresponding button, and a translation is inserted into the other text field. Each clear button removes the text from the corresponding field. The user-interface is shown in Figure 1.

TranslatorA el , fl : JLabel et, ft : JTextField eb, fb, cbe, cbf : JButton c : TranslatorCore

dbClick =  eb.Click ∧ et.getText

c.FrToEn ft.setText ubClick =  fb.Click ∧ ft.getText

c.EnToFr et.setText cbeClick =  cbe.Click ∧ et.Clear cbfClick =  cbf .Click ∧ ft.Clear enterKey =  et.EnterKey ∧ dbClick [] ft.EnterKey ∧ ubClick etEdit =  et.Edit ftEdit =  ft.Edit etInsert =  et.Insert ftInsert =  ft.Insert etDelete =  et.Delete ftDelete =  ft.Delete

Figure 1. Design A for Translator system The interaction between the various components and a human user is quite complicated. The clear buttons are only enabled when the corresponding field contains text. There are two possible means to invoke a particular translation (clicking a button or pressing the ENTER key). We simplify the specification by eliding details such as focus, layout, etc. We specify the first design by system class TranslatorA, We define state variables representing the labels (el and fl ), text fields (et and ft) and the buttons (ub, db, cbe and cbf ). We use components from [12]. For example, the JButton class is defined as follows:

The TranslatorA class promotes operations of contained components to the system level. We only consider user-visible actions. Clicking on a translation button (dbClick or ubClick ) invokes the button’s Click operation and invokes the translation in the appropriate direction. The translation is comprised of a sequential composition (o9) that retrieves the source text (getText), translates it, and inserts the result (setText). Clicking a clear button (cbeClick or cbfClick ) invokes its Click operation and clears the text field. The remaining user actions are defined similarly. Pressing the ENTER key in a text field invokes the field’s EnterKey operation and also invokes the Click operation of the corresponding translation button (dbClick or ubClick ). Text field operations are simply promoted.

JButton Text : String Pressed , Enabled : B setText ∆(Text) s? : String

INIT ¬ Pressed Enabled getText s! : {Text}

Text
= s?

Clear ∆(text)

ToggleEnabled ∆(Enabled )

Text = EMPTY Text
= EMPTY

INIT el .INIT ∧ fl .INIT et.INIT ∧ ft.INIT eb.INIT ∧ fb.INIT cbe.INIT ∧ cbf .INIT

Enabled ⇒ ¬ Enabled
¬ Enabled ⇒ Enabled


3.2

Press =  [ ∆(Pressed )| Enabled ∧ ¬ Pressed ∧ Pressed
] Release =  [ ∆(Pressed )| Enabled ∧ Pressed ∧ ¬ Pressed
] Click =  Press o9 Release

User-Interface B

An alternative user-interface for the translation system is shown in Figure 2. In the alternative system, users select a language to translate to using a pair of radio buttons and enter the text to be translated in an entry field. Translation is invoked by clicking the Do it button and the result of the translation appears in a label. A Clear button enables the text field to be cleared.

The button db corresponds to the down button and the button ub corresponds to the up button. The buttons cbe 3

Reuse An Object-Z specification can be of assistance in measuring the consistency of a user-interface, but measuring the extent to which effort is reused is difficult to formalise. To measure consistency we need to consider several scenarios for each user-interface. The formal definitions of the scenarios need to be compared to locate tasks with common operation sequences in each scenario. Such tasks are consistent. Consistency is measured by the proportion of consistent tasks that can be located for these scenarios. Given two user-interfaces, we can determine their relative consistency for the given set of scenarios.

Figure 2. Design B for Translator system

TranslatorB in : JTextField trans, clr : JButton res : JLabel rb : RadioButtons ren, rfr : JRadioButton

INIT trans.INIT ∧ clr .INIT res.INIT ∧ in.INIT rb.INIT rb.buttons = {ren, rfr }

User-Computer Communication There are two aspects of user-computer communication to consider: what is being presented, and when (timeliness). Timeliness of user-computer communication cannot be determined from an Object-Z specification because such a specification does not usually provide information on the dynamic “real-time” properties of the system. The correctness of the representations provided by the user-interface for both inputs and outputs can be established from the corresponding data-transformation relationship between the functional core and the user-interface. Usually, the transformation should be bidirectional, so that no information is lost by the user-interface representation of the functional core data. However, the suitability of the manner in which information is presented by the user-interface cannot be readily checked in a mechanical fashion.

Edit =  in.Edit Insert =  in.Insert Delete =  in.Delete EnterKey =  in.EnterKey ∧ transClick inClick =  in.Click rbClick =  rb.Click clrClick =  clr .Click ∧ in.Clear transClick =  trans.Click ∧ in.getText

(([ rb.selected = ren ] ∧c.FrToEn) [] ([ rb.selected = rfr ] ∧c.EnToFr ))

res.SetText

4. Usability analysis of Object-Z specifications Robustness Object-Z specifications of interactive systems provide a basis for formal analysis of the usability properties described by Mahemoff and Johnston. In each case, we assume that the objective is to determine which user-interface from two or more given interfaces is more usable for a given use-case, rather than to place an objective measure on the usability of a single user-interface in isolation.

For a given scenario, error paths are determined for each interface. An error path is a path from the initial state identified for the scenario to a different final state from that identified as the goal state for the scenario. For each interface, the paths provided by the system to enable recovery for the chosen scenario are determined and formalised. The potential error paths and efficiency of the recovery scenarios can be compared for the two competing user-interfaces. An Object-Z specification says little about the likely user error rates for a given scenario for competing user-interfaces. To determine such error rates, one must consider both the physical actions that the user is required to perform and the cognitive operations that are required. The error rate for the task is a product of the error rates for both the cognitive operations and the physical actions. A discussion of methods for determining such error rates is given in [13].

Task efficiency This property can be measured by formalising the steps required to perform a scenario under consideration using a process algebra such as CSP and system-level specification operations. The efficiency of each scenario can then be compared using simple metrics such as the number of operations in the scenario. 4

Flexibility

A comparison of the usability of the two alternative designs can be made using the criteria set out in the previous section.

The flexibility of a user-interface can be measured by considering the number of distinct paths provided by the system enabling a given scenario to be completed. In practice this can be difficult to determine because it is difficult to guarantee for a given Object-Z specification that all paths from a pre-state to a defined post-state have been identified. In addition, this is a simplistic view of flexibility since it considers only distinct paths, but not whether the paths are in some sense usefully distinct. An interface that enables operations to be performed in any order is more flexible than one that imposes a temporal moding, but not necessarily more usable where the moding is natural and the task is well practiced or where flexibility is achieved by splitting task steps that can be designed as single actions (e.g., replacing buttons by radio-buttons and a “do it” button).

Task efficiency: A requires 2 task steps, rather than 2.5 for B (on average, assuming each translation is equally likely and is independent of previous translations), and hence is more efficient. Consistency: If we compare the analysed scenario with the alternative scenario of translating from French to English, we find that A and B are equally consistent. For A the sequence of actions is Edit → ubClick (i.e., there is one operation that is not common, ubClick ). For B the sequence of actions required for this alternative scenario is identical to that required for the scenario of translating from English to French (assuming again that, in the worst case, English is set as the target language). However, the action rbClick takes a radiobutton as an input and invokes the operation Click on that button. Hence, rbClick should be decomposed in an analysis to arrive at the individual widget operations. When this is done, the operation rbClick becomes either ren.Click or rfr .Click and hence rbClick cannot be regarded as a common operation between the original and alternative scenarios.

5. Analysis of Case Study The scenario we consider, for which we wish to determine the relative usability of the two alternative language translation systems is the task of translating a word from French to English. Abstractly, this task is specified by the core operation FrToEn. The abstract task is instantiated for each case study user-interface as a sequence of operations. For system A, a minimal required sequence of operations is as follows (the sequence is minimal because we assume no deletion and re-editing). Note that dbClick can be replaced by enterKey.

User-Computer Communication: The mapping between the core state and the representation in A and B is one-to-one. The core specification (TranslatorCore, defined previously) produces strings s! for the translations generated by FrToEn and EnToFr . These strings are represented in A using text fields and in B as a text field and a label. Both text fields and labels display strings directly, with corresponding Text attributes. Similarly, inputs to the core are represented in the user-interface as strings.

FrenchToEnglish A =  ftEdit → dbClick Whereas for system B, a minimal required sequence of operations is as follows (the Edit and rbClick steps are interchangeable), assuming that French is set as the target language (or this is the first translation; initially no radiobuttons are set according to rb.INIT ) and the target language therefore needs to be toggled. Again, transClick can be substituted by enterKey.

Robustness: We consider the error of failing to perform a translation from English to French. We consider whether this error is possible for each of interfaces A and B and in such case the recovery steps required to correct the error. Note that for both interfaces it is possible to enter the text for translation and then clear the entry field erroneously. However, this is not an error for which design intervention is possible. We do not consider the likelihood of error. In part such likelihoods are determined by the labelling of the text fields and buttons and may differ according to whether the user is an English or French speaker. Such likelihoods cannot be determined simply from an examination of the formal user-interface design.

FrenchToEnglish B =  Edit → rbClick → transClick The operation rbClick sets the appropriate radio button, according to whether translation from English to French (click “English”) or French to English (click “French”) is desired. For this scenario, translation from French to English is required. However the operation rbClick need not be invoked if the pre-state of the system is such that English is already selected as the target language. We do not need to consider the situations in which users make editing mistakes, since that part of the interface is the same for both systems (both use a text field to enable text to be entered and edited).

For user-interface A, the erroneous sequence of actions is etEdit → dbClick , which results in the contents of 5

et being set to pardon, if we assume that both text fields are initialised to empty. Recovery requires that the entire task be re-performed.

priate radio-button (rbClick ) followed by clicking on the ”Do it” button (transClick ).

User-interface B permits the following sequence of operations: Edit → rbClick → transClick (where rbClick sets the radio button to ren, i.e., English as the target) which translates from French to English. The error in this case is to click the wrong radio button. It is likely that the translation function ftoe does not contain a mapping corresponding to most English words and the result will therefore usually be pardon.

Based on the properties considered, and the analysis that is possible from an Object-Z specification, A appears to be more efficient, however B appears to be more robust and flexible. The flexibility in B is achieved however at the expense of efficiency. With minor changes, the robustness problems identified for A can be corrected (in that the error path is no longer possible). Overall therefore, A and B offer different advantages, but the revised design for A appears to be more desirable since it would offer efficiency rather than flexibility. Because the interface is simple and the task is well known (enter data then execute an operation on that data by clicking a button), the extra flexibility offered by B is not as desirable as the efficiency offered by A. Another possible design would remove the Do it button from user-interface B and translate the contents of the text field immediately the appropriate radio-button was clicked. Such an approach would breach user-interface design conventions that prohibit actions being associated with radio-buttons other than setting a variable in the system state. Mahemoff and Johnston’s usability properties say nothing about which sort of widgets to use for which types of operations in the system but an Object-Z specification could be checked for conformance with such widget guidelines.

To recover the user does not need to reenter the text of in; they need only perform rbClick → transClick (where rbClick sets the radio button to rfr , i.e., French as the target). The same number of recovery operations are required as for A, but recovery is simpler because etEdit is likely to involve several keystrokes, as opposed to the single mouse operation required by rbClick . Our model does not provide a keystroke level model of interaction and hence we cannot formally analyse the efficiency of the recovery sequence at this level of granularity. In [10], a notation is provided for integrating UAN annotations with Object-Z which would be suitable for such keystroke level analysis. User-interface A could be redesigned to improve robustness for the examined scenario by “greying-out” the buttons db or ub according to which text field had been last edited by the user or was not empty. However such an approach could reduce flexibility and would complicate recovery paths for other tasks. For example, consider the scenario in which a user enters an English word, translates the word to French then clears the English word erroneously. One recovery path, assuming translations are reversible, would be to translate the French back to English. If the buttons db or ub were disabled according to the last edited text field, the user would need to click on the French text field before clicking on db.

6. Related Work Palanque et al. [18] translate task specifications into equivalent models expressed as Petri nets and Interactive Cooperative Objects. The example they present is an automatic teller machine (ATM) and they identify temporal constraints that must be applied, for example, so that a user’s card must be withdrawn from the ATM before cash is removed. They show absence of deadlocks, reinitialisability (that is, that the user can return the system to its initial state), and that all actions are reachable. Similarly, Rosis et al. [19] describe a notation combining Petri nets with Card, Moran and Newell’s KLM theory [2]. They describe a patient consultation system and evaluate correctness and usability. Correctness is evaluated in terms of completeness, access constraints, and nonambiguity. Usability is evaluated in terms of consistency and complexity for both action and display. While the analysis provided by Palanque et al. and Rosis et al. is compelling, it is only with respect to a small number of specific properties. The derived properties are relatively low-level, relating to particular aspects of the functionality of the system and of the Mahemoff and Johnston reuse, efficiency and robustness properties. There has been considerable work at York on formally

Flexibility: For A, there are two correct paths from the initial state of the system to the desired final state, either ftEdit → dbClick or ftEdit → enterKey. Userinterface B allows the Edit and rbClick steps to be interchanged: B is therefore more flexible. However the lack of flexibility in A arises not because of artificial modings in the design, but because of the inherent task structure. It is impossible to perform the task correctly without entering the word for translation before requesting the translation. User-interface B achieves flexibility by splitting the sub-task of selecting translation from French to English or from English to French (modelled by the operations dbClick and ubClick in user-interface A) into two steps: selecting the appro6

specifying interactive systems. This work explores mathematical models of interaction for both analysis and implementation, and falls into two broad areas: abstract system models and interactors. The work on abstract system models [4] aims to provide a broad semantic framework for describing usability principles, focussing on the relationship between system state and representation, expressed as usability principles concerning visibility and predictability. The work on interactors [5] is mainly focussed on developing concrete system models that incorporate user-oriented concerns. For example, the specification of the EuroPARC AV system, presented in [5], is analysed in terms of user properties for privacy, conformance, progress and feedback. The York models of interaction are more abstract than those used in our work and the properties examined are more specific to the particular problem domain and less comprehensive than those analysed in our work. Butterworth et al. [1] explore how user assumptions can be expressed mathematically and integrated with an abstract device model. They use Lamport’s Temporal Logic of Actions (TLA) to explore the knowledge a user requires to achieve a task and how this knowledge is supplied by a display. They provide a World Wide Web browser example and observe that improving user knowledge about the device may yield less error-prone behaviour. The work by Butterworth et al. differs from our work because it focuses on user knowledge and the support the system provides for particular user tasks. The particular property investigated in [1] is concerned with demonstrating Mahemoff and Johnston’s user-computer communication and task efficiency properties for the web browsing task.

portant. A more detailed keystroke level model could be constructed using Object-Z in combination with a suitable keystroke level notation such as User Action Notation [9] (e.g., as in [10]). Future work may be concerned with examining the suitability of such keystroke level models for usability analysis. By analysing models of user-interface designs, the effort required for user-interface development may be reduced. In particular, there may be less need for experimental analysis to determine the usability of the user-interface design. We are addressing the issue of scalability by developing tool support for our approach. We have developed a prototype system to automatically generate a formal user-interface designs from the output of a graphical user-interface builder, and we have done some initial work on tools to analyse such specifications by animation and model-checking. By automatically generating the formal design, the preliminary effort required for formal analysis of usability is diminished. Further, issues of understandability of the specification notation are also resolved because the developer can use direct manipulation techniques to generate the design. Completion of these tools will facilitate a realistic comparison of our approach to traditional usability analysis techniques.

References [1] R. Butterworth, A. Blandford, and D. Duke. Using formal models to explore display-based usability issues. Journal of Visual Languages and Computing, 10(5):455–479, 1999. [2] S. Card, T. P. Moran, and A. Newell. The Psychology of Human-Computer Interaction. Lawrence Erlbaum Associates, 1983.

7. Conclusions

[3] A. Dix, J. Finlay, G. Abowd, and R. Beale. HumanComputer Interaction. Prentice Hall, 1998.

We have analysed the suitability of formal models of user-interface designs for determining usability. We have provided Object-Z models of two small user-interface designs for a language translator and have shown how some aspects of the usability properties described by Mahemoff and Johnston can be interpreted in terms of such a formal model. We have also considered which aspects of the properties cannot be easily determined from the Object-Z models. Object-Z has proved useful for analysing task efficiency, consistency and flexibility (i.e., properties of the task structure), but less useful for modelling and analysing key aspects of the robustness and feedback properties. Object-Z enables examination of the usability of interactive systems at the task level. Some usability features require investigation at the keystroke level (particularly efficiency) and for some tasks (e.g., in the safety critical domain) minor differences in efficiency (in terms of keystrokes) can be im-

[4] A. J. Dix. Formal Methods for Interactive Systems. Academic Press, 1991. [5] D. J. Duke and M. D. Harrison. From Formal Models to Formal Methods. In R. N. Taylor and J. Coutaz, editors, ICSE Workshop on SE-HCI: Joint Research Issues: Sorrento, Italy, LNCS 896, pages 159–173. Springer-Verlag, 1994. [6] D. J. Duke and M. D. Harrison. Mapping User Requirements to Implementations. Software Engineering Journal, 10(1):13–20, January 1995. [7] R. Duke, G. Rose, and G. Smith. Object-Z: A Specification Language Advocated for the Description of Standards. Computer Standards and Interfaces, 17:511–533, 1995. 7

[20] B. Shneidermann. Designing the User Interface: Strategies for Effective Human-Computer Interaction. Addison-Wesley, 1992.

[8] R. Gimnich. Usability Engineering and User Interface Management. In D. A. Duce, M. R. Gomes, F. R. A. Hopgood, and J. R. Lee, editors, User Interface Management and Design: Proceedings of the Workshop on User Interface Management Systems and Environments, pages 113–122. Springer-Verlag, 1990.

[21] B. Sufrin and J. He. Specification, analysis and refinement of interactive processes. In M. Harrison and H. Thimbleby, editors, Formal Methods in Human-Computer Interaction, chapter 6, pages 153– 200. Cambridge University Press, 1990.

[9] H. R. Hartson and P. D. Gray. Temporal aspects of tasks in the user action notation. HCI, 7(1):1–45, 1992. [10] A. Hussey. Formal Object-Oriented User-Interface Design. In D. D. Grant, editor, 2000 Australian Software Engineering Conference, pages 129–138. IEEE Computer Society, 2000. [11] A. Hussey and D. Carrington. Which widgets? Deriving Implementations from Formal User-Interface Specifications. In P. Markopoulos and P. Johnson, editors, DSV-IS ’98, pages 239–257. Springer-Verlag, 1998. [12] A. Hussey, I. MacColl, and D. Carrington. Assessing Usability from Formal User-Interface Designs. Software Verification Research Centre TR00-15, The University of Queensland, May 2000. [13] B. Kirwan, editor. A Guide to Practical Human Reliability Assessment. Taylor and Francis, 1994. [14] B. Laurel. Computers as Theatre. Addison Wesley, 1993. [15] I. MacColl and D. Carrington. Specifying interactive systems in Object-Z and CSP. In Integrated Formal Methods (IFM99), pages 335–352. Springer, 1999. [16] M. J. Mahemoff and L. J. Johnston. Principles for a Usability-Oriented Pattern Language. In P. Calder and B. Thomas, editors, OZCHI’98, pages 132–139. IEEE Computer Society, 1998. [17] S. Nocentini. The mission of the IBM Human Factors Competency Centres. In Proceedings of the SEAS Anniversary Meeting 1987, volume 1, pages 241–247. SHARE Eur. Assoc., 1987. [18] P. Palanque, R. Bastide, and V. Senges. Validating Interactive System Design through the Verification of Formal Task and System Models. In L. J. Bass and C. Unger, editors, Engineering for Human-Computer Interaction, chapter 11, pages 189–212. Chapman and Hall, 1995. [19] F. de Rosis, S. Pizzutilo, and B. de Carolis. Formal description and evaluation of user-adapted interfaces. International Journal of Human Computer Studies, 49(2):95–120, 1998. 8