From nobody Fri Jul 30 14:03:09 2021 Return-Path: X-Original-To: 111attendees@ietfa.amsl.com Delivered-To: 111attendees@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9CBF3A10CA; Fri, 30 Jul 2021 14:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.797 X-Spam-Level: X-Spam-Status: No, score=-2.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=uHuU4FvS; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=LNOwmCI1 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olITmiEtKksO; Fri, 30 Jul 2021 14:02:54 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6756A3A10B3; Fri, 30 Jul 2021 14:02:54 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 1846D32008FD; Fri, 30 Jul 2021 17:02:52 -0400 (EDT) Received: from imap43 ([10.202.2.93]) by compute6.internal (MEProxy); Fri, 30 Jul 2021 17:02:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:cc:subject:content-type; s=fm3; bh=z5y4 0kXlg+VVCWNEmhjEL86KBeX2mk4I477m8YJ5jsI=; b=uHuU4FvSCJLPQlsWf/l/ npk0R4GjVNmI4B2baZkEasYEYNZh36kUzOdMYxO8Uvs+liaLhGrRVXt5l/HXylhP BIORBzeoAl0znkpZM3tPfNSq69BEk70KfJD2PFPg8U11WYtVdVI+n5fI7+8JdZt5 SvnGM6UPoR1LXPQ8TFsFVqdfxlyHlSPU1B1uHTWJyf89x/Ddxn+v5NsdMj9qdct9 iffxPfRXebZvfNuI1MqVe3cJEe/UupMtaMAJl7iJXaqSMOYmIo6BggIdJ8QSJhXX zz0rglX2I5Oyh0iWEXAXKLma7V6rqYFjRf5goZgFvHM01Q4TDIUTwRjJgSqb8tJs Cg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=z5y40k Xlg+VVCWNEmhjEL86KBeX2mk4I477m8YJ5jsI=; b=LNOwmCI1jzV3OnlfvH+de/ n88AJRtXmRN1nDRNZxOdJk8Il7+A5VNY/eFf5l+P/JunJpdLdSlVQm5uoBmJ8JFN tU7D5LjCHOE2qO7+pJKLAFnhIgRo79crDVC7+GmpnXu8QIV8kk6z0yLT13qWRAl8 2hkHRFS03ihQOPokmfnjRV1gu1xrPAGX/c28t3nODHjkE1kAwP6kCjgo/vuSInN+ GSAgqRj9AU6ugh1IeKeq1tvBWAA6xh1W3fI5X1bJf1/sWE5+gdRDn8cnGVDSQ0A4 om/i+OQNrXHTdnxBS20ViiI8rR0+9BYqnpVJekOYZVZiwDx+i6Wu9VP16yX6QBeg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrheehgddugeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerreejnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeffvdekfeegle eiueettddtffehveevffefkeduvddttdekiefgjeduvdfhvdduleenucffohhmrghinhep ihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2A3F3AC0DD0; Fri, 30 Jul 2021 17:02:51 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1002-g563fbe43fc-fm-ubox-20210727.001-g563fbe43 Mime-Version: 1.0 Message-Id: <99ae28be-dd15-4018-bccc-a1f61ce19e47@dogfood.fastmail.com> In-Reply-To: <4268651f-6bd7-10ce-6ed8-a758bd956062@meetecho.com> References: <4268651f-6bd7-10ce-6ed8-a758bd956062@meetecho.com> Date: Sat, 31 Jul 2021 07:02:19 +1000 From: "Bron Gondwana" To: 111attendees@ietf.org Cc: tools-discuss@ietf.org Content-Type: multipart/alternative; boundary=6dbf78494a87456c8b6f6dbe44fec6f6 Archived-At: Subject: Re: [111attendees] =?utf-8?q?Positive_observations_and_proposals_for?= =?utf-8?q?_improvements_to_Meetecho_=28was=3A_Re=3A_Re=3A_So=2C_what_are_?= =?utf-8?q?jabber_scribes_actually_doing=2C_these_days=3F=29?= X-BeenThere: 111attendees@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mailing list for IETF 111 attendees <111attendees.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2021 21:03:04 -0000 --6dbf78494a87456c8b6f6dbe44fec6f6 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Ooh, we're going a full "suggestions for meetecho" thread? I'd like to = propose some things! *that we replace the current "raise hands" tool:* *... *which is based on an expired draft which isn't going to be refresh= ed - with a better tool that allows the chairs to: a) label each option b) have more than 2 options (max 9 maybe) c) select between "choose one" and "choose N" modes (checkbox vs radio b= utton) ... and which appears IN PLACE of the slides when enabled, so that meeti= ng participants don't have to navigate to a separate tab to interact.=20 More generally, it's too easy for some participants to be lost on differ= ent tabs where they can't see the slides. The multiple views where you = can see individual talking heads in more detail are not actually valuabl= e I don't think - if slides are showing they should be the bulk of the s= creen because they need to be read - and if a poll is showing then for s= ure it should be taking over the screen. *a "temporary mute" mode that keeps the audio stream open:* This is still an issue for me. I often mute myself while chairing so I = can take notes without my keyboard sound interrupting the chat - but it = means that I can't easily respond to somebody because the rejigging of t= he audio channel not only creates a hiccup in the incoming audio feed wh= ich means I might miss something someone says, but it also creates enoug= h of a delay that by the time I could have responded the other party's m= ental state has moved on. Timing is really important in conversation and we're already fighting wi= th the quarter second delay imposed by the size of the planet. Addition= al delay makes it unwieldy. *allow multiple connections by the same person to the same session:* I have multiple times wanted to switch device temporarily - from my desk= top computer to a phone / ipad so I can temporarily move to another loca= tion while continuing to follow a meeting. Multiple connection support = would mean I could switch over without a break. Sure it could be abused by people "sharing" a login, but that would be p= retty obvious if both parties tried to participate, and given that we al= low fee waivers anyway, it's unlikely to be abused significantly. Sure = there are Jabber naming issues, but we can avoid that by giving each jab= ber name with a serial number (which I believe already happens now?) ... I've already written these up separately in the past, but: *information about who is speaking in the same place as video feeds* See my previous email :) Basically the "participant list" should just b= e an ordered list of participants and only needs to be switched to when = seeing who is in the call or opening an individual message to them (and = people don't get moved out of order when they're sending something). Th= e "who is sending something" list should be all together with the video,= and chairs pinned even if they're sending nothing right now. Along with visual indicators of "currently sending audio" on people so w= e know who of those with their audio channel open are currently speaking= , this makes it easier to look in one place to see the source of all sou= nd, and eyes can generally flit between the right hand side (video and a= udio indicators) and the slides, without needing to also track via the p= articipant list. *flexible "assign chair"**:* This one hasn't come up in practice, but the chairs for meetings are pre= -assigned from datatracker. It would be great for ADs and the meetecho = reps in each meeting to be able to upgrade anybody to a chair role or re= move a chair role with a simple click. In real rooms, anyone can go sit in the chair at the front of the room, = and it's not abused because of social convention. I believe that we can= map that to this virtual space and still have it work sensibly. People= won't take the chair unless there's a legitimate reason to do it, and s= o long as it's logged - if someone does consistently abuse it we have pr= ocesses to eject them from the IETF for misbehaviour. This has become less important with the ability for individuals to turn = on both audio and video themselves, so the chair is going less busywork = just approving access, but it would be good to make it possible for some= one else to step into the chair if the regular chairs are unable to atte= nd or lose network, rather than making the meeting less able to run. Bron. On Sat, Jul 31, 2021, at 05:38, Meetecho IETF support wrote: > All, >=20 > chiming in just to say that we at Meetecho appreciate and value your=20 > feedback. We'll definitely take it into account when developing the=20 > future releases of the platform. We'll provide comments on the points=20 > raised as soon as we get the chance to parse them, i.e., when the=20 > meeting is over. >=20 > Also, I'm cc'ing tools-discuss@ietf.org and setting the reply-to heade= r=20 > to that list as well, as that's the right place to discuss enhancement= s=20 > and provide feedback that would be easier for us to collect. >=20 > Best, > Alessandro >=20 > Il 30/07/21 19:37, Spencer Dawkins at IETF ha scritto: > > I should have changed the Subject a LONG time ago! But this thread h= as=20 > > morphed into helpful observations and suggestions, so, if I might ad= d a=20 > > couple of things ... > >=20 > > I agree that Meetecho has been improving (and just for fun, the Meet= echo=20 > > guys were participants in the MEDIACTL session I was co-chairing in=20 > > Hiroshima at IETF 76 in November 2009, and they roped in a team memb= er=20 > > from Italy during the discussion using whatever the toolset was back=20 > > then, so many of you have no idea how MUCH they've improved =F0=9F=98= =80). > >=20 > > I see that we've already mentioned detaching the chat window, and=20 > > usually I remember that we can detach the chat by Tuesday of each IE= TF=20 > > meeting week at the latest, which is almost certainly a result of no= t=20 > > having THAT much experience with Meetecho during the four months bet= ween=20 > > meetings. Now that we can use Meetecho for interim meetings, that wi= ll=20 > > help me remember more clearly, so good there, too. > >=20 > > The one thing I've noticed this week is how difficult it is to figur= e=20 > > out who is speaking if they aren't sending video, and there's a long=20 > > list of people in the queue. The suggestion to move the speakers abo= ve=20 > > the queue would improve that, and so would simply displaying the act= ive=20 > > speaker names in the screen space where their video would have gone,= if=20 > > the person had been sending video.One reason that matters, is that i= t's=20 > > helpful for everyone to get the speaker's name right in the minutes.=20 > > That's not just for new attendees, I'm starting to forget what peopl= e=20 > > sound like, unless I'm talking to them regularly, or they have a ver= y=20 > > distinctive speech pattern, so I've definitely depending on seeing n= ames=20 > > when I'm taking minutes. . > >=20 > > The one thing I was thinking about, as I read through this thread, w= as=20 > > that we are kinda *not *talking about what the IETF thinks the targe= t=20 > > audience for our conferencing tool is. > >=20 > > * For probably the last couple of IETFs, I have a GREAT setup for > > remote participation (my laptop screen, plus two 25-inch monitor= s). > > But I do have tiled windows on all three screens. > > * If we think people who can't throw a few hundred dollars at moni= tor > > screens are part of our target audience, that's worth noting. > > * If we think we're going to have hybrid meetings, in at least some > > scenarios, it's going to be good to use Meetecho in the conferen= ce > > rooms (especially if we need to be distancing, so more spread ou= t, > > front to back in the conference rooms). > > * Even if we aren't doing hybrid meetings, I've participated in so= me > > working group meetings from my hotel room, but I wasn't tryng to > > co-chair a meeting, or even to present at a meeting. > > * When Michael Richardson and I talked to the Cellar working group > > participants about switching to Meetecho for our (monthy) interi= ms, > > the first question we got was, "is there an iOS/Adroid client?" I > > haven't checked Meetecho on my phone in years, but I'd bet offha= nd > > that (1) it would work, but (2) it might not be as easy to use as > > some other conferencing systems, on those devices. Do people have > > experience with that? > >=20 > > I'll let you folks continue to share these positive observations and=20 > > proposals. Make Good Choices, of course. > >=20 > > Best, > >=20 > > Spencer > >=20 > > On Thu, Jul 29, 2021 at 6:15 PM Jay Daley > > wrote: > >=20 > > Thanks Bron. Personally I think that=E2=80=99s a great usabilit= y adjustment > > and will forward to the Meetecho team for them to consider. > >=20 > > Jay > >=20 > > > On 30/07/2021, at 10:58 AM, Bron Gondwana > > wrote: > > > > > > On Fri, Jul 30, 2021, at 05:21, Jay Daley wrote: > > >> No we have absolutely not pushed Meetecho into being "just a > > contractor", they are a valued partner and we work very well > > together. If you have any doubts about that then ask them direc= tly. > > >> > > >> It is disappointing that you have escalated a personal conce= rn > > that you have with our services into such a strong criticism when > > that is entirely unsupported by any evidence. > > > > > > Jay, I agree with your sentiment here - this attitude to Meet= echo > > is counterproductive. They've done great work for the last coup= le > > of IETFs and the experience is improving each time. I have > > particularly appreciated the embedded slide management, and I'm = sure > > that will be even better next time too. > > > > > > Regarding the specific interface issues that remain, I do thi= nk > > there's a question of "where do we propose improvements in a way > > that will be noticed"? I've seen the suggestion made very many > > times that the "speaker" area (where the video shows) should have > > additional lines for each person sending anything, rather than t= hat > > information being at the top of the participant list. This is m= uch > > more like the experience with other chat systems, for example Zo= om > > shows either a photo or a blank item for somebody who isn't > > currently sending video, but they're otherwise treated "the same= " as > > a person sending video in terms of real-estate and where to look= for > > their presence by default. > > > > > > Right now with meetecho, my eyes are normally at the video are > > when people are speaking, but if a non-video person is speaking I > > need to look across to the other side of the screen to see the a= udio > > indication. > > > > > > And as was also suggested in this thread, you can't scroll the > > participant list to find someone to chat to, because they jump to > > the top when they are sending, then back to alphabetical positio= n.=20 > > This is also a usability pain. Separating "the list of > > participants" (which wouldn't move about) and "the list of people > > sending something" with the video and audio indications being > > together in one place would be a significant improvement. And a= s an > > additional benefit, when you're looking at the chat window, you > > would still be able to see all the details of who is sending > > (including yourself - if you're sending then the indicator of yo= ur > > own audio should be the same as the indicator of everyone else's > > audio, rather than being in yet a third location up under your o= wn > > name). > > > > > > > > > So those two names would appear in the right hand side, and a= lso > > still have their name in the participant list, and the video fee= ds > > would each have a "here's what's being sent". Chairs would alwa= ys > > have a presence on the right, with whatever they were currently > > sending - and the "participants" tab would only have the list of > > participants, and not be a place you needed to go to see activit= y, > > so you could mostly keep the chat tab open. > > > > > > Bron. > > > > > > > > > -- > > > Bron Gondwana, CEO, Fastmail Pty Ltd > > > brong@fastmailteam.com > > > > > > > > > -- > > > 111attendees mailing list > > > 111attendees@ietf.org > > > https://www.ietf.org/mailman/listinfo/111attendees > > > >=20 > > --=20 > > Jay Daley > > IETF Executive Director > > jay@ietf.org > >=20 > > --=20 > > 111attendees mailing list > > 111attendees@ietf.org > > https://www.ietf.org/mailman/listinfo/111attendees > > > >=20 > >=20 >=20 > --=20 > 111attendees mailing list > 111attendees@ietf.org > https://www.ietf.org/mailman/listinfo/111attendees >=20 -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --6dbf78494a87456c8b6f6dbe44fec6f6 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Ooh, we're going a full "suggestions for meetecho" th= read?  I'd like to propose some things!

that we r= eplace the current "raise hands" tool:

... whi= ch is based on an expired draft which isn't going to be refreshed - with= a better tool that allows the chairs to:

a) label each o= ption
b) have more than 2 opt= ions (max 9 maybe)
c) select = between "choose one" and "choose N" modes (checkbox vs radio button)
=

... and which appears IN PLACE of the slides when enabled, s= o that meeting participants don't have to navigate to a separate tab to = interact. 

More generally, it's too easy for some pa= rticipants to be lost on different tabs where they can't see the slides.=   The multiple views where you can see individual talking heads in = more detail are not actually valuable I don't think - if slides are show= ing they should be the bulk of the screen because they need to be read -= and if a poll is showing then for sure it should be taking over the scr= een.

a "temporary mute" mode that keeps the audio stre= am open:

This is still an issue for me.  I often= mute myself while chairing so I can take notes without my keyboard soun= d interrupting the chat - but it means that I can't easily respond to so= mebody because the rejigging of the audio channel not only creates a hic= cup in the incoming audio feed which means I might miss something someon= e says, but it also creates enough of a delay that by the time I could h= ave responded the other party's mental state has moved on.

Timing is really important in conversation and we're already fighting = with the quarter second delay imposed by the size of the planet.  A= dditional delay makes it unwieldy.

allow multiple conn= ections by the same person to the same session:

I have = multiple times wanted to switch device temporarily - from my desktop com= puter to a phone / ipad so I can temporarily move to another location wh= ile continuing to follow a meeting.  Multiple connection support wo= uld mean I could switch over without a break.

Sure it cou= ld be abused by people "sharing" a login, but that would be pretty obvio= us if both parties tried to participate, and given that we allow fee wai= vers anyway, it's unlikely to be abused significantly.  Sure there = are Jabber naming issues, but we can avoid that by giving each jabber na= me with a serial number (which I believe already happens now?)
=

...

I've already written these up separately in the= past, but:

information about who is speaking in the s= ame place as video feeds
=
See my previous email :)&nbs= p; Basically the "participant list" should just be an ordered list of pa= rticipants and only needs to be switched to when seeing who is in the ca= ll or opening an individual message to them (and people don't get moved = out of order when they're sending something).  The "who is sending = something" list should be all together with the video, and chairs pinned= even if they're sending nothing right now.

Along with vi= sual indicators of "currently sending audio" on people so we know who of= those with their audio channel open are currently speaking, this makes = it easier to look in one place to see the source of all sound, and eyes = can generally flit between the right hand side (video and audio indicato= rs) and the slides, without needing to also track via the participant li= st.

flexible "assign chair":

This one hasn't come up in practice, but the chairs for meetings are pr= e-assigned from datatracker.  It would be great for ADs and the mee= techo reps in each meeting to be able to upgrade anybody to a chair role= or remove a chair role with a simple click.

In real room= s, anyone can go sit in the chair at the front of the room, and it's not= abused because of social convention.  I believe that we can map th= at to this virtual space and still have it work sensibly.  People w= on't take the chair unless there's a legitimate reason to do it, and so = long as it's logged - if someone does consistently abuse it we have proc= esses to eject them from the IETF for misbehaviour.

This ha= s become less important with the ability for individuals to turn on both= audio and video themselves, so the chair is going less busywork just ap= proving access, but it would be good to make it possible for someone els= e to step into the chair if the regular chairs are unable to attend or l= ose network, rather than making the meeting less able to run.
<= div style=3D"font-family:Arial;">
Bron.

On = Sat, Jul 31, 2021, at 05:38, Meetecho IETF support wrote:
All,

chiming in just to say that we at Meetecho appre= ciate and value your 
fe= edback. We'll definitely take it into account when developing the <= br>
future releases of the platfo= rm. We'll provide comments on the points 
raised as soon as we get the chance to parse them, i.e= ., when the 
meeting is = over.

Also, I'm cc'ing tools-discuss@ietf.org and setting the reply-to header&= nbsp;
to that list as well, a= s that's the right place to discuss enhancements 
and provide feedback that would be easier for = us to collect.

Best,
Alessandro

<= div style=3D"font-family:Arial;">Il 30/07/21 19:37, Spencer Dawkins at I= ETF ha scritto:
> I should= have changed the Subject a LONG time ago! But this thread has 
=
> morphed into helpful observ= ations and suggestions, so, if I might add a 
> couple of things ...
> 
= > I agree that Meetecho has been improving (and just for fun, the Mee= techo 
> guys were pa= rticipants in the MEDIACTL session I was co-chairing in 
<= div style=3D"font-family:Arial;">> Hiroshima at IETF 76 in November 2= 009, and they roped in a team member 
> from Italy during the discussion using whatever the t= oolset was back 
> th= en, so many of you have no idea how MUCH they've improved =F0=9F=98= =80).
> 
> I see that we've already mentioned d= etaching the chat window, and 
> usually I remember that we can detach the chat by Tuesday of= each IETF 
> meeting= week at the latest, which is almost certainly a result of not 
=
> having THAT much experience= with Meetecho during the four months between 
> meetings. Now that we can use Meetecho = for interim meetings, that will 
> help me remember more clearly, so good there, too.
> 
> The one thing I've noticed this week is how diffi= cult it is to figure 
&g= t; out who is speaking if they aren't sending video, and there's a long&= nbsp;
> list of people in = the queue. The suggestion to move the speakers above 
> the queue would improve that, and so = would simply displaying the active 
> speaker names in the screen space where their video wou= ld have gone, if 
> t= he person had been sending video.One reason that matters, is that it's&n= bsp;
> helpful for everyon= e to get the speaker's name right in the minutes. 
> That's not just for new attendees, I'm s= tarting to forget what people 
> sound like, unless I'm talking to them regularly, or they ha= ve a very 
> distinct= ive speech pattern, so I've definitely depending on seeing names 
> when I'm taking minutes. = .
> 
> The one thing I was thinking about, as I= read through this thread, was 
> that we are kinda *not *talking about what the IETF thinks = the target 
> audienc= e for our conferencing tool is.
> 
>  = ; * For probably the last couple of IETFs, I have a GREAT setup for
<= /div>
>     remo= te participation (my laptop screen, plus two 25-inch monitors).
>     But I do= have tiled windows on all three screens.
>   * If we think people who can't throw a few= hundred dollars at monitor
&= gt;     screens are part of our target audience, tha= t's worth noting.
> &= nbsp; * If we think we're going to have hybrid meetings, in at least som= e
>    = ; scenarios, it's going to be good to use Meetecho in the conference
=
>     roo= ms (especially if we need to be distancing, so more spread out,
>     front to= back in the conference rooms).
>   * Even if we aren't doing hybrid meetings, I've part= icipated in some
> &n= bsp;   working group meetings from my hotel room, but I wasn't= tryng to
>  &nb= sp;  co-chair a meeting, or even to present at a meeting.
=
>   * When Michael Richar= dson and I talked to the Cellar working group
>     participants about switchi= ng to Meetecho for our (monthy) interims,
>     the first question we got was,= "is there an iOS/Adroid client?" I
>     haven't checked Meetecho on my phone= in years, but I'd bet offhand
>     that (1) it would work, but (2) it might = not be as easy to use as
>=      some other conferencing systems, on those devic= es. Do people have
> =     experience with that?
> 
> I= 'll let you folks continue to share these positive observations and = ;
> proposals. Make Good C= hoices, of course.
> =
> Best,
> 
> Spencer
>&nbs= p;
> On Thu, Jul 29, 2021 = at 6:15 PM Jay Daley <jay@ietf.org 
> 
>     Thanks Bron.  Personally I= think that=E2=80=99s a great usability adjustment
>     and will forward to th= e Meetecho team for them to consider.
> 
> = ;    Jay
>&= nbsp;
>   &= nbsp;  > On 30/07/2021, at 10:58 AM, Bron Gondwana <brong@fastmailteam.com
>     <mailto:brong@fastmailteam.com>&g= t; wrote:
>  &nb= sp;   >
>&nbs= p;     > On Fri, Jul 30, 2021, at 05:21, Jay Dale= y wrote:
>  &nbs= p;   >> No we have absolutely not pushed Meetecho into b= eing "just a
>  =    contractor", they are a valued partner and we work very wel= l
>    = ; together.  If you have any doubts about that then ask them direct= ly.
>   &nb= sp;  >>
> =      >> It is disappointing that you have esca= lated a personal concern
>=      that you have with our services into such a str= ong criticism when
> =     that is entirely unsupported by any evidence.
>      &= gt;
>   &nb= sp;  > Jay, I agree with your sentiment here - this attitude to = Meetecho
>  &nbs= p;  is counterproductive.  They've done great work for the las= t couple
>  &nbs= p;  of IETFs and the experience is improving each time.  I hav= e
>    = ; particularly appreciated the embedded slide management, and I'm sure
>     t= hat will be even better next time too.
>      >
>      > Regarding t= he specific interface issues that remain, I do think
>     there's a question = of "where do we propose improvements in a way
>     that will be noticed"?&nbs= p; I've seen the suggestion made very many
>     times that the "speaker" area= (where the video shows) should have
>     additional lines for each person se= nding anything, rather than that
>     information being at the top of the par= ticipant list.  This is much
>     more like the experience with other ch= at systems, for example Zoom
= >     shows either a photo or a blank item for so= mebody who isn't
> &n= bsp;   currently sending video, but they're otherwise treated = "the same" as
>  = ;   a person sending video in terms of real-estate and where t= o look for
>  &n= bsp;  their presence by default.
>      >
>      > Right now wi= th meetecho, my eyes are normally at the video are
>     when people are speaki= ng, but if a non-video person is speaking I
>     need to look across to the o= ther side of the screen to see the audio
>     indication.
>      >
>      &g= t; And as was also suggested in this thread, you can't scroll the
>     partic= ipant list to find someone to chat to, because they jump to
>     the top when= they are sending, then back to alphabetical position. 
>     This is als= o a usability pain.  Separating "the list of
>     participants" (which w= ouldn't move about) and "the list of people
>     sending something" with the = video and audio indications being
>     together in one place would be a signi= ficant improvement.  And as an
>     additional benefit, when you're look= ing at the chat window, you
&= gt;     would still be able to see all the details o= f who is sending
> &n= bsp;   (including yourself - if you're sending then the indica= tor of your
>  &= nbsp;  own audio should be the same as the indicator of everyone el= se's
>   &n= bsp; audio, rather than being in yet a third location up under your own<= br>
>     = name).
>   =    >
> &= nbsp;    > <image.png>
>      > So those two n= ames would appear in the right hand side, and also
>     still have their name = in the participant list, and the video feeds
>     would each have a "here's w= hat's being sent".  Chairs would always
>     have a presence on the righ= t, with whatever they were currently
>     sending - and the "participants" ta= b would only have the list of
>     participants, and not be a place you neede= d to go to see activity,
>=      so you could mostly keep the chat tab open.
=
>    &nbs= p; >
>   = ;   > Bron.
>=       >
>      >
>      > --
>      >&= nbsp;  Bron Gondwana, CEO, Fastmail Pty Ltd
>      > brong@fastmailteam.com <mailto= :brong@fastmailteam.com>= ;
>    = ;  >
>  =     >
>&= nbsp;     > --
>      > 111attendees mailing li= st
>   &nbs= p;  > 111attendees= @ietf.org <mailto:111att= endees@ietf.org>
>  = ;   <https://www.ietf.org/mailman/listinfo/111attendees>
<= /div>
> 
>     -- 
>     Jay Daley
=
>     IET= F Executive Director
>&nbs= p;    jay@ietf.org <mailto:jay@ietf.org>
> 
>     -- 
>     111attendees m= ailing list
> 
> 

=
-- 
111attendees mailing list


--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com


--6dbf78494a87456c8b6f6dbe44fec6f6--