Open/Include images using Google's Picker API

[Emmay]

Some students want to use personal images for their games. I tried sharing a photo from my Google drive and passing it to the image-url function, but that didn't work. I know this took a lot of fiddling to work with Wescheme, is it possible in Pyret?

[jpolitz]

It is possible but it's somewhat annoying -- the main issue is that Drive doesn't provide easy access to a direct download link, which is what image-url expects. We could expose a drive-image function that tries to do some of the below automatically, but I think the steps up to "Public on the Web" will be necessary unless we change the way we do permissions with Drive.

Instructions:

1. Find the file in the Drive UI, and open up "Share..." via right-click, then click "Advanced" in the bottom right of the share dialog:

2. Choose "Change" under "Link Sharing" to be "Public on the Web":

3. Copy the share link, which will look like:

https://drive.google.com/file/d/0B5LNo4UZI70BVG9jZ1JLYjAyLUU/view?usp=sharing

Copy-paste the ID (the thing starting with 0B5...) at the end of this URL:

https://googledrive.com/host/<id-here>

For example:

https://googledrive.com/host/0B5LNo4UZI70BVG9jZ1JLYjAyLUU

That URL can be used in image-url.

I don't know of a way to get this URL from the Drive UI, unfortunately.

[schanzer]

Have you tried this feature on WeScheme? We use the Picker API, which does exactly what I think you need.

1. log in, and start a new program
2. put the cursor in the definitions or interactions window
3. click "images" from the toolbar
4. select an image (or upload a new one)

[jpolitz]

Yeah, the picker API requires access to the entire user's drive, though, right? I guess maybe CPO is going in that direction anyway.

[Emmay]

Thanks Joe, this is a little involved but it's working great!

[schanzer]

Ah, I see - sorry, I didn't realize CPO was being less demanding. I get the sense this isn't the only thing we'll want more access for, though I can't think of other examples right now. In general, though, I think people are going to push back if we wind up asking for more access later. Better to ask the first time they sign up, no?

[jpolitz]

I've been grimly holding on to a least-authority attitude here, though Google sheets caused another crack in my argument to open up because there's no way to reasonably access one sheet without getting access to them all. There's at least one other use case I have for importing raw JS libraries that would require asking for access to the user's entire Drive, or else do either some really complicated implementation work or an annoying workflow for users.

My inclination from a security perspective is to prompt only when needed rather than asking for everything up front, but maybe we just need everything.

(@hannahqd will enjoy seeing your comment, I'm sure, which has the slippery conclusion that we might as well ask for permission to comment on the user's YouTube videos while we're at it, since we might want to post animations to YouTube someday.)

[schanzer]

If we have to ask later, on a per-use basis, we need to think through the UX very carefully. I can see this friction causing real problems for classroom teachers, whose students blindly click "no" and then complain when something doesn't work.

And the steps you just outlined above basically mean "no public school kids include gdrive images in their games". This isn't a show-stopper for us, but it's going to be a pain to lose something so useful.

[jpolitz]

Yeah prompt-to-confirm is probably the wrong experience here anyway, since our users won't really know how to make an informed decision anyway most of the time.

[jpolitz]

We might be able to do everything we need with https://www.googleapis.com/auth/drive.readonly, which "Allows read-only access to file metadata and file content", meaning all file metadata and file content.

Still more responsibility than I really want CPO to have, but it might be the next step.

[schanzer]

Isn't this more of a CPO issue?