W3C home > Mailing lists > Public > public-webrtc@w3.org > November 2011

Re: User media selection

From: Stefan Håkansson <stefan.lk.hakansson@ericsson.com>
Date: Wed, 30 Nov 2011 19:06:34 +0100
Message-ID: <4ED670AA.3060503@ericsson.com>
To: public-webrtc@w3.org
On 11/30/2011 05:59 PM, Randell Jesup wrote:
> Hoisting to a new thread with a better title...
Good idea!
>
> On 11/30/2011 9:35 AM, Stefan Håkansson LK wrote:
>   >  On 11/29/2011 11:02 PM, Randell Jesup wrote:
>   >>>  We wrote some stuff up at
>   >>>  <https://labs.ericsson.com/developer-community/blog/dmp>  if someone is
>   >>>  interested.
>   >>
>   >>  Yes, interesting. The alternative would be for the app to have a
>   >>  control/button/etc ("media") which re-opens the getUserMedia requester.
>   >>
>   >>  Question: how should this this interact with Fullscreen mode in
>   >>  browsers? And also what about mobile, where people often want browsers
>   >>  to run virtually full-screened? (This closely mirrors the already-open
>   >>  question of how we provide an always-visibile indication that mics
>   >>  and/or cameras are active.) It should be possible, for example, for the
>   >>  app to invoke this requester as well.
>   >
>   >  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?
>
>   >  A means for the app to bring up the device selection pane sounds good to
>   >  me.
>   >>
>   >>  How would it deal with multiple cameras/mics?
>   >
>   >  That's touched upon in the UI walkthrough video where we have three
>   >  getUserMedia() requests and two cameras.
>   >  What could be discussed is an additional parameter to getUserMedia()
>   >  where the app could label the source.
>   >>
>   >>  How does a user look up something in another tab while talking?
>   >
>   >  This should work just fine. The other tab would not have the status view
>   >  (but the tab which has an ongoing audio/video session should have an
>   >  indicator that audio/video is being captured - but the full screen case
>   >  is difficult).
>
> 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!).
> 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.
>
> There's certainly a use-case for people to keep talking while the tab/window
> is not focused ("let me look that up in Google Maps...").
>
>   >>
>   >>  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.
>
Received on Wednesday, 30 November 2011 18:07:35 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:26 UTC