Re: User media selection

On 11/30/2011 08:34 PM, Randell Jesup wrote:
> On 11/30/2011 1:06 PM, Stefan Håkansson wrote:
>> On 11/30/2011 05:59 PM, Randell Jesup wrote:
>>>> This is a difficult one (regardless of how getUserMedia is handled).
>>>> Should there be some visual (overlayed) indication?
>>>
>>> As mentioned, we haven't specified how an implementation will let the
>>> user
>>> know the camera/mic are active, but we need them to have that (and the
>>> ability to mute or kill it). Overlaying has issues unless we spec exactly
>>> how and where it's overlaid (since the app writer need to know how to
>>> avoid it), or have a way for the app writer to adapt to the actual
>>> overlay
>>> (much more flexible, but tougher to get right by the app).
>
>> Yes, there are issues, but what are the options?
>
> Chrome in title bar (when not full screen/mobile).  Has the advantage of
> being visible even if you change tabs (per the Mozilla presentation).
> Any other suggestions?  Per below, some indication in the task bar in
> Windows would probably be good; equivalents in other systems.
>
> For Mobile (and maybe full-screen):
>
> a) Reserve one edge of the screen (L/R in landscape, top/bottom in
> portrait for browser chrome when in a WebRTC session.  Negative:
> intrusive, uses limited screen space (and since it probably runs the
> entire edge, may use more than needed).
>
> b) (Semi?) transparent overlay one end similarly.  Downside: visibility,
> and it's possible an evil app may try to hide it by what it puts
> underneath (though this isn't likely to be a very effective attack).
> Negative: complexity, compositing required which may cut into
> frame rate on mobile devices.
>
> c) Bug in one corner.  Need to define size (or make it discoverable by
> the app) to avoid clashes with the app.   On Mobile, needs to be big
> enough to be selectable.  Also there may be a discoverability issue with
> this compared to taking one edge ("What's that?  Dunno.")
That are some options, and there is a need for experimentation to 
understand what works and what doesn't.

The easy way out for the stds WG would be to say "leave it to the 
vendors", that way you could finalize a Rec that says "Prompt the user 
in a user-agent-specific manner for permission" (plus similar language 
for informing the user of what is ongoing, and giving the user 
possibility to revoke/change consent) and leave the rest to the 
implementors.

However, there is a need for a similar behavior between implementations 
so that users easily understand when switching devices/browsers. But it 
is not clear to me how far the Rec. need to go and how much that can be 
left to implementations.
>
> Others?
>
> There's a related issue for how the app handles UI when the video is
> full-screen (mobile or desktop).
>
>>> There was an implication of muting when not focused - true? People have
>>> said things assuming both muting on tab-switch and no muting on
>>> tab-switch.
>
>> If I remember right, the discussion at TPAC went along the line that you
>> should not mute at tab-switch (since a very normal behavior is to put
>> another tab in focus during a conversation to look things up, just as
>> you say!).
>
> Good.  If we mute, it should mute video only (in that you aren't seeing
> their video - this is a more open case).
>
>>> FYI, I don't consider the color change on the tab to be sufficient or
>>> discoverable enough by general users.
>
>> I think Anant showed something like this, and that it was generally
>> liked at the meeting.
>
> Good; glad that went over well.
>
>>>>> What happens if the user focuses another window?
>>>> ...or minimizes the browser. Should there be an indication in the
>>>> system tray?
>>>
>>> Probably. Also what if another window obscures the browser window or
>>> where
>>> the indicator is?
>
>> Yeah, difficult to handle.
>
> Yes, another reason for indication in the system tray, and I'd suggest
> (but not mandate) a reminder to the user when they minimize with
> mic/camera on with option to mute/end, or on minimize force a mute.
>

Received on Thursday, 1 December 2011 15:01:16 UTC