The "Run" text in the run toolbar button

[ellisonbg]

Just noticed in recent versions of the notebook that there is the text "Run" in the run button in the notebook toolbar. No other buttons have text:

What the motivation behind this? It is pretty non-standard in a UI like this to put text in a toolbar button, and the "play" icon here is one of the most universal icons. Here is Google Drive and Word:

We would need a really strong reason to add something like this - such as strong evidence from well run multi-person usability study. We would also need to understand if out choice of the "play-stop" variant was the problem and that another icon wouldn't solve the issue. Outside of evidence like that I think we should revert that change before the 5.2 release.

@gnestor

[gnestor]

This was added in 5.1. It looks like you approved of it at the time 😉 #2433 (comment)

[takluyver]

Two main reasons:

• Provide a larger click target for actions that are especially important (like run). This is a well established concept from UI design.
• Make the purpose of buttons clearer, because it's often hard to find an icon that clearly identifies what you want, and different extensions may use the same icons. I think this is a common criticism of toolbars. E.g. cite2c:

Text alongside icons is not uncommon in toolbars, e.g. here's Thunderbird:

Most traditional toolbar widgets have it on either all icons or none, but it's not clear whether that's a design feature or a toolkit limitation. It's not universal; here's the toolbar of an image editor called Pinta:

Another precedent for mixing labelled and unlabelled buttons is the 'Ribbon' UI now used in various Microsoft applications. Here it is in Office 365:

And here's the experimental Libreoffice 'Notebookbar':

Apparently, one of the reasons that Microsoft did this was issues with discoverability: people were asking them for features that were already there. The ribbon controls actually go beyond what we're doing by hiding and showing some labels as the window size changes, but that doesn't mean we can't take some good ideas from them.

Besides those examples, though, I don't get the insistence on rigidly sticking to what other applications have done. It seems unlikely that adding labels to selected buttons is going to confuse anyone, so what's so terrible about doing something a bit different? As Grant pointed out, you didn't mind this a few months ago. If you have observed people actually having problems as a result of the new label, let's try to work that out, but just reverting it because it's slightly different feels unproductive.

[ellisonbg]

You bring up some good points about UX design in general and for this issue specifically. In working with Cameron and the Bloomberg design team, I have watched them use two tools in making UX design decisions: 1) survey other tools and 2) observational user tests.

On the question of researching what other "similar" UIs are doing, that is surely not the end, but it does highly constrain the solutions investigated.

You bring up good points about the target size, the usage of text+icons in other UIs and the discoverability issues of icons. The ribbon design of Microsoft was an answer to their ever growing set of toolbars in incomprehensible icons. However, We don't have that issue in the classic notebook or JupyterLab - there are a very small set of icons, and they use very standard icons.

A good comparison set would be other interactive computing UIs. Here is a quick survey of other "notebook" like UIs:

• CoCalc (traditional play button in toolbar)
• nteract (traditional play button in upper R of cell)
• DataBricks (traditional play button in toolbar)
• Zeppelin (traditional play button in upper R of cell)
• RStudio ("Run" text plus different icon in toolbar)
• Online Mathematica (no icon/button, just shift+enter and menu item)
• Colaboratory (traditional play button in the prompt area)

Based on this, it appears that our usage of the play+stop icon in the classic notebook stands out (we have gone back to standard play in JupyterLab). Some of these tools had a separate "run all" icon with text on that one (the icon was non-standard), other handled run all in a menu item.

One the observational user research side, we actually have some data about this. At JupyterCon we did a 30m observational user test ("think aloud style") on 26 users. This included a range of users (we have their biographical/experience info). There were 2 tasks where the user needed to run a cell (they were not told how). Out of 26 users, all completed the task successfully wth their first action (24 used shift+enter, 2 used the play icon). This was the JupyterLab UI with the play button in the toolbar icon - no "run" text. This user tests has sampling bias in that the individuals were at JupyterCon and all the but one had used JupyterLab or the classic notebook. But this data does support the idea that the target size of the button isn't important to optimize repetitive usage - users are relying on shift+enter once they get going.

However, having the "Run" text in the button might be useful for new users (dicoverability). My only observations on that front are in teaching university students data science and scientific computing (probably 300 over the past few years). Those users quickly learn the play button and I have to work hard to get some of them to start to use shift+enter. However, those users have a "guided" experience of the notebook - I teach them how to use it and can answer questions. For users trying out Jupyter alone, I have no data that is not purely anecdotal.

Based on these factors, this is the direction I am thinking (and which we are taking in JupyterLab):

• Stick with the familiar standard play button with no text in the toolbar button (not the play+once variant in the classic notebook currently)
• Add a play button to the upper right corner (or prompt) of each cell for quicker access.
• Make sure the buttons have a descriptive tool text.

With binder, we can more easily user test the notebook UI itself. Doing a user test to investigate this question with new users wouldn't be too difficult. We have many more pressing UX design questions to work on, so I don't think that makes sense at this point. However, if someone wants to dive in, I am more than willing to chat about the details.

[ellisonbg]

And as far as my changing my mind on this matter - my thoughts on design do evolve and I try to embrace a sprit of experimentation, especially when I don't have time to dive into an issue.

[dhirschfeld]

Add a play button to the upper right corner (or prompt) of each cell for quicker access

That sounds like it would add unnecessary clutter IMHO.

[ellisonbg]

yes, this is why we have been slow to add per-cell UI. If we do this, it would be hidden by default and likely only show if you have a cell selected or hover directly over the upper right of a cell. It will be subtle to get it right, but important - seeing a notebook with a bunch of play buttons would be distracting.

…

On Tue, Oct 10, 2017 at 2:21 PM, Dave Hirschfeld ***@***.***> wrote: Add a play button to the upper right corner (or prompt) of each cell for quicker access That sounds like it would add unnecessary clutter IMHO. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2914 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABr0Npd-N33j1zuQkMB-ARoc9vd3g1qks5sq9_rgaJpZM4PzPx8> .

-- Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgranger@calpoly.edu and ellisonbg@gmail.com

[takluyver]

Brian, I appreciate that your thoughts evolve, but I get frustrated by what I see as a tendency to present your current thoughts as objective principles to be followed, and this issue seems like a prime example.

I've given two arguments for adding a label to the run button. I also have a third: I want to have at least one labelled button in the default UI to alert extension authors to the possibility. Discoverability and memorableness* are going to be more important for buttons added by extensions, especially when different extensions use the same icon from the limited set available.

(* 'memorableness' is something that always seems to be ignored in these discussions, perhaps because it's harder to measure than how easily unfamiliar users 'discover' a feature. This is also a more general concern about 'data driven' design: do we wind up optimising the things that are easy to measure, rather than measuring the things it's important to optimise?)

You've presented some data from a very small set that the label may not be necessary, which is different from demonstrating that it is actually problematic to add a label.

Following my comment yesterday, I read some blog posts from Microsoft about how the Ribbon was designed. One story that stuck out was that they considered demoting the 'paste' toolbar button, although they knew paste is used a lot, because they thought most users use it through keyboard shortcuts or the context menu. But when they looked at more data, even the small fraction of pastes done by clicking the toolbar button were enough to make it the most-clicked button. So they instead made it a big, obvious button with a label. Obviously we don't have the data to know if the same is true of our run button, but given complexities like this, I'm not inclined to place too much weight on what a small self-selected sample did.

The rest of your argument appears to boil down to doing what everyone else does. That's a reasonable starting point, but:

• From the list you present, what other interfaces do is not consistent. E.g. associating the run button with the individual cell may make it clearer than being in a toolbar at the top.
  • RStudio provides another example of a UI mixing labelled and unlabelled buttons. Thanks ;-)
• Other tools are probably also designed based on what everyone else does. Common UI patterns are of course helpful, but we shouldn't assume that what we're imitating has been carefully studied and thought out by someone else.
• Most importantly, the change we've made (adding a label) is minor, and does not seem likely to confuse anyone. If you look for a play-like icon, you will still find it in the toolbar, and then the text confirms your expectation. This is not some bold new UI paradigm that we're experimenting with, it's adding a short label to the same button in the same toolbar you know and love.

There's a separate question about which icon to use for 'run cell'. I think the rationale for the current choice was that it's more analogous to stepping forwards in a video than to playing it. Here, I think your survey of other tools is useful, and I'd agree that going back to the 'play' icon, which most of the tools you looked at use, probably makes sense.