jupyterhub / binderhub

Run your code in the cloud, with technology so advanced, it feels like magic!
https://binderhub.readthedocs.io
BSD 3-Clause "New" or "Revised" License
2.54k stars 388 forks source link

Add a "redirect to your binder when ready" checkbox to the main page #196

Open Carreau opened 6 years ago

Carreau commented 6 years ago

People seem to want to copy information from the build/launch page. I'm suggesting not launching automatically and have a big button: "Your binder is ready: GO" button.

CH added edits:

It looks like the current agreement on this is to do something like:

Add a checkbox in the build form that says something like "redirect to notebook when ready". If this box isn't checked (which is is by default), then:

  1. a redirect will not happen after the build finishes
  2. the button then takes on the words "redirect to my Binder"
  3. when the button is clicked, you are then redirected
choldgraf commented 6 years ago

I think this is part of a broader UI discussion around the UX pathway for users. As a stopgap, I'd be +1 on this for any binders that need to build (so that the person has a chance to peruse the logs before being redirected) but have it automatically redirect if the image has already been built.

yuvipanda commented 6 years ago

I think it should launch automatically, but perhaps have a 'launching in 5, 4, 3, 2, 1' button with the ability to stop it if needed. Users shouldn't have to manually press another button, IMO.

betatim commented 6 years ago

As a user I find myself frequently going to "the page" (not sure what to call it) to either grab the badge or use it as a template to switch branches, repos, etc. An easy to reach/click button to cancel the auto launch would be cool. 👍 on the default being to launch though.

minrk commented 6 years ago

:+1: to cancel launch button with artificial delay to give users time to cancel. An arg/url that prevents launch could also be used.

minrk commented 6 years ago

We are already serving two different handlers that render the same HTML:

  1. ParameterizedMainHandler is what people hit when they click a binder link. This serves index.html with the form filled out and the launch button clicked.
  2. MainHandler is what people visiting mybinder.org and filling out the form by hand see.

I don't think we should serve the same pages for these two URLs at all, since they are for very different use cases. The only thing these pages have in common is that they should be able to show a progress bar and the build output.

Here's a proposal:

  1. Main shows the form and allows triggering a build, but never redirects to the launch page. This should help the lost build output case. Basically the same as we have now, except without redirecting. A dedicated Launch button, only available after a successful build, should open in a new tab to avoid losing build
  2. Parameterized shows the progress bar, but not the editable form, and loses most of the surrounding text. Text can be replaced with something focused on visitors to an existing binder, rather than people building their own.
choldgraf commented 6 years ago

I think that's a good plan. What if for 1, we had a spinning wheel thing rather than a progress bar (or a progress bar with more incremental updates). I feel the bar isn't super useful for the binder link usecase, since for the majority of people, the repo should already be built. I fear many users will think that the page has stalled since there isn't any text coming in etc.

choldgraf commented 6 years ago

Hey all - an update on this issue. Number 2 from above was implemented, so that just leaves Number 1.

Main shows the form and allows triggering a build, but never redirects to the launch page. This should help the lost build output case. Basically the same as we have now, except without redirecting. A dedicated Launch button, only available after a successful build, should open in a new tab to avoid losing build

I'm +1 on this idea. Many people would like to look at their logs, and I think it's OK for the "main" page to simply build the image and ask the user to act once-more before they launch.

What do people think? If we are +1, then I'll edit the top-level comment with an actionable path forward.

yuvipanda commented 6 years ago

I left a much longer comment in https://github.com/jupyterhub/binderhub/issues/350#issuecomment-352102100 which is sortof a duplicate of this and most of that is still relevant I think.

Specifically, I would prefer the solution be:

A quick fix now would perhaps to be have a checkbox (ticked by default) under the launch button that is something along the lines of 'redirect to notebook when ready' that users can uncheck to wait and watch logs.

This allows for people who do want to watch logs to be able to do so, while providing a similar experience to right now for people who don't care.

I also wanna re-iterate my stance on using the word 'build' anywhere in the UI, which I also thinkk is relevant:

From a UX perspective, I'd like us to not introduce the word 'build' as an action that the user can do explicitly different from 'launch'. Separating the user's mental model from what we're actually doing will only cause more confusion, not less. We should solve the underlying issues IMO, than apply possible bandaids, esp. if bandaids change user mental models of how stuff works.

I'll also say that you never actually see your logs all the time - 99% of the time they're just 'found image. launching image!'.

choldgraf commented 6 years ago

I added a few edits to the top-level comment to make this issue more actionable...PRs are welcome!