Re: User media selection

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.")

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.

-- 
Randell Jesup
randell-ietf@jesup.org

Received on Wednesday, 30 November 2011 19:36:39 UTC