The content on this page is the work of Professor Glenn Blank.
Be advised that Professor Blank is no longer on the active faculty at Lehigh.
This content continues to be available as a courtesy, but it may not be maintained or current.

Collaborative Network Interface Specification for CIMEL project

15 February 2001

Prof. Drew Kessler


Objective: To design, implement and evaluate a collaborative user interface in which personae seamlessly connect students to human instructors and librarians via networking technologies.

Collaborative Interface Specification


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. the expert saves the communication, they will be prompted for the topic of the communication. 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. the expert is available, and accepts the student’s request, the live connection begins. 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 student will be prompted for search criteria list of communications relevant to the search criteria will be returned.

Network Communication Specification


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. TCP for guaranteed, ordered delivery

2.1.2.     Communication messages IPQ protocol with vector time stamps                Orders event data so that different mediums (show me actions, typed chat lines, audio, video) are synchronized.                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)                Combines guaranteed with droppable data                Tag events at each sender with event ID (increases for each event) and local time                Send vector time-stamp (maximum event ID received from each remote connection) with each event.                If known, send connection ID of causative event (augmented vector time stamp, AVTS)                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: ID or unavailable role they play acknowledges receipt.

2.2.2.     Student client contacts the server to join or leave class session. ID (email address?) or leaving info (course she is working on, group ID for group projects, etc.) acknowledges receipt.

2.2.3.     Student clients contact the server to request available experts. experts, experts of a particular role or set of roles, or particular expert. responds with info on each matching expert.

2.2.4.     Student clients contact the expert client to request a connection. client acknowledges if still available.

2.2.5.     Student clients contact the server to request other students who have joined. set of attributes to match student info (course, group ID, project, etc.) responds with info on each matching student.

2.2.6.     Student client contacts client of other student to request a connection. 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). 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. browser plug-in windowing system application

2.4.3.     Interface actions are transformed to screen-independent form motion to web page location/component (location on text, location on image, type-in box, check box, etc.) motion to web browser interface component (scroll bar, menu item, etc.) button click select from drop-down list

2.4.4.     Interface actions are replayed with supporting graphics when on item is demonstrated with circle around item

2.4.5.     Communication between clients include: browser state (URL, scroll location, cookies, history,...) 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. 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. need a separate server to accomplish this.

2.7.  Video – deferred due to domain expert’s negative comments on suitability.