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>
- [vmeet] Duties of WG Chairs John Leslie
- [vmeet] Supporting interim meetings (was Re: Duti… Dave CROCKER
- Re: [vmeet] Supporting interim meetings (was Re: … Thomas Narten
- Re: [vmeet] Supporting interim meetings John Leslie
- Re: [vmeet] Supporting interim meetings (was Re: … Dave Cridland
- [vmeet] The philosophy behind the list of recomme… Dave CROCKER
- Re: [vmeet] Supporting interim meetings Dave CROCKER
- Re: [vmeet] Supporting interim meetings Brian Rosen
- Re: [vmeet] Supporting interim meetings Dave CROCKER
- Re: [vmeet] Supporting interim meetings John Leslie
- [vmeet] timeframe Dave CROCKER
- Re: [vmeet] timeframe John Leslie
- Re: [vmeet] timeframe Doug Otis
- Re: [vmeet] timeframe Dave Cridland
- Re: [vmeet] timeframe Brian Rosen
- Re: [vmeet] Supporting interim meetings Thomas Narten
- Re: [vmeet] Supporting interim meetings Doug Otis
- Re: [vmeet] Supporting interim meetings Peter Saint-Andre
- Re: [vmeet] Supporting interim meetings Doug Otis