Benefits of the classic UI and use cases for classic over JupyterLab (Was: Why is Tim not moving to lab?)

Anything in particular holding you back from switching to Lab?

I just prefer the old UI in terms of it not being “IDE-like”.

Some examples off the top of my head (and I think they are probably “complaining at a high level”):

  • my browser already has tabs and keyboard shortcuts for switching, duplicating, closing, moving them so I don’t need tabs inside my tabs/end up doing weird stuff when muscle memory takes over
  • my most used button is “restart and run all” which is missing from the kernel controls
  • it feels like I have more “space” when using classic notebook. In lab I tend to make the file browser wider than the default and then hide it when I am not using it. A bit like my “two tabs” workflow but without keyboard shortcuts for switching between them.
  • it doesn’t feel like it solves a problem/pain point I have and it is different so old people like me are like “ahrg why you change things, aaahhhrgg”

edit to add things I am excited by:

  • I frequently switch to lab just to use the terminal because it is much nicer than the one in classic (when on mybinder.org)
  • the “single notebook only” view that Yuvi prototyped months ago and the “zen mode” experiment from the Cal Poly interns for lab is nice
  • better UX for “run stuff and make small edits” when using notebooks on a mobile phone (narrow portrait mode touch screen) (Feels like a toss up between lab and classic right now)

In particular for mobile (narrow portrait mode) I’d love a screen layout like:

Not sure what should be in the four buttons at the bottom but something like “file tree view”, “launcher view”, “notebook view” and “more stuff/menu”. The most important button is the play button to run a cell :slight_smile: I even wonder if clicking (in as much as you can do that on a touch screen) on a cell should switch it to edit mode on mobile.

6 Likes

I moved this to a new thread because it felt like it had little to do with the original thread. However I had no good idea for a subject. If you have an idea let me know.

1 Like

I changed the title again.

Saul, I use both Lab and Classic.

For teaching and demonstration to folks that are new to programming, the Classic interface is more approachable since there is less visual distraction and less complexity to get started (“Shift-Enter”). Although the single user mode is available, the Lab UI is still more complicated. Sort of like the difference between using the VSCode editor over mu.

There was some informal discussions at the weather/HPC conference this week and there was a healthy percentage of folks that they support that have tried Lab and choose to use Classic instead.

3 Likes

Just to echo what some others have suggested in this thread - I know many of the instructors at Berkeley will probably not transition to Lab until either:

  1. There’s a really strong case that’s made about why the widgets / visualization / modularity of Lab is beneficial for the data science courses (IMO this is a matter of more documentation to show what’s possible, and much better documentation to teach people to create their own labextensions and widget layouts, but right now we haven’t seen instructors organically start building on top of JupyterLab because it’s really hard to do this unless you’re a seasoned javascript developer IMO)
  2. There’s something “streamlined” with minimal extra buttons and options, such as the simplest notebook or the CalPoly clarity mode demo. In many ways, the benefit of the Notebook UI is that it restricts the space of what’s possible so that you can focus on the narrative + coding around that narrative, which is quite useful for teaching. Lab expands what’s immediately possible, which is super useful if you know what you’re doing, but also comes at a cognitive cost, and cognitive costs get amplified when you’re teaching to people new to coding.

edit: I was just thinking about this a little bit more, and a question that comes to mind is “how does JupyterLab differentiate it from tools like VSCode?”

By that I mean: one of the most common metaphors I hear for JupyterLab is that it is “an IDE”. This then draws a comparison to other IDEs like vscode or atom, and is at an immediate disadvantage because Lab backs much of the developer firepower and broad community that the other major IDEs have.

My personal opinion is that Lab shouldn’t be categorized in the same group as these tools, but I sometimes struggle to point out exactly why, and I think the community could make this case more strongly.

Put another way, I think JupyterLab needs to make a case for itself as a standalone platform. Compared directly to the Notebook UI, it feels like there are too many “knobs” to turn, and doesn’t have that streamlined focus on the content. Compared directly to a major IDE, it feels underpowered. I think we need to make a clearer case that Lab isn’t “just an IDE” or “just another notebook interface”, but something that’s greater than the sum of its use-cases.

3 Likes

I think we have a lot of opportunity to define what sort of platform it will be. The Lab team has done a fantastic job getting us to where we are: they built the huge Lego set that’s on the cover of the box, and the challenge is now showing people that they can use those pieces to build whatever they want.

documentation to teach people to create their own labextensions and widget layouts

The writing of the documentation is part of it: where the next Lab developer consumes those docs for developing Lab, counts to: I submit that needs to happen in Lab. Having a general story for in-Lab docs consumption and editing is huge, and is a potential platform.

A big limiter there is not being able to use Lab itself to meaningfully develop things for Lab, so they would presently say things like now go over to your real editor. jupyterlab-lsp nailed down, and merged into core lab, would make the in-Lab docs much more tractable, with words like, click here to open extension.ts

The “four kinds of docs” stuff has been making the rounds again. People love to use notebooks for the interactive/practical piece, but for their software, presupposing someone has already learned Jupyter. How might we build that agency/mastery? One (of very few) things I miss from bootstrap was bootstrap-tour. We really need (discoverable) in-Lab tours (built on some lower-level macro system) for all sorts of things, without going too far down the clippy route, and we need to be able to build/script and remix them in Lab out of commands. That right there is a platform.

“streamlined” with minimal extra buttons

This has come up a few times, and I desperately want to see it happen, but usually end up needing all the bells and whistles lab has: the ability to create at view of two (or n) things at once in a coordinated way that didn’t have to be coded.

That being said, a lot of work is best when focused upon. The CalPoly rich text mode project use of Prosemirror is probably the future: let PM own the nbformat, and transparently show CodeMirror code cells and outputs. Launch with lab/minimal/Untitled.ipynb and need no more chrome than a chompy hamburger menu to show the sidebar. Get rid of prompts entirely. That is another platform.

Compared directly to a major IDE, it feels underpowered

see above re: LSP. Also, developing for any IDE is hardly a walk in the park… we just need to make it even easier to use and own. Further, those applications’ entire audience is developers. We want everyone to be able to build tools for interactive computing. Because Lab can wrap basically anything, we need to figure out how to move features like tours, theming, syntax highlighting into schema-constrained data (in a schema someone else built, preferably) and then build good, extensible UI for it, reusing the best existing stuff we can find.

4 Likes

One trend that I see is that the growth in data science / data analytics support in IDEs/editors makes it much easier for existing users to stay with the classic notebook.

Generally, the most common pattern I find at my company is folks opening both a jupyter notebook and an IDE/editor (e.g., VSCode, PyCharm, Vim, Spyder) when doing their data work. In the past, one would start exploring and developing their analysis/models/data pipeline in jupyter and then using their IDE/editor tools to “productionize” the work. You would go back and forth until the particular project was “done” and the notebook would serve as a data app that could be easily rerun or tweaked with widgets or as documentation if the project had a more software flavor to it. I think this is still common overall and projects like Jupytext have helped make this much more convenient. Jupyterlab helped greatly with this process because you might be working with a variety of text files and notebooks at the same time.

Nowadays, I am increasingly seeing notebooks used as an ending point vs where one starts. As many IDEs/editors continue to improve their support of notebooks as well as building quality of life tools (like plot viewers, data viewers/variable explorers, data exploration tools, remote server support, debugging) then it makes the classic jupyter notebook + IDE setup much stickier. You start your work in your IDE and then switch to notebook only when you are either building the documentation, need a complex visualization, or using it create a rich data app with things like Voila, widgets, etc. In those scenarios, a notebook used in lab is not that different than using the classic one.

When folks are doing most of their text editing and terminal work in their IDE and already familiar with the classic notebook then it can be difficult to change behaviors. I find that it is easiest to convince folks that are working on highly complex projects where you might have large numbers of notebooks, data files (images, csvs), and multiple programming languages. In these situations Lab is one of the few tools that enables you to quickly navigate these elements in productive way.

3 Likes

I found that broken extension based on react-joyride. And I agree a tour would be nice to help users discover Jupyterlab UI.

2 Likes

I have been moving my BI and analytics team to Python over the past 6 months. Only 2 or 3 out of 7 had some Python experience. I have a couple of things to add here:

  • Jupyter Lab is for us a lot better because you can work with multiple files easily. Being able to read .csv files, for instance, is a big win. Now if we could read also excel files it would be even better

  • There is a lot of (unfair?) competition. Some of my team analysts also use Visual Studio or Atom as we have an internal Python library for data analytics. They are sometimes using those IDE’s to develop/edit jupyter notebooks

  • The editor in jupyter lab is quite basic and buggy. Sometimes you press shift/tab and you get the function doc string, sometimes not. I think Jupyter Lab should embrace the Monaco editor

  • Git versioning for notebooks is not straightforward enough. Ideally we have an easy way to commit notebooks to “publish and deploy” workflows

  • When it comes to scheduling and orchestration we find python modules a lot better suited than notebooks

I tend to agree that the new architecture behind jupyter lab is the way to go but we lack good extensions. Ideally the lab is all an analyst needs to do their job, this means we need a lot more extensions. But then again, is there some way to fund extensions? Can there be a paid version of extensions like in wordpress?

I think people are sticking to the old version of jupyter because the lab is not offering enough of an improvement. I think we all expect extensions to play a big role here but so far the extension ecosystem is lacking, I ultimately think that’s the problem jupyter lab is facing (better more reliable extensions).

3 Likes

Just wanted to chime in here and thank all of you for these detailed comments. It’s great to have them all together here, to help drive future direction.

On one specific point:

I agree and I have started compiling a list of pain points we can be aware of as we put some work into extending the build system at our next sprint: https://github.com/jupyterlab/jupyterlab/issues/7468 If you have any further ideas, please chime in there!

2 Likes

I want to pitch in some UI/UIX improvement ideas as someone who has set-up JupyterHub + JupyterLab for the Data Scientists and non-technical users (low on Python coding experience).

  • Add to the GUI toolbar:
    • “Move selected cells up/down”: ↓, ↑
    • A drop-down arrow Ë… next to the + which enables options like “Insert (e.g. Markdown) cell above”: Especially helpful if there is no “Move cell up” button
    • Keyboard Icon in toolbar that opens “commands” which only shows “notebook cell operations” (pre-entered in search bar).
    • Add shortcut text behind the name or in de tool tip: Prevents the need of any tutorial or someone telling you, you can use “shift+enter” to run a cell. Take a look at Blender for inspiration.
  • Create a natural learning curve to go from “beginner that uses interface buttons” to “shortcut expert of often used function” design narrative. For every GUI change, think of how it can help beginners grow, while not impairing advance users.

Blender user interface

Take a look at Blender 3D creation suite (https://www.blender.org/) for insights how to create an UX/UI experience that caters to beginners and professionals alike. With v2.79 to v2.80 they went from a “program for the poor student and hobbyist 3D modeller”, to “we take over Maya and other industry giants while staying open source and free” (and even getting big companies to invest in them).

A big reason for this new success is their redesign of the interface (13:28): https://www.youtube.com/watch?v=MyxWDHy4ppY

  • It would be great to have a full interactive experience (graphs and sliders, maybe in combination with Panel Pyviz (cannot add more than 2 links)) without showing any code. I know this is already somewhat possible, but not so straightforward. The use-case would be that Data Scientist need only to make minimal changes, which than can be shown to less technical people who still want some data insights through a GUI, but are afraid of lots of code (also useful for mobile access, as mentioned by @betatim above).
  • Make a notebook read-only. When I had to set it up months ago, I achieved this by setting Unix permissions to not allow “write”. Not sure if anything changed already?
  • Show an error if a user presses “ctrl+s”, but it cannot be saved (e.g. due to permission errors).
6 Likes

(Sorry, can only add 1 image per post)

  • Remove the context dialogue when using Terminal. It blocks the natural way programmers use the terminal only for the limited functionality of refreshing the terminal. Refreshing functionality can be added to âźł in the terminal tab / (EDIT) or move the right-click functionality to the tab area itself, instead of inside the tab window (add “refresh tab” to right-click terminal-tab (above “close tab”)).
  • Move the + from the “file browser” right-side-tab to the tabs with notebooks and such. This is a more straightforward location (like a browser), is not hidden if “file browser” is not selected, and allows the tab to be added to correct tab when using split screen mode.
  • “Close all other tabs” to only apply to that split screen window.

5 Likes