HUMAN-COMPUTER INTERACTION
SECOND EDITION
HUMAN-COMPUTER INTERACTION
SECOND EDITION
As we have indicated, the differences between groups mean that some configuration by the group is essential. That is, shared editors require some form of local structuring. However, that does not mean that there will be no problems. Participants will point at the screen with their fingers when in different rooms, and use indexical expressions when they are in separate screen mode. The more their sense of engagement, that is the more they feel as if they are working together, the more likely they are to revert to natural forms of expression. We cannot prevent this entirely; as we saw, mistakes can happen in 'real life' too.
In addition to email, you may have one or more text-based synchronous communication tools. For example, many UNIX machines have two tools, 'write' and 'talk'. The command 'write Alison' followed by some text prints that text on Alison's screen. She can respond by doing a 'write' back to the sender. The 'talk' command establishes a more continuous conversation, as described in Section 13.3.1, where both participants' screens are split in two, each half displaying one of the participants' contributions. Although both can be seen as synchronous/remote, they operate at different levels of sharing (Section 13.6.2). Whereas 'write' only sends the text after the contribution is completed, 'talk' sends each user's contributions character by character as they are typed. That is, 'talk' sits further down towards the bottom left of the
Again, there are loose connections between the two levels of sharing. For example, it makes little sense to have a single insertion point but different views. However, one document annotation system has separate insertion points but a shared view. Any user can choose to scroll the view of the document, but it then scrolls for all users. To make matters worse, the other users' insertion points stay at the same point on the screen as the document moves. So if they are typing when the screen is scrolled, their characters appear all over the document! It is a testimony to the power of social protocols that this system is not only used successfully, but also enjoyed.
The first new arc represents deixis. Recall that we first encountered deictic reference in the context of meeting room software (Section 13.4.2). The participants needed to refer to items on the shared screen, but could not use their fingers to point. In general, direct communication about a task will refer to the artefacts used as part of that task.
We have discussed a wide range of groupware systems, but there are formidable problems with implementing such systems, particularly synchronous groupware. Groupware systems are intrinsically more complicated than single-user systems. Issues like handling updates from several users whilst not getting internal data structures or the users' screens in a mess are just plain difficult. These are made more complicated by the limited bandwidth and delays of the networks used to connect the computers, and by the single-user assumptions built into graphics toolkits.
When editing text, a delay of more than a fraction of a second between typing and the appearance of characters is unacceptable. For text entry a slightly greater delay is acceptable as you are able to type ahead without feedback from the screen. Drawing, on the other hand, demands even faster feedback than text editing. Groupware systems usually involve several computers connected by a network. If the feedback loop includes transmission over the network, it may be hard to achieve acceptable response times. To see why, consider what happens when the user types a character:
9 and the feedback is given on the user's screen.
There are two major architectural alternatives for groupware, centralized and replicated, with variations upon them both. In a centralized or client--server architecture each participant's workstation has a minimal program (the client) which handles the screen and accepts the participant's inputs. The real work of the application is performed by the server, which runs on a central computer and holds all the application's data (Figure 13.13). Client--server architectures are probably the simplest
The second major architecture is replicated. Each user's workstation runs its own copy of the application. These copies communicate with one another and attempt to keep their data structures consistent with one another. Each replicate handles its own user's feedback, and must also update the screen in response to messages from other replicates. The intention is often to give the impression of a centralized application, but to obtain the performance advantages of distribution.
This race condition is a common problem in distributed computing. A standard solution there is to roll back one or other replica and re-execute the commands. However, if the results have already been displayed on the user's screen this is not acceptable -- standard computing algorithms often fail for groupware. Happily, many of the concurrency control mechanisms, such as locking or floor holders, mean that such races do not occur, or at worst occur only when users obtain locks or other large-scale events. So, when rapid feedback is not required, standard mechanisms may be applied, but, for real synchronous update, special-purpose algorithms are required.
processed in 0.006 seconds
|
| |
|
HCI Book 3rd Edition || old HCI 2e home page || search
|
|
| feedback to feedback@hcibook.com | hosted by hiraeth mixed media |
|
| |