Re: [vmeet] Supporting interim meetings

John Leslie <john@jlc.net> Wed, 13 May 2009 02:55 UTC

Return-Path: <john@jlc.net>
X-Original-To: vmeet@core3.amsl.com
Delivered-To: vmeet@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FE503A68E4 for <vmeet@core3.amsl.com>; Tue, 12 May 2009 19:55:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.879
X-Spam-Level:
X-Spam-Status: No, score=-5.879 tagged_above=-999 required=5 tests=[AWL=0.720, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thJihozRrTBf for <vmeet@core3.amsl.com>; Tue, 12 May 2009 19:55:22 -0700 (PDT)
Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 7A5AB3A689D for <vmeet@ietf.org>; Tue, 12 May 2009 19:55:20 -0700 (PDT)
Received: by mailhost.jlc.net (Postfix, from userid 104) id 1B20933C37; Tue, 12 May 2009 22:56:53 -0400 (EDT)
Date: Tue, 12 May 2009 22:56:53 -0400
From: John Leslie <john@jlc.net>
To: Thomas Narten <narten@us.ibm.com>
Message-ID: <20090513025653.GD14375@verdi>
References: <20090507175356.GG32848@verdi> <4A08BC3C.9070302@dcrocker.net> <200905121242.n4CCgnj4013481@cichlid.raleigh.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <200905121242.n4CCgnj4013481@cichlid.raleigh.ibm.com>
User-Agent: Mutt/1.4.1i
Cc: dcrocker@bbiw.net, vmeet@ietf.org
Subject: Re: [vmeet] Supporting interim meetings
X-BeenThere: vmeet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF remote participation meeting services discussion <vmeet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/vmeet>, <mailto:vmeet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vmeet>
List-Post: <mailto:vmeet@ietf.org>
List-Help: <mailto:vmeet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vmeet>, <mailto:vmeet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 May 2009 02:55:23 -0000

Thomas Narten <narten@us.ibm.com> wrote:
> Dave CROCKER <dhc@dcrocker.net> writes:
> 
>> ... an interim meeting could require good Internet access for
>> participants and, therefore, limit voice to VOIP.  But content
>> display and meeting management tools probably become more important.
> 
> Actually, I don't agree with this (necessarily). The absolute
> requirements to participate in an interim meeting are more
> modest. Think about the critical things:
> 
>  - audio bridge (could be VoIP, or POTS, that is a detail)
>  - access to charts
>  - IM capability as a side channel

   We have been running virtual meetings with that much for some time
now, any many folks are used to it. By human nature, if we provide a
tool that folks aren't used to, they'll gravitate back to _that_ model
they're used to.

   So, while I support Dave's call for more than that, we can't just
make a list -- we need to explain _why_ each feature we recommend is
a significant improvement over bare-bones.

> The above would in practice cover 90% of what WGs really do in
> practice during interim meetings.

   Indeed -- by definition...

> You do not need "good" Internet access for IM. Just good enough.

   Nonetheless, we've all seen cases where "good enough" wasn't
available. (Last week's IESG telechat comes to mind...)

> (You presumably need a lot better connectivity for whiteboards, etc.)

   It depends...

> Sure, there are other nice-to-haves, but I think most of those are not
> requirements in the vast majority of cases.

   "Nice-to-have" is really a shorthand for "things that help sometimes".

>> Based on this view -- and folks are encouraged to comment -- I think
>> that a good near-term goal is to try to find a tool to enable easy,
>> virtual interim meetings.
> 
> Don't underestimate the power of
> 1) a phone bridge and
> 2) advance availability of charts,
> 3) best practices about how do teleconferences (e.g., when changing
> slides, telling everyone which slide you are on).

   1) Right now, a phone bridge is essentially state-of-the-art for
audio. Most everything else flunks Brian's 150 msec test.

   2) Advance availability of charts is egregiously poorly enforced.
Where it is enforced it leads to charts which only exist in the
presenter's imagination. Preparation of slides is the best exercise
for most presenters to organize their thoughts -- and, alas, the
last minute is when it, almost by definition, happens.

   3) Best Practices simply don't get followed, unless somebody is
constantly nagging.

> I suspect that many of us have lots of experience with the above.

   ... but with the reality, not the ideal...

>>> MG-C:  Individual virtual session, small scale (30?)
> 
>> Henning offered these items in response:
> 
>>> - Ability to render PowerPoint and PDF MUST, OpenOffice SHOULD.
>>> - For audio, allow VoIP and PSTN dial-in (800# is MAY).
>>> - Ability to mute remote participants (e.g., to deal with someone's
>>>   music-on-hold system)
>>> - Audio recording
> 
> I might add IM for a back-channel. This is good for things like: "I
> want to speak now", asking short questions (clearly), telling people
> which chart we are on, etc.

   Absolutely!

>> I think we could get away with a relatively modest initial
>> requirement.  Say, 30 people?  That will limit applicability for the
>> larger and more active working groups.
>... 
> 
> Careful about predicting future participation based on the past,
> especially if travel issues are now motivating more to stay at home.

   Agreed; but it's a reasonable starting point...

>> 1.  Meeting management -
> 
>>      a)  Ability to queue up participants, as if at a microphone
>>          For meetings of a group that can easily be 20-40 people,
>> with relatively little history of group collaboration, the job of
>> meeting management is vastly easier when there is some functional
>> help for coordinating who wants to speak next.
> 
> It may also be necessary for basic fairness. Folk can get mighty
> unhappy if it seems to them that they are being treated as second
> class citizens in the microphone queue relative to others.

   I regard this as very important; but I'm not happy with any
automated functions I've seen in a telepresence package. A simple
plaintext list of folks who have asked to speak (and not given up
their place or spoken) is what all participants should have.

   I consider this important enough that someone should have the role
of maintaining it if we can't get it automated.

>>      b)  Ability to shift who is presenting
> 
> While I agree this is necessary, I am not sure that we require tools
> to support this. Charts in advance work pretty well in practice. But
> not at the expense of limiting participation if the bandwidth
> requirements are too high.

   It is a weakness of many of the available tools that they expect
every participant to have the same available bandwidth. This simply
isn't the world we live in. Anyone without sufficient bandwidth to
support a real-time display should be able to turn that bandwidth
demand off.

   As a general rule, we shouldn't be designing for the lowest
(bandwidth) common denominator.

>> 3.  Shared slide presentation
> 
>>      Shipping powerpoint files around is tolerable only for special
>> cases, I believe.
> 
> I disagree. I think shipping charts around in advance has benefits
> too.

   When they actually _get_ shipped, I agree.

> Doing everythig at the very last second (especially for a meeting
> that is schedule far out in advance) does not necessarily result in
> good meetings and/or good presentations. And it can actually be quite
> useful to skim a presentation in advance before a talk begins.

   But last-minute changes, even changes _during_ the presentation
are the nature of the beast. I agree with Dave.
   
> And I believe that in most cases, we are taking about presenting
> static charts, not whiteboard sessions.

   When a presenter has to face and "connect with" an audience, any
whiteboard-style action is too difficult for most of us. In a virtual
meeting, the tradeoffs are very different; and whiteboard actions
are a very good substitute for the waving hands. ;^)

>> Since we are talking about broad-based, regular use, we should make
>> presenting slides as comfortable as it is in a room.  A major
>> benefit of integrated slide presentation and control is that there
>> is then no need to worry about people's knowing what slide is
>> showing.
> 
> We should strive to make it easier to follow a presentation without
> the requirement for such tools, since they don't help when playing
> back an audio recording...

   Playing back an audio recording is not the normal case. We should
design for the normal case.

>> 4.  Shared white board
>>      My gut says that this really is an extremely useful feature for
>> many meetings.  And since it's available in a number of products, it
>> seems to make sense that we require it.
> 
> Useful, but not necessary in the vast majority of WG sessions I've
> attended.

   Not _used_ -- while this makes it "not necessary" by definition,
it says little about how useful it could be.

   I don't mean to belittle Thomas (were I even capable of doing so),
but we need to escape the "We've always done it this way" mindset.

====

   My own concerns:

1) Participants need to figure out who's speaking. There are many ways
   to help them, but it deserves to be high among our concerns.

2) Snapshots of slides and/or whiteboards can help keep folks on the
   same page. Things change during meetings, and it's very easy for
   human memories to diverge.

3) There really should be a "record" of a meeting. This is, admittedly,
   an art form; but folks don't want to listen to an audio recording
   or even read a transcript of every word spoken. It very likely would
   be helpful if such a record could be visible in real-time to some
   participants. (I don't claim to be particularly good at doing this,
   but there _are_ folks who are good at it.)

4) Every meeting should create "action items" that someone is responsible
   for following-up on. (Some are group items; some private.) These
   deserve far more visibility than they usually get.

5) Separate applications is very likely better than one integrated
   application. Webex drives me crazy by taking over organization of
   the screen. I don't want anything else interacting with my Jabber
   application.

6) VoIP-as-we-know-it doesn't meld well with POTS conferencing. Until
   VoIP can have consistent delay -- ideally Brian's 150 msec, but
   definitely under 500 msec -- we'll probably have to do without it.

7) Learning curve is way too high for most telepresence packages.
   Folks simply _won't_ learn how to use them effectively. Formal
   training / learning / practicing sessions are essential. With
   enough of them, we can get perhaps ten percent of participants
   fluent enough to _use_ their features. (Much less than that, the
   features will atrophy for lack of use.)

--
John Leslie <john@jlc.net>