- From: Kenton Varda <kenton@google.com>
- Date: Wed, 9 Dec 2009 19:44:11 -0800
- To: public-device-apis@w3.org, Ian Hickson <ian@hixie.ch>
- Message-ID: <4112ecad0912091944t14421088u41050af3fb320d35@mail.gmail.com>
Hi all,
I wrote some thoughts about Ian's UI ideas on a Google-internal mailing
list, and someone recommended that I send it to this list as well. So, here
I am, and here's what I wrote:
====
Whatever UI we end up with, I'd like to strongly suggest that it have these
important properties:
A) It should be extensible to any device, including things we haven't
thought of. This will allow the market to innovate and come up with new and
interesting devices without having to get support from us. (Take "us" to
mean either w3c or browser vendors.)
B) It should support the case where the user has multiple webcams (or
whatever other device) connected. Note that since this would be for power
users, the interface doesn't have to make this case easy and intuitive, but
it should be *possible*.
C) It should support "virtual" devices which are actually implemented by
other software (or web apps). For example, I should be able to write a
piece of software which exposes a virtual web cam that just plays a movie
fed from a file, or a piece of software that merges two camera feeds into
one with the images side-by-side. Again, this would be for power users, so
does not necessarily have to be easy, just possible.
Note that if the UI supports (B), then (C) should presumably be automatic.
Of the four UI designs suggested by Ian, #2 (the device drawer) supports the
above properties most naturally.
I'd also like to suggest a design #5 (sorry, no ASCII art): The web page
could have a box which is a "socket" for a web cam (or whatever) device. If
you click on (or maybe hover over) the socket, the browser will pop up a box
suggesting devices that could be connected to this socket, but advanced
users should also be able to drag and drop devices other than the suggested
ones.
The metaphor here is of hooking up devices physically. If I want my iPod to
be able to play music to my head phones, I plug my headphones into the
iPod's audio output socket. If I'd rather that it play to my stereo, I hook
that up instead. Everyone understands how this works in the physical world.
Can we extend this to virtual space as well?
====
Elsewhere in the thread, I wrote the following, which is also probably worth
reposting here:
====
A file-access <input> allows you to select a file to open. Similarly, a
webcam <input> should allow you to select a web cam to connect to. Not only
does this create the possibility of having multiple cameras, but I think it
forces the user to think about what is happening. A dialog box that simply
says "OK to use web cam?" will probably get reflexive "yes" clicks, but one
saying "Choose a web cam to use: [list]" will, I think, force the user to
realize what they're doing. And if they don't want to think about it,
they'll probably click "cancel", thus avoiding giving away capabilities they
didn't intend.
> In terms of the additional "power features" below, at least some of these
strike me as browser config options.
I don't know about that. A config option, done naively, would probably only
allow one camera to be used at a time. What if I want to connect multiple
cameras at once? Say, for example, that I have multiple video conference
participants at once site, each with a camera on them, and want to share one
computer and browser instance among them.
This is analogous to singletons in object-oriented design. They seem
incredibly convenient until the moment that you decide that you need more
than one instance, and then all of the sudden the singleton is a huge road
block. The same applies to "singleton" devices. In OO design, it usually
is not as hard as you think to avoid using a singleton, and I think the same
is true of device interfaces.
====
-----Original Message-----
From: public-device-apis-request@w3.org [mailto:
public-device-apis-request@w3.org] On Behalf Of Ian Hickson
Sent: Tuesday, December 08, 2009 09:40 AM
To: public-device-apis@w3.org
Subject: UI for enabling webcam use from untrusted content
I've been trying to come up with what the UI could look like for allowing
untrusted content access to one's camera and other devices, for the
purpose of streaming or direct access, as opposed to the simpler cases of
getting a static picture or non-live video. For example, for the purpose
of implementing a Web-based video conferencing system.
I haven't yet been able to find something that really works.
Here are the ideas I've looked at. For each example, I assume that there
are two devices, a webcam and a mic, and that the site wants the user to
enable the webcam. Key requirements are that the user actively pick the
webcam, not just click through a prompt, and that the user be kept aware
of the camera being enabled for as long as it is enabled.
1. Toolbar buttons.
+-----------------------------------+
| [] [] [_http://www.exa_] [] () () | <-- last two buttons are the
| +-------------------------------+ | webcam and the mic
| | | |
| | To start the video chat, | |
| | activate your camera. | |
| | | |
| +-------------------------------+ |
+-----------------------------------+
Cons: - Unintuitive.
- Doesn't scale to multiple devices.
- Cluttered.
2. Device Drawer
+-----------------------------------+
| [] [] [_http://www.example.c_] [] |-----------.
| +-------------------------------+ | () Webcam | <-- User has to drag
| | | | () Mic | and drop the icon
| | To start the video chat, | | | into the content
| | activate your camera. | | | area to activate
| | | | | the device.
| +-------------------------------+ |-----------'
+-----------------------------------+
Cons: - Even more unintuitive.
- UI idiom is only established on Mac.
- No indication of device use when drawer is closed.
3. On-screen indicator
+-----------------------------------+
| [] [] [_http://www.example.c_] [] | +----------+
| +-------------------------------+ | | x Webcam |
| | | | | Mic |
| | To start the video chat, | | | |
| | activate your camera. | | +----------+
| | @ RRR EEE CC
| +------------------------ @@@ RR EE C
+--------------------------- @ R R EEE CC
REC indicator first appears grayed out when the page requests a
device. When the user clicks the indicator, a menu appears showing
the available devices, and clicking one enables it, turning the REC
indicator red.
Cons: - Unintuitive.
4. Infobars
+-----------------------------------+
| [] [] [_http://www.example.c_] [] |
| +-------------------------------+ |
| | Bla bla (Enable Webcam) (No) | |
| +-------------------------------+ |
| | Bla bla (Enable Mic) (No) | |
| +-------------------------------+ |
| | | |
| | To start the video chat, | |
| | activate your camera. | |
| | | |
| +-------------------------------+ |
+-----------------------------------+
Cons: - Doesn't scale to multiple devices.
- Users will enable devices they didn't intend to, since they
likely won't read the prompts.
- No on-screen indicator of active device use.
Anyone got any better ideas?
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 10 December 2009 07:50:10 UTC