getUserMedia prompts

Data nerding again… this time we are looking at the time that passes between the getUserMedia call and the success callback. Why is it important? Most of the time this is the first interaction a user has with WebRTC. And as my former coworker Lynn Fisher wrote in an excellent blog post about UX considerations for WebRTC services,

Preparing the user for this interaction is important and so is understanding each browser’s quirks

When a web site calls getUserMedia, the browser will typically prompt the user for permission to access the camera and microphone which the user can either allow or reject. This permission can be persisted which is supported by both Chrome and Firefox.

We ignore failures for the time being. Since both Firefox and Chrome have very different UIs for this, we need to split up the data before looking at it:

create or replace view dataset as select * from features_import where timeBetweenGetUserMediaAndGetUserMediaSuccess > 0 and getusermediaerror = ‘0’ and browsertype = ‘webkit’ order by date desc limit 100000;

A similar query can be run for Firefox. Splitting up the webkit dataset further between Chrome and Opera is possible but did not yield significantly different results.

Fortunately, no getUserMedia call took longer than 20 seconds. We will group the call durations into buckets of different size, starting with one for all calls that returned in less than 100ms, the next for calls that took between 100 and 200ms and so on. The resulting query is somewhat long:

SELECT count(*), case
  WHEN timeBetweenGetUserMediaAndGetUserMediaSuccess < 100 THEN 100
  WHEN timeBetweenGetUserMediaAndGetUserMediaSuccess < 200 THEN 200
  WHEN timeBetweenGetUserMediaAndGetUserMediaSuccess < 300 THEN 300
  WHEN timeBetweenGetUserMediaAndGetUserMediaSuccess < 400 THEN 400
  WHEN timeBetweenGetUserMediaAndGetUserMediaSuccess < 500 THEN 500
  ...
  ELSE 20001
  END AS gumtime FROM dataset 
  GROUP BY gumtime ORDER BY gumtime;

The results look very different for Chrome and Firefox:

In Chrome, about 45% of the calls suceed within less than 100ms, more than 75% in less than 500ms. This is too fast for most humans to react so it is safe to assume that the permission to the devices is persisted. We can see a small spike in the bucket from 1000ms to 1500ms which might be users who click fast enough.

The Firefox data looks drastically different. Virtually nobody has persistent device permissions which are a secondary option in the getUserMedia prompt (which is currently being redesigned). On average, it takes the user three seconds to allow the prompt.

The Firefox data is much more interesting since it shows users making a decision and roughly how long it takes them. Note the bump at 7.5 seconds is due to the changed bucket size, the actual numbers are decreasing roughly linearly.

Gathering data like this is quite essential to designing the onboarding experience. Now we know how much time we have until the user makes a decision. And we can formulate a hypothesis for making experiments, for example whether presenting the user with a button to ask for camera access will reduce the average time between the getUserMedia call and the success callback. More on that soon…