UI

[minrk]

Once we have the API (#6), we'll want a basic web UI for managing, browsing shares. I've added an empty package.json, assuming we'll be using the npm-style tooling we have elsewhere. I'd like to give react+es6 a try here, rather than the phosphor+typescript approach in JupyterLab. This won't be a desktop-style multi-pane application with menubar, commands, etc.

We should draft what sort of features are needed in the UI, and what each page should look like.

Basic pages:

• user's home
• list user's shares
• single share
  • owner actions: delete / rename / modify / upload
  • non-owner actions: download (more?)
• list other users and their shares

[minrk]

Related questions:

what should a view of a single share look like? Does it need things like browsing files in the share, showing rendered notebooks, etc.? A simple file-listing and single-file view could be handled simply enough without needing to unpack the uploaded zipfiles.

cc @ellisonbg

[ellisonbg]

@minrk thanks for opening these issues! I am buried with teaching this week, but wanted to give a few super quick ideas:

• Totally fine with react for rendering stuff like the hubshare ui.
• Would prefer typescript for any programmatic APIs, but babel + Typescript type files are fine.
• In terms of the UI, I think we will need something that is highly integrated with the file browser in the classic notebook and in jupyterlab. The reason for this is that at least two panes will be needed: one to show the hubshare entities, and another to show the file system where existing hubshare downloads would be and where uploads would by copied to. In JupyterLab we would definitely add drag-n-drop for those interactions.
• Because of the high level UI integration needed, I think we should start with a command line "UI" (similar to nbgrader's) that will work for users in both classic/JupyterLab. That will also ensure there is a smooth transition for nbgrader.

On Fri, Jan 27, 2017 at 6:48 AM, Min RK notifications@github.com wrote:

Related questions:

what should a view of a single share look like? Does it need things like browsing files in the share, showing rendered notebooks, etc.? A simple file-listing and single-file view could be handled simply enough without needing to unpack the uploaded zipfiles.

cc @ellisonbg https://github.com/ellisonbg

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jupyterhub/hubshare/issues/7#issuecomment-275681970, or mute the thread https://github.com/notifications/unsubscribe-auth/AABr0MKd69LdMdB6T81KWvbz-BIl-X0Vks5rWgPEgaJpZM4LvyYw .

-- Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgranger@calpoly.edu and ellisonbg@gmail.com

[minrk]

Another design question is how much of the UI should be presented in the single-user extensions vs pages served by hubshare itself. I'm mainly thinking here of the pages served by hubshare itself. The JupyterLab plugin should certainly integrate with JupyterLab's design, but I imagine the main things it would have in common with the hubshare pages is the REST API and possibly a js client to that API, and that's about it.

[ellisonbg]

I don't know what separate hub share pages would offer. Even the most basic operations exposed in the UI would also need access to the contents API and file browser UI. But yes, minimally, the different UIs would share the REST API and a JS client to that. Just to make sure we aren't talking past each other, what were you thinking the standalone hub share pages would allow the user to do? I guess I was thinking the entire hubshare UI would be single user notebook/jlab UI extensions, but there may be other aspects that would point to a separate set of pages.

On Wed, Feb 1, 2017 at 3:30 PM, Min RK notifications@github.com wrote:

Another design question is how much of the UI should be presented in the single-user extensions vs pages served by hubshare itself. I'm mainly thinking here of the pages served by hubshare itself. The JupyterLab plugin should certainly integrate with JupyterLab's design, but I imagine the main things it would have in common with the hubshare pages is the REST API and possibly a js client to that API, and that's about it.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jupyterhub/hubshare/issues/7#issuecomment-276817767, or mute the thread https://github.com/notifications/unsubscribe-auth/AABr0OhPqnBZVg2c7CscbcGjIMaAk3_Tks5rYRWwgaJpZM4LvyYw .

-- Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgranger@calpoly.edu and ellisonbg@gmail.com

[willingc]

Also https://notebooks.azure.com/faq#libraries has a pretty intuitive UI approach.

[ellisonbg]

Yes, they did a really nice job of their UI. The main difference is that the sharing semantic and units are different from that of hub share. In their Azure notebooks Libraries feature a "library" is all of the files in a given notebook instance. For us, it is a subdirectory within a notebook server. This would be akin to JupyterHub starting a separate notebook server for each user, for each and every "project" they were working on. While I think there are many usage cases where that works really well, it would be very awkward for things like nbviewer and would require a complete redesign of jupyterhub. But there are definitely things about their UI that I like.

On Wed, Feb 1, 2017 at 3:50 PM, Carol Willing notifications@github.com wrote:

Also https://notebooks.azure.com/faq#libraries has a pretty intuitive UI approach.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jupyterhub/hubshare/issues/7#issuecomment-276821685, or mute the thread https://github.com/notifications/unsubscribe-auth/AABr0Iz94oIp2hKhpRZXzaS389HUyinHks5rYRpIgaJpZM4LvyYw .

-- Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgranger@calpoly.edu and ellisonbg@gmail.com

[minrk]

@ellisonbg I was thinking pretty much the opposite - that the single-user extension would provide the bare minimum, probably start with just adding a 'publish this' action to directories, and ~all UI for HubShare would be handled by pages on HubShare itself (browse, search, manage, rename, etc.).

[ellisonbg]

I think we are going to need both. There are something that would work fine separately and then the classic notebook and other jupyterhub hosted things (even things like RStudio) could take advantage of them.

But there are definitely some things that will likely require full, in depth integration with JupyterLab:

• Detailed interactions with the jupyterlab file browser (drag-n-drop) putting hubshare bundles to particular paths and back, showing which directories in the filebrowser are hubshare bundles (think of how git extensions to VSCode, Sublime, TextMate work).
• Interactions with non-file system based content APIs. The biggest example we pretty much have to support is the jupyter-js-services implementation on-top of the google drive client side APIs. Ian has built this and it is already working at some level. Showing integration of real time collab with jupyterhub is one of the core grant deliverables and a huge feature for educational usage cases.

Based on this, I think the best way forward is to start by building the JS (JS+TS type files, or pure TS) and Python client libraries and then using that to integrate with 1) Lab directly 2) classic notebook 3) separate hub share pages (react.js is fine) and 4) command line.

How does that sound?

On Mon, Feb 6, 2017 at 3:03 AM, Min RK notifications@github.com wrote:

@ellisonbg https://github.com/ellisonbg I was thinking pretty much the opposite - that the single-user extension would provide the bare minimum, probably start with just adding a 'publish this' action to directories, and ~all UI for HubShare would be handled by pages on HubShare itself (browse, search, manage, rename, etc.).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jupyterhub/hubshare/issues/7#issuecomment-277636844, or mute the thread https://github.com/notifications/unsubscribe-auth/AABr0KMncgzu2wYEeDEKAjDBELlNYrS-ks5rZu_hgaJpZM4LvyYw .

-- Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgranger@calpoly.edu and ellisonbg@gmail.com

[minrk]

But there are definitely some things that will likely require full, in depth integration with JupyterLab:

Yes, this is mostly a JupyterLab plugin. The main 'integration' is that both the JupyterLab plugin and the HubShare pages use the same REST API. There will likely be close to zero browser-side code in common beyond a tiny client for that API, since it's ~all UI that they won't have in common.

Showing integration of real time collab with jupyterhub is one of the core grant deliverables and a huge feature for educational usage cases.

How would HubShare interact with real-time? Since it's for this publish/download model, it doesn't seem like it would have any relationship. I agree that real-time is important, and I'm mostly waiting on the single-user server to support it before I can do anything in JupyterHub. I'm not sure how HubShare would connect to it, though.

How does that sound?

Sounds great! I'll try to get started putting the skeleton together, but probably won't have anything until I'm at Berkeley after SIAM.

[ellisonbg]

Great question how would HubShare interact with real-time. Here is the usage case I see for that:

Imagine teaching a course using a JupyterHub+JuptyerLab+nbgrader+hubshare deployment. But imagine that there is a lot of group work so the profession sets up JupyterLab to store all notebooks on Google Drive and installs the RTC extension for JupyterLab. No notebooks would ever live on the file system, but the professor/students would still need to push/pull notebook from Google Drive to/from HubShare.

Or imagine someone writes an S3 based notebook store for their organization (as an entirely frontend jupyter-js-services implementation).

In both of these cases the connection point between hubshare and the contents API would take place in the browser. As long as the hubshare API allows the incremental creation of a shared directory by uploading individual files/notebooks, that would work just fine. Download could also be done in a similar manner. The only difference between this and talking to hubshare from the server is the language that is doing that.

All of these usage cases are basically making sure that hubshare isn't welded to a file-based notebook store.

[minrk]

All of these usage cases are basically making sure that hubshare isn't welded to a file-based notebook store.

Yup, I think both directions are planning to use REST APIs, so storage doesn't matter. If Lab is talking directly to Drive / etc., that would mean that HubShare will not be able to push or pull files to users, only notebook clients can push/pull to HubShare. This is because HubShare cannot execute code in users' browsers, which is the only context with access to the user's Drive (or whatever) storage when the contents service is implemented client-side.

In general, I think this and other things point to pull from the client (JupyterLab plugin) being more important than push from HubShare. Not least of which being that push from HubShare cannot happen unless the destination single-user server is running, even when it's talking directly to the server contents API.

[ellisonbg]

Yep, fully agree. In fact, I think that using a pure pull from client approach would be fine. There is always going to be a client that can do the pull actions right?

[minrk]

There is always going to be a client that can do the pull actions right?

Yes, definitely.