Re: Content of URL picked by Intent

Sorry for the slow response here. Inline:


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
>

Agreed.


> * 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?
>

I'm sympathetic to this, but the "boilerplate" is also what makes you
automatically able to handle a SEND_MULTIPLE style of intent. The default,
correct way to write a receiver in this world is also the way to implement
both single and multiple item receipt. It's surely less overhead than
writing the same thing in the SEND_MULTIPLE version and then having a
single-item handler as well, isn't it?


> 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<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.
>>
>>
>