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.

9 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.

2 Likes

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.

4 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.

4 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: Extension Development Wishlist · Issue #7468 · jupyterlab/jupyterlab · GitHub 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).
7 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

I think there’s a lot of folk arguing at cross purposes in the JupyterLab vs Jupyter notebook debate, in part arising from orthogonal community and use cases from which arguments are made, in part from different experience and expectations levels.

For me, the classic UI has benefits of making computing relatively accessible to folk who aren’t and never will be developers and don’t want to spend time learning how to be developers. It encourages linear scripts / narratives and it can act as a computational notebook that lets you do quick calculation stuff in an ad hoc way.

The linear narrative is useful for things like documentation and tutorials where you also want to support live interaction, and where the focus is on the notebook content and code execution outputs, (i.e. the focus is on the document and its content) not on the features afforded by a complex environment that wraps around the document.

The notebook UI also lets folk do quick calculations like they would in a spreadsheet, but in a linear format and in a relatively simple environment, like a spreadsheet sheet without lots of complex tool bars and cluttered sidebars to complicate things. In the classic notebook UI, the focus is on the document.

This is not the same use case as developing packages; many of the use cases I have for notebooks are simple one off scripts and they have zero overlap with package development requirements. And I wouldn’t know what to do with a debugger even if you gave me one, so the lack of one is not an issue; cell level repr displays are way more powerful than print debugging statements, and that’s the level I’m at an unlikely to ever get past.

To a certain extent, the notebook UI humanises computing and provides and environment that folk can use to do computing-y stuff without being a developer.

There are a lot of nice features in the JupyterLab UI when it comes to being able to run multiple panels in a single view at the same time, but a quick hack can pop out cell outputs in notebook in to a floating widget that affords some similar behaviours (like keeping the results from one code cell in floating view as you scroll a notebook. It’s not too hard to tweak the notebook CSS to dodge the by default central notebook view to a left aligned view that is draggable width wise etc. This falls short of JupyterLab behaviours, but it’s good enough. (I remember early days of IPython notebooks, where a lot of features seemed at best “good enough”…And they were…)

For more adventurous users, the classic notebook is relatively easy to build extensions for by copy and pasting legacy extensions and writing simple javascript. If I need a dev envt to start building something, then installing it is a hurdle I’m unlikely to get past.

I have to admit I also get confused at folk who say that the notebook suck for developers and JupyterLab is the answer, whereas if I were teaching folk to use an IDE because they were going into a developer role, I’d probably suggest they use something like VSCode, PyCharm, Eclipse etc, which tends more towards the employability relevant/industry standard personal development environment.

I do see value in JupyterLanb, but I also think that many arguments made in favour of moving to JupyterLab are made by people who like computers, rather than people who hate them and want as little to do with them as possible, but who see the utility of things like spreadsheets and might also be persuaded to see the additional benefits of linearising operations in the the narrative scripted way that notebooks afford. But who will never entertain the possibility of using anything that looks like an IDE.

1 Like

I think for many folks (at least in my experience), Notebook vs Lab is quite an odd situation to encounter within the scientific computing space which is why there is so much debate and interest to find ways to close the gap. When I look back on my own experience over the years with teaching folks scientific computing and tools (like RStudio, SPSS, Matlab, etc), you never really had a situation where a major upgrade/expansion of the toolchain led to a split in the community (except perhaps Python 2 vs 3).

One of the core causes I think is that many of these tools have a natural growth path from intro/non-technical user to power-user and this is where JupyterLab can feel awkward. The story here is improving over time but there is quite a bit of friction at the moment.

I’ll use the example of RStudio. Often when R is taught as part of an intro stats or analytics course, most students will only be taught to use the text editor and console and the rest of the features will be ignored. And for most people this is great. You double click to open RStudio, you select a chunk of text, use a shortcut to send to console, and suddenly you have results and plots. You could use RStudio in this way year after year and never need to use (or even visually see) any of the advanced features (e.g., RMarkdown, RNotebook, version control, package mgmt, etc) unless you started working on projects that required them. In that case, RStudio would “grow” with you as your work complexity increased but still served the simple user as expected. (Note: I am describing my experience with developers and technical non-dev users like scientists or researchers)

If you were someone who has been using classic notebooks then you have to deal with a much more dramatic change and I find this is at the heart of the issue vs the community or tool having different use-cases. If you are a classic notebook user and you upgrade to Lab then all of your extensions break, the behavior of the notebook is not exactly the same (perhaps this is more aligned these days), and in practice it is more difficult to manage it (e.g., people are often bewildered by JupyterLab’s build process because they have never encountered one before).

Instead of being perceived as simply an upgrade (e.g., RStudio version x to x+1), it can feel like you are using a different tool and without a ton of clarity why (or even a worse one depending on the extensions you relied on). Early on one of the main blockers I encountered was users not understanding why their nb_extensions were not working when they started JupyterLab or interpreting the presence of a build process as “this tool is in alpha/beta version.”

On the development/IDE side of things this “growing with you” problem comes in at the higher-complexity work. For a power-user, JupyterLab provides great tools to do really advanced modeling and analysis with tons of flexibility. You end up hitting a wall when your projects reach a certain size and you need more advanced functionality like multi-file/multi-line editing capabilities (particularly of text files). The reason this is an issue is that most of the standard IDEs (PyCharm, VSCode, etc) have pretty poor support for data science workflows due (but not limited) to things like not supporting all the packages you might need (e.g., Altair in PyCharm), extremely clunky visualization tools (e.g., VSCode’s plot viewer/interactive window), poor non-static intellisense (e.g., pandas method or dataframe column completion), or just having buggy notebook support in general. Jeremy Howard has many good comments/perspective on this topic.

The result is that you end up with this situation where you need to use 2 tools simultaneously: JupyterLab for the iterative parts of the workflow and an IDE for the package development/advanced editing functionality. This is fraught with its own issues in that now people need to maintain and learn 2 separate tools and often leads to more mistakes due to things like having to manually copy and paste frequently. Going back to the RStudio example (though also applies to things like Matlab, SAS, etc), you generally see everyone using a single tool from intro to advanced user unless you are really doing something far outside of a data science / analytical task.

And one thing I would also point out is that these are not developers in the traditional sense but data scientists or statistician/academic types that know how to code for analytical purposes and their projects often have different needs than what you see in a traditional software role (though there are areas of overlap). So when people talk about things like “notebooks suck for developers” it is not because someone is trying to build something like Instagram from a notebook but that building repeatable analyses/models can be quite difficult at the moment due to the lack of standard tooling/IDE-support around these things.

I think many people see JupyterLab as being able to overcome these frictions since it has all of the right ingredients to enable you to be successful whether you are just starting and need to run simple notebooks/scripts or are doing big modeling projects on a cluster. Much of this can be fixed with UX changes and as the extension ecosystem continues to mature the friction around the things I describe above is improving pretty quickly each year.

Note: This is particularly focused on the Python community (since Julia and R users have their own IDEs so they would have a different perspective)

3 Likes

Along these lines, it is probably best to highlight recent work by Jeremy Tuloup (@jtp) and contributors on jupyterlab-classic. See announcement of the release candidate here with a link to launch via MyBinder for trying it.

“The goal of the jupyterlab-classic project is to look as close to the classic notebook UI as possible, while leveraging the efforts put in the development of JupyterLab itself and its extension system.”

4 Likes

Thanks @fomightez for sharing!

“The goal of the jupyterlab-classic project is to look as close to the classic notebook UI as possible, while leveraging the efforts put in the development of JupyterLab itself and its extension system.”

Just a quick update: after a couple of iterations and discussions, we started to think that the goal of JupyterLab Classic might not be to be exactly like the classic notebook, but more something like this:

Jupyterlab Classic is an alternative JupyterLab distribution with the look and feel of the Classic Jupyter Notebook UI

(updated the README to reflect this)

3 Likes

@jtp I’ve just experimented with JupyterLab Classic and wanted to congratulate you all for listening to users. I feel this is the way to go for JupyterLab. As others have commented, JupyterLab unfortunately came out as a complicated version of JupyterNotebook and a half-assed version of an IDE, despite the technical improvements. This year we’ll be switching students to JupyterLab Classic and hopefully they’ll be able to transition to JupyterLab in the future if they feel like it.

I think longterm these projects should be merged though. The names are also getting a bit clunky. I’d rebrand “JupyterLab Classic” as JupyterLab Simple, bundle it with JuypterLab and make it the default for creating new notebooks.

Thanks @PepeMandioca for the feedback :+1:

Glad to hear. Don’t hesitate to open new issues on the repo if you have more feedback about JupyterLab Classic!

There has been some discussion around this topic in this issue, which includes screenshots of what it would look like to add the JupyterLab Classic feel to the JupyterLab Simple Mode:

2 Likes

I’m also still squarely on Classic :grimacing:

2 Likes

@labarba Me too… I don’t have the skills, or time to learn/develop the skills, being not-a-developer, to update the really simple HTML/js extensions and magics we use to support teaching to Typescript’n’complicated frameworks’n’etc etc.

If the jp-proxy-widget wrapped js-app widgets we also rely on “just worked” as tear-offs with sidecar, that might be enough to nudge us over, but they don’t; and the plumbing required to decouple our apps from the jp-proxy-widget hooks we cobbled together and then wrap them as “proper” ipywidgets that work in standalone panels in JupyterLab is way beyond my skill set.

1 Like