Rationalize modern Jupyter front-end offerings

[afshin]

This is a placeholder issue for JupyterLab 4.0's coverage of some of the different user experiences that the official Jupyter front-ends offer our users.

Problem

We currently offer:

• The classic Jupyter Notebook
• nbclassic
• JupyterLab default mode
• JupyterLab simple mode
• retrolab

Proposed Solution

We should build into the JupyterLab 4.0 roadmap a set of front-end offerings that covers the user experience aspects of the Classic Notebook (also nbclassic and jupyterlab-classic) that meet our users' needs, including:

• the jupyter ... commands that they invoke
• the pip install jupyter... commands they need to run to install them
• the extension installation experience (which front-ends am I installing this extension for, etc.)

cc: @Zsailer @jtpio @ellisonbg

[Zsailer]

In case anyone is interested, this topic is being discussed weekly in the Jupyter Notebook meetings, Wednesdays at 8:30 AM Pacific (on Jupyter's Zoom channel). That meeting will likely produce most of the in-person (virtual, of course) discussion, direction, and decisions raised here.

We can be sure to post the notes from those meetings here for public record.

[afshin]

Here are mock-ups (done by hacking some CSS) of what single document mode could look like for notebooks, editors, and terminals. The mock-ups aim to preserve the classic notebook’s mental model of working on a physical sheet of paper.

In this mode, we could also pop the file and running tabs out of the side bar, and make them available in the menus. That would give you all of the main tabs of the classic notebook. File -> Open would launch the file browser and View -> File Browser and View -> Running would also be available.

We can scope the context menu items available in single document mode to remove things like “Create new view for output” that only make sense in multi document mode. Extensions can generally choose whether to add/remove their side bar items based on the document mode.

The classic notebook applies dynamic width sizing based on window width. We can apply rules to accomplish the same regardless of whether a widget is in single document mode. We should also allow the user to take up the full width if they like, perhaps as a context menu option, and as a setting for the default behavior.

Notebook

Text Editor

Terminal

[blink1073]

cc @willingc @isabela-pf @fperez

[blink1073]

cc @choldgraf @betatim @yuvipanda

[choldgraf]

I would recommend as part of this also documenting this for others and providing guides to make it easy for the community to navigate this landscape! I think that JupyterLab is super overwhelming and scary for many people to understand, and there are a lot of really cool tools, workflows etc that people never learn about because they didn't happen to make the right google search

[ellisonbg]

Very cool explorations. Can you post screenshots of what it looks like with the L/R sidepanel expanded?

[ellisonbg]

Also, if you have the CSS for this could you post it here so we can try it out?

[afshin]

Here’s what it looks like with a smaller margin and the file browser open:

Here’s the CSS used:

.jp-MainAreaWidget {
    background-color: #eeeeee!important;
    padding-right: 100px;
    padding-left: 100px;

}

.jp-MainAreaWidget > .lm-Widget {
    -webkit-box-shadow: 0px 0px 12px 1px rgba(87, 87, 87, 0.2)!important;
    box-shadow: 0px 0px 12px 1px rgba(87, 87, 87, 0.2)!important;
}

.jp-Notebook {
    /* TODO: We should add a class to the content of the main area widget */
    margin-top: 20px!important;
}

.jp-Terminal {
    margin-top: 20px!important;
}

.jp-FileEditor {
    margin-top: 20px!important;
}

[ellisonbg]

Thanks @afshin I will play with this. What I am thinking about is how the L/R spacing around the notebook get's filled up by the L/R side panels when they are open. This is a key different between document oriented and IDE oriented interfaces:

• IDE oriented UIs tend to move content over when side panels open.
• Document oriented UIs tend to either use the L/R spacing for the side panels or to overlap content (and not move it over).

[willingc]

Thanks @afshin. This is a nice start.

One of my concerns is the side panel which takes up a lot of space when students open on a tablet. Is there a way to move the side panels to the top menu or integrate with the top menus?

The visuals help a ton. Thanks for including them.

[ellisonbg]

Yeah, in a mobile phone/tablet context there are a number of things we need to change, for both the classic notebook UI variant as well as the full JupyterLab UI. I have seen tablet apps with a single L side panel, but in a more compact manner (see the iOS HIG for example https://developer.apple.com/design/human-interface-guidelines/ios/bars/sidebars/). But definitely not both L/R side panels. There are a number of design patterns used in these contexts we could leverage such as tab bars ( https://developer.apple.com/design/human-interface-guidelines/ios/bars/tab-bars/) and accordians (https://www.nngroup.com/articles/mobile-accordions/).

…

On Thu, Mar 4, 2021 at 11:23 AM Carol Willing ***@***.***> wrote: Thanks @afshin <https://github.com/afshin>. This is a nice start. One of my concerns is the side panel which takes up a lot of space when students open on a tablet. Is there a way to move the side panels to the top menu or integrate with the top menus? The visuals help a ton. Thanks for including them. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#9869 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAGXUFSF45YJTF53A36N4DTB7M37ANCNFSM4YE2CAFA> .

-- Brian E. Granger Principal Technical Program Manager, AWS AI Platform (brgrange@amazon.com) On Leave - Professor of Physics and Data Science, Cal Poly @ellisonbg on GitHub

[isabela-pf]

Re-reading the initial comment for this issue, it sounds like the main solutions are focused on more on creating clear and consolidated descriptions of existing front-ends and their relationships to each other. Does that sound correct?

I definitely agree with @choldgraf that documenting these could be very helpful, but I'm going to think if there's any useful in-interface information since I always think there's a good chance people may not check external documentation.

[isabela-pf]

Re-reading the initial comment for this issue, it sounds like the main solutions are focused on more on creating clear and consolidated descriptions of existing front-ends and their relationships to each other. Does that sound correct?

I definitely agree with @choldgraf that documenting these could be very helpful, but I'm going to think if there's any useful in-interface information since I always think there's a good chance people may not check external documentation.

[aiqc]

@ellisonbg "document oriented and IDE oriented interfaces" says it all. The page is approachable and tangible. It's a good transition for users who are new to programming to make them feel comfortable.

I launched an old notebook included with an OReilly book the other day and was struck by how different the page made it feel. UX is emotional.

[meeseeksmachine]

This issue has been mentioned on Jupyter Community Forum. There might be relevant details there:

https://discourse.jupyter.org/t/benefits-of-the-classic-ui-and-use-cases-for-classic-over-jupyterlab-was-why-is-tim-not-moving-to-lab/2419/18

[jtpio]

We discussed this topic a little bit at the Notebook weekly meeting today and a couple of previous JupyterLab meeting too.

RetroLab (previously called JupyterLab Classic) has been out for a couple of months now and is continuously being maintained and released. Folks seem to like it and might consider it as an easy way to get into lab from classic, while keeping the document oriented UI.

The initial goal was to replicate the UI and workflow of the classic notebook, but using the modern JupyterLab components. Then the focus was more on providing an example distribution for those who would like to build their own lab-based app so they can have a better idea of how to do it. This was mostly to not give the false idea it will be an official classic notebook replacement.

We should build into the JupyterLab 4.0 roadmap a set of front-end offerings that covers the user experience aspects of the Classic Notebook (also nbclassic and jupyterlab-classic) that meet our users' needs, including:

Now I have been thinking: maybe we should just bring RetroLab intro the main JupyterLab repo for 4.0? There would be a couple of benefits to this:

• jupyterlab would offer a classic like experience for those who want to use a document oriented UI
• the "retro" bits of JupyterLab would sit behind (under its own endpoint). Folks happy with JupyterLab would not even notice it
• the name "retro" could be changed to something else (classic, doc as in "Document Mode")
• jupyter retro / jupyter doc / jupyter classic would open a classic like version of JupyterLab (pretty much RetroLab like it is now)
• the classic experience folks are often looking for is the ability to open documents, consoles and terminals in new browser tabs. And have the file browser in a separate tab. Which is what RetroLab provides.

About the technical aspects:

• Since the RetroLab shell is different than ILabShell, some third-party extensions don't work or are just not visible (added to the left and right areas).
• So maybe the retro shell should be a lab shell with hidden left and right areas and a bit of extra CSS
• RetroLab does not support "building extensions into it" (jupyter labextension install). But supports JupyterLab prebuilt extensions.
• Bringing retro into core would mean:
  • adding new packages to packages/
  • adding the Python handlers
  • update the build system to output new assets, if we want to keep the retro app and shell separate

This would also still be compatible with the existing JupyterLab normal mode and simple interface.

And of course it would also be perfectly fine to keep RetroLab separate in its own repo like it it now, as an unofficial Jupyter frontend that folks could still install if they want to. Just posting this here in case other folks would be interested.

[isabela-pf]

@jtpio thanks for bringing this up! I am in favor of having RetroLab in main JupyterLab.

I know we have the current simple mode/document mode, but I personally think this is a stronger iteration on the same idea. By having this mode already in JLab, we've already acknowledged that having a document-focused layout, like Notebook is often praised for, is something that we think serves users. I would not like to add another viewing mode to JLab, so I would love to see RetroLab be integrated as the new simple/document mode.

I also haven't come up with any way that this would negatively impact users since it doesn't interfere with the default JLab experience. Overall, it seems like a good opportunity to unify projects and give user more distinct experiences to choose between.

[jtpio]

FYI, I have opened jupyterlab/retrolab#257 to start thinking about what it would take to merge RetroLab and the JupyterLab Simple Interface.

[jtpio]

This topic was discussed at the Jupyter Governance meeting last week.

For more context:

• [Discuss] The future of the classic notebook interface jupyter/notebook#6210 (comment)
• [Discuss] ProtoJEP - the evolution of the Classic Notebook v6 and v7 jupyter/notebook#6220

[afshin]

I think we can close this issue because of the discussions and decisions made around Notebook 7, deprecation of retrolab, and the evolution of nbclassic -- all outlined in the Notebook 7 JEP that passed and subsequent discussions in the relevant repositories.