15
February 2001
Objective: To design, implement and
evaluate a collaborative user interface in which personae seamlessly connect
students to human instructors and librarians via networking technologies.
1. Expert – Professor, Librarian, or
Teaching Assistant:
1.1. The expert will have an “Available”
and “Not Available” option.
1.1.1.
If the expert is available, they will have the option to accept or not
accept incoming requests for assistance.
1.2. The expert will have the option to
communicate through four methods.
1.2.1.
Video and audio
1.2.2.
Video and text
1.2.3.
Audio Only
1.2.4.
Text Only
1.3. If the expert uses video, they will
have two options for the video source.
1.3.1.
A camera connected to the expert’s computer
1.3.2.
The assistant’s computer screen.
1.4. After each video feed, audio feed,
or text communication has ended, the expert will have three options.
1.4.1.
Save the communication.
1.4.1.1.If the expert saves the
communication, they will be prompted for the topic of the communication.
1.4.1.2.The expert will then index it
however they wish.
1.4.2.
Delete the communication.
1.4.3.
Let the expert decide later.
2. Student – Individual taking the
course:
2.1. The student will have an interface
with the option to get assistance.
2.2. The student will have the option to
communicate through email with one of the avatars, look at a saved video feed
from one of the avatars, or attempt a live connection with one of the avatars.
2.2.1.
If the student selects a live feed, the program will then determine
whether the expert is available or not.
2.2.1.1.If the expert is available, and
accepts the student’s request, the live connection begins.
2.2.1.2.If the expert is not available or
does not accept the request, the student will be given two options, email the expert
or view a saved video feed.
2.2.2.
If the student selects email, it will open and initialize the email with
the proper email address.
2.2.3.
If the student selects to view a saved video feed
2.2.3.1.The student will be prompted for
search criteria
2.2.3.2.A list of communications relevant to
the search criteria will be returned.
1. Architecture – Hybrid Client/Server,
Peer-to-Peer topology
1.1. Server
1.1.1.
Stores network location and information on available experts and
connected students.
1.2. Clients
1.2.1.
Expert (Reference Librarian, Instructor, Teaching Assistant...)
1.2.2.
Student
1.2.3.
Clients connect to server to obtain information about available experts
and students.
1.2.4.
Clients connect directly to experts and students, as desired.
2. Communication Protocols
2.1. Synchronization
2.1.1.
Connection messages pass through server, and therefore needs only to be
ordered in data stream.
2.1.1.1.Use TCP for guaranteed, ordered
delivery
2.1.2.
Communication messages
2.1.2.1.Use IPQ protocol with vector time
stamps
2.1.2.1.1.
Orders event data so that different mediums (show me actions, typed chat
lines, audio, video) are synchronized.
2.1.2.1.2.
Orders events from multiple sources so that chat lines and actions are
seen after any chat lines and actions that could have preceded it in the
sender’s context. (Causal ordering)
2.1.2.1.3.
Combines guaranteed with droppable data
2.1.2.1.4.
Tag events at each sender with event ID (increases for each event) and
local time
2.1.2.1.5.
Send vector time-stamp (maximum event ID received from each remote connection)
with each event.
2.1.2.1.6.
If known, send connection ID of causative event (augmented vector time
stamp, AVTS)
2.1.2.1.7.
Order entering events, audio, and video stream data by vector time-stamp
and adjusted local time (update local vector time-stamp)
2.2. Connections
2.2.1.
Expert clients contact the server indicating:
2.2.1.1.Unique ID
2.2.1.2.Available or unavailable
2.2.1.3.What role they play
2.2.1.4.Server acknowledges receipt.
2.2.2.
Student client contacts the server to join or leave class session.
2.2.2.1.Unique ID (email address?)
2.2.2.2.Joining or leaving
2.2.2.3.Other info (course she is working
on, group ID for group projects, etc.)
2.2.2.4.Server acknowledges receipt.
2.2.3.
Student clients contact the server to request available experts.
2.2.3.1.All experts, experts of a particular
role or set of roles, or particular expert.
2.2.3.2.Server responds with info on each
matching expert.
2.2.4.
Student clients contact the expert client to request a connection.
2.2.4.1.Expert client acknowledges if still
available.
2.2.5.
Student clients contact the server to request other students who have
joined.
2.2.5.1.Some set of attributes to match student
info (course, group ID, project, etc.)
2.2.5.2.Server responds with info on each
matching student.
2.2.6.
Student client contacts client of other student to request a connection.
2.2.6.1.Second client responds if still
available.
2.3. Entering the expert’s queue
2.3.1.
Assumes student client has connected to expert
2.3.2.
Student client sends question to expert client, perhaps requesting a
certain set of communication mediums (interface overlay, chat, audio, video),
expert client responds with unique ID.
2.3.3.
Student client may also request pending questions, response is question
string with ID
2.3.4.
Student client may send request to join the student(s) that have asked a
question, using the given ID (expert client may deny or accept request. The
expert may indicate that a question is not “sharable”).
2.3.5.
Student client may withdraw question, using unique ID assigned by expert
client.
2.3.6.
Expert client notifies student client when question is addressed by
expert, and makes appropriate connections (interface overlay, chat, audio,
video).
2.3.6.1.If communication medium request is
different then student’s request, student client makes additional connections
(based on student input as to whether the medium is ok).
2.4. “Show me” Interface Overlay
2.4.1.
Student client or expert client makes connection with the expert client
or student client, respectively.
2.4.2.
Interface (web browser) capture software is started. It provides
interface actions to client and draws an overlay on the interface to
demonstrate the actions of the remote user.
2.4.2.1.Web browser plug-in
2.4.2.2.Separate windowing system
application
2.4.3.
Interface actions are transformed to screen-independent form
2.4.3.1.Mouse motion to web page
location/component (location on text, location on image, type-in box, check
box, etc.)
2.4.3.2.Mouse motion to web browser
interface component (scroll bar, menu item, etc.)
2.4.3.3.Mouse button click
2.4.3.4.Item select from drop-down list
2.4.4.
Interface actions are replayed with supporting graphics
2.4.4.1.Click when on item is demonstrated
with circle around item
2.4.4.2.Etc.
2.4.5.
Communication between clients include:
2.4.5.1.Web browser state (URL, scroll
location, cookies, history,...)
2.4.5.2.Screen-independent Interface Actions
2.5. Chat
2.5.1.
Student client or expert client makes connection(s) with other
client(s).
2.5.2.
Messages from a client are time-stamped and transmitted to other
connected clients with sender’s ID.
2.5.3.
Incoming chat messages are causally ordered, and displayed in the
correct order. If “cause” message is known, the chat interface is given the
relationship to display.
2.6. Audio
2.6.1.
Student client or expert client makes connection with another client.
2.6.2.
An audio stream is established between an expert and a student.
2.6.2.1.Using existing audio streaming
software
2.6.3.
If many students are connected to an expert, audio sources are mixed at
the expert client and broadcast to all students.
2.6.3.1.May need a separate server to accomplish
this.
2.7. Video – deferred due to domain
expert’s negative comments on suitability.