RE: Content of URL picked by Intent

> -----Original Message-----
> From: Greg Billock [mailto:gbillock@google.com]
> Sent: Tuesday, September 25, 2012 2:38 AM
> To: Brett van Zuiden
> Cc: Tobie Langel; Jungkee Song; Norifumi Kikkawa; Paul Kinlan; WebIntents;
> public-device-apis@w3.org; Frederick.Hirsch@nokia.com
> Subject: Re: Content of URL picked by Intent
> 
> Thanks, Brett, this is really useful! Agreed that the use cases are
> often distinct. It's easy to see this for images and contacts for
> example -- picking a single image probably wants to be presented by
> the service differently than picking multiple.
> 
> We don't want to have to change the API to support new use cases, so
> invoking an intent is a single API call and we differentiate by action
> and/or type. I'm reluctant to name this a different action because the
> action signals the cross-type purpose of the activity. Thinking about
> non-MIME type data, it seems like the best solution is to have a
> different collection type for, say, multiple images (a "gallery" or
> "album" perhaps) as opposed to a single image.

Pick Media Intent [1] is meant to specify interfaces for the very use cases.
The data type that the Pick Media Intent should handle is a collection (JS
array) of images, video and audio contents that are called as media objects
in the draft. Besides, each media object defined in the current draft
carries the properties that we discussed for a MIME type content as well.

partial dictionary Media {
    MediaContent content; // URI and Blob
    DOMString type;
    DOMString path; // for filename
    DOMString title;
    DOMString description;

    // and rest of optional metadata fields
}

I think we can further align the basic vocabulary.

One more thing I would like to discuss is whether a collection type should
be explicitly described in the spec. Current Pick Media Intent draft does
not explicitly specify the interface for the collection but only describes
the guide to delivery an array of media objects by example codes. I can
presumably add some interface like the following, if required:

[ArrayClass, NoInterfaceObject]
interface MediaList {
    getter Media item(unsigned long index); // not actually implemented in
JS but used as [index]
    readonly attribute unsigned long length;
};

The same story seems to be applied to Pick Contacts Intent [2] as well.

> This makes me think
> that having distinct types for a single entity vs. a collection is the
> way to go. That differentiates the intent such that services can
> register for one or the other, and present different UI for them.

Yes. Service providers can implement gallery-like services differentiated
from single image services.

> I think everyone is in agreement that using JS arrays for the native
> type is the right solution. If the above reasoning is compelling, then
> the remaining question is what to call the multiple selection type.
> 

Greg, I am not sure if you think of more generic scheme like
"multipart/related" or some rule that certain types themselves indicate they
are inherently served as collection. I prefer the latter because we are
talking about a way to distinguish *single* use cases and *multiple* use
cases from the beginning.

e.g., The types of the Pick Media Intent and Pick Contacts Intent
(http://intents.w3.org/type/Media and http://intents.w3.org/type/Contact)
specify the media objects and contact objects are delivered in the *-List
format.


[1] http://w3c-test.org/dap/gallery/
[2] http://w3c-test.org/dap/contacts/


Jungkee

> 
> 
> On Thu, Sep 20, 2012 at 11:34 AM, Brett van Zuiden
> <brettcvz@filepicker.io> wrote:
> > Hi there - I'm typically just an observer here, but felt like this was
> an
> > area where we can share a lot of what we have learned.
> >
> > I'm one of the founders of Filepicker.io, and our first product has
> strong
> > parallels to web intents. We've had thousands of developers use our
> product
> > over the last handful of months, so have some real-life experience in
> > interacting with developers around the api.
> >
> > Our initial approach was to treat multiple as a flag to the getFile call
> > (our equivalent of the "pick" intent). If multiple wasn't set, we would
> > return the url and data as an object, if it was we would return an
array.
> > I'm convinced this is the wrong way to do multiple, and that the right
> way
> > is to have an explicit pickMultiple call.
> >
> > Rationale:
> > * a {"multiple": true} flag has poor discoverability. I'm fairly happy
> with
> > our documentation, but we still get on average one question a week from
> > people asking if they can/how to select multiple files
> > * The use cases for selecting multiple files are fairly distinct from
> those
> > asking for single files. We initially thought the flag would help people
> > switch between the two - in practice, this rarely happens.
> > * We've found that the user interface for selecting multiple files
> should be
> > reasonably distinct from selecting a single file. For instance, the
> presence
> > of a "shelf" where selected files are queued before being submitted
> > * Making single-file pick an array creates a significant boiler-plate
> issue
> > where every implementation needs the same blob of code. It also raises
> > questions about edge cases: what happens if the user closes without
> > selecting any file? Can an empty array ever be returned for a single-
> file
> > pick? Will the length of the array always be identically 1?
> >
> > Happy to provide more insights into what we've learned from our
> customers.
> > We've recently spec'd out the next version of our API and so have
> aggregated
> > quite a bit of experience into that document.
> >
> > - Brett van Zuiden
> > Founder | Filepicker.io
> >
> >
> >
> > On Thu, Sep 20, 2012 at 1:56 PM, Greg Billock <gbillock@google.com>
> wrote:
> >>
> >> On Thu, Sep 20, 2012 at 10:43 AM, Tobie Langel <tobie@fb.com> wrote:
> >> > On 9/20/12 7:27 PM, "Greg Billock" <gbillock@google.com> wrote:
> >> >
> >> >>The discomfort I'm estimating as the most acute
> >> >>is client developers wanting to get started. I'd like them to have as
> >> >>few problems as possible using the API, and so I'd like to make their
> >> >>path as clear as possible.
> >> >
> >> > That's actually easily mitigated by providing example code developers
> >> > can
> >> > copy. It also an issue during a relatively short period of time and
> is
> >> > relevant to that particular API only. It's also very possible that
> the
> >> > developers will be familiar with the pattern having seen it
elsewhere.
> >> >
> >> > However, inconsistencies in the platform hurt the productivity of
> >> > beginner, intermediate and seasoned developers alike. Not only does
> it
> >> > hurt developers when they are using that particular API, but it also
> >> > hurts
> >> > them **every time they will use any other API where consistency with
> >> > that
> >> > particular API would have been expected.** In other words, coming up
> a
> >> > custom solution here diminishes the quality of the platform as a
> whole.
> >>
> >> I completely agree, and that's a major source of discomfort I'd dearly
> >> like to avoid. :-) If we can document around early pitfalls and give
> >> developers touching a lot of the platform a consistent experience,
> >> that's definitely where the balance of intuition ends up lying. I
> >> definitely think using arrays for multiple MIME values is the way to
> >> go, and accords well with the rest of the platform. The question is
> >> how to best indicate that. Always using them is a good approach that
> >> will work fine.
> >>
> >

Received on Tuesday, 25 September 2012 06:10:46 UTC