Final design changes for 6.0

[ellisonbg]

This does the final design changes for 6.0. Fixes #1110

Based on work by @cameronoelsen but modified.

[ellisonbg]

Here are screenshots:

Default slider state:

Hover/active slider state:

Default range slider state:

Hover/active slider state:

Progress bar:

Active text area:

Default button state:

Hover button state:

Press/active button state:

Dropdown:

[SylvainCorlay]

This is truly wonderful! Some first remarks

• The change of default value for the Button description should also be done in the js defaults.
• The fact that this label is added by default breaks some of the examples in the Styling notebook, such as the carousel example.
• The capitalization by default is very nice but makes the caption take more space, which will require the styling notebook to be adjusted.

Edit: I also read through the slider styling logic change and like it very much!

[ellisonbg]

Button default fixed in ts. file, working on other updates now...

[ellisonbg]

• Fixed bug in interactive that was auto-displaying the output.
  interact should auto-display, but interactive can't or its entire
  purpose doesn't work.
• Update examples to Matplotlib 2.0.
• Got all examples working again. Some API changes in skimage, etc.
• Using viridis in Lorentz example
• Shorten the button text in used in interact_manual.
• Fixed button labels in Styling notebook
• Fixed Variable inspector to use default table styling (not boostrap)

Should be ready to merge!

[SylvainCorlay]

Thanks. I have minor changes to push on the top of this, but will do in a fixup PR.

[SylvainCorlay]

@ellisonbg I have merged, saved all the notebooks with the widget state and made another pre-release of jupyter-js-widgets to test on nbviewer and readthdocs.

I added a comment inline on a change that does not seem to be parsed. A consequence is that dropdowns don't render correctly on Readthedocs.

http://ipywidgets.readthedocs.io/en/latest/examples/Widget%20List.html

[jasongrout]

This makes it impossible to see when the button is focused, which is a huge accessibility problem. Can we add some styling change for when the keyboard has focused the button?

[jasongrout]

Again, this is a huge accessibility problem. We need to have some way to signify the slider handle has focus for keyboard input.

[jasongrout]

(the problem here, I think, is that border is none below, so setting the border color in the focus doesn't help - we also need to set the border)

[ellisonbg]

The issue of focus is going to be *really* challenging. The designs I have done try to cleanly separate different states: * Hover * Active * Non-active For regular mouse based interactions, focus is redundant with active, even confusing (focus remains on even after you stop interacting with it). The only case where focus gives useful information is during keyboard interactions. Even then, using the default outline is such a strong visual effect that you can't see any other styling (shadows, borders, etc.). I am open to trying to fine good focus styling that is more subtle, but can't visually interfere with all the other styling. Want to open an issue on that?

…

On Mon, Feb 20, 2017 at 9:35 AM, Jason Grout ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In jupyter-js-widgets/css/widgets-base.css <#1130 (comment)>: > } .widget-select select { + outline: none !important; (the problem here, I think, is that border is none below, so setting the border color in the focus doesn't help - we also need to set the border) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1130 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABr0MOzoslOOPbSu5f7Z7Ub2xxuNeBXks5recDggaJpZM4MFTyB> .

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

[jasongrout]

I think a lot of these styling changes look good, thanks!

I'm puzzled by the toggle button hover/active state, though - the button appears flat until I hover over it (so it's a bit undiscoverable as a button until I've happened to hover over it, which requires a lot of waving the mouse around and is impossible to do on mobile), and then when it is active, it appears to jump off the page even more. I usually think of buttons as being pressed down, so having an active (i.e., 'pressed') button floating above the page looks odd to me.

Can we (a) make the button look pressable (maybe with a shadow) by default, and (b) make the pressed state look lower than the unpressed state? I can try some possibilities out too.

[ellisonbg]

This is mostly following the material design spec for desktop style raised buttons: https://material.io/guidelines/components/buttons.html#buttons-raised-buttons The MD spec has raised buttons with a 2dp shadow be default, but they say that on a desktop style app, the shadown can be removed in the default state (Added on hover). I tested both options and honestly, the UI quickly gets's too busy with all buttons having a shadow by default. Previously, default buttons looked almost identical to text boxes and dropdowns. to make them more button like I did: * background color that matches border color * Uppercase font * Adding shadows on interaction We can add the 2dp shadow on the default state, but then we have to use (a third) color to indicate the hover state. I was trying really hard to not use more than 2 colors for the different state of everything. That gets to be really difficult to interpret 3 or more colors in the interaction. On the shadow treatment, LOL! A number of people have remarked the the Material Design spec gets it backwards. Physical items get a *smaller* shadow when they are pressed, not larger (as in the MD spec). I think the reason they went this way is that using a larger shadow for the unpressed state becomes too strong visually. So, even though I agree it is backward, I followed there spec (which is widely used). I will say that the the possibilities are *endless* when you combine shadowns, color, bordercolor for different state (hover, focus, active, default). I have tried hard to constrain the model by following the Material Design spec as much as possible, but deviating to match our own look or to simplify.

…

On Mon, Feb 20, 2017 at 12:06 PM, Jason Grout ***@***.***> wrote: I think a lot of these styling changes look good, thanks! I'm puzzled by the toggle button hover/active state, though - the button appears flat until I hover over it (so it's a bit undiscoverable as a button until I've happened to hover over it, which requires a lot of waving the mouse around and is impossible to do on mobile), and then when it is active, it appears to jump off the page even more. I usually think of buttons as being pressed down, so having an active (i.e., 'pressed') button floating above the page looks odd to me. Can we (a) make the button look pressable (maybe with a shadow) by default, and (b) make the pressed state look lower than the unpressed state? I can try some possibilities out too. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1130 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABr0N3_sqLto4_eazqT_grML8-K7XVwks5reeRBgaJpZM4MFTyB> .

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

The background on the MD button spec: http://ux.stackexchange.com/questions/72823/material-design-buttons-raise-not-depress LOL all the way home...

…

On Mon, Feb 20, 2017 at 12:42 PM, Brian Granger ***@***.***> wrote: This is mostly following the material design spec for desktop style raised buttons: https://material.io/guidelines/components/buttons. html#buttons-raised-buttons The MD spec has raised buttons with a 2dp shadow be default, but they say that on a desktop style app, the shadown can be removed in the default state (Added on hover). I tested both options and honestly, the UI quickly gets's too busy with all buttons having a shadow by default. Previously, default buttons looked almost identical to text boxes and dropdowns. to make them more button like I did: * background color that matches border color * Uppercase font * Adding shadows on interaction We can add the 2dp shadow on the default state, but then we have to use (a third) color to indicate the hover state. I was trying really hard to not use more than 2 colors for the different state of everything. That gets to be really difficult to interpret 3 or more colors in the interaction. On the shadow treatment, LOL! A number of people have remarked the the Material Design spec gets it backwards. Physical items get a *smaller* shadow when they are pressed, not larger (as in the MD spec). I think the reason they went this way is that using a larger shadow for the unpressed state becomes too strong visually. So, even though I agree it is backward, I followed there spec (which is widely used). I will say that the the possibilities are *endless* when you combine shadowns, color, bordercolor for different state (hover, focus, active, default). I have tried hard to constrain the model by following the Material Design spec as much as possible, but deviating to match our own look or to simplify. On Mon, Feb 20, 2017 at 12:06 PM, Jason Grout ***@***.***> wrote: > I think a lot of these styling changes look good, thanks! > > I'm puzzled by the toggle button hover/active state, though - the button > appears flat until I hover over it (so it's a bit undiscoverable as a > button until I've happened to hover over it, which requires a lot of waving > the mouse around and is impossible to do on mobile), and then when it is > active, it appears to jump off the page even more. I usually think of > buttons as being pressed down, so having an active (i.e., 'pressed') button > floating above the page looks odd to me. > > Can we (a) make the button look pressable (maybe with a shadow) by > default, and (b) make the pressed state look lower than the unpressed > state? I can try some possibilities out too. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#1130 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AABr0N3_sqLto4_eazqT_grML8-K7XVwks5reeRBgaJpZM4MFTyB> > . > -- Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub ***@***.*** and ***@***.***

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