Ana səhifə

Grounding in computer-supported collaborative problem solving


Yüklə 1.41 Mb.
səhifə8/18
tarix25.06.2016
ölçüsü1.41 Mb.
1   ...   4   5   6   7   8   9   10   11   ...   18

The VCE: TecfaMOO

  1. Criteria for selecting a groupware system


For our purposes of studying multi-modal computer-mediated collaboration, with an eye toward building a collaborative software agent, we needed a groupware system with at least the following components:

  • A language-based communication facility. This should be rich enough to allow fluent, unrestrained conversation. While this facility could include speech or typed text (or both), we chose to concentrate ontext-based communication, since spoken-language interpretation is not currently practical, except with fairly limited domains.

  • A graphical presentation facility (whiteboard), which allows collaborators to draw and manipulate schema, and express them to one another.

  • A data collection facility, which allows the experiments to capture the interaction, as completely and concisely as possible, for later analysis.

  • Hooks to allow the integration of other software, both for presenting and allowing manipulation of aspects of the domain task, and, in the future, for integrating a software agent as part of the collaborative team, rather than using all humans sitting at computer workstations.

Our ideal system would integrate all of these facilities, including speech and typed text, organized into reviewable conversations, a whiteboard with flexible placement and editing of objects, with a facility for combining graphical objects into more complex schemata, with real-time pointing, and full mixed initiative between collaborators: either agent can do any operations at any time. The ideal system would also allow the importation of external data, such as predrawn figures, text, and icons or "stamps", and would be easily extensible to allow the logging needed for experiments, and the computer access by software agents. We several system systems which appeared as goog candidates.

  • NCSA Collage. This is an integrated, bitmap style whiteboard, popular for some previous experiments on multi-modal collaboration. It has many colours, and a free-hand drawing tool. It also is a fairly stable program. It did allow text entry, but the editing features were fairly limited - subjects could erase, but not move or edit previously drawnsketches. Screen captures could also be imported into the window.

  • Sun Microsystems Showme. The main feature is a bitmap whiteboard with sound and video connections. The whiteboard includes a number of drawing options, including a set of preset stamps. Drawn items were not editable (only erasable), although itdoes include two panes, so that one can make part of the drawing the background, and not subject to erasure. The cursors of both participants are always visible, to allow easy pointing. Showme has an additional mode that allows it to share any X program between multiple participants. This allowed us to experiment with groupversions of standard single-user programs, such as Memolab, and fancier drafting programs. The drawback to this mode, however, is that it is more subject to system failure, and turn-taking is rigidly controlled - a participant must first seize control, before he can act upon thesoftware.

  • MBONE. This network system allows audio, video, and whiteboard connections. Thewhiteboard is from Lawrence Berkely Labs. It has several nice features, including movable drawings, a freehand tool, multiple pages, importation of postscript and text. It also has several disadvantages, however: no cursor is visible, and only the drawer can edit a drawing - the other participants may see, but not move these drawings. While this is a nice feature for an Internet demonstration or lecture, it is not the most useful choice for collaboration.

  • Groupkit. This is a user-extensible package for building groupware systems, using tcl/tk as a basis. It provides a number of tools, including sometext chat tools, a 'post-it note' tool, and a simple whiteboard. While the programmability would have allowed us to design our own custom system, given the time, neither the provided tools, not the programming environment was sufficiently developed at the time we started the project. The drawing tools did not allow for text to be represented. Also, there were still frequent crashes in our test version.

  • RTZ Software TVM for Mac and Windows. This software had nice drawing capabilities, but had different bugs on Mac and Windows versions, making it unusable at the time we tested it. For instance, on Macinsotsh platforms, drawings would get out of synch on the two screens, and the pointer tool did not work.

  • Self/Kansas. This is an object-oriented graphical programming environment, including a variety of graphical and navigational widgets. While it would have been possible to develop what we needed using this platform, it was still to early to stake our project on it, as the system was still in Alpha testing. The software also seemed too open -- a good feature for a programmer, but potentially allowing an inexperienced user to get into too much trouble.

  • Belvedere. This is a program designed specifically to represent negotation graphically. It provides boxes and arrows with embedded text, giving a semantics of argumentation to the connections between boxes. This would have been an interesting choice for some tasks, but at the time the project started, the software was not available to run real-time on our hardware.

Even with roughly comparable media, we noticed vast differences in the way different software allows one to interact with these media. In some cases, one can clearly say one functionality is better than another; but, in most cases, there is a tradeoff: how to make the best decision depends on the task that the collaborators need to perfrom, and even the way in which they might choose to perform this task. One must also consider the entire system, as many functions can migrate from one medium to another, depending on the relative costs and opportunities that a tool provides.
      1. TecfaMOO


While we examined quite a few groupware systems, none of them (at least no public domain or moderately priced systems) met our ideal. First of all, many groupware systems are geared more towards management goals rather than synchronous collaboration. Also, for those systems using synchronous communication, much effort is currently being placed on audio/video links, rather than more persistent forms of communication, such as whiteboard drawings.

The system we ended up choosing was a MOO environment. The has one advantage in that it is widely used on the Internet for collaborative, educational, and social purposes, and thus is fairly stable, and has a good base of ready users. Its most basic functionality is a text-based messaging system, providing several modes of communication. The MOO is a text-based a "virtual reality", including spatial locations and manipulable objects. The subjects move in different rooms, where they find suspects and objects. They talk to each other via two commands: "say..." to communicate with anybody in the same room, and "page John..." to communicate with John where ever he is.

Importantly, for our purposes, it is also extensively programmable, so we could embed a problem environment, as well as special resources. MOO programming also allowed us to produce the protocols of actions and communications of the collaborations. The MOO works by sending information to a central server whenever someone hits -it thus sends messages only when a complete utterance has been typed, which has some implications for the granularity of communication, turn-taking and grounding.

There exist several hundreds of MOO environements on Internet. These experiments have been run with standard MOO called TECFAMOO, developed by Daniel Schneider and several colleagues at TECFA10. In this experiment the subjects use a MOO client called Mudweller which runs on Macintosh and TKMOO-lite a client which runs on UNIX workstations. The window is split into panes: a pane of 14 X 19 cm, which display about 60 lines of text (any interaction uses several lines) and, just below, a text entry pane just which enter to type 3 lines. Example 1 shows a part of MOO window.



join sherlock

Auberge du Bout de Nappe: Lower Corridor

Obvious Exits: Lobby (to Lobby), UC (to Upper Corridor), B (to Bar), P (to Private Residence), R1 (to 1), R2 (to 2), R3 (to 3), and R4 (to 4).

Auberge Guest Room: 1

You see Rolf Loretan and Claire Loretan here.

Sherlock is here.

Obvious Exits: Out (to Lower Corridor).

Sherlock asks Claire Loretan about last night

Claire Loretan answers "I was in the restaurant with my husband and the Vesuvios. When the restaurant closed, I briefly went to my room and then joined the others in the bar."

Sherlock asks "Do you know when the bar has closed?"



wisper Did you notice that he is an insurance agent?

I don't understand that.



"what are doing?

You ask, "what are doing?"



ask rolf about the gun

hercule asks Rolf Loretan about the gun

Rolf Loretan answers "i looks like a military issue gun. Why don't you ask that Colonel?"

Sherlock says "Forget it. I thought it could help if we make a tab with the informations about where were th people at what time."



"Actually sounds a good idea.

You say, "Actually sounds a good idea. "

"I think we should find more information about the gun

You say, "I think we should find more information about the gun"

Example 1: An excerpt from the MOO window. Bold lines are entered by the user (Hercule).

We implemented several functions specifically for these experiments:



  • Users can type abbreviated communication commands: instead of typing "page Hercule ok" the user can simply type "' ok".

  • TecfaMOO is an open public space, where everyday people from all over the world connect for some time. This was not compatible with experimental purposes. Hence, the area of TECFAMOO in which the two subjects worked has been protected against the entry of other visitors. Users outside the auberge could not page to our subjects.

  • All actions and interactions are recorded in a text file (see the example of protocol in Appendix 2). We recorded the time of each action, its argument, who performed it and where. We hence have at the end of each experiment a very detailed transcript of interactions among subjects and their actions in the virtual world.

  • The detectives carry a notebook which automatically records the answers to all the questions that they asked to suspects. The answers are automatically sorted by suspect, whatever the order of questions was, as illustrated in example 2. They can merge the content of their notebooks or exchanges their notebooks.

read heidi from dn2

You consult Detective Notebook 2.

You turn Detective Notebook 2 to the page on Heidi Zeller.

----------------------------------------------------------

Info about Heidi Zeller :

----------------------------------------------------------

When asked about `last night' the answer was:

I had a drink with Hans in the bar. Then, around 7.45, I went out with Lucie, first for a pizza and then to the new night club El Gringo. We were out pretty late because she was flirting with some Czech hockey players.


When asked about `Mona Lisa Vesuvio' the answer was:

What do you want me to say. She was one of those snobish businesswomen who believes that everbody is at her service.


When asked about `gun' the answer was:

I saw it when I was cleaning the Colonel's room the other day. He's a scary old man!



Example 2: Retrieving information from the notebook (excerpt from the MOO window)
1   ...   4   5   6   7   8   9   10   11   ...   18


Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur ©atelim.com 2016
rəhbərliyinə müraciət