oturn home > Theory of presentation: overview > §3 Context

A theory of presentation and its implications for the design of online technical documentation
©1997 Detlev Fischer, Coventry University, VIDe (Visual and Information Design) centre

3    Context

Presentation happens in the context of a domain with its patterns of activity and protocols. In the domain of service engineering, patterns of activity appear in the differentiation of  groups and individuals which governs the delegation of particular engine problems to particular users; in the daily, weekly and monthly work patterns with its meetings, breaks and periods of peak activity; and in people's seating orders, hierarchies, and patterns of co-operation. Protocols are the various more or less stringent rules and procedures that govern acts of presentation, for example, the protocol of forwarding a telephone call, accessing a database, filing documents, responding to particular problems by asking particular questions, or raising mandatory memos.

An important dimension of context is the validation context which determines the conditions of successful presentation close-out. The validation context may depend on an external referent domain and its scheduled and emergent processes. Or it may be an emergent product of presentation, for example, in dialogical evaluations.

The context depends on, and at the same time produces, the resources on which presentation relies. Resources include the material architecture of sites, buildings, work places, documents and document interfaces, filing systems, and classification schemes. The transformations that produce resources are covered in chapter 5–Articulation, while resources are covered further down in section 3.7 Resources.

Context has different dimensions which may all affect users' presentation. The domain is characterised by the business context. The presentation interest of the domain must be distinguished from users' particular interests. The form of presentation is linked to the scheduled and emergent processes of the referent domain and the level and scope of problems.

The presentation setting surrounding users determines the character of the resource pool as presentation develops, i.e., which people, documents, equipment, or interfaces to any of these may become available and relevant for users. Depending on the pertinence of processes and patterns of activity, presentation settings can be stable or emergent.

Finally, the context determines the weight of presentation through factors such as predicted cost, urgency, likely consequences, novelty of problem or resource, and available validation options.

3.1    Patterns of activity

Repeated involvement in the recurring processes characteristic for a setting and domain result in transparent patterns of activity. These patterns, in turn, shape the course of new presentation. Patterns of activity are not mental models of individual users. They are material and behavioural regularities of the presentation context which guide the activities of ensembles of users along trajectories built up through prior presentation instances.

The substrate of patterns is both external (in the make-up of setting and domain) and internal (in users' minds). The pattern links external and internal substrate in that activities simultaneously produce aspects of the setting and users' experience. Both belong together and mutually remind their counterpart. Patterns can be likened to implicit memories [1]  that guide activities without conscious awareness.

3.1.1    Domain patterns

In well defined domains such as service engineering where problems and engineering solutions evolve over decades, patterns of activity settle into domain patterns. The domain pattern contains known problem patterns and corresponding response patterns that advance presentation along familiar trajectories. Often, the identification of the problem pattern already implies the appropriate solution space. For example, if the pattern indicates a  error, the solution may be to clean or correctly re-assemble equipment. If the pattern indicates a worn or broken part, the solution may be to repair or replace it. If the pattern indicates an equipment design fault, the solution may be to modify the equipment.

Domain-specific problem patterns correspond to specific response patterns. Appropriate troubleshooting questions arise as reported problems resonate on relevant domain patterns. Typical troubleshooting questions make up a repertoire which is largely shared between service engineers. Typical examples are: - How much time had passed after start-up before the trouble appeared? - Was anything done in response? - Had their been similar problems before? - What had been done about it?

3.2    Protocols

Protocols are explicit, often contractual, articulations of domain activities, rules or procedures. Protocols articulate . (‘If this symptom is present, I always ask for X’). For example, the report of a serious engine fault triggers the articulation of an ‘A sheet’, a type of mandatory memo.

The domain contributes protocols in  which are often grounded in domain patterns. Interval and sequential order of the maintenance procedures described in technical manuals are grounded in the domain of engine operation with its observed physical regularities such as tolerances or wear. Parts, for example, have a certain ‘life’ after which they are unsafe and must be replaced. Regulatory protocols such as prescribed intervals for checks simply formalise such known domain patterns. Protocols may even be : a ‘baulkings feature’ in an engine modification can physically prevent the fitting of pre-modification spares, thus enforcing a compliant pattern of activity.

Protocols also preserve the status quo. Within organisations, protocols of organisational hierarchy articulate the power differential between users. This is expressed in generic job definitions, which are sets of protocols independent of the individual inhabiting the job. The quasi-contractual nature of presentation in the field can be traced back, on the one hand, to the work contract between organisation and employee (securing the stability of the setting ), and on the other hand, to the bargaining power and contractual obligations between organisation, customers and suppliers. The bargaining power implies fuzzy protocols that reign the hard protocols of contract enforcement. For example, in the face of a possibly damaging controversy with an important customer, the organisation may exercise ‘goodwill’ rather than execute the protocol.

One can distinguish between situational protocols which define the scope of presentation and power differential of people in a setting, and operational protocols which set out rules and procedures for decisions and actions.

Depending on the stability of the setting, the situational protocol defines or negotiates the scope of presentation. Users may or may not have access to certain documents; access privileges of document systems encode such situational protocols. In emergent settings the situational protocol is negotiated between users. For example, in evaluations, users ask questions such as ‘Am I allowed to ask questions?’

The operational protocol defines or conceptualises particular presentation actions, for example, in navigating documents (‘this sequence of actions takes me to a certain resource’). In the absence of protocols, there is irresolution or arbitrary action. Serendipity, however, will often generate provisional protocols on the fly.

Protocols can extend to scheduled procedures, or build up repertoires to be chosen from. In the first case, an instructor may proceed by discussing all components of a flow system one by one in the order of flow; in the second case, an engineer confronted with a set of engine fault symptoms may pick the most relevant out of a fairly consistent repertoire of troubleshooting questions.

The boundary between patterns of activity and protocols is fluid: patterns can be articulated as protocols (although not without loss), and learned protocols can ‘sink in’ to become transparent patterns guiding behaviour.

Where patterns are weak as in learning contexts, skills are acquired as explicit protocols such as the steps required for transferring a telephone call or accessing a database. Over time, such skills become transparent patterns. Routine blends technically separate steps of the protocol so that they are no longer seen as conceptually separate. For example, in describing the protocol of an activity such as a telephone call, one can differentiate discrete actions such of taking off the handset, moving it to the ear, registering the ‘free’ tone and pressing ‘9’ for an external line. As the pattern sets in, these steps are lumped together as one transparent activity which the user is likely to describe as ‘trying to get in touch with X’ rather than ‘operating the phone’.

3.3    Validation context

The validation context consists of more or less precise measurements in order to establish if resources solve a current or anticipated problem.  In the field they are formulated as protocols that check the validity and  of resources against strict protocols such as specifications or document type definitions. In the evaluation context, the validation context may involve standardised  tests that compare given answers with ideal answers [2]; or it may be emergent and involve ‘understandings’ and negotiations between users and evaluator. Reliable validation contexts are vital for  systems. A failing video recorder is just annoying; a failing flight deck indication system can be disastrous. The precision of validation contexts ranges between transparent assumptions that a problem is now ‘done with’ and formal validation protocols.

Precise validation and quality control is by definition system-immanent and cannot acknowledge contextual factors. It cannot reveal problems that are not already expressed in its validation protocol. SGML parsers can validate the structure and links in a document system, but they cannot account for variance in contexts of use. For example, manuals complying to the AMTOSS [3]  standard for task description show an excessive  into sub-tasks stored in only one location to avoid duplication. In a computer-based context of use, these sub-tasks can be accessed immediately through transparent links. However, in a context of use where AMTOSS manuals are stored in print or microfilm form, this  forces a laborious one-by-one search and compilation of all sub-tasks needed—an effort which may be bypassed if time is scarce (cf. subsection 7.2.1 Domain pacing in chapter 7–Confluence).

The validation context in evaluations is very different from that in the field. In evaluations, the user implicitly validates resources as they seem to saturate a problem dimension and thereby advance presentation. For example, users in the cinegram evaluation never questioned the  the objects they found described in the questions and then discovered in the document system; the mere fact that the same objects were referred to in both question catalogue and document system seemed to create a closed validation context lending sufficient factuality to the objects [4] (cf. appendix V–Evaluation).

In the field, the validation context reaches beyond situated selections and constraints of presentation, whether of ‘communication’ or individual consciousness. Presentation is valid only , depending on repercussions down the line. I may overhear or fail to realise the import of a remark in a meeting so that it escapes my understanding at that time, but my ignorance does not make the referent of the remark disappear. In time, it may surface in some form of breakdown of understanding or process. A customer may be happy with some given advice, but return if decisions and actions made on the basis of the advice do not work. An implemented equipment modification may create another set of problems in service so that operators may request a return to the pre-modification standard. An argument for the safety of a design may be won, but events down the line can discredit the design forever[5].

The wider validation context of resources must include the situation of use and the degree of emergent fit between users' needs and characteristics of used resources. The success or failure of this fit reveals much about the particular conditions of use, which can in turn inform document system design. However, the particularity of the context of use implies that it is difficult to generalise and apply results to qualitatively different contexts. The general lesson for evaluation design is to choose or create validation contexts that resemble as much as possible the anticipated context of use [6].  The caveat of all formative evaluation is that the future context of use in all its complexity is not available. A pilot does not scale up to the full system implementation [7].

3.4    The domain

The organisation's business context specifies different domain contexts which trigger and constrain presentation. Each domain has its particular resources, interests, scheduled or emergent processes, and problems. The domain's objects, patterns and processes are products of its history, not facts or indicators of ‘given’ objective domain properties [8].  Processes in a domain such as engineering constantly produce new domain features which potentially undermine reference validity. Users must always reckon with change: weekly modifications to a new engine type are common as it approaches service. Users know and adapt to this latency of context. Over time, they learn to make ad-hoc corrections and predict developments which might impinge on presentation.

3.4.1    Business context

The organisation's business context specifies the processes for which resources are used. When the organisation is an airline, equipment (such as turbo-fan engines) is the root resource for the core business process, which is selling transport [9], while equipment documentation is a derivative resource to keep technicians skilled and the equipment serviceable. When the organisation is an academic institution, lecturers, rooms, text books and software are root resources for the core business process, selling education, while staff training, room maintenance, photocopiers and computing services are derivative resources to keep lecturers skilled and equipment serviceable.

Generally, the goal of the business context is gaining competitive advantage through maximising operational efficiency (and thereby, profits) and minimising breakdown. Profit maximisation however leads to contradictions within organisations, since there are other conflicting goals [10].  In the case of airlines, for example, there is a permanent conflict between punctuality and equipment safety [11]. In the case of universities, there is a permanent conflict between maximising research reputation and maximising the quality of teaching, rooted in different mechanisms for generating revenues. Another conflict exists between the concept of individual performance with all the inter-student competition and mistrust entailed, and the goal of instilling the co-operative, interpersonal and managerial skills that future employers require.

Although the business context is not subject of this study, it is important to realise the pervading influence of the choice of business model on all other levels of context and indirectly, on presentation. In the aircraft industry, manufacturers are about to change their business model from selling equipment to selling services, for example, ‘power by the hour’[12]. The product to be sold is no longer the engine, but its operation and servicing so that the provider carries the risks of equipment failure. As a consequence, operational costs become more predictable for the airlines. A consequence for the manufacturer which impacts on presentation is that the usability of documentation can no longer be seen as an extraneous factor since it directly affects profitability [13].

The business context in which the use of resources must be seen is itself subject to changes on many levels. These changes are driven mainly by factors directly or indirectly related to market forces. They include changes to production methods aimed at the shortening of the ; the concentration of production to fewer sites; tightening of the supply chain and outsourcing; risk- and profit sharing between the organisation and its suppliers; and increased use of technology like work flow software to guide the production, distribution, and maintenance processes. They also motivate the move to on-line documentation. These changes affect many aspects of the work context, for example, composition and location of groups, job definitions, and hierarchies [14].

3.4.2    Presentation interest

The presentation interest is a composite of the domain interest which is in turn grounded in the business context, and users' particular interests. This becomes clear when the service engineering context is compared to the evaluation context.

The domain interest of service engineering is the compliant support of the customer's business in order to minimise costs and liabilities. This domain interest is grounded in the organisation's contractual relationships and informal commitments based on estimations of future business opportunities. It is directed both at the mechanical failure to be fixed and resulting operational consequences to be managed. The quickness of a solution which restores customers' scheduled operation is often more important than its adequacy or permanence—an aspect shown in the importance of ‘intermediate fixes’.

Users' presentation interests in service engineering are diverse and may compete with the domain interest. For example, they may be interested in getting through the day without too much hassle; in the satisfaction of helping others; in the reputation of being good at their job; in learning about the domain in order to improve career prospects or secure employment; or in choosing the most pleasurable mode of presentation within situated limits (cf. section 6.7 Navigation pleasure in chapter 6–Navigation).

The domain interest of the evaluation context is the successful completion of the set evaluation procedure. It is grounded in the designer's interest in assessing the workability of the design and in revealing usability problems. If designer and evaluator are the same person the domain interest is ambiguous. While breakdowns are welcome and valuable since they indicate design flaws, they are at the same time unpleasant since they may prove design decisions wrong and investments in implementation wasted but for the fact that they revealed that something didn't work.

Users' presentation interest in evaluations is graceful compliance to the evaluation protocol in order to minimise mutual unease and the embarrassment caused by breakdowns. As users become more at ease with the situational protocol, other emergent interests appear, such as demonstrating competence or satisfying curiosity about the document system or the referent domain. Users typically begin to ask questions or talk about their world near the end of the evaluation when the duty is done, protocols have become familiar and social cost predictable.

3.4.3    Scheduled and emergent processes

Each presentation context is the result of the interaction of scheduled and emergent processes occurring in the domain. Emergent processes typically result from the breakdown of scheduled processes.

Scheduled processes are sequentially ordered activities of any length. The type and order of tasks or topics is largely specified in advance. Examples are flight schedules, scheduled line maintenance, and curricula for classroom-based training. By contrast, other contexts are characterised by emergent processes that are triggered through the exceptional breakdown of scheduled processes. Troubleshooting, for example, is necessary when an engine breakdown causes disruption of a flight schedule.

Scheduled processes motivate the design of schedules in documents. Examples of schedules are maintenance procedures in technical manuals, job cards, or CAL courseware which describe engine checks or the removal and installation of components.

Schedules can be encoded in documents which then order and possibly pace a series of displays, such as pages or screens. The substrate of encoding may be a courseware script or the time code of a video. Encoding may also reside in a teaching curriculum or the order of a stack of OHPs, to be mediated and qualified by a human presenter. The schedule constrains a part of the resource. It navigates to the next slide, OHP, screen, or video frame, and articulates the problem through voice-over and cueing.

Users contextualise presented schedules through emergent response presentation. This implies that topics in schedules cannot completely determine the problem, even if the display is driven by an encoded pace. In their response presentation, users' aggregate the problem from the paced display and other activated resources (such as rememberings, noticed responses in the audience, inconsistencies between resources, and so on). The timed code cannot determine which part of the overall resource is relevant to users at any given time. Mechanics react to contingencies of equipment by diverting from the prescriptions in schedules. Learners in classroom settings often follow their own train of thought at the expense of keeping up with the pace of the schedule.

Scheduled processes (and related response presentation) occur in nested contexts. In the domain of aircraft operation, for example, levels of context are business context, operational context, and mechanical context. At the top level, the business context requires serviceable aircraft, staff, etc. for the maintenance of the airline's flight schedule. The operational context requires an engine management schedule embodied in documents or work flow software which triggers different types of operational and maintenance checks [15]. At the bottom level, the mechanical context requires a task schedule, for example, a job card which triggers steps of the mechanical maintenance activity.

Emergent processes usually result from breakdown of scheduled processes. On the business level the emergent process may be the re-negotiation of salaries when strikes threaten the business process; on the operational level it may be the re-scheduling of maintenance actions or swapping of aircraft deliveries to service; on the mechanical level it may be the repair or replacement of parts when the engine has failed.

One can further differentiate emergent processes according to whether or not established response patterns exist. Response patterns may guide switching from autopilot to manual operation responding to abnormal autopilot behaviour, or instigating fault-finding checks responding to unusual equipment behaviour. No such s exist for unforeseen problems (e.g., having to monitor  deterioration inside the engine when there are no access ports like those for borescope inspections of turbine blades).

Whether the context is dominated by scheduled or emergent processes affects many aspects of users' presentation, for example, its causes, selection of participants, and logic.

In a predominantly scheduled process such as classroom-based training and evaluation sessions based on question catalogues, the schedule causes presentation, both on the situational level—the scheduling of the session—and on the operational level of scheduled steps. In predominantly emergent processes such as troubleshooting, the cause driving presentation emerges from problem aggregation and feedback from the referent domain.

The difference is also expressed in the selection of participants. In emergent presentation, the selection of appropriate participants emerges from situated needs, while scheduled contexts such as maintenance training courses or evaluations select users by virtue of a preconceived plan.

Schedules and emergent presentation also differ in the type of logic which specifies order, coverage, coherence, pacing, and close-out. Schedules are based on one predetermined logic according to the predicted needs of users. The logic specifies the schedule's order and coverage and guarantees its coherence. It may be based on the physical order of components in a system, the temporal order of a sequence of events (‘before inserting the borescope one must remove the borescope plugs’), or the conceptual order from overview to detail, from location to function, or from normal state to exceptional states. Its coverage is usually wide and even and its pacing pre-determined: each topic is timed so that close-out is forced by the completion of the schedule within the allotted time.

The logic of the schedule limits the possibility of accommodating problems that may emerge from users' response presentation. Users choose to follow or gloss over the topics of the schedule depending on the strength of their belief that they might be useful in the future.

In contrast, the logic of emergent presentation appears only in retrospect. Its coherence rests in situated relevance, i.e., in users' ability to make sense of the current problem. The order of presentation is generated ad hoc. The mode of progression is that of jumping, although to guesses rather than to conclusions. Jumps are often intuitive, i.e., they are based on patterns not formalised as explicit protocols. Coverage is specific and uneven, coherence situated, and pacing is dominated by the degree of urgency, unexpected interruptions, and the demands of other concurrent presentations. Close-out depends on fixing the problem in compliance with the appropriate validation context.

The logic of emergent presentation can change at any time with unexpected events or sudden turns of the problem that render the past of presentation irrelevant but for the fact that it led to the current view.

Schedules and emergent presentation can trigger each other. A breakdown of understanding in a training course may cause an emergent question by a trainee and consequent communicative repair before the schedule is resumed. In dealing with a particular emergent problem, a service engineer may work through a schedule such as print-out of all similar problems of other engines of the same type, or a chain of components in a systems diagram.

A particular mix of emergent and scheduled aspects is embodied in algorithmic schedules, i.e., encoded schedules controlled by conditional protocols which attempt to formalise an emergent process as a finite problem space. An example is the type of decision tree diagram for fault isolation used in the maintenance manual. The algorithm formalises the mechanical-operational level. For each common fault indicator, the fault isolation tree instructs checking procedures with branches chosen according to yes/no questions such as ‘Is oil quantity level normal?’. However, the finite problem space cannot cover all contextual and situational contingencies of real engine problems. Also, the scheduled order of fault elimination does not correspond to a realistic  which usually starts with the ‘most likely’ fault (or type of fault) and suggests an elimination process starting with the most salient symptoms irrespective of their position within the fault isolation tree. The service context acknowledges the dominance of the ‘most likely’ approach in the production of ‘informal’ documents such as the RB211 ‘rapid fix’ troubleshooting guide, which sacrifices logical elaboration for a flat and parsimonious architecture based on problem frequencies observed in the field.

3.4.4    Level and scope of problems

The presentation context produces problems on substantive or operational levels that vary in scope, ranging from specific to generic. In the evaluation context, a user has to deal with two levels of problem: the substantive problem introduced through the scheduled question, and the operational problem introduced through the novel document system. The substantive problem may be specific (‘Can the scavenge filter element be re-used?’) or generic (‘Why are there filters in the oil system?’). The operational problem may equally be specific (i.e., not knowing how to get back to the overview) or generic (i.e., not knowing that clicking at objects affords navigation).

In the service engineering context, substantive problems are specific to this engine or generic problems of the engine. Operational problems exist for new employees, or when users use new resource types. The scope of the substantive problem is reflected in the filing of emerging resources, such as reports, messages, or data logs. This-engine problems are grouped in a specific engine event file tagged with the individual engine number, while the-engine problems are filed in the generic subject filing system under the ATA reference. Presentation dealing with the specific might indicate relevance for the generic and vice versa, which on the level of resource is expressed in the re-filing of documents.

3.5    Users and settings

The setting is the physical context of presentation: the place surrounding users when they use resources. It is made up by the physical distribution of users, material resources, and resource interfaces. Mediated through such interfaces such as on-line links or the telephone, the setting may include remote sites. The distribution of resources in settings affects resource availability. In office settings, for example, the location and grouping of users defines if presentation may be shared through overhearing which affords intervention or peripheral learning. The setting of the Oil system group in the Service engineering section of the Customer Support Department at Rolls Royce Commercial Aero Engines plc. in Derby is shown in figure 3.1.

Fig. 3-1 showing a floorplan of the Service Engineering department at Rolls Royce.

Figure 3.1. Floor plan showing the layout of the oil system group and the location of some of the key resources.

Users' domain knowledge, motivation, and intentions are an indirect result of the setting and its processes in that settings largely determine the scope of experience and competence of users and thereby the degree to which they may manage and possibly change the context. Knowledge reaches beyond the current job; education and other jobs in other organisations contribute to users' experience.

3.5.1    Stable and emergent settings

The setting can be stable or emergent, i.e., itself generated through the current presentation. An example of a relatively stable setting are the groups that evolve within departments of organisations. Emergent settings are generated, for example, in user evaluations. The degree of stability of the setting has an impact on the type of protocols and procedures and the way users aggregate and saturate presentation problems.

Stable settings evolve over time through the repetition of processes and the ensuing shared patterns of activity and protocols. They should not be confused with stable domain patterns. A re-organisation of the service engineering department, for example, will thoroughly change settings, but domain patterns will remain largely unchanged [16].

Stable settings show a high recurrence of similar processes. Job definitions and users' accumulated habits define the scope of activity and afford mutual expectations. Engineers can tie novel problems to already familiar problems by drawing on the established and largely shared repertoire of protocols, such as questions or test procedures. Familiarity is not just a subjective-psychological attribute; it implies that the substrate of familiarity is shared by a group—a ‘family’—of users.

Emergent settings are generated in unfamiliar situations such as evaluations, where users try out a novel document system. In emergent settings, participants interactively define protocols for activity on the situational and operational level (cf. appendix V-Evaluation).

On the situational level, participants articulate protocols which negotiate the power differential of the setting and establish a provisional scope of permitted activities. The negotiation of situational protocols outlines the basic structure of the setting through questions such as ‘How are we going to handle this?’ or ‘What do you want me to do?’ Often the domain will allocate a dominant role to one participant. For example, the dominant position of the evaluator is implied in the evaluation protocol. (Exceptions are evaluations or reviews with peers who are used to constructive mutual critique.) The session is planned by the evaluator, who prescribes, at least initially, what will happen in the session by providing verbal or printed instructions. By the same token, users expect to be told what to do. Their act of volunteering implies a quasi-contractual submission which they only accept because of the pre-defined temporal tolerances of the setting: it will expire after two hours (cf. section 7.2 Temporal tolerances in chapter 7–Confluence).

On the operational level, participants articulate protocols for carrying out activities. This involves questions such as ‘Who takes the minutes?’ or, in dialogical evaluation settings, ‘Can I ask questions?’ Within the initially defined situational and operational boundaries of activity, participants may define sub-protocols. They may split and swap tasks such as taking minutes or navigating documents. Carrying out activities soon develops patterns that spark off the articulation of methods. For example, in evaluations, one user may have noticed that a pop-up menu allows a short-cut for navigation and informs the other user. Articulation of methods may involve the evaluator when users experience breakdown [17].

Evaluation settings are action systems [18] which are tuned by the emergent actions (and omissions) of all participants. This makes it difficult to change the system intentionally. The evaluator who wants to counter the prescriptive nature of evaluation settings and engender the build-up of a situation of relative user autonomy must allow enough time for the re-tuning of the prescriptive setting towards a dialogical and co-operative setting. This goal can only be reached as a by-product, not directly through personal intent. The attempt to avoid direct instructions may simply lead to a situation where the evaluator's speech act types users' responses. For example, hypothetical questions which evaluators ask to spark off user actions may only spark off a ‘use dream’. Instead of triggering an action, a question such as ‘What would you do to find out?’ is likely to generate a response in the same mode, such as ‘I would try clicking these buttons’ (rather than trigger a performance of the described action).

The asymmetries the evaluation setting deserve some additional remarks. The evaluator's methodological choices determine to what degree the initial prescriptive context may be relaxed. The chosen methodology affords or precludes the emergence of situational and operational protocols in the course of the session. The choice implies a decision between measurability on the one hand, and emergence (and observability of emergence) of context and user autonomy on the other hand. In the natural sciences, the difference between observer and observed behaviour limits feedback so that measuring has no impact on the nature and observability of emergent behaviour [19].  However, in other fields such the one historically known as HCI research, observation and observed behaviour are intricately tied together. Attempts to bracket out the effects of observation are paid for with a restriction of scope and subtlety. They show the limited applicability of controlled experiments for the understanding of the dynamics of real situations of use.

For measurements of user behaviour or evaluation ‘outcomes’, the emergence of context  is detrimental because it undermines the very conditions which make quantitative comparison possible. On the other hand, the observability of emergent learning depends on the realisation of a high degree of user autonomy. Some dramatic learning  flip-overs would never occur under prescriptive conditions where evaluation protocols tie user behaviour to a controlled schedule to safeguard comparison across sessions.

3.6    Presentation weight

The weight of presentation corresponds to estimated costs, urgency, predictability of consequences, novelty and validation options (cf. figure 3.2).

The hypothesis is that users always aim to reduce the weight of presentation; for example, if the context requires urgent and consequential presentation users will avoid novel resources and try to validate resources through communication and comparison. Communicative validation requires resource types with a high degree of feedback, e.g., the telephone rather than written messages, while comparison requires the availability of several confluent resources.

[A diagram showing the effect of cost, urgency, consequence, novelty, and validation options on presentation weight]

Figure 3.2. An overview of the main dimensions contributing to presentation weight.

3.6.1    Cost

Much of the weight of presentation can be traced back to anticipated costs. I do not attempt to discuss information economy [20] issues in any detail, I merely sketch a rough taxonomy of the types of cost that affect users' presentation. I suggest three different types of domain costs: resource costs, delay costs, and repair costs.

Resource costs are costs incurred through the production or acquisition of resources, for example, the production of technical manuals, acquisition of work stations and consumables, or charges such an accumulating telephone bill or a flat monthly subscription charge for on-line services. Resource costs have a temporal dimension: acquisition cost must be seen in relation to the ‘life’ of the resource (the span of time until machines, documents, etc. become unusable through wear or irrelevance), and in relation to maintenance costs, which include both scheduled (budgeted) and emergent costs, e.g., costs of revisions and modifications.

Delay costs increase the longer it takes for presentation to solve a problem. Delay cost for an organisation such as Rolls Royce are internal and external. Internal delay cost can be expressed as time and effort expended for presentation. Effort is not simply a subjective category [21]:  it can be expressed as the product of the amount of time required and the number of people involved in presentation, and has knock-on effects such as the impact of stress and disruption on concurrent activities, or illness and absence from work. Internal delay cost includes aspects such as delays incurred through loss or misplacement of resources. External delay costs accumulate through liabilities such as compensation payments to operators, costs of equipment replacement, or hotel bills of delayed passengers.

Repair costs are incurred through erroneous decisions made as a consequence of presentation, and costs of knock-on effects. Repair costs are contingent on the strength of commitments of presentation (embodied in contractual obligations and liabilities, or the scope and permanence of visibility of the error calling for repair) and severity and permanence of presentation  which hinges on resource types and the type of reference relationship. Social repair cost, such as embarrassment, is linked to visibility. For example, noticing and concurrent articulation in dialogical evaluations incur low social repair cost since errors are transient and easily corrected (or overlaid and forgotten).

At times the suggested types of cost are convertible, at other times they involve qualitative changes which are irreversible. Delay cost may be reduced by increasing resource cost (i.e., by ‘throwing money at a problem’), or they may accumulate to a point where they trigger repair costs, such as the loss of an important customer and consequent knock-on effects such as a loss of ‘brand equity’ [22].

Costing of resources is strategic in that it depends on estimates of volume and direction of  and future technological, economic, and political changes with unpredictable interactions and knock-on effects. Economies of scale affect resource costing. For example, production costs of a master CD may be higher than those for a print master, but unit and distribution costs for CDs are much lower, so that from a certain number of units upward CDs are cheaper to produce. The  changes again for on-line technical documentation where customers access manuals remotely against some charging mechanism. Here, resource costs are composed and spread differently and must be traded off against possible repair costs, e.g., breaches of security or down-times, and delay costs, e.g., speed and reliability of access. Technological and design innovation quickly changes such costing models: improved resource integration, for example, reduces delay costs (e.g., reduces the need for navigation to separate temporary revisions [23]), and repair costs (e.g., afford cheaper and more reliable mechanisms for updating).

Costing models are not realistic if they only include costs that can be priced. Important but elusive  hinge on contextual aspects such as  use (saving or increasing navigation time),  with other resources (deciding over resource uptake or failure), or use of alternative resources and support systems (increasing communication and support cost). Usability criteria are more likely to contribute to design decisions if designers can point out such hidden costs.

There are as many possible referents of costs and benefits as there are competing goals within an organisation [24].  Costs and benefits for the organisation and the individual user interact in complex ways. A presentation that increases costs for the organisation may simultaneously increase benefits for employees such as generating competence and satisfaction. Examples are articulations like engineers' chats with colleagues, or navigations like excursions to the shop floor in order to look, once in a while, at real equipment rather than documentation. A narrow calculation may consider both chatting and shop floor visits as delay costs; however, a more comprehensive calculation will acknowledge benefits for the organisation through increased competence of the individual and better co-ordination of activities across departmental boundaries, which may in turn result in faster and better (more valid) decisions and consequently, lower delay and repair costs.

3.6.2    Response pressure

Response pressure increases presentation weight, particularly if the referent domain sets deadlines with penalty clauses. Evaluations never cause the same degree of response pressure since qua evaluation protocol they have no costly or negative consequences for the user or a referent domain. Response pressure limits the availability of resources. Delay cost does not accumulate in a linear fashion; delaying an aircraft beyond a certain hour may imply putting up passengers in a hotel since the destination airport would be closed at the time of arrival [25].

Response pressure is also related to the power differential within and between people and organisations. Its force can be seen in the fact that it creates presentation artefacts.

In evaluations, presentation artefacts are a consequence of the response pressure caused by the power differential between user and evaluator and the immediacy of face-to-face dialogue. Users feel they must offer some answer even if they don't know one. So they produce answers that do not match the initial trigger question but impute a different question which has only come about through the presentation process (cf. problem drift in subsection 4.7.1 Problem changes across settings in chapter 4–Problem). The longer users continue to elaborate such artefacts, the higher the social cost of admitting breakdown. Response pressure prevents careful consideration and serendipitous exploration of the document. It applies notwithstanding any permissive declarations by the evaluator, and is only relieved over time, when users experience that the evaluator seriously welcomes the  breakdowns as instructive for design.

In the field, response pressure reflects the bargaining power differential between organisations. Response pressure can force presentation close-out without saturation which leads to presentation artefacts. Engineers frequently reported the case of ‘wanting to be seen to be doing something about a problem’. For example, under pressure from a customer, the organisation may start preparing a modification before there is a clear case for it, simply to prove goodwill. Or it may issue superficial changes to the wording of a maintenance procedure as a symbolic action to ‘share the blame’ for a customer's maintenance error without admitting liability.

3.6.3    Consequence

Presentation weight also depends on known or probable consequences for the referent domain. For example, a message may have weight when it betrays secret intentions or might cause arguments with a customer (e.g., a request to move an faulty engine to Derby for investigations). Consequence is related to the materiality of the resource: it is stronger in material resources than in transient articulations. Letters cannot be taken back, or adapted and qualified, as easily as spoken words.

3.6.4    Novelty

Novelty of resource, setting, or substantive problem increases presentation weight. This is apparent in the hesitance of evaluation users before they start using the cinegram. In evaluations with service engineers, those who knew the referent system were more at ease than those for whom it was unfamiliar. The designer's acquaintances were more at ease than strangers since the setting and situational protocol was already familiar. Witnessing in evaluations adds to novelty and increases presentation weight. Quiet witnessing is weightier than dialogical witnessing since the latter allows the definition of situational and operational protocols which reduce novelty. For example, the weight of witnessing on presentation was apparent when the evaluator had to leave the room for a couple of minutes in the middle of a session. Unwitnessed, the user suddenly had a leap of confidence and began to explore the cinegram prototype.

3.6.5    Validation options

The validation of resources decreases presentation weight. Comparative validation requires the confluence of several documents, while communicative validation is afforded through the confluence of users' articulation in conversation. Comparative validation takes place, for example, when human reporting and reporting by the electronic system back up the same interpretation. Communicative validation takes place when users agree on decisions and a course of action in conversation. In the cinegram evaluations, pairs of users were less likely to be paralysed than individual users, because they could articulate and discuss decisions. Single users tried to validate resources by involving the evaluator. In the workplace where individual decisions directly affect external settings, communicative validation accounts for an intermittent pattern where engineers advise customers on the phone, and afterwards talk to colleagues about the case to validate the analysis and the given advice. In important presentation communicative validation becomes part of the protocol: at Rolls Royce, weighty decisions are taken in face-to-face meetings involving senior members of several departments, such as engineering scheme review meetings or modification policy meetings.

3.7    Resources

An important part of the presentation context are resources. A resource is anything that may become available for display in presentation [26].  Two fundamental classes of resource can be distinguished: material resources that are already given in the setting and are navigated by users, and occasioned and emergent resources that are articulated, for example, in talking, gesturing, writing or drawing. When articulated in a permanent form, occasioned resources become material resources of varying degrees of permanence, to be piled, filed, passed on, or thrown away. Articulated resources will be the subject of chapter 5–Articulation. Here, I discuss the material resource pool that forms a part of users presentation context.

From the most ephemeral, a post-it with a scribbled reminder, to the most durable, the engine and its generic documentation, material resources encapsulate intentions for use in their target setting (cf. appendix II–ATA-certified documents, and appendix III–Engineering Technical Graphics). Each domain has its peculiar resource pool for presentation, including a vast variety of documents and document systems [27].

Material resources store articulations for reference at a later time. They vary in permanence. The least permanent are situated measurements triggering transient messages on computer screens, or telephone numbers jotted down in the margins of a document which may later be transferred to more permanent resources such as address books or databases. Semi-permanent resources are notes or memos which are filed to be re-filed or thrown away at a later time, e.g., at the end of the month. At Rolls Royce, the most permanent resources are formal documents such as engineering reports or schematic drawings, which are allocated a unique number, kept in duplicates in two different libraries and recorded in the STAIRS mainframe system.

3.7.1    Resource provision

On the level of the organisation and department, strategic decisions are made about resource provision and level of service, either by buying in resources or in-house production.

Resource provision can be re-negotiated on different levels. On the level of users, users design new resources when the provided resources are inappropriate or non-existent (cf. section 8.1 Requirements in chapter 8–Design). On the level of department, managers provide local resources such as stand-alone PCs carrying Excel database software to alleviate users' difficulties with mainframe applications. On the level of organisation, management endorses new information models and strategies, as Rolls Royce did when it decided to contract out its information technology to EDS [28].

3.7.2    Resource material & meaning

Resources can be discussed from two different perspectives, that of material and meaning.

The material perspective of resources means that it consists of physical units at different levels of granularity. Units may be entries on a page, pages in a document, documents in a file, or files in a drawer. In computer systems, they may be different addressable servers or different addressable Web pages, or different search submissions. In articulated resources, a similar classification would be words in utterances, utterances in conversations, and conversations in memories (or collections of minutes). Units are generated through some procedure with a certain amount of complexity. In the case of this symbol: valve symbol , this procedure consists in inserting a graphic element into a word processing file.

The meaning perspective of resources means that in users' presentation, units become meaningful tokens on different levels of abstraction. A graphical symbol such as open valve symbol in a technical flow diagram is both a technical unit at a certain level of granularity of the material resource, and a potentially meaningful token at a certain level of aggregation in users' presentation (the concept of token is covered in more detail in section 4.3 Tokens and granularity in chapter 4–Problem).

3.7.3    Content, volume, granularity, architecture

The materiality of resources forces a mediation of document content, volume, granularity and architecture.

The document's volume may exceed the capacity of a container type on a certain level of granularity so that it must be segmented and spread over more container instances. The relation volume-container is repeated on many levels of abstraction, e.g., in the relation between the number of lever arch files and shelf capacity, between the number of pages and the capacity of folders or files, between text length (or picture size) and page capacity, or between the length of an e-mail message and the byte ceiling of the transfer protocol.

Document volume interacts with content in the conceptual allocation of segments which attempts to make material boundaries coincide with content classification boundaries. Container types also imply a material architecture which is often reflected in the protocols of resource articulation. Documents filed in the type of manila folder used for engine event files, for example, are stacked up, the material architecture therefore reflects the temporal order of filing. Such architecture may support or hinder users' presentation. For example, the stack architecture keeps related messages, memos, etc. in some spatial proximity, but is not helpful for the retrieval and presentation of a singular detail in a document which might be months or even years old. Manila folders also do not stay open at the chosen page—they must be held open and therefore impede navigation and confluence, particularly if the engineer's other hand is already tied up with holding the phone.

3.7.4    Effects of change in the referent domain

Equipment, although material, is not a constant point of reference. It is subject to design changes, so-called modifications, brought about by emergent trouble and consequent presentation. Such modifications equally affect the body of equipment documentation.

Equipment modifications occur both between and within engine developments. I will not discuss the complexity of modifications to equipment. Instead I take such changes for granted and focus on the consequences for documentation.

A problem for the documentation design process is to provide timely documentation in the face of frequent changes. Near the commissioning of a new engine, there will be ‘teething troubles’ calling for many changes to equipment or related procedures (checks, adjustments, etc.). The pace of such change cannot be matched by current documentation procedures (which are slowed down by validation protocols); therefore, important changes are issued to airlines as temporary revisions, which means that a tertiary resource needs to be checked in order to make sure that the secondary resource, the manual, is still up-to-date.

Over time, the evolution of the–engine leads to diverse modification standards (for short: mod standards) both on the level of the–engine (as it is customised for different airlines) and on the level of this–engine, requiring different manual variants for different airlines, and different versions within manuals covering different mod standards, since engines often remain in pre-mod configuration until the next overhaul stop. In printed manuals, the need for coverage of different mod standards causes bulk and noise. Their unwanted confluence complicates navigation. Differences between mod standards are sometimes as subtle as a tiny additional hole in a relief valve, where the variant design is recorded on the same illustration.

3.7.5    Validity of reference

The temporal and produced nature of context implies that the validity of reference is hypothetical. Both resource pointer and target may fail. Firstly, the target resource may lack quality, i.e., it may fail to refer to or render visible the relevant dimensions of the referent. For example, Rolls Royce service representatives reported cases where oil pipes were one foot away from the location indicated in the Illustrated Parts Catalogue. Secondly, the target may lack veracity, for example, the target document may show an outdated part. Thirdly, the pointer may lack integrity, i.e., fail to produce the target; users following a fault isolation tree or on-line link may discover that a pointer is invalid [29].

The context, its patterns and protocols, define how users deal with the substantive problems that the setting processes. The emergent troubles that occur in the referent domain trigger presentations that turn these troubles into problems to be understood and eventually solved. The next chapter will address the problem, its relation to the context and its aggregation towards close-out.


Footnotes to chapter 3Context

[1] Cf. the idealist rendering of Polanyi (1985/1966) who coined the term implicit memory.

[2] Cf. von Foerster's (1984) critique of tests as trivialising non-trivial cognition.

[3] The acronym AMTOSS stands for Air maintenance task–oriented support system . Cf. Farrington (1994).

[4] One question in a pilot of stage 2 of the cinegram evaluation contained an error which led to the situation that it was impossible for users to find ‘the feature that prevents oil draining …during a pressure filter change’ simply because the manual still presented an outdated version of the filter. Nevertheless, the two users did not doubt the factuality of the mechanism implied in the question; rather they settled for the subtle solution of giving a factual description of the unrelated drain plug removal before the filter change, thus fudging the link between their answer and the unanswerable question.

[5] I therefore disagree with Winograd & Flores (1986, p171) constructivist view that ‘ultimately…satisfaction is determined not by the world but by a declaration on the part of the requester that a condition is satisfied’. It is the world and its events that changes validation contexts beyond the scope of individual declaration. No NASA engineer would declare the Challenger spacecraft safe after its accident (cf. Moore 1992).

[6] This point is repeated in much of the literature dealing with systems evaluation (cf. Moser 1995; Johnson & Briggs 1994; Usability Evaluation 1994; Rubin 1994).

[7] Cf. one of Lindsay's (1994) design problems, scalability.

[8] This orientation towards unknown future states is a common element of design (cf. Jones 1992) and critical theory (cf. Horkheimer 1970/1937). It implies the fundamental difficulty of determining an action (designing or theorising) not within a given framework, but in anticipation of its future emergent consequences (cf. also von Foerster's (1984/1971) ‘Perception of the future and the future of perception’, ). The same difficulty appears in business process re-engineering (cf. Hammer & Stanton 1995); here, the scope of anticipated change is artificially limited to the level of organisation.

[9] Or, in customer-oriented lingo, a ‘service’ instead of simply transport, but the core is still transport. Cf. the brief case study of British Airways redefinition during business process re-engineering in (Ascari 1995 p15).

[10] As Lindsay (1994) points out, ‘organisations don't exist to perform only the goal set by the owners or managers of the organisation, but to fulfil all sorts of other internal [e.g. social] goals.’

[11] The pressure on maintenance to deliver the aircraft in time leads to an increase in errors which affect safety (see, for example, the role of ‘maintenance errors’ in the face of an unrealistic deadline in the incident of Excalibur A320 G-KMAM in Gatwick on 26 August 1993 (Mellor 1995)

[12] Cf.Skapinker (1995).

[13] Indirect costs exist, but they are harder to measure because they transcend organisational boundaries. They surface, for example, when manufacturers' poor documentation contributes to customers' errors in maintenance and pre-flight checking procedures (cf. Mellor 1995, and Funk et al 1996). The bad publicity of the resulting problems and incidents then affects manufacturer's reputation and business opportunities.

[14] For an introduction to business process re-engineering, cf. Hammer & Stanton (1995). BPR results in 16 companies are analysed in Ascari et al. (1995).

[15] Cf. Taylor (1990).

[16] At the time of writing, Rolls Royce was said to be planning to dissolve the Service Engineering department and allocating individual service engineers to project teams centring around individual engines.

[17] Even the rule books for usability testing admit the necessity of ‘exceptional’ help by evaluators when users get seriously stuck (cf. Rubin 1994). This implies the idea of the evaluator as a neutral feedback-free observation machine. Interest is supposed to be a mask, because otherwise it could lead to emergent communication which spoils the objectivist framework: ‘Try to be businesslike rather than either overly familiar or too formal…A moderate degree of positive reinforcement, uniformly distributed, can significantly improve the amount of information volunteered by the respondents. This only requires the interviewer to appear interested…' [My italics] (Usability Evaluation 1994 p69).

[18] The development of relative user autonomy has similarities with Goldfield's (1995 p302) descriptions of the dynamics of apprenticeship between mother and child. Goldfield talks about the assembly and tuning of nonautonomous attractors so they become autonomous.

[19]  It is commonplace by now that this independence ends on the micro-level of quantum physics. The difference between observer and observed seems grounded in the degree of similarity on the scale of animate-inanimate, and the consequent degree of resonance between the observer and the observed. The inanimate Belousov-Zhabotinskii reagent (cf. Thelen & Smith 1994 pp45; Goldfield 1995 p118) is oblivious of the fact that the animate researcher takes photographs of the emerging spiral wave. In contrast, both observer and observed in HCI evaluations are animate, causing a high degree of behavioural resonance in both directions. Every methodological choice, in including negative choices such as silence or absence of the evaluator, can be traced in the observed results.

[20] Cf. Lindsay's (1994) chapter on information economy.

[21] In the literature, effort is usually treated as a psychological, not a social and economic variable. Cognitive effort is described as being inversely related to a feeling of directness (Hutchins et al 1986 p95), or quantified as a subjective measurement such as AIME—‘Amount of mental effort invested’ (Guri 1984 p45).

[22] For a definition of brand equity, cf. Ambler (1995). A poignant example was the slump in Rolls Royce's brand equity after the loss of British Airways as a customer for the Trent engine family (cf. Skapinker 1995).

[23] British Airway's PINPOINT electronic manual allows updating with temporary revisions that overwrite outdated pages in the manual.

[24] Cf. Lindsay's (1994)chapter on information strategy to appreciate the complexity of these issues. The problem of determining the cost referent shows in the concept of ‘internal market’ which forces managers to reduce costs on the departmental level while encouraging neglect of knock-on effects for other departments. Departmental savings may result in overall increases of costs when presenting cost on the organisational level. An example related by service engineers at Rolls Royce shows the interaction of resource cost and repair costs. The attempt of design engineering to minimise component weight (and thereby reduce resource cost by using less raw material) leads to more component failures and consequently, to disproportionately high repair cost for another setting, service and repair engineering. Ironically, repairs and modifications also reverse the initial weight and material savings when ‘we later have to weld on all the material they have saved during design’. However, the situation is still more complicated. The organisation may not have won the competitive tender in the first place without presenting an engine specification conforming to the customer's requirements, which includes weight restrictions. This shows that the ‘rationality’ of design is bound to the irrationality of a market that necessitates opportunistic ‘narrow focus’ presentation at the expense of ‘wide focus’ presentation that would include the whole life cycle of the product.

[25] Gaining time and thereby allowing for the use of better resources is the motivation behind systems such as BISAM (developed jointly by Lufthansa, Sietec and DeTeBerkom) that allow forwarding fault reports from the airborne aircraft via ACARS, and advance retrieval of documentation, spares and tools, and expert articulation. (Cf. ‘BISAM. Multimedia Teleservices in Aircraft Maintenance’.)

[26] The concept of resource, often called information resource, is widespread in the literature. Skills, memory, and other people are all commonly treated as resources, as are manuals or computerised information systems Cf. Suchman (1987), Kellogg (1990), Brown & Duguid (1992), Hall (1994), Rolfe (1991), Boyd & Pask (1987), or Brown (1994).

[27] At the risk of boring the reader I will give an example of a typical (abbreviated!) on-wing maintenance resource repertoire of one operator, Lufthansa (Orlowski 1995). The picture will be similar in other airlines. Lufthansa mechanics use the following data sources: reports in Technical-, Cabin-, and Ground Log Book; and messages, on-line or as print-out, of Engine Instrumentation System (EICAS), Central Maintenance Computer (CMC), and Airborne Condition Monitoring System (ACMS). They may also require the following documents or document systems: Aircaft Maintenance Manual (AMM), Fault Isolation Manual (FIM ), Reliability on Demand (ROD), maintenance procedures (TBH-L), Technical Follow Up (TFU), Build-in Test Equipment (BITE) Manual, Engineering Orders (EO), job cards, and materials listing.

[28] ‘Rolls Royce contracts out £600m of IT’, Financial Times 15/11/95, p15.

[29] Another example is the lack of hypermedia link integrity, e.g., the frequent failure of World-Wide-Web cross references to other URLs.

Last update: 16 February 2009 | Impressum—Imprint