Cooperation without (reliable) Communication

Alan Dix

at time of publication: HCI Research Centre, Huddersfield University


Extended abstract of talk given at the IEE London, 24th November 1995.
Full reference:

Alan Dix, Cooperation without (reliable) Communication, Digest No.95/219, IEE London, ISSN 0963-3308, pp. 4/1-4/4.

A longer version of this can be found as:

A. J. Dix (1995). Cooperation without (reliable) Communication: Interfaces for Mobile Applications. Distributed Systems Engineering, 2(3): pp. 171-181.

Introduction
Bridging the gulf
Theme
Pace and bandwidth
Factors affecting pace
Where are wireless comms.
Pace of tasks
Feedback and mediated interaction
Caching
Collaborating
Why conflicts arise
Dealing with conflict
References



Introduction

This abstract considers problems in building interactive systems for mobile computers connected by wireless networks. It is largely a synopsis of work published in a paper of the same name in Distributed Systems Engineering (Dix 1995a) .

top of page || contents


Bridging the gulf

On May 17th 1897, Marconi transmitted the first radio signals over the sea from Lavernock Point in South Glamorgan to Flat Holm Island in the Bristol Channel (Goodall 1968) . Since then radio communication has been used to bridge the gulf between people living and working apart. However, the very fact that efficient voice telecomms exists serves to highlight the remaining deep gulf between, on one side, mobile workers who out of choice or necessity work away from a central location and, on the other side, both their colleagues working at other locations and also centrally stored corporate data.

Portable computers allow mobile workers to use the same applications as they use on their desktop systems. However, increasingly work relies on the use of local networks for access to shared applications and to facilitate cooperative work. At first sight wireless LANs seem to offer an answer allowing network applications to be simply ported to a new operating environment. However, this is not so - the nature of the medium has profound implications on the user-interface especially for collaborative working.

top of page || contents


Theme

From an external perspective wireless comms have two major problems compared to LANs: (i) poor performance whilst connected and (ii) the possibility of temporary disconnection due to noise or loss of signal. The latter is most problematic. We can attack this problem on two fronts: first to modify the user interface to make it more robust to delays and disconnection and second to look for technological solutions. Most important to note is that these are both necessary and are mutually interdependent.

top of page || contents


Pace and bandwidth

The most frequent parameter associated with communication channels is bandwidth - how much information can pass down it. However, in previous work it has been argued that a more important parameter for user interaction is pace - how often you can communicate (Dix 1992) . To be precise, the pace of interaction is the rate at which we can send messages or perform actions and get a result.

top of page || contents


Factors affecting pace

The pace of interaction of a channel is obviously related to the channel's latency, but this is not the only factor. Other factors which can influence pace include the bandwidth of the channel, buffering and computation, interface elements (whether messages attract the attention of users) and external factors such as physical processes or the nature of people's working environment.

top of page || contents


Where are wireless comms.

When considering wireless networks, we are principally interested in the way in which the physical nature of the medium affects the pace of interaction. We can position various media in pace/bandwidth space. Wireless communications may have a bandwidth similar to that achieved with modems over terrestrial lines. However, because of noise and possible broken connections (even if these are automatically repaired), the pace may stretch from fractions of a second to minutes. Furthermore, this pace is neither fixed, nor predictable.

top of page || contents


Pace of tasks

The jobs that people do can also be assigned a pace, measuring the rate with which they need to interact with the things on which they work. For a specific job we can use task analysis (Dix, Finlay et al. 1993) to build a task/sub-task hierarchy of what people do, then look at the frequency of the different sub-tasks. If the pace of a sub-task is greater than that of the communication channels, the task cannot be performed remotely. In addition, generic activities have well known paces, for example, direct manipulation tasks demand feedback within a few 100 milliseconds, command line interfaces (generally) less than 5 seconds (Shneiderman 1982) .

top of page || contents


Feedback and mediated interaction

We can tackle a channel/task mismatch by adapting the user interface. Direct manipulation (DM) metaphors demand virtually instant response. If the information required for such a response is remote then this is impossible. Retaining a DM interface in such circumstances is disastrous. A better approach is to admit the problem and adopt a mediated interaction approach. Instant feedback is required to confirm to the user that something is happening, so this must be separated from the eventual semantic feedback of the results of the operation.

top of page || contents


Caching

A technical approach to the same problem is to use caching techniques to bring the data to the user. This is effectively the technique used in the CODA distributed filesystem (Satyanarayanan, Kistler et al. 1990) . An extreme case is complete replication of all data as used in many Lotus Notes databases, but this may not be possible on a small portable system. In traditional RAM or disk caches the algorithms must be fast and automatic, but some cache misses are acceptable. The different pace of mobile working changes this cost-benefit trade-off. For mobile systems, a cache miss during a period of disconnection stops work completely. This implies that more complex algorithms are necessary including user involvement.

top of page || contents


Collaborating

Collaborative software and groupware is frequently divided into synchronous systems, where the participants are working simultaneously, and asynchronous where the participants are not aware of simultaneous activity. Wireless networks allow synchronous activity during periods of connection. However, during periods of disconnection only asynchronous activity is possible. Where systems allow for both modes, the transition between the two is assumed to be planned and infrequent. the mobile worker is thus lost somewhere in the middle.

top of page || contents


Why conflicts arise

Where shared data is held in local caches there is a danger of conflicts due to simultaneous updates. Locking strategies are not acceptable in most asynchronous applications as they may freeze data for unbounded amounts of time. Measurements by the CODA group indicate that for UNIX file usage conflicts are rare at most a few per cent of files may be affected. However, this is for a largely single-user use. Periods of synchronous collaborative activity will encourage a common focus, people will be likely to be working on the same document or diagram. If mobile workers engaged in synchronous collaborative work are unexpectedly disconnected then they must either cease working or face a very high risk of eventual conflict.

top of page || contents


Dealing with conflict

After periods of disconnection data at different sites must be resynchronised. There are two main problems: first detecting whether conflicts have arisen and second managing the merging of different versions when conflicts have occurred. Systems which rely on time-stamps for resynchronisation, such as many file-transfer programs or Liveware (Witten, Thimbleby et al. 1991) effectively assume that conflicts are either impossible or unimportant. More sophisticated systems such as CODA or Lotus Notes detect conflicts, but do little more than signal the conflict for the user's attention. Where conflicts have arisen file difference programs can help the user to merge files (Neuwirth, Candhok et al. 1992) . The two are integrated in proposals for multiple source control (Dix and Miles 1992) which is based on branched version trees, similar to those found in traditional version control systems such as RCS (Tichy 1985) . Merging of the trees themselves is trivial and conflicts show up as branches. Merging of the branches may require user intervention, but the information held in the version tree and the use of dynamic pointer techniques (Dix 1995b) can both make automatic merging more likely and also ease user controlled merging when necessary.

All these schemes are relatively heavy weight. If a mobile worker's connection is broken temporarily for say 30 seconds or a minute, we do not want the worker to have to engage in a complex resynchronisation process. For some application domains, the integrity of the data is essential. the best one can hope for is semi-automatic procedures that are invisible to the user most of the time, but occasionally require user intervention. However, if the data format is less fixed or the data is less critical we can use some tricks to reduce the necessity for manual merging. One technique is to restructure the data to make conflict less likely. In fact standard database normalisation can be seen as an example of just such a technique. In a graphics applications, we could only use XOR operations making all updates commutate with one another and so making automatic merging always possible.. Alternatively we may be prepared to accept slightly different versions on different people's screens - again in a graphics system, the odd pixel different where lines cross might be acceptable.

top of page || contents


References

A. Dix, J. Finlay, G. Abowd and R. Beale (1993). Human-Computer Interaction. Prentice Hall.

A. J. Dix (1992). Pace and interaction. Proceedings of HCI'92: People and Computers VII, Eds. A. Monk, D. Diaper and M. Harrison. Cambridge University Press. pp. 193-207.

A. J. Dix (1995a). Cooperation without (reliable) Communication: Interfaces for Mobile Applications. Distributed Systems Engineering, 2(3) pp. 171-181.

A. J. Dix (1995b). Dynamic pointers and threads. Collaborative Computing, 1(3) pp. 191Ð216.

A. J. Dix and V. C. Miles (1992). Version control for asynchronous group work. YCS 181, Department of Computer Science, University of York, (Poster presentation HCI'92: People and Computers VII).

F. G. Goodall (1968). The Story of Radio. Loughbrough, Ladybird Books, Wills & Hepworth.

C. M. Neuwirth, R. Candhok, D. S. Kaufer, J. Morris and D. Miller (1992). Flexible Diff-ing in a Collaborative Writing System. CSCW'92 - Proceedings of the Conference on Computer-Supported Cooperative Work, . ACM Press. pp. 147-154.

M. Satyanarayanan, J. J. Kistler, P. Kumar, M. E. Okasaki, E. H. Siegel and D. C. Steere (1990). Coda: A Highly Available File System for a Distributed Workstation Environment. IEEE Transactions on Computers, 39(4) pp. 447-459.

B. Shneiderman (1982). Response time and display rate in human performance with computers. ACM Computing Surveys, 16(3) pp. 265-286.

W. F. Tichy (1985). RCS - a system for version control. Software Practice and Experience, 15(7) pp. 637-654.

I. H. Witten, H. W. Thimbleby, G. Coulouris and S. Greenberg (1991). Liveware: a new approach to sharing data in social networks. Int. J. Man-Machine Studies, 34 pp. 337-348.

top of page || contents


maintained by Alan Dix