[PULSATING MUSIC PLAYING]
[WHOOSH]
STEVE BAZYL: Hi, everyone.
I'm Steve Bazyl.
Thanks for watching today.
For today, I want to talk about something that's been
personally bothering me with some of the app
integrations I've seen.
And this is apps that are implementing their own file
pickers on top of the Drive API.
And first, what do I mean by a file picker?
This is really something that most of you
should be familiar with.
It's an interface for selecting files from a file
system, very much like what you would see if you were to,
say, do a native file upload from your file system.
People are building similar interfaces for selecting files
from cloud services like Drive as well as other services like
Dropbox, Evernote, and so on.
And the overwhelming reason for why I've heard of people
wanting to do this really comes down to UX consistency.
They basically want the interface to feel like it's
part of the way their app looks and feels.
And I'm going to go into that just a little bit more.
The other two reasons that this comes up--
and these are a little bit more technical reasons--
one is having to do with missing features with some of
the alternative solutions or for mobile applications where
a native file picker for that cloud service
may or may not exist.
And I'll show you a couple screenshots.
We can switch over to my screen here.
I just want you to show two quick ones.
These are from apps that I've seen, just to give you a sense
of what people are building.
I'm not going to say which apps these are.
But some of you may have seen these interfaces before.
But here's one for picking from Drive and another one
here which very much shows what some of these issues are.
So there's four reasons why the approaches that some of
these developers have taken are problematic.
Number one is pretty straightforward.
It has to do with security.
Since we launched the Drive API about a year ago, we have
been pushing this notion of file-based permissions.
So we have this drive.file scope, which limits your
application's access to only those files that the user
chooses to share with your application.
For this to work, though, it requires that we know which
files the user chooses to share.
And that's only possible if they do some
action via our UI.
And that happens automatically when they open a file
from the Drive UI.
It also works if you use our pre-built Picker Widget.
And I'll show you some demos of that in just a few minutes.
And we think this is actually very important.
In order to implement your own file picker, you need elevated
permissions.
At a minimum, you would need read-only
access to the file metadata.
If you actually need to read the contents of those files,
you would also need, at a minimum, just full
read access to Drive.
If you were to save files back, then you would need
write access as well.
But the point is that you need a lot of permissions in order
to actually build something like this interface.
And the more permissions you have, the more access you have
to drive, the more the user is exposed.
We certainly trust that most developers out there take
security seriously.
But every time there's an application that has elevated
access, that is one additional point of risk.
So we strongly encourage applications not to ask for
more permissions than they need.
And one of the best ways to do that is to use pre-built
picker widgets like ours in order to minimize the level of
access that you have.
The second reason why these tend to be problematic--
and you can actually see here in this particular screen shot
that I showed--
is a lot of developers don't design and
test with large corpora.
Most of the time, people will set up a test account.
And they'll put in a couple dozen files and folders and
make sure that, yeah, they can navigate and show files and
show folders and navigate the hierarchy.
But then you get somebody who is a Google Apps user--
maybe they're a part of a large organization, or they're
really heavy Drive users, like those of us here at Google--
and these interfaces fall over.
Personally, for example, just for my google.com account, I
certainly have thousands or even tens of thousands of
files and folders, plus all the files that are shared with
me, which is just an incredibly
large number of files.
And there's been a few applications that I've tested
out in the past few weeks where I would go and try to
upload a file, and their picker
interface would time out.
It would give me an error.
In this particular case, they didn't anticipate somebody
having more than 100 folders in their top-level directory.
So you really have to plan ahead for not just simple test
users or casual users but really the business users, the
people who are the power users and heavily use Drive and have
thousands, tens of thousands, even hundreds of thousands of
files within their database.
The other area where the size of the corpus matters is on
the response time for queries.
For example, our google.com corpus is so large that some
of the queries, just the default page size that we use
for the Drive API is too large.
And just in my own testing, in order to reliably get results
back quickly from the Drive API for a files.list call, I
really had to scale the page size down to about 50.
And default is somewhere around 1,000 or so.
And so you can see how once you're dealing with these
larger sets of files, especially if you have to
really restrict yourself down to about 50 files per call,
that's a much more effective pattern for me.
And so it's frustrating to go to an application where the
file that I want to upload is not something that I created.
It was something that was shared with me.
And I haven't bothered to take the time to organize it into
my own folder structure.
And then I'm presented with an interface that makes it very
difficult for me to get that content.
And again, implementing alternatives, such as Search,
or at least something complementary to a file
picker, such as Search, is really important.
And lastly, I do want to talk to this issue of UX
consistency.
So again, the main reason why people have chosen to do their
own pickers has really been because they want this
interface to look like the rest of their application.
And this is really a debatable point.
And I think there's a strong argument to be made that for
Drive users, it's equally as consistent to give them an
interface that is the same as what they normally see on a
day-to-day basis with Drive.
And the file picker that we give to you as a third-party
developer is actually the same picker that we use within our
own properties.
So it appears within Google Drive, within the editors.
It appears in some of the other
properties such as Google+.
So it's for Google users, people who are going to be
using this particular functionality.
It's an interface that they're already comfortable using.
And so you have to weigh that level of consistency and
comfort against wanting to have that balance with your
own application.
So that said, what are the preferred approaches?
And really the simplest one, if you're building a web
application, is to use our Picker Widget.
I'm going to switch over to just a quick little demo here,
just to share some of the customizations
that you can do.
But this is our Picker Widget, assuming--
OK, here we go.
It's going to load.
I'm not doing this on my corporate account.
So this is actually a fairly small purpose.
But trust me when I say that this actually works equally as
fast, actually even faster, on my google.com account.
It's pretty straightforward.
You can actually do some customizations here.
Say I want to separate out my files versus things that are
shared with me and allow upload.
We actually have a nice little drag-and-drop.
Or we can do upload from our native file system that
actually uploads into Drive and then shares that file out
to your application.
There's some really cool stuff you can do with the views.
So I'm actually going here.
Right now you can see we have these controls.
I can toggle over here and get a nice thumbnail view.
Some of these actually don't have thumbnails.
But you can scroll down, and we start to see those
thumbnails load.
It's a little slower than it should be today.
But we can also pin that view into something.
So if you just want to force it into a thumbnail view, we
can do that as well.
You could also do things like filter by MIME type, go back
to List, and then anything that's not that MIME type will
actually get filtered out.
Of course, you can always navigate into folders.
And that is good, really straightforward.
The cool thing with the Picker, though, is it's not
limited to just Google Drive.
So if you want to allow people to pick from YouTube, from
Google Image Search, there's a whole bunch of other
properties that it actually integrates into YouTube.
Really powerful.
And you can go over to developers.google.com/picker
to learn more about that and how it works.
But it's a really powerful interface.
So that would be the preferred approach.
There are a couple limitations, of course.
The two are currently you cannot select
folders as the target.
So you can pick files from Drive.
But there are cases where developers may
need to select a folder.
And so you can think of this as cases of, say, selecting
the target for dropping files.
So you're doing online faxing or e-signatures, and you want
the equivalent of a Dropbox folder so you can dump in
incoming files.
If you're a scanner, where to save things
that they've scanned.
And also as a location where you might want to
be consuming files.
So we see this with applications like IFT and a
few others that do these file automations, and they just
watch a folder for changes.
So there are cases where you're not interested in one
particular file, but you just want to find a destination
that you can then do something interesting with.
In that case, the Picker just doesn't work.
That's more of a bug on our end and something that we hope
to fix fairly soon.
But the other case, which is a little bit harder to deal
with, is mobile.
And right now the Picker is web-only.
We don't have a native picker for any of the mobile
platforms right now.
And unfortunately, the Web Picker doesn't really respond
well to being viewed on a mobile device.
It's not quite designed to be responsive.
And so, developers, if you're building a mobile application
and you do need to select files or folders for Drive,
you are pretty much left with building your own.
There are some alternatives to our Picker.
One that I think is kind of cool is Filepicker.io.
This is a really interesting developer product.
They basically built a layer on top of Drive and all the
other cloud storage providers--
Dropbox, Box, SkyDrive, Evernote, you name it--
and they give you a set of pre-built components.
And you can see here all their different services.
And I can click in Drive and just navigate through
everything just as well.
And they have mobile pickers as well.
They do have some of the same restrictions in terms of I'm
not entirely sure if they support folder selection.
There are some issues if you are trying to do an app that
supports both open from Drive as well as using their picker.
Within their app, they do mask the underlying file IDs.
This is done for security reasons.
That does make it a little bit difficult to implement both
use cases--
open from Drive and then pick a file from within your app--
because you end up having to do our Drive API for that one
use case and then their API for a separate use case.
If your application doesn't need to be launched from
within the Drive UI, Filepicker.io is actually a
really nice solution.
And it has the benefit that it gets you basically support for
all of the cloud-storage solutions with one
integration.
But again, it doesn't solve every use case.
But it is something that I would certainly encourage
people to look for if that is the use case that they're
trying to implement.
Another option--
and this speaks more towards the folder case--
which is if you're trying to set a destination for where to
put files, rather than giving users a
choice, just pick a default.
And you actually see this a lot with applications like
HelloFax and HelloSign, a few others that are just creating
destination folders for their content.
They don't even present a choice to the users.
And the nice thing is since Drive is based off of opaque
IDs, so we have unique identifier for files, it
doesn't matter if the user then goes and renames that
folder or moves it, reorganizes it, once you
create that folder and you have that ID, the user can do
whatever they want to it.
And you'll still be able to do writes to that folder no
matter where it goes, if they share it,
they rename it, whatever.
So the easiest thing is just don't even
bother with a picker.
Just create what you need, and you're good to go.
So for those cases where you don't really have a choice--
you're building a mobile application, you need to be
able to let users select from existing folders, and you
can't create a new one just for your application--
just a few things to watch out for based on some of the
earlier problems.
One is certainly try to minimize the level of access
that you need.
If you are only reading the content--
Actually, better yet, we'll start with the most
restrictive, which is if you just need to pick a
destination folder, you can actually pick a fairly narrow
scope to build your picker.
So what you would do is you can combine drive.file with
drive.readonly.metadata.
What that would do is you would have full read/write
access to the files you create.
But for the purposes of the picker, you would only have
read access to the file metadata, which would be
enough for you to show the navigation
structure for those folders.
But you would not be able to read the contents.
You would not be able to write to any of those files.
And that would be a pretty reasonable way to narrow down
the permissions for that case.
If you do actually need to read the file that you just
selected, then instead of doing drive.readonly.metada,
you would use drive.readonly, which would then let you read
that content.
If you actually need to read and write, then you have to
use the full Drive scope.
The other thing is if you are building your own picker
interface, consider adding a search option.
This is really important for users that are parts of large
organizations.
They have far, far, far more files than your typical user.
Many of those are files that are shared from coworkers and
may not be organized in a way that a file-oriented or
folder-oriented navigation structure is
really great for them.
Adding a search option is really easy.
Just add a text field that API supports Search.
It's pretty easy to do that as an alternative.
It's probably easier to do Search than it is to actually
build a file picker.
And it's just way more useful for users to have that.
And actually, I ran into a case recently--
not one that I showed-- an application that had their own
Drive file picker, but they also had some YouTube
integration.
And the way they required users to say which YouTube
video they wanted to attach was they had to go to YouTube,
find the video, extract the video ID from the URL, and
then copy that back into their field.
And it's just horribly, horribly painful for users to
do that when the YouTube API has a search capability.
They could have just as well have embedded YouTube Search
right in there and then extracted out the relevant
information themselves.
So really, please don't underappreciate the power that
Search has for these use cases.
And lastly, is just to make sure that you test with a
large corpus.
You don't have to have gigabytes of data.
The actual file size is somewhat irrelevant.
But when you do create your test accounts, make sure that
you are creating a significant number of folders at the root
level, as nested folders, and also to make sure that there
are regular files in there as well, just so that the number
of files that you need to fetch is some significant
multiple of the page size.
So like, set your page size to 50.
And then make sure you have 1,000 or so folders in there.
That way, you can see how your picker is responding when you
have to make 5 or 6 or 10 requests in order to populate
the results.
And I think once you do that, you're going to start to find
out where these seams are, figure out ways to
incrementally show those results, and just make that
interface much, much more responsive for users that are
heavy Drive users or parts of large organizations that have
these tens or hundreds of thousands, or even
millions, of files.
If we're dealing with RESTful APIs, I would certainly
strongly encourage everyone to use the Picker API.
So that's it for today.
Again, I hope this was useful and motivates people to do the
right thing for their users.
We'll be back next week.
I'm not sure if we have a topic yet.
But we'll let everyone know as soon as we can.
Thanks.
[WHOOSH]
[PULSATING MUSIC PLAYING]