Chapter 13

Groupware

13.1 We discussed the use of a group pointer in a shared editor with a shared view. Consider the advantages and problems of using a group pointer when participants have different views. How do you show the pointer if it is outside part of the document you are working on? Think also about the issues when the system is a hypertext-based co-authoring system. Is there any use for a group pointer in this case?

answer

The purpose of this exercise is to encourage students to think of the various scenarios that can arise during group editing and to encourage creative interface thinking. Where suitable tools are available, students can create mock-ups of their solution using a drawing package, or even envisionments of specific scenarios using HyperCard or a presentation tool. Below are some ideas.

We can start off with the shared editor shown in Figure 13.7. Imagine if your colleague wanted to point to the line starting 'Thinking about'. She could select the 'group pointer' tool, at which point she can drag around an icon shaped like a hand. She moves this over the words 'Thinking about' and starts to talk about the text (using some other means of direct communication such as the telephone). As the phrase in question is on both displays there is no problem about where to display the hand: it is placed over the words 'Thinking about' on your display. (Note that the group pointer is at a different physical location on each display).

Arguably the group pointer is even more important when there are separate views than when the view is shared. With a shared view the participants can be assured that they are seeing the same thing and so can assume a shared context. With separate views the participants are likely to have various problems when they forget that the others' views are different. For example, they will have trouble with indexical expressions or with relative statements 'the thing at the top'. The presence of a group pointer can help the participants to gain a shared focus.

On the other hand, the very presence of the group pointer can encourage the participants in a false sense of shared context. One could therefore argue that when participants want to enter a period of shared focus and synchronous discussion, they also move to a shared view. However, for the rest of this answer we'll assume that the views stay different.

What do we do when the group pointer is outside of the view? For example, in Figure 13.7, your colleague might move the group pointer to the line starting 'More adaptable'. In this case, your screen cannot display the group pointer in its correct position. Various options suggest themselves.

One could have the hand icon appear at the very top of your display with the finger pointing straight upward, meaning 'see above'. Similarly, if the group pointer were below the screen the icon could appear at the bottom pointing down. If such icons were displayed then the user could scroll the screen upwards until the group focus was found. Alternatively, one could arrange that to click on the icon scrolled one to the correct position.

Instead of, or in addition to, these 'out of view' icons, one could use the scrollbar and display the group pointer's position in it, thus allowing the user to see where it is easily, and scroll there if appropriate.

In the hypertext case, the solutions depend very much on the particular style of the system. If the individual nodes are large, then even if two participants are acting on the same node they may have different views, in which case all the above measures become relevant. If the participants are looking at different nodes, then the first action of a group pointer should be to direct attention to the node of interest. In a hypertext where the node graph is shown, this can be achieved by displaying the group pointer on the node of interest. Alternatively, if the graph is not displayed, the presence of a group pointer could be shown by adding a 'go to the focus node' button, rather like the 'home' button in many HyperCard stacks.

Although it is not mentioned in the question, it is worth also considering the display of other people's insertion points. In Figure 13.7, although your insertion point is within your colleague's view, it is not displayed in any way. There is no reason why other people's insertion points should not be displayed (suitably identified) when they fall within your view and vice versa. In addition, one might want some indicator on your scrollbar to show where your colleague's current view is. Such indicators can enhance group awareness and be a focus for initiating direct communication.

13.2 Repeat the exercise on page 490, but this time look for shared data on your system. Is the data updated by one person and viewed by many, or have you files or databases which are updated by several people? If the latter, find out what methods are used to prevent two users changing the same data at the same time. There may be no mechanism at all, a computerized one (for example, locking) or a social protocol (for example, a floppy disk is passed around).

answer

There is an argument that bulletin boards are a form of shared data, so they should certainly be acceptable as an answer to this question, depending on their nature at your site and also on how well argued the answer is.

You are likely to come across a lot of loosely shared items, where only a small group access them. For example, the files that comprise the book Human-Computer Interaction were shared between the authors. Whether any sort of locking is used will depend on the facilities available in your installation, but typically such small-group sharing is handled by social protocols (sometimes unsuccessfully!).

Here are some more specific examples from one of the authors' sites:

There are centralised databases containing phone numbers and car numbers. The former is used in place of the internal telephone directory and the latter when you notice some lights have been left on in the car park! Both of these are updated centrally by one of the administrative staff. Changes are notified (by email) to the administrator. However, access to the information is available to all.

Each user has a 'plan' file in their local directory into which they can put generally informative remarks about their whereabouts. Typically, this might include a contact telephone number, regular appointments a simple diary, or indeed anything of interest. When another user enters the command 'finger Alison', Alison's plan file is displayed. As the file is owned by the individual user, normal access permissions apply and so typically a user can only update their own 'plan' file. However, through the 'finger' command the information is publicly available.

There are also examples of publicly updateable shared files. For example, some email groups are handled by having a file containing the email address of each recipient. Anyone can edit the file to add or remove their name from this list. (In fact, they can just as easily add or remove someone else's name!) On our system this file has no form of protection from simultaneous update, the assumption being that such updates are so rare that they will never happen (really).

The lack of shared data with locking is a reflection of the poor level of system support in the UNIX world. Users of PC-based software should be able to find examples of locking of shared files or databases.

Finally, it is worth discussing the use of implicitly shared information. For example, the 'finger' command in UNIX also tells you whether the user is logged in and, if so, where. This is information known to the system, but made available to the users in such a way as to facilitate cooperation.

Worked exercises

The following appears as a worked exercise in Chapter 13:

HCI 2e home page || changes and additions || resources || search || contents || authors || ordering
feedback to feedback@hcibook.com
http://www.hcibook.com/hcibook/
designed and hosted by hiraeth mixed media
webmaster@hiraeth.com