Adding top-level CSS variables to theme notebook+cells more

[ellisonbg]

Previously most of the notebook+cell styles were done with private CSS variables (not ones in the theme). I have moved a few of these to the top level to better let us play with notebook design. I have deliberately made some provocative style changes to the In/Out prompts. I am not at all convinced these are better than our usual monospaced ones. I mainly want to get all of us thinking about better ways of improving the design of the notebook. Here are some of the ideas I had in mind:

• User content first. The old prompts were much too visually strong and detracted from the users content (code!). Because of this I have applied a bit of opacity to reduce the impact of the prompts. Might be too much.
• Less clash with our material design colors. Our old colors go way back and pretty much clash with the other colors we are using in juptyerlab. I have picked material design colors that are close to the old ones, but more in lines with the MD colors we are using.
• Better typography. I know the old monospace prompts have a long history, but as I played around, with different fonts and typographical options (letter spacing, font weight, etc), it became clear that there may be some better alternative designs.

My proposal is that we merge this, open an issue to track everyones opinions (and ideas!!!) as we approach beta. I want to emphasize that I view this as an exploration and am very open to going in other directions or even back to our original ones. Another option that I didn't explor here would be to get rid of the In/Out part and just keep the [N]: portion. But I sort of like wider prompts as it keep line lengths short in wide notebook panels. I have played around with width dependent prompts as well here: #1624

[sccolbert]

Do you have before/after screenshots?

[ellisonbg]

Classic Notebook:

This PR in Lab:

[ellisonbg]

I should note that I am not really happy with the typography of either of these fonts for the prompts. I like the look of the san serif, but not this particular ones (Helvetica Neue) because its I looks like an l. May look around a bit more for an open source sans serif with better character shapes for this purpose.

[sccolbert]

👍 for better typography and muted prompt colors

👎 on opacity applied to prompt colors because it makes them look "disabled" due to the extra dithering/anti-aliasing

[ellisonbg]

Yeah, the opacity is tough to get right without it looking disabled. I will play around a bit more to see if I can mute the colors without opacity.

[ellisonbg]

Here is the same hue (MD Design Blue/Orange 900) but with the saturation down (30%) and lightness up (60%). This takes it towards grey and lightens it.

[ellisonbg]

And that is opacity 1.

[dhirschfeld]

I guess "better" typography is pretty subjective... so is a great subject for bikeshedding! FWIW I'm actually happy with the old-style fonts. I do however use Source Code Pro in my Spyder theme.

In the sample above I find the I a bit too far away from the n in the In prompt which to me is a little visually jarring.

[stsievert]

I don't think applying color/opacity is the best way to focus on the user content. I've fleshed out this idea more and generated a mockup of my idea in #1692 (comment)

[ellisonbg]

Thanks for the input! Lost in teaching for the next few days, will jump back into the discussion later this week. Cheers, Brian

…

On Sat, Feb 11, 2017 at 8:16 PM, Scott Sievert ***@***.***> wrote: I don't think applying color/opacity is the best way to focus on the user content. I've fleshed out this idea more and generated a mockup of my idea in #1692 (comment) <#1692 (comment)> — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1691 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABr0BUMZepa9WG9ObOF1VAuMtVF34aTks5rboeHgaJpZM4L8_UU> .

-- 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

[ellisonbg]

OK getting back to this. Here is Droid Sans Mono, MD Grey 600:

[ellisonbg]

Roboto Mono, MD Grey 800:

[ellisonbg]

Roboto Mono, MD Grey 600:

[ellisonbg]

Roboto Mono, MD Grey 600, Alt prompt chars:

(don't think this works)

[ellisonbg]

Roboto Mono, MD Grey 600, Alt text:

[ellisonbg]

Noto Sans, MD Grey 600

[ellisonbg]

Some observations:

• Roboto Mono is probably my favorite, simple, clean, proportioned
• I really like using a medium grey for the prompts. Some where in the MD Grey 700 range. I think the grey downplays the prompt in an appropriate manner.
• The simplified prompt text [4]: is nice. It also allows for a narrower prompt area. But with this text, you don't have a difference to tell input and output apart. But maybe that is OK as they look different for other reasons.

How do folks feel about tentatively moving forward with the following:

• Roboto Mono, MD Grey 700.
• Standard prompt text with In/Out.

The PR also contains refactoring of the CSS that will make these explorations much easier moving forward.

[ellisonbg]

Here is what that looks like:

[stsievert]

But with this text, you don't have a difference to tell input and output apart. But maybe that is OK as they look different for other reasons.

Maybe with [4]: still use Out[4]:?

[ellisonbg]

@stsievert yes that is definitely one solution. I will post a screenshot to see how it looks...

[blink1073]

Very nice, @thomasaarholt, my favorite so far.

[ellisonbg]

@thomasaarholt thanks for the suggestion, I will try that one out over the weekend when I get back to it. As an aside, I respect GitHub for daring to change their visual design (for better or worse). It is really hard to change the design of software that many people use...

[ellisonbg]

I too like the simplicity of the [4] design. Trying to think about how to distinguish output visually. One option:

[sccolbert]

My personal opinion is that I don't like input/output pairs which don't visually "align" with each other vertically. So having different right-most symbols between in/out make the prompts look staggered to me.

[ellisonbg]

Yeah, even though this is a monospace font, and the characters are mostly the same, it does lack the visual alignment. Another possibility is to create custom `[]` characters whose vertical bars are centered in the width of the character. That would at least align the vertical bar parts. Might not be any better though...

…

On Sat, Mar 4, 2017 at 10:53 AM, S. Chris Colbert ***@***.***> wrote: My personal opinion is that I don't like input/output pairs which don't visually "align" with each other vertically. So having different right-most symbols between in/out make the prompts look staggered to me. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1691 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABr0FZO85ZBvcfYbtTvJM4moeCwHc3Rks5ribNHgaJpZM4L8_UU> .

-- 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

[sccolbert]

What about simple abbreviated in/out: I[4]: O[4]: with a font which has horizontal bars on the capital I?

[ellisonbg]

Nice idea! I will try that...

…

On Sat, Mar 4, 2017 at 10:59 AM, S. Chris Colbert ***@***.***> wrote: What about simple abbreviated in/out: I[4] O[4] with a font which has horizontal bars on the capital I? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1691 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABr0M4g8IdhVCZdIPzlGw1s3ZwupLqVks5ribSCgaJpZM4L8_UU> .

-- 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

[stsievert]

Do we want to label each input cell or provide a prompt for each input cell?

If we're trying to label each cell, I like input as [4] and output as [4]:. If we're trying to provide a prompt, I like In [4]: and Out[4]: or some modification.

This isn't the Jupyter (or IPython) console, so I think we should label each cell (and use [4] and [4]:).

nteract uses the same [4] encoding (minus the output labels):

[AbdealiLoKo]

May also be useful to have variables for icon paths so that the icons can be changed in themes easily

[Carreau]

What about simple abbreviated in/out: I[4]: O[4]: with a font which has horizontal bars on the capital I?

Please no, the In/Out are mapping to variable names in the kernels, that map to history. We've keep these as is because otherwise you get confusions. And this is also assumed by a lot of Python tools, like sphinx extensions that understand this and strip it.

Changing the naming of the prompt is not a question of design anymore it's a question of backward compatibility with other tools. It also make all books that have currently been public obsolete.

We are also trying to have a smooth transition, dramatically changing the design will make this hard.

[blink1073]

My 2 cents as the maintainer of several kernels: they do not use the In/Out variables, nor was I even aware of that feature in ipykernel. This does not affect the notebook format, only the display. Of note, nteract only shows [1].

[thomasaarholt]

Can we get any references to code showing whether or not renaming In/Out breaks things? I feel like @Carreau's post essentially kills the suggestion.

[blink1073]

The text is set in the display only, Out is here and In is here. That text never touches any other code in the application, it is only applied to the html element itself.

[blink1073]

The notebook format defines execution count as a number or null, that is the value that is shared.

[ellisonbg]

Changing the `In/Out` prompts isn't quite a formal API breakage. The API (in the IPython kernel) still works the same, and is unchanged, but there would no longer be a close linkage between the prompt names and that API.

…

On Mon, Mar 20, 2017 at 4:35 PM, Steven Silvester ***@***.***> wrote: The notebook format defines execution count as a number or null <https://github.com/jupyter/nbformat/blob/d2f3ca435fbe2768ce8a51bf1460b4e5124299a2/nbformat/v4/nbformat.v4.schema.json#L195>, that is the value that is shared. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1691 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABr0J0hJKbR5-gXt1dS60OFYXqkEzpyks5rnw1TgaJpZM4L8_UU> .

-- 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

[ellisonbg]

Closing in favor of recently merged #2123 and follow on work.