Problem
Our CSCW class uses the MASH conferencing tools to allow remote participation. The class engages in discussion on assigned papers every week. Local participation within the Colab is plentiful and fluid. However people attending remotely show a lower level of interaction during the discussion. When one of them do talk, the person's audio shows up unexpectedly because her voice emerges suddenly without any prior indication. It breaks the fluidity of interaction within the Colab and this person sometimes apologizes for interrupting.

Analysis
I believe these problems arise because local participants (LPs) inside the Colab lack an awareness of remote participants (RPs). Even though most of the RPs are transmitting videos of themselves, a few problems are hindering interaction between LPs and RPs:

• The videos are blocky and smaller than real-life size. This results in the loss of facial expression and body language cues that are fundamental in face-to-face interactions. For example, when an LP wants to speak, she may open her mouth, slightly raises her hand, and/or wiggles up and down. The LP currently speaking sees these intentions to speak and yield the floor at his convenience. However, an LP do not get these cues from an RP's video. Thus, when RP's audio shows up it is often unanticipated.

• A few mechanisms are employed in class for the LPs to be more aware of the RPs. One is timer-switched videos. RPs' videos are cycled through periodically on computer screens. This makes it difficult for the LPs to distinguish the RP speaking. For example, we have two female RPs with similar voices and it was difficult for the LPs to distinguish them in the first class.

• The other mechanism is voice-switched videos. An RP's video shows up on computer screens as she speaks. This allows the LPs to associate the videos with the RPs and distinguish which of them is currently speaking. This approach solves the above problem in timer-switched videos. But it does not address the issue of awareness of the RPs before they speak.

• There are many research projects that attempts to add awareness into a collaborative session. Examples include life-sized video screens/walls, gaze detection, eye contact, etc. Although these techniques are extremely useful and solve the above problems, they are expensive and difficult to deploy. This proposal focuses on cheaper solutions that are easier to implement and experiment in settings such as our CSCW class.

• Awareness of RP currently speaking
  Voice-switched videos has proven to be useful in our class. I propose some ways to enhance its functionality. Enlarged videos of each RP should be placed in a fixed window thus a fixed location in the Colab. The border of the enlarged window and the corresponding thumbnail video are highlighted when its occupant is speaking. If the number of RP exceeds the number of such possible locations, then RPs are divided to use timer-switched videos to share one location. For example, LPs in the Colab usually look towards the LiveBoard. The two monitors in the front can accommodate one main vic window and three enlarged windows. Five RPs (A,B,C,D,E) can share the three windows (W1,W2,W3) like this: A,B in W1, C,D in W2, and E in W3. Of course there are smarter ways in doing allocation such as the more talkative RP can occupy a window alone while the quiet RPs share another window.

• Awareness of RP intention to speak
  I also propose that vic be augmented to show an RP's intention to speak before her audio is being sent out. The main idea is to compensate diminished body language and facial expression cues from RPs, so LPs become more aware of them in ways other than looking at the videos. For example, when a RP wants to speak, she pushes a button in vat and this causes her videos (thumbnail and/or enlarged version) to blink. To use the traffic light metaphor, when one RP is speaking his video is highlighted in green. When another RP wants to speak, her video is blinking in red then yellow to denote she has been waiting. My previous proposal suggested to distinguish the kinds of intentions, such as comment, agreement, question, etc. However, I am not sure whether this approach places too much constraints on the RPs and thereby discouraging them to use the new features. If time allows, experiments can be conducted to test out this hypothesis.

• Coordination architecture
  To add these extensions to the MASH conferencing tools, I am using the existing conference bus protocol to send messages between the tools. Part of this project is dedicated to designing a more refined coordination protocol so that conference control extensions can be added easily in the future. For example, currently, an unreliable message can be multicast to tools on other machines (e.g. send A's "I want to speak" message to every vat/vic listening to this class) and a reliable version would be more useful. However, in many cases the message can be forgotten after certain timeout because that comment is probably already out of context.

• Independent Variables
  Mash conferencing tools with and without the added awareness mechanism.
• Dependent Variables
  
  • how often the RPs "jump in" without using the awareness features
  • compare the length of discussion of RPs and LPs
  • qualitative results from user questionnaire. This includes whether the features shows right types of information, introduces disturbance and/or annoyance, provides easy to use interface, and improves collaboration. Also questions that ask about overall value of the features, and solicit suggestions for improvement.
• Participants
  CSCW class members which include graduate students and professors.
• Method
  The CSCW class use the new tools to conduct discussion between RPs and LPs. If time allows, reiterate this process with new changes.
• Results and Discussion
  I predict that with the awareness features, LPs will become more aware of RPs and their intentions to speak. As a result, the class discussion will be more fluid in nature.

• Design of general awareness (GA) features (B-)
• Design of intention awareness (IA) features (B)
• Implementation of GA (B+)
• Implementation of IA (A-)
• Testing (A)
• Rounds of testing and implementation (A+)