- From: Alex Russell <slightlyoff@google.com>
- Date: Tue, 25 Sep 2012 17:30:36 +0100
- To: Brett van Zuiden <brettcvz@filepicker.io>
- Cc: Greg Billock <gbillock@google.com>, Tobie Langel <tobie@fb.com>, Jungkee Song <jungkee.song@samsung.com>, Norifumi Kikkawa <Norifumi.Kikkawa@jp.sony.com>, Paul Kinlan <paulkinlan@google.com>, WebIntents <public-web-intents@w3.org>, "public-device-apis@w3.org" <public-device-apis@w3.org>, "Frederick.Hirsch@nokia.com" <Frederick.Hirsch@nokia.com>
- Message-ID: <CANr5HFXgq4Cbw3YD91krLdEho9Ev-apBvZn+Um8sy0qeep2PbA@mail.gmail.com>
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. >> >> >
Received on Tuesday, 25 September 2012 16:31:35 UTC