Having consulted with UX and Product, we've decided to try to turn the microphone and camera buttons into global mute toggles.
There are a few reasons for this:
The current indicator and behaviour on Linux and Windows is unintuitive. The icons, when clicked, send you to the most recent window and tab that has streams being shared, and then opens the permissions panel just for that tab. This is a really bizarre context transition, to go from global state, to individual tab state. It's also somewhat redundant - we're forwarding the user from one indicator of state, to another indicator of state (albeit one with the ability to revoke the permissions for that state).
We believe that global mute of camera and microphone is just generally more useful as a way for users to have control over what they're sharing over WebRTC.
Consider a use case where I am working from home, and am both in a video conference, and also recording something in a separate tab using the microphone. Suppose one of my children comes in with a question, and I don't want my colleagues nor my recording to hear our conversation. I have a few options: if I'm lucky enough to have a microphone with a hardware mute switch, I could use that. Or I could go into each individual application and mute myself. The first is not guaranteed (I don't think hardware microphone or camera cutoffs are typical), and the second is very awkward. A global mute control like this allows me to stop all audio going out to any and all applications simultaneously, and then resume them when I'm ready to get back to work.
We're hard pressed to think of a similar use case of the current implementation that's as compelling. Sending users into a permission panel to do the revocation of a permission when they want to quickly mute seems like a sub par experience. Unmuting is similarly awkward, as now the user has to go through the flow of re-granting permissions for a particular device. Moreover, revoking the permissions is even known to cause some applications to stop working altogether. Talky.io, for example, breaks if you revoke the camera permission, forcing the user to reload the page to resume a video conference.
We believe we're solving a real problem here by giving users a quick, easy, immediate and smooth way to mute and unmute their cameras and microphones, without having to go through the ins, outs and quirks of whatever web applications they're dealing with. From a privacy and user control perspective, this seems generally like just the right thing to do.
As I've gathered, there are a few concerns here with the idea of a global mute, which I will now attempt to address:
- Pre-existing muscle memory, and the loss of finding tabs being shared
There are users that are used to the old pattern of clicking on the indicator to take them to a tab that they're sharing from. The proposed design no longer has a flow for this. We hypothesize that the number of users who have so many tabs that they've lost track of which ones they're sharing streams over, is small. We believe we are serving the interests of more users with the simpler and more intuitive global mutes.
- Users being confused by multiple layers of mute
We actually believe this is something most of our users can understand, and won't be confused by. Presuming the indicator hasn't been minimized or moved offscreen by the user, we expect that the "mute" state of the indicator will make it clear when a global mute is applied. We expect that the "always-on-top" nature of the indicator will reinforce the notion that the state being displayed is global, and not tab-specific. The scenario that jib brings up in comment 11, at step 3, we expect the user is aware that they've shared some devices because they will have gone through the permission dialog. We expect the user to understand that the global indicator applies to the new tab as well.
jib brings up a really interesting scenario in bug 1654916 comment 9 - the idea that sites across different domains that a user is sharing streams over can collaborate to identify a user by comparing times of mute events firing. There are probably a number of ways of working around this. The one that comes to mind immediately for me, is only immediately firing mute events from the global mute on tabs that are in the foreground. Tabs in the background should then get their mute events fired either after some random amount of time, or perhaps only when the user foregrounds the background tab. That's just off the top of my head - certainly, however, I believe this fingerprinting vector can be noised enough to no longer be an issue.
Having evaluated these concerns, we're still confident that the global mute control is the right path. If there are more concerns that I've failed to mention, please bring them up.