Re: Content of URL picked by Intent

While it's obviously desireable to reduce the api surface area, it's been
our experience that the _multiple use cases are distinct enough across the
API and UX front that they should be pulled into a separate call. The
multiple case for share/save should have a significantly distinct UX as
well.

- Brett



On Thu, Sep 20, 2012 at 2:42 PM, Paul Kinlan <paulkinlan@google.com> wrote:

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