W3C home > Mailing lists > Public > public-media-capture@w3.org > March 2012

RE: UI Guidelines?

From: Travis Leithead <travis.leithead@microsoft.com>
Date: Tue, 13 Mar 2012 18:26:16 +0000
To: "SULLIVAN, BRYAN L" <bs3131@att.com>, Anant Narayanan <anant@mozilla.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>
Message-ID: <9768D477C67135458BF978A45BCF9B3838279E81@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com>
>-----Original Message-----
>From: SULLIVAN, BRYAN L [mailto:bs3131@att.com]
>
>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.


I think that mandating a particular UI in an API spec is not appropriate. However,
the spec may certainly contain non-normative sections on UI suggestions that support
the security concepts described in the spec. (This is similar to how HTML5 doesn't mandate a particular UI for certain form elements, but does have suggestions on what they could look like.)


>Thanks,
>Bryan Sullivan
Received on Tuesday, 13 March 2012 18:27:04 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:14:59 GMT