Continuity of Operations >> Raising hands

[brewerj]

"Hand-raising will be supported exclusively via irc. Hand-raising features of the teleconference system should be disabled (preferable) or (less preferable) be bridged to irc."

Why?

I've been in multiple meetings where hand-raising within a teleconferencing or videoconferencing app was far more usable and accessible to members of a meeting. Until that improves, we have what we have, and chat within an app may need to be an option, depending on who's present.

[nigelmegitt]

As a Chair or scribe, dealing with multiple ways for people to add themselves to a queue is really tricky. I'd support "one way to do it in any given meeting", and IRC is probably the best way, because the sequence and timing of hand-raising is visible. Another option to consider is to give flexibility to groups to choose their own method of hand raising though.

[brewerj]

Nigel, thanks for giving a rationale for this. Nevertheless, I think we need to encourage flexibility in cases where not everyone can access the controls in the same way.

• Not everyone in every meeting can access IRC regardless of whether they are using a teleconferencing or videoconferencing app.
• In some cases, the hand-raising app control may be more available to a participant once a teleconference or videoconference is in progress, and it may be difficult for someone to swap back and forth from that app to an IRC client to raise their hand. It make take multiple extra strokes or commands.
• In some videoconferencing platforms, the hand-raising feature may not be accessible.

If it is difficult for the Chair or the scribe to follow two modes of queuing, they can enlist someone's help in watching the queue in one or more environments. I've been on calls with five modes of queuing -- IRC, within-app, participant real hand-raising in a video-window, interpreter signaling in a video window, and voice queuing. It worked reasonably smoothly and I trust will get more so as people get more experienced at that.

+1 to posing the consideration to groups, but then giving them flexibility on how they achieve it.

IMO it is most useful to draw attention in this Guide to the issues to consider -- e.g., "Let's confirm that everyone has ways that work well to queue themselves" -- and least useful to dictate a single mode for all groups.

And if it turns out that a single approach for queuing works just as well for all, great.

[nigelmegitt]

I am now wanting a Model-View-Controller style API for queue management (a new W3C Rec, anyone, maybe part of RTC?!) that can be used to integrate the queue management techniques from multiple systems.

[swickr]

I'm fine with giving some discretion to group chairs to choose queue management mechanisms that work best for all participants. If the chair is willing to watch multiple queues or if another participant is willing to help the chair watch multiple queues without substantively detracting from that participant's ability to participate in the discussion, we should not object.

But I want to give chairs some basis for declining what might otherwise be simple personal preferences on where to "q+".

Note that December 2019 enhancements to Zakim provide greater information to the chair to allow them to acknowledge the queue in some order other than first in, first out. Simple 'hand-up' buttons in teleconference systems often don't even display the order of hand raising let alone provide the raiser an opportunity to note why they wish to speak.

[swickr]

Note also that the sentence cited is specific to the AC meeting. We can, and IMHO should, expect that AC Reps become accustomed to our style of using irc.

[brewerj]

Nigel, one of the issues that came up in RQTF discussion this morning of videoconferencing accessibility was the need for greater interoperability when one has a videoconferencing system running, potentially with various assistive technologies as well, since some of the videoconferencing platforms play poorly with other apps that need to run in parallel. So, not sure if your suggestion was tongue-in-cheek, but an API for cross-platform queue integration might indeed be useful, though I suspect challenging.

[brewerj]

Ralph, do we have confirmation that there are accessible IRC clients on all platforms at this time? Last I heard there were exceptions, though that could be out of date. Unless you can confirm that, then we need to check before W3C bans use of other means of queuing during the AC meeting.

[nigelmegitt]

not sure if your suggestion was tongue-in-cheek

Only partially - I genuinely think it could be a good idea, but I doubt I have enough domain knowledge to define such a thing and I certainly don't have the effort available to do any significant work on it.

So I was throwing it out there a) to put it in the public domain and b) in case anyone who can work on it and agrees it's a good idea wants to pick it up and run with it. I half wondered if it could be a thing for W3 "geek week".

[nigelmegitt]

Also @brewerj as you suggested, by creating an API then in principle it could be easier for folk to write accessible clients for it.

Of course all clients should be written to be accessible, but feasibly there might be accessibility use cases that require a different paradigm of UX - I'm vaguely wondering about switch controls for example, without having thought much about the details.

[brewerj]

+1 to putting the API idea out there @nigelmegitt

I think we need accessibility integrated into all clients though. We've been collecting some feedback on that, all the needs seem doable within any tele/videoconferencing, and it's good to be able to be in the same space/ on the same platforms.

[brewerj]

Much better, thanks