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

RE: Scenarios doc updated

From: Travis Leithead <travis.leithead@microsoft.com>
Date: Fri, 20 Jan 2012 08:35:09 +0000
To: Robin Berjon <robin@berjon.com>
CC: "public-media-capture@w3.org" <public-media-capture@w3.org>
Message-ID: <9768D477C67135458BF978A45BCF9B38381F3F42@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com>
More updates pushed to the doc this evening (part 2/3)

>-----Original Message-----
>From: Robin Berjon [mailto:robin@berjon.com]
>Sent: Wednesday, January 18, 2012 6:29 AM
>To: Travis Leithead
>Cc: public-media-capture@w3.org
>Subject: Re: Scenarios doc updated
>On Jan 16, 2012, at 21:08 , Travis Leithead wrote:
>>> From: Stefan Hakansson LK [mailto:stefan.lk.hakansson@ericsson.com]
>>> * It is not stated what should happen when the browser tab that has been
>>> allowed to capture is not in focus. I bring this up since one of the
>>> Speech JavaScript API Specifications
>>> (http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/att-
>>> 1696/speechapi.html#security)
>>> proposed that capture should stop in such cases, while that kind of
>>> behavior is not at all what you would want in e.g. a conferencing
>>> scenario (where you would often like to use another browser tab to check
>>> out things while being in the conference)
>> This indeed is an interesting scenario. I would love to hear other's
>thoughts on this. We'll walk a fine line between user privacy (e.g., seems
>like a bad idea to just leave the user's camera on when they switch away
>from an active browser tab), and usability (e.g., in conferencing
>scenarios). Perhaps the use of a PeerConnection can trigger some state
>change in implementations such that they persist after switching tabs?
>You'll note that killing capture when the tab is backgrounded largely kills
>the screen capture scenario as well!
>I think that this may largely be a UX issue, namely: is it possible to
>background a tab (or possibly the entire browser) while still making the
>user aware that capture is ongoing, and while making it easy for them to
>turn it off post-haste. If there's a decent UX solution to this (e.g. some
>on-screen button that's always on top) then I think we're good, but if not
>we're probably in trouble.

I incorporated this idea [not terminating capture on tab switch] into scenario 2.2, and also discussed the UX designs and goals in section 5.1 of the updated scenarios doc.
Received on Friday, 20 January 2012 08:35:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:08 UTC