Re: New approach to HTML Media Capture

On Thu, Apr 21, 2011 at 7:14 PM, Ian Hickson <ian@hixie.ch> wrote:
> For something like Google Goggles, you want video, not a photograph.

Are we talking about different things?  On my Android phone, the
Google Goggles app takes still photographs, not videos.

> I don't see a problem with making both available, even in this case.

There's no problem in making both available, as long as it doesn't
distract or confuse the user.  At a minimum, authors will in some
cases legitimately want to tell the UA which input mechanism to
emphasize, for UI quality reasons.  Good UI will direct the user
toward the most likely action and will not offer alternatives (at
least not prominently) that the user is very unlikely to want.

>From the perspective of what the user is technically able to do, this
feature is not needed, but for a user experience that matches native
apps, it is.

On Fri, Apr 22, 2011 at 2:41 PM, Maciej Stachowiak <mjs@apple.com> wrote:
> I'm sympathetic to that point of view, but I'm not sure it's right from an HI perspective. For native applications, it's common to only offer only one of file input or camera/microphone input. It's somewhat uncommon to offer a generic dialog that gives the user the choice of existing file or capture. For example, on Mac OS X, Preview opens files and doesn't do camera capture. Photo Booth can take pictures with the camera, and doesn't even have an option to choose an existing file (even though you could imagine that applying its photo effects to an existing file might be useful). On iOS, you see the same pattern. Apps generally offer access to the system photo collection or their own image collection separately from camera capture, even if they provide both. And many apps only do one or the other.
>
> I think people will want to build Web apps that meet the same standards of HI polish.

I agree with this, although I'll add that it would be good if web apps
automatically gave the user the *option* to use files from a different
source than the author expects (unlike the OS APIs we're discussing,
which require extra author work to get that effect).  But the author
still needs a lot of control over how that option is presented, to
create a good user experience.

Received on Friday, 22 April 2011 20:33:57 UTC