Re: Content of URL picked by Intent

Hi Brett,

Thanks for the feedback.  I am in agreement that setting it in the payload
is not great, and that Array syntax could cause issue for single instance
pick.

If we keep them distinct, then this pushes us towards different actions
http://webintents.org/pick and http://webintents.org/pick_many, likewise
for share.  Another option would be to indicate that the data type be an
array, so rather than "image/png" we would have something like
"image/png[]" or "multipart/related; type=image/png" to indicate the data
is an array.

P


On Thu, Sep 20, 2012 at 7:34 PM, 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.
>>
>>
>


-- 
Paul Kinlan
Developer Advocate @ Google for Chrome and HTML5
Watch my I/O talk: http://www.youtube.com/watch?v=O1YjdKh-rPg
G+: http://plus.ly/paul.kinlan
t: +447730517944
tw: @Paul_Kinlan <http://twitter.com/paul_kinlan>
LinkedIn: http://uk.linkedin.com/in/paulkinlan
Blog: http://paul.kinlan.me
Skype: paul.kinlan