RE: UI Guidelines?

Anant,

I note that DAP has been down this road though before, unsuccessfully. The permissions model, if more than single-shot allow/deny, gets into complicated areas of defining a session or managing persistent permissions. And there is no guarantee that the user who gave permission is the user whose streams are being captured later. In BONDI/WAC, we developed what I think was a simple and flexible model for procedural API permissions (even given the limitations noted above), but DAP failed to reach consensus on that approach, and as a result DAP shifted to the declarative/markup API approach you see in HTML Media Capture. Having started down that path, isn't the declarative approach an option here, and being user-intentional, doesn't it provide adequate consent verification? Determining how getUserMedia would be accessible only through markup (e.g. through "onclick" or as an input type) would need to be decided. But I think it might avoid the UI/permissions-definition issues that a prompt approach carries.

I do think that getting specific about how the chrome should show what devices are in use is a good discussion to have, but this also gets close to differentiation needs for browsers.

So overall I would be less worried that the UX would vary significantly across browsers (real experience might result in convergence on the one that works best, or we might find that the multiple approaches do not confuse users after all), as compared to spending significant time going down the prompt system rabbit hole.

But  if we want to explore this again, wire frame illustrations at least would help clarify the depth of detail and choice that you are recommending we define. It might turn out simpler that what we had considered before.

Thanks,
Bryan Sullivan 

-----Original Message-----
From: Anant Narayanan [mailto:anant@mozilla.com] 
Sent: Monday, March 12, 2012 11:00 AM
To: public-media-capture@w3.org
Subject: UI Guidelines?

This is not a formal proposal, rather an email to gather feedback about 
the idea in general.

Currently, the getUserMedia specification says a little about how a UA 
is expected to obtain user consent (Step 10: Prompt the user in a 
user-agent-specific manner for permission...).

I would like to expand on that by describing in a little more detail:
- What information should be exposed to the user, at a minimum
- What choices are offered to the user (in terms of accept/deny but also 
device selection), at a minimum

In addition, I would like to include some guidelines on how UAs should 
inform the user about whether or not a device (both camera/mic) is 
currently in use, especially if they switch to a different tab than the 
one that has an active getUserMedia session. This is very much in the 
spirit of the SPDY indicator for Chrome: 
https://chrome.google.com/webstore/detail/mpbpobfflnpcgagjijhmgnchggcjblin 
and Firefox: 
https://addons.mozilla.org/en-US/firefox/addon/spdy-indicator/ though 
the actual method of notifying the user will likely be different.

The goal is not to homogenize UI completely. I do support browsers 
trying differentiate themselves with unique user interfaces, the main 
intent of these guidelines is only to ensure that a user is not entirely 
confused when they use the *same* web application in a different browser.

For some types of UAs these guidelines might be meaningless, and that is 
why they are just guidelines. The hope is that atleast the major browser 
will support a more-or-less consistent user consent flow & device usage 
indication.

I'm happy to draft the exact text to be included in the guidelines (and 
perhaps some pictures!), but I first wanted to get some feedback on the 
idea before delving in.

Regards,
-Anant

Received on Tuesday, 13 March 2012 06:48:30 UTC