- From: Neil Stratford <nstratford@voxeo.com>
- Date: Tue, 24 Jan 2012 14:30:05 +0000
- To: Adam Bergkvist <adam.bergkvist@ericsson.com>
- CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
On 24/01/2012 13:29, Adam Bergkvist wrote: > On 01/24/2012 10:18 AM, Neil Stratford wrote: >> There are things that users expect that would not be possible without >> capabilities - for example rich presence displaying camera icons next to >> contacts who are available for video calls, or hiding the ability to >> call entirely if no microphone is available. I find it difficult to >> imagine a good UI that has no information about what may or may not be >> possible before an actual call is attempted. >> >> My concern is primarily providing a good end user experience that >> doesn't require hacks like attempting dummy call setups to retrieve >> capability information - which is likely what developers will resort to >> if we don't provide such an API. > > I agree that having the UI reflect what the app can do is a tricky > matter. But knowing the capabilities of the browser is not a guarantee > for successful communication. The user (on any side) may not give > permission to use a device, and even when you have a stream, there's a > risk of not finding a working transport. It's not a guarantee, but it's a very good indication of what is possible and a good way to set the user expectations. On another point, moving the permission request to getCapabilities() would also provide users with a chance to check their devices before they make themselves available to receive calls. I don't want the first time I notice that I've forgotten to connect my webcam and headset to be when I hear ringing and the remote party is hanging on the line waiting. Neil
Received on Tuesday, 24 January 2012 14:31:02 UTC