What we decide on to be the default matters a great deal. I think we should make it so that the default is to use jupyterlab.
Yay or nay?
I would wait until there is a none beta release of JupyterLab.
IMO we can also let the JupyterLab community guide us on this.
@ian-r-rose @jasongrout @ellisonbg it'd be great if, over time, y'all could give us ideas for when to start "defaulting" to jupyterlab.
Lab|Notebook|Me
-|-|-
|
|
lol that's amazing
FWIW, as of JupyterLab 0.33, we have dropped the Beta label
On Tue, Jul 31, 2018 at 11:58 AM Chris Holdgraf notifications@github.com
wrote:
lol that's amazing
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jupyterhub/zero-to-jupyterhub-k8s/issues/776#issuecomment-409331063,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABr0NoWZ1JKqIyxUp6ao0CSCTCJD2Wzks5uMKjkgaJpZM4VZqhq
.
--
Brian E. Granger
Associate Professor of Physics and Data Science
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
[email protected] and [email protected]
Yaaaaaaaaaaaaaaaaaaay!!!!!
Well the base notebook that we are using as the default image for a z2jh deployment, got bumped YESTERDAY to JupyterLab 0.33!!!
I say let's do it!
I should note that some functionality that cover feature parity with the
classic notebook are in extensions right now. In the coming months many of
those will be merged into the main distribution, but we may want to think
about having a canonical set of extension that get installed.
On Wed, Aug 1, 2018 at 10:10 AM Erik Sundell notifications@github.com
wrote:
Yaaaaaaaaaaaaaaaaaaay!!!!!
Well the base notebook that we are using as the default image for a z2jh
deployment, got bumped YESTERDAY to JupyterLab 0.33
https://github.com/jupyter/docker-stacks/commit/25181541de5e8da7c315ff6d8f3319ff84367642
!!!I say let's do it!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jupyterhub/zero-to-jupyterhub-k8s/issues/776#issuecomment-409649823,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABr0JNnPoPecvFX0YlEkJm1W4SqOQI7ks5uMeDzgaJpZM4VZqhq
.
--
Brian E. Granger
Associate Professor of Physics and Data Science
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
[email protected] and [email protected]
wow I didn't realize that beta would get dropped so soon. hmmm, in this case I am more open to JupyterLab by default.
My main question is: @ellisonbg and others, what's your main experience with "first timers" seeing JupyterLab? Are we at a point where there's enough good documentation out there that it doesn't scare people away w/ the extra complexity?
My experience with JupyterLab first-timers is that the usability of lab is
equal to or better than that of the classic notebook. My biggest source of
data for this is that I have been teaching intro to Data Science in Python
each winter quarter (about 60 students/year). I am with the students 6
hours a week, working with them all closely as they code. I had used
classic for years and this past January (2018) used Lab. Using lab with
year for the first time was very pleasant and, in a number of ways much
better than classic. However, I should note that both lab and classic have
ongoing usability problems that often tower over other improvements we have
made:
As we have resources, we are tackling these and other usability problems in
lab, so the situation should get better in the coming months.
At the same time, we still hear from folks that "lab is more complex than
classic." We have worked extremely hard on its design and have specifically
worked to preserve the simplicity of the classic notebook. We would love to
understand this perception, but haven't had the resources to do a formal
study. Even though many individual UI elements in lab are simpler than in
the classic notebook, I think there is something to these perceptions and
am hopeful we can understand and address it.
The user documentation in lab is in reasonably good shape, but in my
experience, most first timers won't even get to the docs if they have a bad
experience in getting started on their own.
However, we have enough users of the classic notebook, I don't think there
is any harm to introducing "lab as the default" slowly. One of the big
lessons of the Python 2 -> 3 transition for me was "more carrot, less
stick." I want people to switch to lab because there are so many great,
cool things that they want to use it - not because we force them to.
On Wed, Aug 1, 2018 at 11:30 AM Chris Holdgraf notifications@github.com
wrote:
wow I didn't realize that beta would get dropped so soon. hmmm, in this
case I am more open to JupyterLab by default.My main question is: @ellisonbg https://github.com/ellisonbg and
others, what's your main experience with "first timers" seeing JupyterLab?
Are we at a point where there's enough good documentation out there that it
doesn't scare people away w/ the extra complexity?—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jupyterhub/zero-to-jupyterhub-k8s/issues/776#issuecomment-409676332,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABr0BP4P8evMoa4270KPfy8bzRu43GKks5uMfPfgaJpZM4VZqhq
.
--
Brian E. Granger
Associate Professor of Physics and Data Science
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
[email protected] and [email protected]
One of the big lessons of the Python 2 -> 3 transition for me was "more carrot, less stick." I want people to switch to lab because there are so many great, cool things that they want to use it - not because we force them to.
Maybe we can start with making "change to using lab by default" a recommended first task/exercise for customising your hub. So either add it to https://zero-to-jupyterhub.readthedocs.io/en/latest/setup-jupyterhub.html or link to "change to lab" as the next step?
@betatim I like it! I think it will be a z2jh maintainer experience, setting something up without trouble and things just work (because it is just adding /lab to singleuser.defaultUrl I think).
@ellisonbg thanks for this write up! Getting such experience isn't easy, so I consider being able to pick up on your insights very valuable to me! By the way, regarding the horrible user experience of running out of memory - https://github.com/jupyterhub/kubespawner/issues/223 (and duplicated on JupyterHub: https://github.com/jupyterhub/jupyterhub/issues/2043)
I like the idea of making the documentation for this step more front-and-center. That's a nice compromise!
I think https://github.com/jupyterhub/kubespawner/issues/149 is related as well.
Any more thoughts .... should we handle this alongside https://github.com/jupyter/repo2docker/issues/724 ?
I think that we could make the default different in Z2JH before we do it in repo2docker since it affects fewer users. That said, I am not sure what's the criteria that we should use to switch. Perhaps if we get some data saying that a majority of users prefer the JupyterLab interface to the notebook interface?
At a minimum, I would wait until we have finished the work to make
JupyterLab's single document mode a suitable replacement for the classic
notebook style UI. We are aiming to have that in place for JLab 3.0 this
summer.
On Thu, Jun 11, 2020 at 4:16 PM Chris Holdgraf notifications@github.com
wrote:
I think that we could make the default different in Z2JH before we do it
in repo2docker since it affects fewer users. That said, I am not sure
what's the criteria that we should use to switch. Perhaps if we get some
data saying that a majority of users prefer the JupyterLab interface to the
notebook interface?—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jupyterhub/zero-to-jupyterhub-k8s/issues/776#issuecomment-642976923,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAGXUFAIK5NCTAOKBONSK3RWFQWVANCNFSM4FLGVBVA
.
--
Brian E. Granger
Principal Technical Program Manager, AWS AI Platform ([email protected])
On Leave - Professor of Physics and Data Science, Cal Poly
@ellisonbg on GitHub
@ellisonbg that is both
We are looking at having the improved single document mode included in the
URL (maybe /sdm rather than /lab) so it would be possible to modify the
jupyter lab command to direct the user there on launch
On Fri, Jun 12, 2020 at 8:02 AM Chris Holdgraf notifications@github.com
wrote:
@ellisonbg https://github.com/ellisonbg that is both
- Very exciting to hear about the single document mode (will it be
activate-able via the launch command? then that should be an easier switch
for z2jh and binder)- Sounds like a good criteria for switching to me
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jupyterhub/zero-to-jupyterhub-k8s/issues/776#issuecomment-643320873,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAGXUDT2OSIKGBN5E2S35DRWI7RXANCNFSM4FLGVBVA
.
--
Brian E. Granger
Principal Technical Program Manager, AWS AI Platform ([email protected])
On Leave - Professor of Physics and Data Science, Cal Poly
@ellisonbg on GitHub
@jupyterhub/jupyterhubteam what are your thoughts about having /lab as a default at this point in time?
I think that the improvements to single document mode help a lot. Perhaps we can wait for a few release cycles of JupyterLab 3.X to wait for the bugs to get worked out, and more importantly to wait for the extension ecosystem to be 3.X-compatible, and then make the switch?
Perhaps we can wait for a few release cycles of JupyterLab 3.X to wait for the bugs to get worked out, and more importantly to wait for the extension ecosystem to be 3.X-compatible, and then make the switch?
+1
Most helpful comment
At a minimum, I would wait until we have finished the work to make
JupyterLab's single document mode a suitable replacement for the classic
notebook style UI. We are aiming to have that in place for JLab 3.0 this
summer.
On Thu, Jun 11, 2020 at 4:16 PM Chris Holdgraf notifications@github.com
wrote:
--
Brian E. Granger
Principal Technical Program Manager, AWS AI Platform ([email protected])
On Leave - Professor of Physics and Data Science, Cal Poly
@ellisonbg on GitHub