Campos, J. Creissac

Universidade do Minho: RepositoriUM

Interactors as Boundary Objects∗Jose´ Creissac CamposDepartamento de Informa´tica, Universidade do Minho, Portugaljose.camposdi.uminho.pt1 BackgroundI am a lecturer at the Informatics Department of the University of Minho, having worked for a few yearsas a software engineer developing both custom made and ‘off the shelf’ products. I am integrated in agroup with three main areas of interest: Human-Computer Interaction (HCI), object oriented (OO) softwareengineering (including UML), and computer graphics. My main research interests lay in the intersectionbetween HCI and software engineering. My teaching duties include HCI and OO.I hold a Licenciate degree in Software Engineering from the University of Minho, and a M.Sc. inComputer Science, also from the University of Minho, with a dissertation on the rapid prototyping of userinterfaces from functional specifications.I got my D.Phil. in Computer Science at the University of York, with a thesis on applying automatedreasoning tools to model based usability analysis. This work was developed under the supervision of Prof.Michael Harrison while at the York HCI group, a interdisciplinary group with members coming both fromthe Computer Science and Psychology departments.2 PositionToo often software engineers see the user interface as a last layer that must be placed on top of the functional(or business logic) layer in order (simply?) to enable users access to its functionality. This vision rests onthe assumption that all the application’s logic is at the functional level, and is independent of the userinterface. The user interface then is simply a information transmission layer between the user and the“application” (i.e., the functional layer). Even a software development method such as RUP, which isstrongly based around the notion of Use Case, pays little attention to the design of the user interface. RUPtransforms use cases directly to the architectural design of the functional layer of the application. Suchapproaches compromise the quality of both the users’ interface and of the code, in terms of• poor interaction experience.User interface layers in practice are required to implement control logic. In current applications,control logic of the user interface layer is usually tightly coupled with the logic of the functionallayer. Both layers must be adequately designed so that they can provide a high quality of userinteraction.• poor code.An inadequate design specification leads to a user interface layer that is developed in a more or lessad-hoc fashion. Design and the implementation will require frequent update as problems are foundand improvements requested.In order to address these issues more effectively, better integration of human factors concerns into thesoftware engineering life cycle is needed. This can be achieved by carrying out usability analyses of∗CHI 2004 workshop: Identifying Gaps between HCI, Software Engineering, and Design, and Boundary Objects to Bridge Them.1SystemArtefactIdentifyDesignModelBuildPropertiesVerifyResultsAnalysePrinciplesRequirementsHuman−FactorsHuman−FactorsFigure 1: Integration of verification in developmentsystem designs early in the development process. Usability analysis should not be left to the later stagesof development when changes will be more difficult and expensive to make. Lightweight techniques areneeded that enable reasoning about the usability of systems as early as possible so that design can be shapedby usability criteria and concerns.Discount methods for the analysis of usability have been proposed that are cheaper to apply than moretraditional empirical methods. They have the advantage that they do not require substantial planning, andcan be used in the early stages before the design is implemented but they do tend to require human factorsexpertise. This creates problems when they form part of a process that is carried out by software engineerswho do not have such skills. There is thus a need for an interdisciplinary development process involvingsoftware engineers, human-factors experts and designers.A complicating factor, when it comes to the analysis step, is the sheer size and complexity of themodels that must be considered when developing complex systems. Usually, the above mentioned discountmethods tend to focus on what could be called surface issues in the interaction, with little consideration ofmore complex behavioural issues of the interaction between user and device that will arise in real usageconditions. Techniques and tools are required that enable a more thorough analysis of interactive systems,in an interdisciplinary context. I (with Michael Harrison) have been working towards a method for thedesign of the user interface that involves joint analysis by software engineers and human-factors experts.The approach taken is that depicted in figure 1. Whenever usability issues must be considered, a modelis built that captures salient interactive features of the design. The model is used to capture the intendeddesign, and at this stage different alternatives can be considered. Once a satisfactory model is reached, thedesired usability properties must be expressed and afterwards verified of the model. If the verification failsfurther redesign is needed.In order to enable the analysis of the behaviour of non-trivial systems, models are built from compo-nents using a modelling language with rigorous semantics. Components are described using the notion ofinteractor in the style of [3]: an object-like entity which is capable of rendering (part of) its state into somepresentation medium. The state of each interactor is described by a set of attributes and annotated with therendering relation. The behaviour is described by axioms in Modal Action Logic (MAL). The resultingMAL specification is similar to a production systems’ style specification. This style of specification hasbeen found useful and understandable by psychologists (see [2]).Properties that are to be checked of the system (in much the same style as usability inspection) are writ-ten in Computational Tree Logic (CTL). CTL enables the expression of such properties over the behaviourof the model as: some state can eventually be reached; or some state will inevitably be reached.We have developed a tool that enables the translation of interactive systems models into the SMV modelchecker input language (i2smv) [1]. When the properties do not hold, SMV attempts to provide a counter-2example in the form of a trace leading to a state where the property does not hold. Analysis of the tracewill lead to a new iteration of the process where either the model or the property have been modified.3 Boundary objectsIn the work described it can be said that a number of boundary objects are involved:• the interactor models — they are used to describe the user interface (with particular emphasis on itsbehaviour). Human-factors experts, interaction designers, and software engineers can use them asa basis for discussion about the user interface design. The models capture both the structure of theinterface’s presentation (at a high level of abstraction), and the behaviour of the interface in termsof the effect of user actions on the interactors’ state. Interaction designers can use these models toexpress both what information should be present in the interface (and how it should be presented)and how the interface behaves in response to user input. Usability experts can use the models toidentify potential usability related problems and desirable properties. Software engineers can use themodels as road-maps to the implementation of the systems.• the CTL formulae — the formulae capture desirable user interface properties and test the model.Once properties required to verify the model are identified, software engineers code them in CTL.Defining these properties, and how to encode them in CTL, will promote discussion about the char-acteristics of the user interface, and how they impact on the design. Assumptions about how the userwill interpret specific user interface elements might be an issue at this stage. Such assumptions willhave to be discussed with interaction designers and usability experts.• the SMV traces — these traces represent behaviours where the user interface fails the property underconsideration. They can be used as triggers for scenarios that falsify the property, and can be usedto discuss why the user interface does not hold that specific property (characteristic) and how to bestcorrect the problem. For example, circumstances (narratives) including the sequence defined by thetrace can be constructed by a domain expert. It might happen that some specific behaviour can beconsidered irrelevant (for example, when analysing how an airplane’s autopilot supports the pilot inacquiring a target altitude, we might not want to consider the case where the pilot turns the autopilotoff). In this case, the property will have to be changed to rule out unwanted behaviours and againthese changes will be negotiated between the software engineer and human factors expert. In thiscontext, the property can also be seen as triggering a scenario: the scenario under which the propertywill hold of the system.Together, these boundary objects enable the characterization of (specific features of) an interactivesystem, of its desirable properties, and of scenarios relating to such properties (both where a given propertyholds and where it fails).AcknowledgmentsI wish to thank Michael Harrison for his valuable input on this paper.References[1] Jose´ C. Campos and Michael D. Harrison. Model checking interactor specifications. Automated Soft-ware Engineering, 8(3-4):275–310, August 2001.[2] Martin B. Curry and Andrew F. Monk. Dialogue modelling of graphical user interfaces with a produc-tion system. Behaviour & Information Technology, 14(1):41–55, 1995.[3] David J. Duke and Michael D. Harrison. Abstract interaction objects. Computer Graphics Forum,12(3):25–36, 1993.3

Interactors as boundary objects

http://repositorium.sdum.uminho.pt/bitstream/1822/766/1/CamposCHI04pp.pdf

Interactors as boundary objects

Abstract

Similar works

Full text

Available Versions

Universidade do Minho: RepositoriUM