As an experiment in community design, I propose that we together try to solve a well known problem in Zoom’s design. If this is fun and works well, we can look at other design challenges too. It’d be great to have a forum where people can bring design problems and have a community of designers suggest possible solutions.
The problem: People in a meeting raise their (virtual) hands to request to talk, and when their turn comes, they unmute themselves but often forget to lower their hands again. The host, on later spotting the hand still raised, has to ask: is that from before, or a new request to speak?
What do you propose? I suggest some ideas of my own in a recent post.
Hello! This is really interesting, and the post is very thought-provoking. The problems you present about Zoom are tricky. I like the idea of “tightening” the concepts in Zoom so that mute and raisehand are synchronised. I wonder if in order to solve the problem of losing your place in the queue to speak if you accidentally unmute could be solved with a pop up asking “have you been called on?” (or something better worded) when a user re-mutes after they speak when their hand was raised. This might be a bit clunky, but would allow users to preserve their place if they didn’t intend to unmute.
One simple answer: if you unmute while your hand is up, zoom offers to take it down for you.
Second, more complex: The host/moderator knows who they want to call on. They should be able to click-to-select, then an unmute/hands-down happens. Could also have a query to the hand-raiser after the host selects, asking “ready to go now?”, at which point a “y” makes the unmute/hands-down happen. Yes, have to be host to do this, but if someone else is to run a discussion, host can make them co-host ()temporarily).
@swconcepts, in response to your first suggestion: another possibility is to prompt not when the speaker unmutes, but when they mute again. That way (a) they wouldn’t be interrupted when about to speak, and (b) the ordering in grid view (in which I think raised hands are promoted to the front) would not change until the speaker is finished with their contribution.
Interesting problem. From a conceptual point of view perhaps it would be useful to see if the concept of “hand raised” can be linked to another concept already present in Zoom?
Zoom already has a concept of the “current speaker”, used to shift the camera view to that person in the Speaker view, activating the microphone icon level meter, among other things, I assume by audio amplitude detection on that person’s audio channel.
This can become confusing when multiple people speak, or a conversation happens relatively quickly, so perhaps a percentage of time used since raising a hand could be used.
In the case that someone has their hand raised and unmutes to speak, start a timer, and for a percentage of that time to be defined via testing the app removes the hand and posts a notification explaining what it has done. “Since you were speaking your hand has been lowered, please raise again if required.”
If the user has been speaking, but for some reason not on the topic they raised their hand for, they have to raise their hand again manually. This doesn’t seem too onerous, but if the host relies on ordering to work as a queue this could be a poor experience for them, as they would end up at the back of the queue.
Hi Andrew, Welcome to the forum! Yes, I think a synchronization between RaisedHand and other Zoom concepts is needed – or, as I mentioned in my post, and others have suggested, a new Moderation concept. Amused to see that since we started this discussion Zoom has modified the UI to address this issue: when you raise your hand, a “lower hand” button pops up (see screenshot) and remains visible. But in meetings I’ve had so far with this new feature, it doesn’t seem to change people’s behavior and they still forget to lower their hands. In a meeting I was in last night, the moderator kept manually lowering people’s hands for them, which was tricky and in some cases he lowered a hand before the person spoke.