Collaborative Notebooks for the Virtual Workplace Phil Turner MARI Computer Systems, Old Town Hall, Gateshead, NE8 1HE, UK email:
[email protected] Susan Turner Department of Computing, University of Northumbria, Newcastle-upon-Tyne, NE1 8ST, UK email:
[email protected] Sue Green BAeSEMA, 1 Atlantic Quay, Broomielaw, Glasgow, G2 8JE, UK email:
[email protected] Phil Mayne MARI Computer Systems, Old Town Hall, Gateshead, NE8 1HE, UK email:
[email protected]
ABSTRACT This chapter discusses issues in the design of information sharing software systems for the virtual workplace. The discussion focusses on the trial use of a purpose-built shared collaborative notebook by a group of software engineers, managers and support staff distributed over two widely separated sites. The design of the notebook and the user context are described, and the results of the pilot trial reported. These results showed a partial take-up of the technology and clear variation between technical and nontechnical staff in levels of use. The findings indicate that when designing information sharing systems of this type (i) the true extent of the collaboration in question must be elucidated; (ii ) the system should allow for the fact that willingness to share information is at least partially determined by its the perceived formality or informality and the perceived formality or informality of the medium for sharing; (iii) the application must bridge the gap between personal and business information systems.
INTRODUCTION The virtual workplace (by which, for the purposes of this chapter, we mean an on-line forum where members of a team distributed over space and perhaps time can work together) should support both formal and informal information sharing and co-working. In the DUCK1 project we were interested, inter alia, in supporting informal co-working between members of a distributed group. DUCK was a CSCW (Computer Supported Cooperative Work) project which aimed to provide a cooperative toolset for the practice and management of engineering design. The development of the toolset was driven by detailed requirements engineering and by longitudinal pilots situated in the actual working environments of the end users. The DUCK project’s user company was a large supplier of engineering and software services and consultancy with many sites distributed across the length and breadth of the United Kingdom, and pressure to maintain efficiency had led to a keen interest in the possibilities afforded by virtual workplaces. It has become clear that the social, cultural and technical context into which CSCW technology is introduced is an essential consideration. This is reflected in a growing number of implementation case studies reported in the literature. Such reports originate from domains as varied as a government technology agency (Bowers, 1992), architecture and civil engineering 1
Designers as Users of Cooperative Knowledge. The project was supported by funding from the United Kingdom Department of Trade and Industry and the Engineering and Physical Sciences Research Council. The consortium comprised MARI Computer Systems, BAeSEMA Ltd and the University of Paisley. DUCK is a three year project and began in January 1994.
(Harper and Carter, 1994), management consultancy (Orlikowski, 1992) and education (Reynolds, 1994). Accordingly, our particular focus has been the sharing of work-in-progress situated in its everyday context. Additionally this domain was not the routine office automation setting: instead it concerned distributed, collaborative software design, build and testing. This chapter reports and discusses issues arising from a pilot study which sought to support the cooperative working of distributed software engineers.
Mutual Awareness of Workplace Activities Where members of workgroups share a physical workplace, they are continually aware of what their colleagues are doing through the everyday processes and cues of co-presence. It is easy to pass on information in an ad hoc way when the situation demands it, and to glean information useful to oneself. For example, a designer passing a colleague’s desk may recognise part of a design sketch, recall that problems had been found with a similar component in an earlier project, and suggest an alternative. A further piece of information afforded by the encounter is that work on this part of the assembly is far from finished, and therefore the first designer’s task on an interfacing area can be postponed for a while. In a more active exploitation of copresence, a calculation which ‘just doesn’t look right’ can be passed across the desk for someone else to check. The key points about these types of interaction is that they are unscheduled, informal and demand very little extra effort beyond that required for the main task in hand. This is not, of course, a phenomenon which is peculiar to the design context, and has been described by researchers working with, for example, air traffic controllers (Bentley et al, 1992) and London Underground staff (Heath and Luff, 1991). All these contexts for cooperation have a common feature, however: information and activity on the work-in-progress is distributed amongst the individuals concerned and sundry objects in their immediate environment. They are thus examples of distributed cognition, i.e. cognition that is distributed across the internal mind and the external environment, among groups of people, and sometimes across space and time. Such external objects might be screen displays (Underground control rooms), flight strips (air traffic control rooms), whiteboards (engineering design office - Rogers, 1993) and, in our particular context, technical notebooks, of which more below.
The Designer’s Notebook One of the main loci for the work of designers, managers and others in technical domains is the notebook, daybook, logbook, journal or laboratory book2. In its prototypical form, this is of A43 size with hard covers. The notebook is used for a wide range of activities - for engineering designers these include recording and exploring ideas in words and sketches, notes of discussions, calculations, records of trials, keeping lists of tasks and so on. Notebook contents comprise not just the book’s original pages, but frequently other items are attached or simply interleaved. Our own anecdotal knowledge of notebook use is supported by two surveys conducted as part of the early requirements work in the DUCK project.
2
3
Notebooks are commonly used in this way in the UK. We do not know how far their use is general practice in other cultures. 210mm x 297mm
The engineering company survey A questionnaire enquiring into current working practices and expectations of CSCW was distributed to over 200 engineers, managers and support staff at the DUCK user company. Part of the questionnaire focused on the use of notebooks. Respondents indicated whether they used notebooks for any of the following purposes, the list being derived from earlier requirements data. ♦ notes of discussions ♦ pasting-in sections of print-outs ♦ calculations ♦ pasting-in other things ♦ to do lists ♦ other uses Of the 103 people who responded, 90 were engineers or managers who used notebooks. The proportions for each category of use are shown in figure 1. The percentages should be read as, for example, ‘22% of all entries are calculations’.
Patterns of use of notebooks by engineering professionals Other items pasted in 7%
Discussion 34%
'To do lists' 28% Pasted-in printouts 9%
Calculations 22%
figure 1
A mixture of text and sketch modes was reported, and 'other' uses mentioned included: ♦ ♦ ♦
recording own actions recording actions placed on others log of time spent on various tasks
♦ ♦ ♦
diary of meetings/events listing client phone numbers maintaining contact and personal expense data
The software house survey In a complementary survey of 25 software engineers, designers, and software project managers into their use of notebooks or equivalent, the following pattern of use had emerged (note that the categories are not equivalent). Again, the percentages should be read as, for example, ‘51% of all entries are for technical purposes’.
Patterns of use of notebooks by software professionals Records of work 30% Non-technical uses 8%
As a diary 11%
Technical uses 51%
Figure 2
Although the profiles of usage from the two studies do vary, there remain a number of key commonalities. Notebooks are not used exclusively for technical matters; and notebooks are used for both formal and informal information. Notebooks thus provide the repository for much of the stream of work which is the subject of informal interactions of the sort discussed above. Consideration of the notebook as a resource for work-in-progress suggested that sharable on-line notebooks could support distributed cognition in the virtual workplace where opportunities for mutual awareness and the casual exchange of information are restricted.
THE COLLABORATIVE NOTEBOOK SYSTEM The collaborative notebook system (CNS) is a software implementation of an A4 notebook. The CNS is built on a Lotus Notes platform thus giving it all the necessary facilities to support both group and distributed working. The CNS presents the user with pairs of pages separated by a ‘binder’. The right-hand page supports simple note taking, and the ability to add comments, identified by a marker and between and within notebook ‘hyper-links’. The lefthand page is a OLE-enabled page into which any OLE capable document can be embedded. Figure 3 is a screenshot of a typical pair of notebook pages.
Figure 3
New (empty) notebooks or ready populated notebooks created from user-specified keywords are easily created. For example, a user could ask for a new notebook to be created from all journal pages to which he or she has access containing the words ‘bug report’ or ‘management meeting’ and so forth. The on-line notebook also supports full text searching (using the Lotus Notes search engine), printing, a contents page and page publication. Publication is the means by which notebook pages are shared. Figure 4 illustrates the dialogue whereby a page may be published from a notebook to one or more other notebooks. Published pages are then rendered read-only but comments may be added. Access control also allow users to specify who has access to their notebooks and the nature of the access, e.g. reader or writer. Publication is, of course, optional and controlled at the level of access to a particular pair of pages.
figure 4
THE COLLABORATIVE NOTEBOOK PILOT
Methods Software development The CNS had been iteratively developed over a period of nine months, prior to deployment, working closely with the end users. Early prototypes had been developed and frequently demonstrated to the potential end-users and had been greatly modified in the light of their criticisms, evolving and frequently contradictory requirements.
Validating the software To validate the CNS an extended pilot was set up across a pair of test sites selected from the DUCK project’s user company’s offices. These test sites were geographically remote being located in London and Glasgow (some 400 miles apart) but shared responsibility for the user company’s software product range. The design of the pilot followed the recommendations of Opper and Fersko-Weiss (1992) who have argued that the pilot introduction of CSCW technology should be divided into two phases - an experimental and then an expanded pilot. In the former, which is the case under report, the group itself is heavily involved in the evaluation of the system and actively observe changes in their own behaviour and working practices. Opper and Fersko-Weiss distinguish between these two styles of pilot as follows:
Comparison of Pilots Size Applications Members Influence Importance of project Process / content Computer expertise
Experimental
Expanded
7-12 Simple Innovative; flexible Significant Low Process centred Experienced
25+ Complex Representative Average High Content centred Varied after Opper and Fersko-Weiss (1992) p. 91
The end-users The end-users at both sites were groups of software designers, developers, support staff, sales staff, and a management team all of whom were very IT literate (in all there were eight endusers in London and three in Glasgow). As a group they were initially very enthusiastic about the CNS and its potential to resolve a number of information sharing issues that existed between the two sites. Overall, these groups were responsible for the continued software development of their product range of CASE tools. The development drive came from a number of sources but most immediately from customer feedback. This feedback took a variety of forms but centred around change requests and bug reports. However the information sharing issues faced by these groups were much broader than that, as in addition to change requests and bug reports, requests for support, sale enquiries, training enquiries and so forth for the full product range frequently arrived at either site. This happened despite the fact that the support of these products is explicitly demarcated between sites. It was therefore envisaged that the CNS would play an informal role in supporting a range of such activities. The end-users were interviewed at three points: immediately before the start of the pilot; after one month; and after three months.
Patterns of Work and Information Flow Division of work Prior to the pilot the end users were asked to estimate how much of their work normally fell into each of the following categories: independent4, sequential5, reciprocal6 and team working7. (Categories drawn from Van de Ven and Delbecq, 1976). The mean percentages of work allocated to the four categories were:
Technical Managers / support
independent 70% 37%
sequential 0% 15%
reciprocal 13% 28%
team 17% 20%
If these data are graphed (summing the sequential, reciprocal and team percentages to arrive at an overall percentage for the amount of cooperative work):
Division of work by job type
Cooperative working
Managers / support Technical
Independent working 0%
10%
20%
30%
40%
50%
60%
70%
figure 6 From the above data and very clearly from figure 6, it can be seen that the relative proportions of independent and cooperative work are virtually mirror images of each other.
Information flow In addition to the patterns of working, the end-users were invited to identify the communication pattern (from a set of four, after Orna 1990) which best described their perception of the situation at their site. Information flow within the London office was considered by the potential CNS users to be a mixture of network and more diffuse network types (Orna 1990) while the network type best described the Glasgow office. A network pattern of information flow is typified by (i) flexible decision rules and a degree of autonomous decision making; (ii) information and feedback flowing from the bottom to the top of the organisation. A more diffuse network is characterised by (i) a highly adaptive
4
Independent working: work is performed by you independently and does not involve anyone else in the team. Sequential working: work flows between you and one or more other members of the team, but only in one direction. 6 Reciprocal working: work flows between you and one or more other members of the team in a reciprocal 'back and forth' manner. 7 Team working: you and one or more other members of the team problem solve and collaborate as a group at the same time to deal with the work. 5
organisation; (ii) a flow of information and decisions which evolve in the response to needs rather than preset objectives, and (iii) an abundance of prompt feedback. Further to this the groups described themselves as having a peer-group structure with regard to technical (but not management) information, so much so that they declined security features and access control to the CNS journals and pages. Technical information was freely exchanged within each site. However, at the beginning of the pilot there was little communication between sites, except for support information regarding one of the software products, and this was typically by phone, fax or email. There were no apparent differences between technical and other staff in the frequency of use or choice of medium.
Pilot Results The CNS, at the time of writing, had been piloted for five months at these two sites and at strategic points during the pilot the users’ perceptions of the usefulness of the CNS had been evaluated by way of administered questionnaires. Evaluation point
Summary of key findings
Pre-pilot
Each of the sub-groups within the pilot sites (i.e. technical staff, salespersons, managers and support staff) foresaw a clear role for the CNS in their range of day-to-day duties. For the technical staff this was product support activities; and for the sales staff, marketing activities and so forth. For the managers it would be used for all of these! The software engineers uniformly failed to use the CNS. In contrast, other staff at the test sites used the CNS extensively, particularly those individuals supporting their software products. Further analysis of the evaluation data revealed that there appeared to be an antagonism between the clarity and ease of information sharing that the CNS offers - no more Chinese whispers8, as one individual put it, with the apparent transformation of informal to formal information when committed to an electronic medium. Informal information exists without a written record or time and date stamped. All information within the CNS is written and time and date stamp. Yet, users did find the CNS useful for jotting down ideas and for managing unstructured information. In all the software engineers appeared to resist using a means of communication perceived as formal for communicated information which they took to be informal. In contrast the managers and sales staff were using the CNS as they had indicated at the pre-pilot stage. Four major issues emerged after this extended period of use, (i) the endusers reported greatly improved information sharing between the two sites, but (ii) the transition from their current working practices to CNS was proving to be very slow, which was being hampered by (iii) software reliability problems. The end-users finally noted (iv) that there was a clear need to integrate the CNS with other information sharing tools such as MSMail™ and Microsoft Schedule+™.
After 1 month
After 3 months
A number of benefits had arisen from the improvement in information sharing between the two sites. The number of faxes exchanged had greatly reduced and this was due to the end-users at each site seeing the shared information as it changed or was updated. It was also reported that problems, particularly those of a repetitive nature, were found to be easier to track and solve.
8
That is, information which becomes distorted on telling and re-telling.
DISCUSSION AND CONCLUSIONS That the transition from the current working practices to the CNS was to be very slow is understandable and is a problem faced by many if not all CSCW pilots. The existing working practice at the pilot sites was proven, well understood and familiar and the need to migrate to a new system in this instance was due to technology push rather than an identified set of problems. The major example of a ‘shared notebook’ used in real-world contexts is the Virtual Notebook System™, (e.g. Brunet et al, 1991; Fowler et al, 1994) a much heavier-weight instantiation of the notebook concept, supporting large repositories of information in several media. The VNS™ has been found to be most valuable where its introduction is hand-in-glove with process re-engineering, thus facilitating adoption of information sharing resources. This supports our observation that the adoption of the CNS may have been limited by the attempt to infiltrate the notebooks into existing work patterns. While it remains the case, as noted earlier, that CSCW initiatives must take account of current custom and practice, a significant degree of re-engineering (or alternatively, a green-field site) may be key to full exploitation. There remain two basic findings for which explanations are here sought, firstly, ‘Why didn’t the technical staff use the CNS?’ and secondly, ‘Why wasn’t the CNS used for sharing informal information?’. In answering these questions three principal observations can be made: 1. There may be a substantial difference between the end-users’ perceptions of their patterns of work compared with the actual patterns. While it will be recalled that the technical staff reported that they spent around 30% of their time in team work, this may be an overestimate of the true situation and/or this work may actually consist of co-ordinated, but relatively independent activities. In such circumstances the information sharing supported by the CNS may be to some extent an irrelevance, and the lesson for designers of similar technologies may be that information only needs to be shared at the boundaries of individual tasks. 2. The style of work between technical and non-technical staff may be assumed to differ. Even allowing for the distortions in perception suggested above, non-technical staff reported a much greater proportion of group working. Moreover: ...we observe that some occupational groups, such as artists, architects and mechanical engineers (designers of physical objects whose development is shared in posted drawings or sketches) tend to prefer open workspaces through which colleagues are encouraged to browse. Other occupational groups (e.g. software engineers, academics, writers) tend to prefer more enclosed and private workspaces which offer fewer intrusions and interruptions. Reder and Schwab, 1990 While Reder and Schwab are referring to the physical workplace, this observation appears very pertinent to our findings. And finally, as we have observed elsewhere (Turner and Turner, 1995) technical staff are frequently reluctant to commit partially formulated information (i.e. informal information) to publicly available media in case it is used prematurely. The moral here is perhaps that considerations of privacy, responsibility and ownership remain very important in implementations of this type even when information sharing is discretionary. Indeed the whole issue of responsibility for the integrity of information once electronically available is one that warrants further study. 3. The final observation to be made lies with the dichotomy between personal and shared (or business) information systems. The identified need to integrate the CNS with other tools was not unexpected. This is consistent with our experience elsewhere, in the context of real-time, multi-media information sharing (Turner and Turner, 1992) that users prefer integration with existing tools rather than innovation per se, which has been described as the ‘not another box on my desk problem’. The existing personal information system we sought to replace here was the A4 notebook which may be characterised as being (i) easy to use; (ii)
portable; and (iii) secure or easily secured. In contrast the corresponding characteristics on a shared and / or business information system are: (i) integration with (other) information systems; (ii) integration with messaging systems / calendaring / scheduling (iii) integration with business applications; and (iv) that it is secure. The CNS attempted to bridge this dichotomy but only partially succeeded as it matched some of the former characteristics but few of the latter. It can therefore be concluded that any CSCW application must bridge the gap between personal and shared (or business) information systems.
REFERENCES Bentley R., Hughes, J. A., Randall D., Rodden T., Sawyer P., Sommerville I. and Shapiro, D. (1992) Ethnographically-informed systems design for air traffic control. In CSCW’92 Conference Proceedings (Turner J. and Kraut R., eds), pp 123-9. New York: ACM Bowers, J. (1994). The Work to Make a Network Work: Studying CSCW in Action. Proceedings of CSCW'94, New York, ACM Press. Brunet, L. W., Morrissey, C. T. and Gorry, G. A. (1991). Oral History and Information Technology: Human Voices of Assessment. In Journal of Organizational Computing, 251-274. Fowler, J., Baker, D.G., Kouramajian, V., Gilson, H., Dargahi, R., Long, K.B., Petermann, C., and Gorry, G.A. (1994) Experience with the virtual notebook system: Abstraction in hypertext. Proceedings of CSCW'94, New York, ACM Press. Harper, R. and Carter, K. (1994). “Keeping people apart.” Computer Supported Cooperative Work 2: 199-207. Heath C. and Luff P. (1991) Collaborative activity and technological design: Task coordination in London Underground control rooms. In Proceedings of the Second European Conference on Computer-Supported Cooperative Work EC-CSCW ‘91 (Bannon L., et al, eds), pp 65-80. Dordrecht: Kluwer Opper, S. and Fersko-Weiss, H. (1992) Technology for Teams - Enhancing Productivity in Networked Organisations, Van Nostrand Reinhold: New York. Orlikowski, W. J. (1992). Learning from Notes: Organizational issues in groupware implementation. Proceedings of CSCW'92, New York, ACM Press. Orna, E. (1990) Practical information policies, Gower. Reder S. and Schwab, R. G. (1990). The Temporal Structure of Cooperative Activity. Proceeding of the Conference in Computer Supported Cooperative Work , October 7-10, 1990. Reynolds, M. (1994). “Decision-making using computer conferencing: a case study.” Behaviour & Information Technology 13(3): 239-252. Rogers Y. (1993) Coordinating Computer-mediated Work CSCW 1: 295-315. Turner, S. E. and Turner, P. (1995). Best Practice in the Management of Technical Information. MARI Computer Systems. Turner, P. and Turner, S.E. (1992). Report on the non-functional requirements capture exercise for the BMST (UNOM project deliverable ref UMAR520010PPGI02) Van de Ven, A. H. and Delbecq, A. L. (1976). Determinants of Coordination Modes within Organizations. American Sociological review 41(April): 322-338.
Biographical Sketch Dr. Phil Turner is a senior consultant at MARI Computer Systems. He has a background in psychology and information technology and was consortium manager for the DUCK project. Susan Turner is now engaged in research and teaching in the areas of CSCW and HCI at the University of Northumbria and was the evaluation specialist for DUCK. Dr. Sue Green is a senior consultant at BAeSEMA and was responsible for user liaison and much of the fieldwork for DUCK. Phil Mayne is a software engineer at MARI Computer Systems and built the Collaborative Notebook application.
