Notebook: Removing the play button introduced in 5.6.0?

[ivanov]

I understand the rationale of trying this feature out, but I worry that it becomes a feature that if we keep this change now we will have a harder time deprecating it in the future. We don't have enough information about it to keep it as the new default, and in a day of usage, I find it to be visual noise and frustrating.

One particular problem with the current implementation is target area for executing a cell in place fills the entire vertical column, but the icon is only at the top.

Alternatives paths forward could be to provide this as an option, or to patch the release taking this feature out and put it back in in master to let it bake for longer.

I feel that a UI change like this is significant and I think that the cost to current users who do not need it is too great for the benefit it provides to those who want such a feature.

[takluyver]

I imagine you can use some custom CSS to hide them. I don't buy that there's a significant cost to people who're not using it.

[ivanov]

This is a significant visual change and I disagree with the addition of this feature via #3535.

In its current form, it hinders my workflow. I am not alone and talked with others at SciPy who were uneasy with this change. The absence of a transition for an element in the upper left when the user hovers automatically draws my gaze there.

Thomas, your dismissive language in a short reply that calls my sincerity into question hurts me.

[jasongrout]

I've used this a short time, and I find the hover behavior very distracting - as my mouse moves over the notebook, the apparent movement in the gutter draws my eye to the play button that keeps moving around.

Also, the fact that the play button follows the mouse hover instead of the current cell is confusing. If I leave my mouse over a cell, then move around with the keyboard, the play button stays on the cell hovered over, even when the mouse pointer disappears - then it seems like there is this arbitrary play button next to one of the cells, which isn't the current cell, but does change as I scroll the notebook in the page.

That's not to say that we can't fix these sorts of issues, of course. However, I'd definitely be +1 on removing this from the current released notebook and letting this behavior bake more in master, with wider UX testing before committing to it.

[takluyver]

Sorry to have hurt you. I'm frustrated by this issue because:

• The feature was worked on in two pull requests which no-one besides me reviewed (#3437, #3535).
• I merged it nearly two months ago, and I'm not aware of any complaints while it was in master.
• M improved on it in a third pull request, still without any real review (#3687).
• We made a release candidate a few weeks back. No feedback.
• I find the time to get a real release out, and within hours I've got a complaint saying it should be reverted.

It feels like there's a huge imbalance between how many people care about the notebook and how many people are willing to be involved in the development process.

Furthermore, this feels like the kind of complaint provoked by any UI change: it's not what we're used to, we'll find a reason that it's objectively bad, and then demand that it be reverted. The fact that it comes so soon after a release reinforces this impression.

Given the process this has already been through, I don't see what "letting it bake" more in master will achieve: clearly next to no-one is running from master, so it can either 'bake' indefinitely or we can replay this the next time someone tries to include it in a release.

I'd like to see concrete suggestions for improving the feature, even if that's only "hide it except on touchscreen devices", rather than people just requesting that it be reverted and someone else should improve it. It was meant to solve a real issue, and I don't want to have to tell a contributor that their accepted PR was reverted.

[gnestor]

I agree that this is a significant (and apparently unwanted by some) change to the UX of the notebook. I suggest that release 5.6.1 without it and allow it to bake in master longer.

To summarize discussion points thus far:

• The new play button is distracting because it's constantly being displayed and hidden whenever a cell is entered/exited
• The target area for the new play button fills the entire vertical column, but the icon is only at the top
  
  
  
  • I can't reproduce this, the cell is only run when I click on the play button, not anywhere around it
  
  
• The new play button can get out-of-sync with the current cell when the keyboard is used to navigate cells

Some additional discussion points:

• To back up, the original issue reads "add a execute button near "In [ ]" so it can be like the refresh button in dashboard page". What exactly is the problem that we're trying to solve?
• To run a cell, we currently have the run button in the toolbar and the keyboard shortcut. Do we need a third way to run a cell?

[takluyver]

I don't think 'baking in master' will help, because it seems hardly anyone uses master.

Instead of reverting it, why don't we use this space to think about how it could be improved. From the discussion so far, there are two possibilities that seem to jump out:

1. Show it following the selected cell rather than the mouse cursor, so it follows the keyboard and is changing less as you move the mouse around.
2. Only show it on touchscreens.

[jasongrout]

@takluyver - I definitely hear you. We have had the same issue with ipywidgets (luckily getting better now with more people running master). On the flip side, I know it's hard to try to run master and keep up with the development of many different projects.

@gnestor - thanks for summarizing. My main objection is with the hover-based UI, and how that distracts from my normal notebook workflow. I would be interested in hearing from others what the driving use-case is for a run button by the cell, and particularly how that is better than the run button on the toolbar. If it does make a huge difference on touchscreens for example (it seems like it might?), then showing it only on touchscreens makes sense to me. I would still not make it follow the mouse hover in that case, though, since following the mouse position doesn't make sense on a touch screen.

[takluyver]

It already doesn't follow mouse hover on touchscreens - it shows for every cell there. Here's the relevant CSS rule:

https://github.com/jupyter/notebook/pull/3535/files#diff-f130df4e3dc9603a54e1abc96ccda2faR49

[jasongrout]

Okay, thanks. So I think my main objection would be taken care of by removing the hover css at https://github.com/jupyter/notebook/pull/3535/files#diff-f130df4e3dc9603a54e1abc96ccda2faR45

[minrk]

Thanks for bringing this up, @ivanov! I also think it's something we can and should fix. I think only on touch screens is a good option, since it doesn't seem to be working well when you have a mouse cursor, but still solves the direct problem on touch screens that it was hard to execute without a keyboard. I like #3776 as a solution, at least for the interim. I still think the idea of a cell context/action area may be a good one for the future, if we can figure out the UI for it, but the sparse nature of the document part of the UI is very precious to a lot of users so it's a tough balance to strike.

I agree that with the current state of things, 'baking in master' is not very useful at this point for UI. As @takluyver said, this baked in master for some time without objection. That's always going to happen, though—the number of people running from releases is huge compared to those running from master or release candidates. So we need to be prepared for feedback after releases, even for things that have been reviewed and in master for a long time. The lack of PR reviewing attention on this repo is something we definitely need to work on.

[nehz]

An option to disable it would be great. (I also find it hugely distracting)

[mfenner1]

I'll start with an apology: for as heavily as I use and rely on jupyter notebook professionally, I do not actively follow its on-going development. I do try to be active in various open source projects by following through on bug reports, fixes, etc. I want to thank takluyver for his work and effort on this feature. I only became aware of it when I upgraded my jupyter install and noticed the new behavior in my notebooks.

I agree with the discussion point: "The new play button is distracting because it's constantly being displayed and hidden whenever a cell is entered/exited". Things appearing and disappearing on screen grab my attention. I actively disable just about any and every pop-up and alert system on my technology devices because my work requires extreme focus -- which I have a hard enough time generating because of my own faults.

Having said that, I would very much support some combination of (1) default disabled and (2) easy option to disable the per-cell play button.

[cailiang9]

You can take a look at https://colab.research.google.com . Seems google's run button is not that distracting? Another example is mathematica.

So why google or mathematica adds a run button?
Because at least for machine learning tasks, most processes are unknown. Updating graphs with newer data or model is quite frequent.

For clean versions, nbviewer is the right version for people don't write experiment code.

Here I think an icon with lighter color could make people feel better.

[jasongrout]

For me, the huge difference is that the run button in Colab follows the active cell, not the mouse hover. Having the run button follow the mouse hover was the really distracting thing to me.

[cailiang9]

For me, the huge difference is that the run button in Colab follows the active cell, not the mouse hover. Having the run button follow the mouse hover was the really distracting thing to me.

Actually on PC, when you hover mouse on other cells in Colab, you can also see the the run button. For active cell, the run button is always there.

Or do you mean other platform?

[jasongrout]

On OS X, for me, in Chrome and Firefox, the play button to the left of the cell only appears when the cell is active, and I don't see anything changing in cells when I merely hover over them.

[cailiang9]

The difference is hovering the whole cell VS only the [ ] area of the cell(Colab). So is it possible to implement the hovering of run button like this way?

Though I don't feel distracting at all.

[blomadam]

My issue with the feature is that I now have huge invisible targets around my screen that have been causing cells to run unexpectedly, which sometimes causes a delay of 20 min while large data files are processed.

This usually happens when I am trying to click in the little gutter to new the blue selection indicator so I can quickly navigate to the top of the page.

I don't mind the feature or find it very distracting except for the large invisible vertical target area on the side of all my cells. Hopefully I can change my habits quickly enough to not go mad.

[cailiang9]

I can't understand.
Seems google Colab's design is quite good ? There are also many people using Colab system. Do they feel distracting?
If not, why not just borrow Colab's design?

[gnestor]

To clarify, as of notebook 5.7, the inline run button is only displayed on mobile devices (which I believe was the original intention of this feature). We welcome PRs that improve this UX of this, but at least now mobile users can easily run cells and desktop users are unaffected.

[cailiang9]

So how to enable it also on desktop web, if I want to see it in my own fork?

[gnestor]

Just remove this line: https://github.com/jupyter/notebook/pull/3776/files#diff-f130df4e3dc9603a54e1abc96ccda2faR39

[cailiang9]

I just implemented like google's colab.
for selected cell, it always display a transparent run button. (this static design also tells users there is a quick way to execute cells)
for rest cells, the run button only shows when hovering div.prompt_container. This resolved the distracting issue(it only shows when users hover a very small area. )

such UX design also resolved the issue that on touch devices, too much ugly run button displayed for every cell.
On touch devices, users can tap to select the cell and then tap the run button to execute. It is still efficient.

div.run_this_cell {
  position: absolute;
  display: none;
  cursor: pointer;
  color: #333;
  background-color: #ffffffb3;
  padding-top: 5px;
  padding-bottom: 5px;
  left: 2ex;
  padding-left: 3.5ex;
  padding-right: 2.5ex;
  width: 2ex;
}
div.prompt {
  min-width: 9ex;
}
div.selected div.input .run_this_cell {
  display: block;
}
div.code_cell div.prompt_container:hover .run_this_cell {
  display: block;
}

[gnestor]

such UX design also resolved the issue that on touch devices, too much ugly run button displayed for every cell.

This is a good point. Another option would be:

.code_cell .run_this_cell {
    visibility: hidden;
    cursor: pointer;
    color: #333;
    padding-top: 5px;
    padding-bottom: 5px;
    padding-left: 2ex;
    padding-right: 2ex;
    width: 1ex;
}

@media not all, (any-pointer: coarse)
.code_cell.selected .run_this_cell {
    visibility: visible;
}

A couple things to observe:

• This will only show the run button for cells that are selected (vs. hovered)
• This uses the visibility property vs. display to prevent inputs from moving around when a cell takes focus/selection