FREE ELECTRONIC LIBRARY - Theses, dissertations, documentation

Pages:     | 1 || 3 | 4 |   ...   | 5 |

«A Confederation of Tools for Capturing and Accessing Collaborative Activity Scott Minneman Xerox Palo Alto Research Center (PARC) 3333 Coyote Hill ...»

-- [ Page 2 ] --

During each IP segment there are two kinds of activity, discussion and conclusion. Discussion activity takes place across the table and involves all the participants, who are interacting with each other. This is the most critical activity, and we want our technology to be non-intrusive. For example, we do not require that the participants focus on the LiveBoard. Ron takes notes during the discussion on the laptop; he acts as a recorder, only occasionally participating in the discussion himself. Ron's notes are not totally private, however. We found it useful to "beam" his notes from the laptop to the LiveBoard as he takes them. Participants tend not to orient towards these beamed notes, but rather monitor them "out of the corner of their eyes" to make sure their contributions are being noted by Ron.

Ron brings the discussion activity to a close and initiates the conclusion activity of the IP segment. This activity involves making a decision on how to handle the IP and noting any associated action items. This activity is different from the open discussion in that Ron stands at the LiveBoard, where he marks the rating and disposition of the IP and handwrites the action items. Although there is discussion during this part, the participants are more focused on the board and on Ron than on each other, because they all want to see and make certain they concur with the conclusions.

Later, Ron documents the discussions and conclusions reached in each meeting (this may be days or weeks afterwards). He does this in the access setting, which is simply an office with a Sun workstation and audio/video playback devices, pictured in Figure 2. We call this particular configuration the "Salvage Station."

Figure 2. An access setting.

The Salvage Station consists of a workstation, monitor, and speaker. The workstation contains the LiveBoard display, playback controls, and an editor for creating documentation.

Creating the documentation in this setting involves a careful review of the captured materials. Ron summarizes each IP discussion in about a page of text. His typed notes from the meeting are often cryptic, serving more as indices into the recordings than as substantive summaries in themselves.(6) The Salvage Station, shown as a screen shot in Figure 3, provides him with playback controls, a Tivoli application showing the same pages as were created on the LiveBoard in the meeting, and a text editor to create the documentation. Every mark or note that was made on or beamed to the LiveBoard serves as a time index into the recordings. Thus, in order to get access to the recorded materials for a given IP, he buttons the Tivoli application to display the page containing the notes for that IP. Then by simply touching a mark or note on the displayed page he causes the media to play from the time when that mark or note was made in the meeting. This gives him meaningful random access into the recorded material. He listens and relistens to some portions of the recordings until he understands the significance of what was said. Although he may alternate between listening and typing the summary documentation, he often does both simultaneously, listening only for important points that he may have missed the first time around.

Figure 3. Salvage Station screen showing Tivoli, a text editor (buffers of meeting notes and summary), and a simple timeline controller.

Description of the Application Domain and the Work Settings Results of Using the Tools in This Domain Our work in supporting this application domain is ongoing, and we are continuing to develop new tools. However, even at the stage of development described here, we have several qualitative indications that the tools were successful.

First, we were able to support the meetings without disrupting them or forcing changes in practices. Second, the meeting participants commented favorably when they saw that the documentation was qualitatively improved by Ron's having access to the captured materials. Third, the meetings proceed more freely, because the participants seem to have greater confidence that their contributions will not be lost. Fourth, Ron is pleased to have the capability to produce better documentation. The trade-off is that it takes him longer to produce this more thorough documentation; but this situation should improve as we refine our access applications.

Description of the Application Domain and the Work Settings Table of Contents The Coral Architecture Coral is not a close knit system, but rather consists of a loosely coupled confederation of tools that work together through protocols of communication. We decided early on that the most practical way to evolve the system was to construct a set of applications that share access to a distributed multimedia infrastructure and that export interfaces to each other to permit various kinds of cooperative action. For example, a text editor that participates in this milieu might, by virtue of its connections to WhereWereWe and Tivoli, be making annotated events in a database that will later serve as pointers back into a multimedia recording, driving the current page of the LiveBoard display when the text editor is flipped from page to page, and "beaming" segments of the editor's text onto the screen of the electronic whiteboard for shared discussion or review.

Each of the tools in the Coral confederation is fully functional without one or more of the others (as we know from various weeks where we were still sorting out bugs in the individual pieces), but the combination of the tools makes for a more powerful union. Thus, the "system design" is emergent, based on a developing a shared infrastructure and developing protocols for exporting functionality to neighboring tools. Toward this end, major efforts were focused on the design of a suitable application programmer's interface (API) to the WhereWereWe multimedia system resources and similar APIs to other tools (e.g., Tivoli's beaming functionality), which are exported with a distributed object protocol.

Inter-Language Unification (ILU) and WhereWereWe

The tools described here, and WhereWereWe in particular, rely heavily on the Inter-Language Unification (ILU) project for their implementation [Janssen, 1994]. ILU is a distributed object system that lets users easily build objects which exist in one address space on a particular machine but have "proxy" objects that exist in the same or different address spaces on the same or other machines in a network. Either the real or proxy objects may be implemented in any of the following languages: C++, C, Python, Common Lisp, Fortran, tcl,(7) or Modula-3. The tools under discussion currently make use of only the C++, Python, and Modula-3 language bindings.

The proxy objects are operated on by "client" programs which can assume these proxies to be performing their respective functions, although in reality the proxy makes a remote procedure call to the real object (the "server" object), which actually carries out the operation. For example, a WhereWereWe client may create an ILU object from the API (e.g., a video Player object), and not concern itself with the details of the fact that in reality this object is communicating with the WhereWereWe server to carry out its functions. Furthermore, the object may be transparently shared--WhereWereWe allows multiple proxies to represent the same server object to facilitate resource sharing. For instance, multiple users may share a single video Recorder object, each potentially having control over the state of the device (e.g., pause and resume, frame rate), thus reducing hardware resource demands for compression and storage.

Most of these extensions are transparent to typical ILU API users, and the simpler nomenclature of clients and servers will be retained throughout this paper.

The Coral Architecture WhereWereWe Model The application programmer can see seven basic abstractions in the WhereWereWe API. These are all objects, which belong to the following classes: Session, Stream, Event, Player, Recorder, Data, and Notifier. Most applications need more than one of these classes, but few (if any) need all of them. The classes can be broken into three groups.

Sessions, Streams, and Events are classes of objects that are used to do naming in WhereWereWe. Sessions are named collections of Streams, which correspond to semantic occasions, such as "Project meeting from October 15". Streams are media data that can be played back, such as audio, video, or a program activity log. Events are "occurrences" that happen at some point or interval in a Stream. This association with a Stream is purely for the convenience of retrieval, but is one natural way of thinking about the relationship between Events and Streams. Also, each of these three classes supports a property list on each instance of the class, so that application programmers may associate arbitrary application-specific data with each object.

Players, Recorders, and Data objects are used to convert Streams into other forms. A Recorder both creates a new Stream object and takes responsibility for storing the data associated with that Stream (often this is simply a disk file which can be replayed later). A Player displays for the user the data of a previously recorded Stream. A Data object converts a Stream's recorded data into a raw form that a processing application can use as input for its algorithms.

A Notifier object is used by client applications that need to stay informed of the status of ongoing playback or recording activities.

It should be noted here that WhereWereWe can be thought of as "glue" that allows index-making and browsing activity for stream data. It does not attempt to provide general media playback services, but rather provides an infrastructure into which such services can be inserted and utilized in a uniform way. WhereWereWe, at present, has built-in drivers for digital audio and video in one format.(8) WhereWereWe also provides a limited mechanism for additional drivers to be installed and used with no changes to the client software and minimal changes to the server software.

These WhereWereWe API elements may be combined in many useful configurations.

The Coral Architecture Table of Contents Description of Two Primary Tools The initial implementation of the WhereWereWe infrastructure was completed in September 1993. Starting about midway through the development, and still continuing, a number of applications have been constructed or modified to take advantage of the facilities it offers. To explain what makes the WhereWereWe API useful to application writers, we will discuss its use with a pen-based application (Tivoli) for indexing from casual notetaking activity, and an Emacs mode we wrote to gain experience with textual annotation.(9) Tivoli Tivoli is the large-scale, pen-based electronic whiteboard application running on the LiveBoard to support publiclyviewed image manipulation in meetings.(10) While its many electronic whiteboard features have been documented elsewhere [Pedersen et al., 1993; Moran et al., 1995], a number of extensions facilitate seamless marking of activity for later retrieval, enable easy replay of multimedia records, and provide participants with a sense of the relation between the notetaking and recording functionality. Figure 4 shows a typical Tivoli screen layout in our application domain;

this one is for use in rating invention proposals.

Figure 4. Typical Tivoli screen shot, showing an application-specific form, pen-drawn strokes, keyboard text, and clock objects.

Tivoli has within it a stand-alone history mechanism that allows an "infinite undo" of drawing and editing operations;

this history facility also gave us a leg up on allowing the drawing/editing process to be replayed. Late in 1993, Tivoli was extended to use the WhereWereWe API and become a marking and browsing application. Very little needed to be done to extend Tivoli to support indexing, as its history was already retaining timestamps of drawing and editing operations. The application was modified to write that information into the files that it retained about sessions where audio and/or video were recorded. Tivoli was eventually further modified to produce other timing indices, but considerable utility as a side-effect indexer accrued from simply tying into its existing history mechanism.

In addition to the indexing functionality outlined above, the Tivoli application can be used to drive the various WhereWereWe resources for playback. Since each stroke drawn on the LiveBoard is timestamped, it is possible to select a stroke and have WhereWereWe and Tivoli replay all of the recordings made at that time. Thus, the user can utilize a Tivoli page's display as an interface, answering questions such as "what was Joe saying when I jotted this down?" or "what's this all about?"(11) Thus the strokes themselves constitute an important index into the activity.

The user is also presented with a simple timeline interface to the playback functions. This timeline panel offers the user several kinds of control that are not available with the direct selection interface described above. For instance, gross controls such as going to a general portion of the recording (say, "2/3 of the way in") or starting and stopping the session playback, but also finer-grained control such as hopping forward or backward several seconds to catch an unintelligible utterance.

Oftentimes, much of the graphical activity that constitutes the indices of side-effect markers comes after the event-making notes about a point that was made, or sketching a suggested solution. We added a feature that blurs the boundary between Tivoli as a side-effect indexer and as an intentional indexer. Users can insert a sort of temporal bookmark, a graphical object whose primary purpose is to initiate later replay from its creation time. These graphical objects display as a clock face (showing the time that they were created, often allowing users to see the progression of a discussion) and often further serve as bullets in list items (Fig. 4). These clockmarks have become very popular graphical elements, strewn throughout the pages of Tivoli.

Pages:     | 1 || 3 | 4 |   ...   | 5 |

Similar works:

«85037-547-50 Minisart® NML Plus | NY Plus Spritzenvorsatzfilter von Sartorius mit hoher Kapazität Sartorius Minisart® Filter mit Glasfaser (GF) Vorfilter sind optimal für Proben mit hoher Partikelbelastung. Minisart® Plus Filter enthalten einen einzelnen GF Filter oder einen GF Vorfilter vor der eigentlichen Filtermembran. Der GF Tiefenfilter über der Membran schützt den Spritzenvorsatzfilter vor frühem Verblocken. Minisart® NML Plus ist optimiert für die Klarfiltration und die...»

«IN THE COURT OF CRIMINAL APPEALS OF TENNESSEE AT KNOXVILLE Assigned on Briefs September 16, 2014 STATE OF TENNESSEE v. DESHAWN MAHON MANCILL1 Direct Appeal from the Criminal Court for Knox County No. 99058C Steven W. Sword, Judge No. E2014-00278-CCA-R3-CD Filed February 6, 2015 The appellant, Deshawn Mahon Mancill, was convicted by a jury in the Knox County Criminal Court of possession of heroin with the intent to sell or deliver. The trial court sentenced the appellant as a Range II, multiple...»

«Minutes of the meeting of the Confidentiality Advisory Group 11 February 2016 at 10:00 at Skipton House, SE1 6LH Present: Name Capacity Ms Gillian Wells (Alternative Vice Chair) Chairing 2a, 3a, 3b. Dr Tony Calland MBE (Vice Chair) Chairing 4a, 4b, 4c. Mr Andrew Melville Ms Sophie Brannan Ms Clare Sanderson Dr Robert Carr Ms Kim Kingan Dr Murat Soncul Dr Miranda Wolpert Also in attendance: Name Position (or reason for attending) Ms Natasha Dunkley Confidentiality Advice Manager, HRA Ms Diane...»

«Tema 6. ELASTICIDAD.6.1 Introducción.6.2 Esfuerzo normal.6.3 Deformación unitaria longitudinal.6.4 Ley de Hooke.6.5 Deformación por tracción o compresión. Módulo de Young.6.6 Coeficiente de Poisson.6.7 Deformación debida a tres esfuerzos ortogonales.6.8 Compresión uniforme. Módulo de compresibilidad.6.9 Cizalladura. Módulo de rigidez. 6.10 Deformación por torsión. Constante de torsión. Nota: El contenido de estos apuntes pretende ser un resumen de la materia desarrollada en el...»

«Youth Ministry Policies and Procedures HANDBOOK CAPSTONE CHURCH YOUTH MINISTRY JR. HIGH/HIGH SCHOOL POLICY & PROCEDURE MANUAL Contents Philosophy of the Youth Ministry Purpose & Objective Core Values & Expectations II. Youth Protection Policies Application Definitions Inappropriate Displays of Affection Appropriate Displays of Affection Appropriate discipline Guidelines General Transport Overnight Events Exceptional Situations Screening Training/Continuing Education Reporting Counseling Care of...»

«Ministério Público Federal PROCURADORIA REPÚBLICA PARANÁ DA NO FORÇA TAREFA “OPERAÇÃO L AVA JATO” EXCELENTÍSSIMO JUIZ FEDERAL DA 13ª VARA FEDERAL DA SUBSEÇÃO JUDICIÁRIA DE CURITIBA/PR Autos nº 5053845-68.2014.404.7000 e 5044866-20.2014.404.7000 (IPL referente à ENGEVIX), 5049557-14.2013.404.7000 (IPL originário), 5073475-13.2014.404.7000 (Buscas e Apreensões) e conexos O MINISTÉRIO PÚBLICO FEDERAL, por seus Procuradores da República signatários, no exercício de suas...»

«1 M Y FaMilY’s ClaiM to nobility does not extend very far back. In fact, it originates with my father. I say this without the least sense of shame. You must understand that if I were out to hide anything I would never have begun this story at all. My design is to write it straight out, without any deviation, the way you’d go about ploughing a field. Some have dared to claim that my great-grandfather was a mere lackey: a falsehood which I shall be glad to prove to anyone who will listen. In...»

«Routing with Confidence: A Model for Trustworthy Communication APU KAPADIA Institute for Security Technology Studies (ISTS), Dartmouth College and PRASAD NALDURG Microsoft Research and ROY H. CAMPBELL Department of Computer Science, University of Illinois at Urbana-Champaign We present a model for trustworthy communication with respect to security and privacy in heterogeneous networks. In general, existing privacy protocols assume independently operated nodes spread over the Internet. Most of...»

«01-04:Moments Front.3pp 9-04 8/13/10 1:51 PM Page 3 MOMENTS TO G E T H E R F O R COUPLES Dennis and Barbara Rainey Dennis & Barabar Rainey, Moments Together for Couples Bethany House, a division of Baker Publishing Group, © 1995, 2014. Used by permission. 01-04_Moments Front.3pp 9-04 9/28/11 10:36 AM Page 4 PUBLISHED BY REGAL BOOKS © Copyright 1995, 2014 by Dennis and Barbara Rainey. All rights reserved. FROM GOSPEL LIGHT Published by Bethany N T U RPublishers F O R N I A, U. S. A. V E...»

«Contraflow Plan for the Florida Intrastate Highway System Table of Contents List of Appendices List of Tables List of Figures List of Acronyms Executive Summary 1. Introduction 1.1 Background 1.2 Source Document 1.3 Organization of this Technical Memorandum 2. Contraflow Issues and Operations 2.1 Contraflow Setup and Shutdown 2.2 Loading Contraflow 2.3 Terminating Contraflow 2.4 Contraflow Access for Evacuating Vehicles 2.5 Emergency Vehicle Access 2.6 Shoulder Usage 2.7 Concurrent Contraflow...»

«Juan camilo Conde Silvestre Formado en Murcia (donde obtuve el grado de I took my degree in English Studies at the Doctor en 1990) y Manchester (como Research University of Murcia, where I finished my Ph.D. in Fellow en 1992), estoy vinculado 1990. Later I spent one year (1992) as Research profesionalmente a la Universidad de Murcia Fellow at Manchester University, doing desde 1986: como Profesor Ayudante (1986postdoctoral research. I has been teaching at the 1994), Profesor Titular (1994-2007)...»

«Team Member Handbook The team member’s Handbook summarizes the employment policies and procedures in effect at The Palms Hotel & Spa. This guide is effective immediately and is applicable to all team members regardless of their date of employment. The Company may from time to time unilaterally modify, revoke, suspend, terminate or change any of the policies and procedures contained in this guide, in whole or in part. 3025 Collins Avenue Miami Beach, FL 33140 Phone: (305) 534-0505 Fax: (305)...»

<<  HOME   |    CONTACTS
2016 www.theses.xlibx.info - Theses, dissertations, documentation

Materials of this site are available for review, all rights belong to their respective owners.
If you do not agree with the fact that your material is placed on this site, please, email us, we will within 1-2 business days delete him.