search

brownplt / code.pyret.org

Website for serving Pyret to folks.
Other
24 stars 44 forks source link

Possible to show folders in CPO? #346

Open schanzer opened 3 years ago

schanzer commented 3 years ago

Request from a few teachers, as well as Flannery -- since CPO just queries GDrive for all pyret files, we get a giant, flat list. This is fine for students, who rarely have more than a dozen files. But for teachers and power users alike, it's problematic. There's also a common misconception - based on this UI - that Pyret files cannot be organized into sub-folders.

I'm assuming the answer here is "Just open GDrive, silly!" And if that's it, I can live with it. But if it's at all possible to embed a full GDrive viewer instead of the list, I think it would be a big improvement. Most people are familiar with Drive, so I don't think we lose a lot in terms of ease-of-use.

jpolitz commented 3 years ago

Do you know if the picker API does embeds like this? I've only seen non-Google libraries for doing the embed. Can do some more research. I don't really think we should roll something custom.

My usual answer here is just "Yeah, open GDrive, respected friend" which works just fine*

*(until you hit the use case where you want to collaborate on a published shared file, and you have to follow an annoying process to set up the share in a reasonable place. That's a use case to improve, but I don't think it's quite what you're asking for here.)

schanzer commented 3 years ago

It looks like there is a setting to show folders. On https://developers.google.com/picker/docs/reference : 

DocsView.setIncludeFolders(boolean) | Show folders in the view items. Do not combine with setOwnedByMe. When setIncludeFolders(true) is set, setOwnedByMe is ignored.
asolove commented 3 years ago

Would folks be interested in a proof-of-concept here? I don't have enough files/folders yet to really understand the use case super well, but I could plausibly stand up a Heroku sample that other folks could play with to test it out.

jpolitz commented 3 years ago

I know @kfisler has some pain points here with organizing her files across TA teams and across courses, not sure if she can dredge up the memory or wants to chime in.

I think if you just try making a few files with CPO, finding them, moving them to other directories, publishing them, and then trying to understand where everything is, you'll see the challenge.

Though just showing folders in the picker might be a good first step and I'd like to see what that looks like!

asolove commented 3 years ago

After poking at this a bit, things are More Complicated:tm:

In 7c798235d7e613138afdfcf187a4fb13a6872b3a, the CPO dashboard was switched to not use the Google Picker inline. (The commit message makes it sounds like there was a strong reason for this, but doesn't specify it. Does anyone remember?)

The dashboard file list shows recent files from the app folder. This custom UI does show folders, but it treats them as documents. Clicking on them doesn't navigate into the folder, but instead opens the Pyret editor with a new document that is the folder's name. So that behavior is very surprising and is probably why users think folders are disallowed. (BTW, the current code also has some surprising behavior, like explicitly not showing files from the shared folder. Is there a reason for that I'm missing, or is it maybe unintended?)

The Google Picker UI is better if you need to navigate folders, but is also slower to load and tricky to navigate if you have files across the App Folder, Shared Folder, and other random ".arr" files in folders. So I suspect we want some kind of hybrid solution. Show the recent files that are real files for students. Then for users who have ".arr" files anywhere other than the default folder, or who have sub-folders, show the Google Picker underneath the recent files.

kfisler commented 3 years ago

Sorry for my slow reply here.

My perception as a user has been that:

The idea that Pyret was doing some sort of alternate presentation never occurred to me (and I have so many Pyret files that I never noticed any patterns in what was or wasn't presented).

As an instructor, I need to navigate Pyret when developing lectures/assignments, for developing live-coded programs in class, and across multiple courses/projects. I want to be able to create/save programs in different folders for different lectures or courses. If all of the files appear flattened, I have to rely on naming conventions to find things. Folders are partly namespace management, so not seeing folders adds a lot of cognitive overhead.

Hope that helps, Kathi

On Mon, May 10, 2021 at 12:41 PM Joe Politz @.***> wrote:

I know @kfisler https://github.com/kfisler has some pain points here with organizing her files across TA teams and across courses, not sure if she can dredge up the memory or wants to chime in.

I think if you just try making a few files with CPO, finding them, moving them to other directories, publishing them, and then trying to understand where everything is, you'll see the challenge.

Though just showing folders in the picker might be a good first step and I'd like to see what that looks like!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/brownplt/code.pyret.org/issues/346#issuecomment-836941288, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALO7SKF3V6QRB72VOSOCQDTNAECJANCNFSM4RL6ZZTA .

asolove commented 3 years ago

@kfisler Thanks, that's super useful background!

I can definitely see that having folder-aware handling for the dashboard, the save/rename dialogs, etc. would be very useful. At the same time, the Google Drive rules for this could be quite tricky and maybe not worth maintaining as they add new types of shared folders, new permission rules, etc.

But you said something that got me thinking:

since double clicking .arr files in the regular Google chooser didn't work

I think we should consider trying to make this work!

For those who haven't tried, the current situation is that in Google Drive, if you pick a .arr file, it shows a plain text preview. You have to right-click and go to "Open with > Pyret" to actually open it. I think this is because the files are saved with the text/plain mime-type, so Google defaults to showing the text and treats the app as a secondary way to deal with the file.

I have other GDrive apps where double-click does go straight to the app. All of them appear to save with their own mime types, where the app can then request a permission to make itself the default editor for files of that type. It's possible that if we just saved .arr files that way, double-clicking would work, and then we could recommend folks use GDrive without reservations. I'm going to poke at that and see if I can get it to work.

schanzer commented 3 years ago

FWIW - I took a crack at this in an unrelated project years ago. At the time, apps that wanted to be default handlers for MIME types in GDrive had to register as apps inside GDrive itself.

asolove commented 3 years ago

Was there a reason not to do that? Not every student would need to load up the GDrive app, but teachers with complex setups could.

On Mon, May 24, 2021 at 2:17 AM Emmanuel Schanzer @.***> wrote:

FWIW - I took a crack at this in an unrelated project years ago. At the time, apps that wanted to be default handlers for MIME types in GDrive had to register as apps inside GDrive itself.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/brownplt/code.pyret.org/issues/346#issuecomment-846603737, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAACCLZHCNF3QA35SCSIZMLTPFBDJANCNFSM4RL6ZZTA .

jpolitz commented 3 years ago

Huh, I didn't realize the permission for getting into the right-click menu was different than the permission for the MIME stuff.

We could try the custom MIME type again and see if we have luck with the current (expansive) permissions.

(FWIW, I managed to set CPO as the default way to open text files in my Drive, which makes it so when I double-click a .arr file it just opens CPO (but it does the same for .txt files in my Drive). This is a lousy solution, but I bring it up because there may be other user-configurable options to make this better that we could look into.)

On Sun, May 23, 2021 at 5:42 PM, Adam Solove @.***> wrote:

Was there a reason not to do that? Not every student would need to load up the GDrive app, but teachers with complex setups could.

On Mon, May 24, 2021 at 2:17 AM Emmanuel Schanzer @.***> wrote:

FWIW - I took a crack at this in an unrelated project years ago. At the time, apps that wanted to be default handlers for MIME types in GDrive had to register as apps inside GDrive itself.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/brownplt/code.pyret.org/issues/ 346#issuecomment-846603737, or unsubscribe https://github.com/notifications/unsubscribe-auth/ AAACCLZHCNF3QA35SCSIZMLTPFBDJANCNFSM4RL6ZZTA .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/brownplt/code.pyret.org/issues/346#issuecomment-846658502, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAA5IU4X2C6AYJJKFNWJ533TPGOIFANCNFSM4RL6ZZTA .

asolove commented 3 years ago

I was also thinking custom mime type gives an opportunity to not just save the plain text of the program. We could add in metadata about runs, test status, past REPL expressions, etc. both to make it easier for students who spend several sessions on the same program and to make it easier for teachers to get stats about their students that require actually running the program.

schanzer commented 3 years ago

@jpolitz this was YEARS ago, and could very well have changed.

I love @asolove 's idea about storing metadata, but I feel like maybe you all have a strong conviction that .arr files should be plain text? If not, good lord we can do some cool stuff. (drools thinking about saving REPL histories, data about hiding/locking certain lines, etc...)

shriram commented 3 years ago

I've always wished we could store uuencoded or some other form of images in the .arr files. This would avoid the wxmedia nightmare of Racket (add done image and suddenly all standard tools break) while still enabling rich content in files.

jpolitz commented 3 years ago

I don't think Pyret files should become non-plain text to make navigating GDrive easier :-)

On Mon, May 24, 2021 at 7:02 AM, Shriram Krishnamurthi < @.***> wrote:

I've always wished we could store uuencoded or some other form of images in the .arr files. This would avoid the wxmedia nightmare of Racket (add done image and suddenly all standard tools break) while still enabling rich content in files.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/brownplt/code.pyret.org/issues/346#issuecomment-847062983, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAA5IU3UDHM4PKXNLIMDYNLTPJL5XANCNFSM4RL6ZZTA .

jpolitz commented 3 years ago

(I don't mind if they have a different MIME type when saved through CPO, though!)

On Mon, May 24, 2021 at 8:07 AM, Joe Gibbs Politz @.***> wrote:

I don't think Pyret files should become non-plain text to make navigating GDrive easier :-)

On Mon, May 24, 2021 at 7:02 AM, Shriram Krishnamurthi <notifications@ github.com> wrote:

I've always wished we could store uuencoded or some other form of images in the .arr files. This would avoid the wxmedia nightmare of Racket (add done image and suddenly all standard tools break) while still enabling rich content in files.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/brownplt/code.pyret.org/issues/346#issuecomment-847062983, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAA5IU3UDHM4PKXNLIMDYNLTPJL5XANCNFSM4RL6ZZTA .

shriram commented 3 years ago

I think my point was that they should be plain-text files?