- From: Stefan Håkansson <stefan.lk.hakansson@ericsson.com>
- Date: Wed, 30 Nov 2011 19:06:34 +0100
- 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