A Representational Approach to the Specification ... - Semantic Scholar

A Representational Approach to the Specification of Presentations Gavin Doherty and Michael D. Harrison Human Computer Interaction Group University of York

Abstract. The principled design approach improves the quality of user interfaces by ensuring conformance to certain carefully chosen design principles. This involves reasoning about the properties of an interactive system specification. Such specifications usually concentrate on interactive system state and behaviour, and pay little attention to the presentation. We show that arguments about the properties of an interactive system cannot be relied upon without placing requirements on the presentation mapping. We consider in detail these requirements, and the manner in which we can verify their satisfaction. Taking this approach, we can prove that a presentation is valid with respect to a given property, and thus extend our reasoning into the perceptual domain of the presentation.

1 Introduction In recent years, the approach of principled design [DFAB93] has become more widespread in the area of interactive system design. In the principled development process, we improve the quality of the system by ensuring conformance to certain carefully chosen design principles, such as reactivity, predictability and support for the user’s task. This is done through the use of formal specifications, which we analyse with respect to the desired principles. Interactive systems rely on concepts concerned with the presentation, and therefore interactive system specifications must include such concepts. In the interactor model for example, attributes may be tagged as visible to indicate that they are made visible to the user by the presentation mapping. Such tagging is important in relating properties of the system to the user’s behaviour. The problem is that presentations rarely display all data exactly, even in the simplest cases. Real world interfaces contain truncated text fields, approximate representations of numerical data, long lists of items of which only a subset is visible at one time and many other imperfect presentations. Given that such approximation is common, and in many cases desirable, it is important that the approximation preserves the desired properties of the system. For example, if the desired principle is that the system support the user in carrying out a proposed task, then we must ensure that information is presented in such a way that the user can make decisions and gather information as required by the task. We refer to these operations which refer to the presentation as perceptual operations. If the perceptual operations used in performing a task are not taken into account during development, then we can have no confidence in the ability of the system to support the user’s task. Consider other properties such as reactivity - that something is seen to happen when the user invokes an action. Proving this property to be true at an abstract level would involve showing that some subset of the attributes change when the action is invoked. For this to hold true on the presentation we must have the property that a change to this subset results in a visible change in the presentation. Thus our abstract requirements generate presentation requirements. Consider now a property such as predictability - that it is possible for the user to predict the outcome of his next action by using information displayed in the presentation. If the user needs to compare two quantities, it might be assumed that this activity is supported if both quantities are tagged as visible in the specification. However

if the quantities are represented in a graphical display (eg. by bars on a histogram) then rounding will occur unless the quantity is guaranteed to be from a small discrete range, so proportionately small (but perhaps significant) differences between the quantities will not be visible. The result is that the user may not be able to reliably compare the quantities, and thus the interface is not predictable. 1.1 The Development Process To put forward arguments about properties that depend upon the visibility of certain attributes, one must be confident that these attributes are presented in such a way that the properties are preserved (eg. that the user has enough information to carry out the task). This involves input from both the human factors analysis (eg. a task analysis [Dia89] in the case of the task support property) and the behavioural specification. A certain degree of decoupling of specification of presentation requirements and the interactive system specification is still possible, since we are only interested in the presented attributes from the behavioural specification. The human factors analysis provides conjectures about how these attributes are to be used.

Human Factors Analysis

Interactive Principles

Specification Process

Behavioural Specification

Attributes

Detailed

+Invariants

Perceptual Principles

Presentation Spec. Process

Design & Implementation Presentation Specification

Fig. 1. Partial view of the development process

This approach leads us to put forward a new model of development, where a presentation specification is necessary before we can progress from the principled specification to detailed design and implementation (see figure 1). By following the approach of a. generating requirements which interactive system properties place upon the presentation and b. proving a particular presentation meets these requirements, we will have addressed the problem of specifying valid presentations. 1.2 The Interactor Model In this paper, we use the interactor model [DH93] to structure our specifications. The interactor is a concept developed for the specification of interactive systems. Interactors are independent communicating agents (the interactor model is a refinement of the agent model of Abowd [Abo91]), which may participate in events caused by the user, the functional core, or by other interactors. The state of an interactor is made visible to the user by a presentation mapping. An interactive system will typically be specified as a number of cooperating but independent interactors. To summarise, an interactor has three components: – some internal state – a set of operations on this state, which may participate in events – a presentation mapping, which makes some portion of the state perceivable to the user. The model itself is independent of notation; interactor specifications have been written in a wide variety of notations. In this document we use a VDM [Jon86] based notation since it is probably the most widely used of the model based notations, and has a well developed proof theory and theory of refinement.

1.3 Document Overview Our concern in the next section is the modelling of the presentation mapping and the manner in which we place requirements on the presentation - the first component of our presentation development process. We use the notion of logical and perceptual operators as the basis of these requirements. The section following uses an example to explore the means by which we can prove conformance to the requirements considered in the previous section, and proposes a method for doing this. Once this has been done we can have confidence that the presentation preserves the desired properties and the detailed design and development of the interactive system can begin. The final section summarises the work, and sets an agenda for future work.

2 A Model of the Presentation Mapping 2.1 Logical and Perceptual Operators Recent research on graphical presentations has produced a number of interesting and useful results, concerned with the role of external representations in easing the cognitive load on users for certain types of task. Theories of distributed cognition postulate that an important role is played by such artifacts in the cognitive process. These theories and related issues, such as representation, have recently been receiving much attention in HCI [ZN94]. One interesting viewpoint adopted by Casner [Cas91] is to guide the development of graphic presentations by replacing logical operators in the task specification with perceptual operators on a graphic presentation. This determines what representations are valid for a given task. Various heuristic rules are then used to determine which of the valid representations is the most appropriate. Here we are concerned with specification and the validity of a representation, rather than design and appropriateness. Perceptual operators are used as the basis of our treatment of the properties of the presentation entities (which we will refer to as percepts [DH94] 1 ) and hence help us develop requirements involving what is actually perceivable by the user. We restate the problem being addressed for the specific example of task support as follows (see figure 2): the presentation is valid only if the logical operators necessary to perform the task have equivalents composed of perceptual operators in the presentation. The information in the presentation is extracted by the user’s perceptual subsystem, so it is desirable that our model of perceptual operators bears some similarity to the way in which the perceptual subsystem is thought to work. In our examples we shall use a small number of simple concepts closely tied to the visual medium such as determining containment and adjacency, which we assume can be performed by the user. 2.2 Perceptual Operators for Graphical Displays To make the concept of perceptual operator more concrete, we introduce here some perceptual operators for graphical displays, which will be used in our examples. We make no claims that these operators are the most psychologically valid, but this does not affect the validity of the analysis. Our only assumption is that the perceptual operations can be performed by the user. Also, one must remember that different modalities will require a different set of perceptual operators, since from the human perspective the operators define the essential characteristics of the modality. For example, the operators below are spatial since they deal with a graphical display; were we dealing with an auditory interface, then the operators would be primarily temporal [DH94]. Analysis of the operators themselves can be useful; for example, Zhang [Zha96] applies the scale types of Stevens [Ste46] in 1

Note that this differs from the usual use of the word in psychological literature.

Presentation

Abstract Specification

Mapping (ρ)

Principle in terms of Logical Operators

Equivalence

Presentation

Principle in terms of Perceptual Operators

Required

Fig. 2. Required equivalence of logical and perceptual operators

the analysis of relational information displays. The operators below will suffice for the purposes of our examples, where we will use them to formulate perceptual equivalents of the interactive system properties. Equivalence Identifying equivalences such as colour or shading is an important class of operator. Simple equivalences will be implicit in the data of the percept. More complex equivalences may involve some combination of the simple equivalences. For brevity, we will often denote equivalence by “=”, though strictly speaking, the perceptual operator differs with each representation. Comparison Comparing the magnitudes of two objects is likewise very common. Perceptually, magnitude may be defined in a number of ways - the length of a line or bar, the approximate area of a complex shape, comparison of two decimal strings (which we denote by “ text- eld(s:text; ";"; END) 

9

2

!




^

Rather than specify the existence test in terms of the text-field operator, we write it more concisely as:

existence-test1 : TextDesc TextDesc-set existence-test1 (s; sd) 4 i sd i:text = s:text 

:9

2

!

B




It is plain that all operations on the presentation rely heavily on text manipulation operations - extracting fields from the strings, comparing decimal representations of numbers and so on. Analysis of the cost of such operations may yield some insight into the relative merits of the representation. Our concern however is with validity, and the biggest problem in this regard is truncation. Names and version numbers must be truncated, and this information loss may affect the faithfulness of the perceptual operations. If file names differ in characters after the first MaxName characters then they will be indistinguishable. Similarly version numbers longer than the maximum will cause problems. Both pieces of information are used by the version-test operation, and thus we conclude that the presentation is inadequate with respect to this operation and must be altered, or the version test must have a

number of preconditions attached to it, ruling out name clashes and version numbers above the maximum.

Graphical Representation Our second representation is more complex and requires a graphical display. The file type is represented by a single icon; for practical reasons (eg. reusing previously written code), the types are different from the model used by the rest of the system, and icons are of type ASCII text, BINary or DIRectory. If the name is too long to fit in the available space then the first and last k characters, separated by an ellipsis, are printed. Given that related filenames often differ only in the last few characters, this is expected to reduce the number of namespace collisions, which was a problem with the textual representation. The version is not explicitly visible, but files are sorted by date and thus newer versions appear below older ones. The size of a file is represented both textually and graphically. The textual representation is a short decimal string and a letter to denote the unit (Bytes, Kilobytes, Megabytes, etc.). The graphical representation is a horizontal bar, the granularity of which is determined by the largest unit on display. We reuse the definition of HorizBar from the previous example. Part of the specification is given below; since sequencing is important, we define a  function which takes the full set of files to be presented. A mockup of the presentation is given in figure 7.

MyTextFile

257 K

Long...name

135 K

Fig. 7. Mockup of Graphical Presentation

types

IconType = DIR

j

ASCII

j

BIN;

NameString = char inv namstr 4 len namstr < MaxName; SizeUnit = 'B 'K 'M 'G; j

j

j

SizeString = char inv sizestr 4 len sizestr < MaxSize; Icon :: type : IconType name : NameString size : SizeString unit : SizeUnit bar : HorizBar functions

2 -FileSet (fs : File-set) out : Icon pre 8 i; j 2 fs
i:name = j:name ^ i:date = j:date

)

i=j

post let p 2 fs be st 8 q 2 fs
p:size  q:size in len out

= card fs i fs ( ! j inds out out(j) = 2 -File(i; p:size)) v; w inds out; x; y fs out(v) = 2 -File(x; p:size) out(w) = 2 -File(y; p:size) (v < w (x:name