hide the lab link for now

[minrk]

until we are more ready to emphasize it.

Lab's still there, you just have to enter the URL for now.

cc @fperez @ellisonbg @jasongrout @blink1073

[dwillmer]

i appreciate your point, but i really think this is the wrong thing to do. it's clearly marked as alpha - is there something specific that you'd like to see before calling it alpha?

[jasongrout]

I'm comfortable either way, since it's on master - it depends on how many people run on master. Either way, @fperez also suggested we have a very visible notice of what to expect and what won't work.

[jasongrout]

The other factor in the decision for me is how close we are to releasing notebook master as a new release. If it's soon, then not having the button makes sense to me. If it will be a while, enough so we can get the notebook working "minimally", then I think the button is fine.

[jasongrout]

But to @dwillmer's point - let's have a meeting between everyone to draw the feature line for when it's 'ready' for beta testing, etc.

[minrk]

We definitely aren't close to releasing 5.0. We've just had several complaints already suggesting that the button either shouldn't be there, or should be significantly less prominent, at least until Lab can actually be used for something (basic notebook execution).

[sccolbert]

It can currently be used to edit text, run terminals, and do file system operations. Basic notebook execution also works, but with a reduced subset of functionality (if we remove the read-only restriction).

[sccolbert]

There are people running on master, complaining that a well-marked alpha version of in-development code does not work perfectly?

[minrk]

No, there are people complaining that an extremely prominent link that says "Try me!" doesn't do the one thing they care about using Jupyter for: write, edit, and execute notebooks, and there's no information conveying that they shouldn't expect it to do so.

[sccolbert]

These are developers running from master though, and the button says "try" and "alpha". I don't see why this is a problem.

[minrk]

I don't see why delaying the introduction of a button is a problem, either.

[takluyver]

Would sticking it at the bottom of the page for now and tweaking the wording (not exactly sure how, but something less encouraging than 'Try me') be an acceptable compromise?

[dwillmer]

I think the best thing to do is get everyone on a video chat, as Jason suggested, otherwise this PR conversation will quickly become unmanageable :)

[jasongrout]

I think we all agree that there should at least be a prominent notice about what to expect (a modal when the page starts, or a tab on the sidepanel, or a notice at the top of the page, or something).

[jasongrout]

Good point @takluyver - there's likely a compromise somewhere. I think we shouldn't bike-shed this too much either.

[fperez]

Note that currently it doesn't even execute or edit notebooks. So the main functionality of the notebook doesn't actually work at all. It's ok to push out alpha tools, but the current state isn't quite at alpha functionality yet, and we run the risk of simply turn users away.

I think we need to introduce it gradually. As we gain more functionality, we can display it more prominently, but right now we basically need design/UI feedback, it's not really something people can "try" in the sense of using it as a notebook, even for 5 minutes.

So I think we need:

• initially a less-prominent invitation, just so it's easy to find it for someone who actually wants to help test. We can email the list for now to invite people to try it out. @takluyver's suggestion is a good one. To keep it simple, we could make it a plain text link for now (to avoid re-design work); once it matures we can use the nice "try me" button.
• an information page that tells people roughly what to expect. Right now, they might assume that it's an actual notebook, and think the lack of execution (a most basic feature to do anything useful) is missing might be a bug. We don't want that reported, so people need to know what's to be expected as working and what they should report as a bug.
• as we add features, we can move the invitation to be more prominent, changing the plain text link to be the nicer button at the top.

And yes, I'm a developer (sort of :) who runs off master and tried it, but I was immediately confused by the lack of execution, which I thought was a bug as I would expect that it would at least let me do something with the notebooks. So if I had that reaction, we should assume that it can happen to others too and act accordingly.

[sccolbert]

I'm going to jump on the "let's have a call about this" train. The current state is a product of joint decisions between my team and the Jupyter core team, so clearly something was lost in translation.

[fperez]

Unfortunately I have a string of meetings today. But I had a chance to discuss this with @jasongrout yesterday by happenstance, he might be able to channel my thoughts, as it seems I failed to do so in the thread...

[jasongrout]

I don't think anything was lost in translation (i.e., we did exactly what we had planned and had decided on). What happened is that we got feedback and now we're adjusting in response to that helpful feedback.

[Carreau]

+1 on lowering the visibility of the button. It's far from matching the theme of the current UI, feel (to me) like someone yelling at me in upper case letter.
I don't think having a "lab" button of the page is a bad thing. I think the Style, Location and visibility are just inappropriate.

[sccolbert]

I'm fine with adapting style and adding disclaimers, but I think hiding it altogether is a heavy-handed reaction. Basic execution in the notebook does work, but we were specifically asked by Min to make it read-only because it doesn't support all output types yet. The point of the button is to solicit feedback from bleeding edge developers, and hiding it will limit that feedback. I'm not suggesting it be rolled out in a user release at this point.

[Carreau]

I'm fine with adapting style and adding disclaimers, but I think hiding it altogether is a heavy-handed reaction

Agreed it might be too much.

The point of the button is to solicit feedback from bleeding edge developers, and hiding it will limit that feedback. I'm not suggesting it be rolled out in a user release at this point.

The all point of master is to get feedback from bleeding edge developer. The Lab Page is not the only one that get update and need feedback and have no reason to get special treatment. Plus it attracts all users that are running on master instead of just advanced developer who are the one we seek feedback from.

The master branch is also useful to see how people discover things in the UI, and if the interaction with the UI is seamless and feature discoverable.

Adding a flashy button which main point is to be removed later, have a complete opposite effect of what is desired, and target the wrong kind of individual thus makes no sens to me.

[sccolbert]

The all point of master is to get feedback from bleeding edge developer.

Plus it attracts all users that are running on master instead of just advanced developer

These two statements seem contradictory to me. Is there a better branch than master which targets only bleeding edge developers who can tolerate feature-incompleteness?

[minrk]

I'm fine with the button, I just heard from a few directions that maybe it was a little premature to have it there. Sorry for starting this mess.

[jasongrout]

@minrk - thanks for moving on the feedback, though. It sounds like Fernando's proposal is a good way forward.

So I think we need:

initially a less-prominent invitation, just so it's easy to find it for someone who actually wants to help test. We can email the list for now to invite people to try it out. @takluyver's suggestion is a good one. To keep it simple, we could make it a plain text link for now (to avoid re-design work); once it matures we can use the nice "try me" button.

an information page that tells people roughly what to expect. Right now, they might assume that it's an actual notebook, and think the lack of execution (a most basic feature to do anything useful) is missing might be a bug. We don't want that reported, so people need to know what's to be expected as working and what they should report as a bug.

[jdfreder]

I brought this up to @cameronoelsen and this was his first time seeing the button integrated in the UI. Here's how it looks now:

He (and I) think this looks better:

[jdfreder]

Another idea, we could ask @cameronoelsen to reduce the orange in the button, so it's not as focus grabbing.

[rgbkrk]

an information page that tells people roughly what to expect

@sccolbert would it be possible to make a default panel in the lab setup that tells people about the lab interface?

[jdfreder]

I also like @fperez 's plain text link idea

EDIT: @takluyver 's suggestion

[sccolbert]

@rgbkrk Yep - great idea, we can have an "About" tab or something with that info. Just need the text/html people want to put in it.

[rgbkrk]

Go ahead and make the About tab with the text "This is JupyterLab!", then I'll merge it and can submit a PR with better text in it after. 😄

[sccolbert]

@blink1073 ^

[Carreau]

Is there a better branch than master which targets only bleeding edge developers who can tolerate feature-incompleteness?

No. We strive to keep master usable at all time to get feedback from most of the community.
By bleeding edge developer I mean developer that are running the bleeding edge version.
You shouldn't need to have 36 Years of experience in Python and Typescript to run master.
So yes on master you have a lot of user that are not even experienced with git and just know how to
do git pull. If you put a Big Orange button you can expect to get testing (mostly) from these.

If you want feedback from advance developers, you make a feature which is relatively hard to reach, hidden behind a config option, or a non obvious link and advertise it on twitter, the mailing list. Or even just a message in the JS console.

[blink1073]

@rgbkrk, see jupyter/jupyter-js-plugins#98.

[rgbkrk]

As one of the people who said that we should consider making jupyter/notebook and jupyter/lab two separate projects (one has to keep the old APIs, one has their continued green field engineering), I thank @minrk for kicking off this discussion. It had to happen, as a lot of people were fairly minimal in their responses (not wanting to spend too much energy/time combatting it).

What happened is that we got feedback and now we're adjusting in response to that helpful feedback.

👍 I was fairly quiet in the past of just accepting that "this is what we decided, there is no argument™"

The JupyterLab interface is very slick and responsive (with some edges that I'm sure will get cleaned up) and people want a way to showcase it. The cool thing is we can keep moving and disappearing the button every day until we're happy. Consensus is in the code.

[parente]

(Sticks neck out) Any support for making the button more like the existing tabs on the dashboard page already? I know it's not a true tab, but if it appeared in the tab row, maybe right aligned away from the other tabs, it would fit with the existing UI, still be noticeable enough for people to click it, and could contain any amount of text required to express its alpha/experimental/try-this-and-give-us-feedback nature.

[Carreau]

(Sticks neck out) Any support for making the button more like the existing tabs on the dashboard page already? I know it's not a true tab, but if it appeared in the tab row, maybe right aligned away from the other tabs, it would fit with the existing UI, still be noticeable enough for people to click it,...

I like this idea.

[takluyver]

Interesting idea, but I don't think it's great UX to have something that looks like a tab but doesn't behave like one (i.e. it does something other than switching the view in the tab content area).

[dwillmer]

👍 @takluyver is right, it's a nice idea for not having it so visible, but is the wrong interaction. A smaller button, possibly moved to a different place would be better.

[parente]

While this is an open topic, what's the approach an admin of a Jupyter 5.0 deployment should take to disable / hide the try button until he/she is ready to expose and support the new Lab interface? Is there a command line feature flag? Does the admin have to provide custom CSS / template for the dashboard page?

[Carreau]

While this is an open topic, what's the approach an admin of a Jupyter 5.0 deployment should take to disable / hide the try button until he/she is ready to expose and support the new Lab interface? Is there a command line feature flag? Does the admin have to provide custom CSS / template for the dashboard page?

Good question, I don't think we had anything planned in advance.
It should be relatively easy to add a serverside flag.

[cameronoelsen]

What if we just took away the "try" and the orange accent on the button and made it more subtle. Also, the "Try" is probably implied because of the "alpha release" text under the title.

[rgbkrk]

@cameronoelsen That makes it look like the dashboard is jupyterlab

[cameronoelsen]

@rgbkrk Yeah I was thinking of that too :/

[rgbkrk]

I do like how subtle the button is there @cameronoelsen - it fits the current UI very well.

Without the try, I think that's how it makes it look like a brand on the notebook dashboard.

[cameronoelsen]

What if we got away from that button and just put a dropdown arrow next to the Jupyter dashboard logo. When you click on it, it reveals a menu that lets you get to the jupyterhub dashboard (aka just the app itself)

Or even just having the jupyterlab icon:

[fperez]

I like that last option a lot: easy to find for someone who needs it, less likely to catch the unwary :)

And BTW: I want to reiterate this wasn't a slight at all on the original work! I think it's great to have JLab more easily accessible, so we can provide feedback and iterate. Consider this round 1 of that feedback. I also love the stronger button, which we can use later on when things are more functional, and we're willing to start attracting more folks.

Now, one thing I think is very important is to provide a very obvious information page that sets expectations for users who do open it. For example, telling them that right now the notebook tab is read-only. Otherwise people are just likely to be confused. Our project has a tradition of master being bleeding edge but basically usable, and I see no reason to deviate from that. But as long as we communicate clearly what we expect to work and what not, we can get feedback this way. If nothing else, that's critical to get usable reports, otherwise we're just going to get a bunch of people filing bugs that say "the notebook doesn't run", and we'll spend our time closing them as false positives.

Thanks again!

[Carreau]

Now, one thing I think is very important is to provide a very obvious information page that sets expectations for users who do open it. For example, telling them that right now the notebook tab is read-only. Otherwise people are just likely to be confused

This is already much better in master :

[fperez]

Ah, great! I hadn't pulled so I hand't noticed that. Many, many thanks!!

[sccolbert]

👍 noice!