This subsection focuses on the creation of the first prototype of COOPerator's personal computer client application. The host application, constructed on a UNIX system (more specifically,a Sun workstation) is not discussed in this thesis.
COOPerator's human-computer interface is focused on cooperating students: their goal is to create a group document. In order to enable these students to reach that goal, the interface must establish a notion of common ground both between an individual student and his computer system, and between all members of the group, mediated through their respective computer systems. At the client level, the common ground is presented by the directed connected graph. The interface allows students different perspectives on the graph.
An overview of the shared environment is provided through four main windows which will be discussed within the context of this section: a document facility, an agenda, a mail facility, and a graphical browser. The prototype is constructed with the Model-View-Control framework in mind.
In the section that introduces The COOPerator project, a discussion facility is mentioned. This issue-space should have been the fifth main window of the system. However, due to time constraints, it was never finished.
Microsoft Windows® highly influences the scene of interaction: this graphical environment provides an extensive set of standardised widgets and even some functions that surpass the application model (e.g., cut-and-paste mechanisms). Still, it manages to do so on a minimal computer configuration. Windows typically applies the object-action interaction model of direct manipulation, thus (at least) recognising the central role of objects. In turn, the object-oriented structure of The COOPerator allows for a division of functional core and human-computer interface subsystem. The latter enables the user to understand the former.
A comparison of our achievements with the model of collaborative writing is presented in the conclusions section.
To start of this section, I present a summary of our efforts towards a user-centered design of the prototype. First, I introduce you to a typical student who is envisioned to use The COOPerator system.
A typical COOPerator user is a student, either male or female, who may participate in multiple collaborative writing groups at the same time. Each group consists of a limited number of group members that participate on an equal level. Within each group he is a member of a student can take on different social roles. He is probably a novice or experienced computer user, but not an expert (judged by the segmentation of Lee [1994]). Sociocultural aspects like religion and beliefs were not considered in the design.
Now that we know the user, and understand his task, we must focus on his needs. Mainly due to time constraints, in our requirements analysis we did not make use of techniques like interviews and questionnaires. Because a number of people in the development team actually matched the user profile, we decided to find out what the system should do through brainstorm sessions in which the whole team (not only the software engineers) participated.
Once we knew what to support, we needed to figure out how to do this. Task analysis needs to be done in addition to the more general requirements analysis. Normally, user task analysis eventually results in the design of a conceptual model of the system's human-computer interface. In our case, it involved creating sketches of the main window screens, a paper design. Thus, where the requirements analysis does not directly affect the human-computer interface, the task analysis does.
A more detailed task-analysis took us from this 'macro-level', in which we identified the main Windows, to the 'micro-level'. At this stage, for example, we decided how to implement the annotation mechanism: via menus, by using a button bar, or by means of a dialogue box? In turn, this question raised others: Should a menu have multiple hierarchical levels, must an item be accessible through short-cut key combinations? What is the minimal size for push buttons on a button bar, must such a tool bar be configurable? Should a particular dialogue box be modal (which would require a group member to respond before any other action can be taken) or modeless (in which case one may continue to work without responding) and how must push buttons be arranged within a dialogue? Though the literature answers a number of these questions and gives rules of thumb regarding others, a lot is left to the designers. Whatever decision we made, it should be applied consistently throughout the entire interface.
Like the brainstorm practice, we decided to make this an interdisciplinary team effort. After a few design sessions, we came up with a paper design of COOPerator's human-computer interface. Besides screen layouts for the main windows, the paper design contained menu schemes and dialogue boxes and their interrelationships. A number of demands and objectives completed it. The resulting main windows are shown throughout this section.
Sjoerd Michels, Tilburg, The Netherlands