Subject: [vmeet] FRAMEWORK: users

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 17 Apr 2009 10:25:32 -0600

Who are the users of the technologies we're discussing?

I see three classes of users at any given IETF WG session:

1. Those who are assiduously typing away at their computers, checking
email, [micro]blogging, watching online videos, updating their social
networking pages, etc. Once in a while these people look up and pay
attention. They might hum or raise their hands during a call for
consensus, but perhaps only out of habit or a kind of sympathetic
vibration. They are being paid to monitor what's happening at the IETF,
but only in the most charitable sense can they be called participants.
Let's call them "monitors". I'd say 80% of the attendees are monitors.

2. Those who are paying attention most of the time but who never come up
to the mic. They might be in the chat room as a back channel during the
session, but not much else. They might review I-Ds and even post to the
lists once in a while, so we like them, but they're not deeply active.
Let's call them "participants". I'd say they are 15% of the attendees.

3. Those who are actively involved in the conversation. These folks make
presentations, come up to the mic, etc. Let's call them "contributors".
I'd say 5% of the attendees are contributors.

(Naturally, someone who is a monitor at one WG session might be a
participant or a contributor at another session.)

So: are we designing these vMeet systems for monitors, participants, or
contributors?

IMHO monitors could review transcripts, archives, minutes, and other
artifacts after the meeting without harm. They aren't really part of the
real-time interaction in the first place, so why put a lot of effort
into designing vMeet systems for them?

By contrast, participants and contributors matter. These are the folks
who get the work done, who are part of the conversation within a WG.
IMHO we need to figure out what use cases these folks need to complete,
then make sure that we support those use cases in our vMeet systems.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 17 Apr 2009 12:45:39 -0400

I agree with this analysis.  We can quibble with the percentages.

The current audio broadcast plus the current meeting materials archive and notes are sufficient for monitors.

For participants I think we need:
1. Live broadcast of presentation (WebEx and other tools ought to work quite well for this)
2. More consistent mic behavior.  I'm as guilty as anyone else; if you try to listen to the audio feed, you know we aren't very good at it.

If you had a good, consistent audio feed, and you could see the presentations, then you should be able to get as much as anyone else in the room that doesn't go to the mic.

I think if you want to be a contributor, you need 
1) good two way audio.  I've defined that, and I'm sticking to my experience with what that means: low delay, ideally wideband, no echo.  
2) A way to effectively queue for the floor

I wouldn't mess with any video until we got the audio and presentation materials down pat.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Saint-Andre
Sent: Friday, April 17, 2009 12:26 PM
To: [email-masked]
Subject: [vmeet] FRAMEWORK: users

1. Those who are assiduously typing away at their computers, checking email, [micro]blogging, watching online videos, updating their social networking pages, etc. Once in a while these people look up and pay attention. They might hum or raise their hands during a call for consensus, but perhaps only out of habit or a kind of sympathetic vibration. They are being paid to monitor what's happening at the IETF, but only in the most charitable sense can they be called participants.
Let's call them "monitors". I'd say 80% of the attendees are monitors.

2. Those who are paying attention most of the time but who never come up to the mic. They might be in the chat room as a back channel during the session, but not much else. They might review I-Ds and even post to the lists once in a while, so we like them, but they're not deeply active.
Let's call them "participants". I'd say they are 15% of the attendees.

3. Those who are actively involved in the conversation. These folks make presentations, come up to the mic, etc. Let's call them "contributors".
I'd say 5% of the attendees are contributors.

(Naturally, someone who is a monitor at one WG session might be a participant or a contributor at another session.)

So: are we designing these vMeet systems for monitors, participants, or contributors?

IMHO monitors could review transcripts, archives, minutes, and other artifacts after the meeting without harm. They aren't really part of the real-time interaction in the first place, so why put a lot of effort into designing vMeet systems for them?

By contrast, participants and contributors matter. These are the folks who get the work done, who are part of the conversation within a WG.
IMHO we need to figure out what use cases these folks need to complete, then make sure that we support those use cases in our vMeet systems.

Peter

--
Peter Saint-Andre
https://stpeter.im/

---

From: "Scott Lawrence" <[email-masked]>
Date: Tue, 21 Apr 2009 19:27:50 -0400

> I wouldn't mess with any video until we got the audio and presentation materials down pat.

I'd add one thing to the above that's worked very well for me in the
past:

- a text channel that is actively used by the chair and/or discussion
leader to present changes and/or accept them from participants.

Used properly, the current jabber room or the text chat side channels
used in many remote presentation tools would be more than adequate from
a technology perspective.  By properly, I mean:

      * Any time a question is to be answered by meeting participants,
        it should be typed into the text channel, and that display
        should be visible on the projector.

I've noticed an amazing amount of time wasted in the in-person meetings
in which many people present in the room and apparently paying attention
verbally disagree about what a particular show of hands or hum was
really about.  In my experience this is much less common if you force
the display of written text before asking a question, and would
incidentally be much much easier for a remote participant to follow.  (I
suspect this is because people process visual text differently than
language that's heard)

---

From: Doug Otis <[email-masked]>
Date: Wed, 22 Apr 2009 09:29:01 -0700

On Apr 21, 2009, at 4:27 PM, Scott Lawrence wrote:

> I've noticed an amazing amount of time wasted in the in-person  
> meetings in which many people present in the room and apparently  
> paying attention verbally disagree about what a particular show of  
> hands or hum was
> really about.  In my experience this is much less common if you  
> force the display of written text before asking a question, and  
> would incidentally be much much easier for a remote participant to  
> follow.  (I suspect this is because people process visual text  
> differently than language that's heard)

Both WebEx and Adobe Connect offer a polling feature.  It would appear  
Adobe Connect is a bit more limited with respect to remote audio  
input, and requires Windows 2003 servers to establish the service.

-Doug