Open Bug 1004392 Opened 7 years ago Updated 4 months ago

getUserMedia doorhanger is too complicated


(Core :: WebRTC: Audio/Video, defect)

Not set



Blocking Flags:
backlog parking-lot


(Reporter: jib, Unassigned)




(1 file)

I've run our current gUM doorhanger by a couple of "normal" people. TL;DR: TMI.

|                                                     x|
| .----.   Would you like to share your camera and     |
| |    |/| microphone with                             |
| |    |\|                                |
| '----'                                               |
|          Camera to share:                            |
|          .----------------------------------------.  |
|          | FaceTime HD Camera (Built-in)        <>|  |
|          '----------------------------------------'  |
|          Microphone to share:                        |
|          .----------------------------------------.  |
|          | default (Built-in Microphone)        <>|  |
|          '----------------------------------------'  |
|                                                      |
|                      .----------------------------.  |
|                      | Share Selected Devices | V |  |
|                      '----------------------------'  |

Unscientifically gathered feedback (prodded):

- "This is greek to me. Too much to read. I would go elsewhere"
- "Is this FaceTime (the mac video-calling app)?"
- "There's only one choice, so why ask? I've only one camera."
- "I don't think I care about multiple cameras here (yet)"
- On phones: "I think of phone as one camera that I flip the direction of"
- "I don't think about microphones."
- "I understand Allow and Deny" = simple! (on seeing a competitor)

Most disturbing, there was no understanding of what was chrome vs. content.
People had no trouble spotting our prompt though (unlike the competition).

Based on feedback I'd suggest something like this instead:

|                                                     x|
| |    |/|                                             |
| |    |\|                                |
| '----'    wants to use your camera and microphone.   |
|                                                      |
|                                       .-----------.  |
|                                       | Allow | V |  |
|           More options...             '-----------'  |

where "Allow"-dropdown holds "Deny" + persistence options, and
where "More options..." expands to show camera/mic selection + help.

This plays on "allow/deny access" security language to trigger sense-memory of protection and anti-virus, something people have a mental model for. i.e. they'll come to understand this safety interaction as a layer separate from the web.
Probably this should end up moving to Firefox UI (and equivalent for mobile, though that may have less problems).
OS: Mac OS X → All
Hardware: x86 → All
Somewhat tangentially: I have yet to hear of any actual evidence that very many users have any sort of mental model of chrome vs. content, and seeing that reaction in your sample is consistent with that hypothesis.  If there's actual evidence in that space, though, that'd be nifty.
See Also: → 1171078
This should be duped to the UI redesign under way (which is a P1)
backlog: --- → parking-lot
Bug #?
A simplification to device class type prompt would be particularly useful for applications implementing their own device selection flow.

See Bug 1212996.
A simplification of this UI would be so hugely welcome.  particularly the behavior that prompts every time gUM is called on the page.
Attached image image.png

We've made some changes to this dialog for Firefox 88/89. We now show a label instead of a picker when only one device is available. We now have a grace period so many re-prompts are eliminated. We've changed the wording of the dialog and the buttons. Here's a before and after

You need to log in before you can comment on or make changes to this bug.