presentazione ssgrr2002w

D. Bianchi - Tools for collaborative e-activities SSGRR 2002w

Tools for collaborative e-activities

G. Adorni, F. Bergenti, D. Bianchi, A. Poggi, M. Somacher

G. Adorni Università di Genova e-mail: [email protected], D. Bianchi, A. Poggi, M.Somacher, Università di Parma, e-mail: {bergenti,bianchi,poggi,somacher}@ce.unipr.it


Tools for collaborative e-activitiesThis paper discusses a system to facilitate activities through the network (e-activities) offering tools for collaborative work, video conferencing and video on demand. The architecture of the system is composed by two levels. The first level, called collaborative level, allows remote users to take part to a meeting where they can interact with each other via a chatting line and by sharing the use of different applications. A second level, called multimedia level, allows a multimedia interaction between the members of the meeting. Each user must own a microphone, a CCD camera and an internet connection with a sufficient bandwidth to support the exchange of audio and video data.We present some results obtained during research activities (project meetings, software design and debugging, document writing) involving people connected from different towns of Italy. The system was also used in e-learning activities distributed through a campus local network.


The Web in collaborative e-activities. •The Web is assuming a central role in the way people share information. •Web browsers are available everywhere and they provide an environment to integrate different services into a common, easily accessible, platform-independent user interface. •The Web has already been adopted as one of the principal media capable of supporting the collaboration between people.•Nevertheless, the basic communication facilities that the Web offers are not sufficient to support an interactive approach to collaboration. •The communication needs for which the Web was designed was about consulting structured documents and was not about supporting an interactive discussion in a virtual group. •The available Web technologies are not yet sufficient to implement the virtual-workgroup or the virtual-classroom metaphor.


The System Architecture•Our system relies on a multi-level architecture.

•We define three levels that differ for (i) interactivity and (ii) requirements on the user’s multimedia equipment and on the available bandwidth.

•The higher is the level, the higher is the interactivity that the system offers and the higher are the requirements on the user’s equipment.

•The multi-level approach allows the system adapting to the capabilities of the user.

•We propose a solution that is completely based on off-the-shelf technology that also domestic users can access with small investments.


Hypermedia material& E-mail services

Chatting line &Cooperative Tools

Audio & VideoData Exchange

Coarse-grained architecture of the system

•Users accessing the system through a domestic narrowband connection can still use the services of the collaborative level.•Users with a wide band connection (eg. a campus local network) can also access the highest level and take part to an interactive multimedial virtual meeting.


Supporting collaborative activity

•In general terms, a collaborative activity is supported by group communication, i.e., by an exchange of information among a group of participants, the collaborators, in a session.

•Collaborators may play different roles in a session and the roles can change dynamically.

•Collaborators may also join and leave a running session.

•A collaborative platform is required to provide all the facilities needed to support the dynamic nature of the collaboration.

•A collaborative platform should guarantee the availability of suitable media for information exchange.


Synchronous vs. asynchronous collaboration

•A collaborative activity can be roughly classified into two categories, depending on the information exchange dynamism: synchronous or asynchronous •Synchronous collaboration is characterized by a high level of interaction within the group: all the collaborators share a single view of the discussion and the information is exchanged when it becomes available. •Conversely, in an asynchronous collaboration, the information is transferred only on demand, thus lowering the degree of interaction in the group. •The classic Web communication facility support only an asynchronous collaboration, mainly because HTTP protocol rely on a communication model in which the browser needs to request the information, as HTML pages, from the server.


The Basic Level I•Our system supports synchronous collaboration in the middle and the high level. Nevertheless an asynchronous collaboration was added, as a basic level, to give access to HTML pages and to e-mail or news services. •This basic level was introduced mainly to support e-learning activities.•The system presents to the student a course module and its related tutorials through a Web browser. •The theoretical part of the subject matter is presented through HTML pages. •Linked to the main topics of the key chapters there is a series of tutorials (guided training exercises), presenting questions and problems that students are invited to solve offering software tools and simulating instruments for laboratory activities.


The Basic Level II•At the end of each tutorial there is a self-assessment test composed of (i) multiple-choice, (ii) true/false, (iii) fill-the-blank and (iv) essay questions. •While multiple-choice, true/false and fill-the-blank questions are corrected automatically, the essay questions need to be graded by the teacher; therefore, if the student can access to an internet connection, the system automatically sends an e-mail to the teacher with all the information needed to evaluate the results of the test. •At the same time, the student can take advantage of the e-mail connection to write her/his comments and to send questions to the teacher.•A news group is used for general discussion.


Collaborative Level I• Any collaboration support needs to provide consistency-guarantee mechanisms to

correctly manage the shared information.

• In synchronous collaborative environment, where the collaborators share a single view of the shared information, consistency is typically managed by a floor-control policy.

• The explicit floor control policy enables only one group member at a time to modify the shared document. This modifying privilege is commonly described in terms of possessing the modification token.

• The distribution of the token to group members is performed by means of an intelligent policy supported by the voting mechanism.

• The modification-token holder can decide to submit a document change to members’ voting before committing it to a document-session revision.


Collaborative Level II• The collaborative level is based on a collaborative implementation of Java AWT

package that we called CollAWT.

• As the collaborative components do not extend the AWT component services, except for the collaboration support, the application is not aware of the presence of the discussion group thus providing collaboration transparency.

• This package is implemented by means of the event-broadcasting mechanism: whenever a collaborative AWT component generates an event in reaction to an user interaction, this event is broadcasted to all group application instances in order to deal with it as if it was generated by the local user interface.

• Only the token-holder’s components are active, meaning that they can interact with the user, while all others’ components are passive.


Collaborative Level III•Events broadcasting is implemented by the events channel service which acts as an events broker.•After an event is fired by the user interface, the generated object of class AWTEvent is serialized and pushed into the events channel. •The events channel then broadcast the received data to all group applications. •Once received by an instance of the collaborative application, the AWT event is treated as if it was generated locally meaning that it is passed to the application.

Listener

EventService

A text

,

AWTEvent

Application

State


Collaborative Level IV•A user can join or leave a group at any time.•At login the new member receives an instance of the shared application while all group members are informed of this event. •The system supports unanticipated sharing of the application and latecomers can decide to enter into the discussion in a synchronous or deferred-synchronous way. •In the synchronous way, the latecomer is immediately accommodated in the group with a view of the shared document. •Conversely, in the asynchronous login procedure, the latecomer is shown all the changes occurred to the document since its last leaving. •The shared-application instances are synchronised starting from a common state and evolving by means of user-interface generated events. •The deferred synchronous policy is performed by the latecomer’s application asking the transaction-logging service to play back all events occurred since its last group leaving.


Multimedia Level The multimedia level integrates audiovisual components in our system to improve its effectiveness from the point of view of the communication among the meeting participants or in the learning process. Two different tools:

•A videoconferencing tool.•A tool for consulting audiovisual documents stored in digital format.

Are realized using Java Media Framework and implements the floor control mechanism.


Virtual Teams I

•We have used the described e-activities collaboration and communication facilities to manage a virtual team. We are experimenting this tool in research activities. Examples are: project meetings, software design and debugging, document writing.•To support these activities we have tailored a collaborative platform, named JWebTop, that supports sharing of documents and of Java applications for collaborative work. •The platform gives to the participant to the virtual meeting the use of a shared textual and graphical editor, and a web browser.• The editor allows participants to work to a shared document while the meeting is in progress, the web browser allows to display HTML text, or to present slides during a talk. •We are using this platform for scientific meetings with people distributed at home/office of many towns in Italy.


Virtual Teams II•The collaborative level provides as a communication tool a chatting line. But the exchange of written messages is very slow and annoying. To facilitate people communication an audio-conferencing or video-conferencing tool is also provided.•While a video conference requires a wide-band communication channel, the audioconference requires a narrow-band, but it is usually sufficient to guarantee an adequate level of communication amongst the people involved in a meeting. •In the user interface of the client application a person can require or release the floor. The floor request are managed by a FIFO policy. Only the user holding the floor can use the editor or the web browser.•On the contrary in the audio conference each user broadcast an audio stream to all the participants. Voices from different users can be mixed. It depends on the politeness of participants to regulate the dialog turns.


E-Learning: Basic Teaching/Learning Scenarios I•the transmission scenario: related to the empty vessel metaphor (old-fashioned; prevailing classroom teaching and lecturing). This scenario is characterized by a closed domain, well-defined learning goal, fixed learning route, instruction and practice, diagnosis of errors and remediation. The expected outcomes are domain knowledge and skills;•the studio scenario: related to the constructive agent metaphor (current; study-house). It is characterized by open or closed domain, well-defined learning goal, flexible learning route, project-based learning, interaction with different agents (human or otherwise) The expected outcomes are domain knowledge as well as social and practical skills;•the negotiation scenario: related to the situated/distributed cognition metaphor (post-modern). Characterized by open domain, ill-defined learning goal, open learning route, argumentation, negotiation and reflection. The expected outcome regards conceptual changes.


E-Learning: Basic Teaching/Learning Scenarios II•A prevailing transmission scenario is mainly reflected in classroom teaching, lecturing, drill and practice while there is little room for discussion/reflection and for complex problem solving. It is mainly used to teach and learn domain facts and rules: transmission. Most of the classical intelligent tutoring systems, mainly interested in domain and student modeling, fit in this class. •The studio scenario has more emphasis on complex problem solving, on student initiative and responsibility on problem analysis and solving method selection, more emphasis on open tasks (writing an essay, conducting a debate, giving a talk). Main aim is to teach and learn procedures and problem solving strategies. The modeling issue moves away from representing the cognitive states of the individual students to support interactions between users in a situation in which students have to confront with multiple tasks and multiple source of information. Our work may be considered as an example of this scenario. •The negotiation scenario, is based on student directed learning, student defined problems and solutions, student sharing of knowledge and evolving ideas. It is devoted to teach and learn meta-cognitive skills, to create new knowledge and to reflect on one’s understanding. May be promoted by the use of e-activities tools.


E-learning: an example of courseware

•A campus network was used to give access to a courseware case study. The system that we realized integrates the Web with the classic e-learning process to offer students and teachers services with different degrees of interactivity ranging from off-line document consultation, to web based document browsing and e-mail communication, to virtual classrooms.

•The collaborative level offers an application-sharing service to allow integrating the lesson with experiences on, e.g., simulated instruments and tools for laboratory activities.

•The multimedia level allows the integration of course materials with audiovisual documents to be used individually or in the virtual classroom.


The campus network We have two different networks. The first is the TCP/IP intranet of the Campus. This network is normally used for all the activities of the basic and collaborative levels, i.e., access to the Web server, to the mail and news services, to the chatting line and tools for collaborative work. The Campus network can support those services that do not require a fixed bandwidth allocation. On the contrary, multimedia service needs a guaranteed wide band connection to transmit video or audio data. So, a second network based on ATM technology connects the video server with the classrooms and labs.


AAL ATM TLO

ONU

Video Server

ATM

TLO

OLTCampus Network

NTSwitch

PC/ WS

Campus Network

PC/ WS

Switch

PC/ WS

Campus Network

PC/ WS

AAL ATM TLO

ONU

NTSwitch

PC/ WS

Campus Network

PC/ WS

Switch

PC/ WS

Campus Network

PC/ WS

8Mb/ s

0.7Mb/ s

8Mb/ s

0.7Mb/ s

622Mb/ s

155Mb/ s

622Mb/ s

622Mb/ s

BUILDING "A"

BUILDING "B"

BUILDING "C"

The campus network

The ATM network connects the video server with classrooms and laboratories. It is supported by a PON (Passive Optical Network) with a bandwidth of 622 Mbit/sec download and 155 Mbit/sec upload. The fiber optical network is connected with the user equipment using an ADSL switch which is also connected to Campus Intranet (Fast Ethernet).


An Example of Courseware: Hyperprolog I

•The campus network was used to give access to a courseware case study in which the different levels can be implemented and tested. The subject matter of the module is “Mathematical Logic, Logic Programming and Prolog”.

•The theoretical part of the subject matter is presented through hypermedia (which are made of hypertext and other kind of materials as audiovisual documents, animations).

•The course contains also a number of topics related to artificial intelligence: natural language processing, knowledge representation, fuzzy logic, learning, temporal logic.

•Linked to the main topics of the key chapters there is a series of tutorials (guided training exercises) with questions and problems that the students are invited to solve.


An Example of Courseware: Hyperprolog II

•Students can actually try out their answers and solutions by using, within the browser, an available Prolog interpreter on the server together with a number of files related to the examples presented in the tutorials. These sample files can be directly loaded and tried out in this environment which we called PrologLab.

•Also for the AI topics there are a number of working examples that the students can try in the PrologLab environment.

•Students can easily switch from the hypertext to the PrologLab or use both concurrently.

•At the end of each tutorial there is a self-assessment test which the students can take.


Collaborative PrologLab•In order to allow a direct distance interaction between teachers and students, a collaborative environment has been developed.

•The aim is to realize a virtual classroom in which the teacher can demonstrate the use of the PrologLab, develop programs interacting with the students, test the program with the Prolog Interpreter.

•All participants in the classroom have to see the same information on their screens. Moreover each participant can, in an ordered fashion, gain control of the collaborative resources end use them. For example can edit a file, consult a program in the Prolog database, execute a Prolog query and so on.

•The collaborative PrologLab may also be used by group of students working to a common project over the network.


The Collaborative PrologLab InterfaceParticipants can edit and test programs, use a chat line, enter or exit session, request or release the floor.


Collaborative PrologLab Floor Management

•Different floor management policies can be adopted.

•Because our aim, with the collaborative tools, is to reproduce a lesson, we can assume that the teacher may decide, on the basis of a request list, which student has the floor and so have an exclusive control of the application resources.

•At any time, the teacher can also gain the control of the floor previously given to a student.

•On the other hand, if the collaborative tools are used by a group of students working to a common project a more democratic policy of floor management should be adopted.

•A voter list is maintained to allow collective decisions and the members of the group can vote to accept or reject a proposed change to the current program.


System evaluation I •Analysis of the students’ patterns of activity by means of system logs. This analysis will give information about students’ use of the system, which pages of the text they looked at most, which facilities they used the most (tutorials, self test, PrologLab, e-mail, conference area) or which ones they overlooked.

•Effectiveness of the system in terms of the students’ learning outcomes. This evaluation is based on the results of the final test.

•Students’ attitudes toward the resource. A questionnaire was administered to the students to assess how much they liked this resource in comparison with more traditional courses. They were asked which part of the system they used most and which ones least, which ones they felt as difficult to use and why.

•The result of the questionnaires were integrated with the information gathered during focused group discussions on the topic.


System evaluation II

•Analysis of chat recording in the collaborative PrologLab can be used to study the interaction between students in working groups.

•Questionnaires can be used to test the satisfaction of the participants to a virtual meeting.

•We can obtain information about the easiness of use of the tools, the effectiveness of the communication with the chat line or the audio conference or the video conference, the usability at work/home with different communication bandwidth available.

presentazione ssgrr2002w

Documents

basic level

system users

calledcollaborative

calledmultimedia level

highest level

collaborative eactivities

system architecture

high level of interaction