Iteration on range control

[karmatosed]

There are a number of limitations of our current range selector including the arrows often going missing and small spaces to interact with. #14166 audited this control, I took a dive into iterating this based on the great work being done in #18667.

As I am working on global styles, one of the controls will be the range one to interact with the typography scale, so this was a little diver deeper into that control.

Before I dive in, props to @ItsJonQ for providing some fuel to the investigation I went on here. Some research links to share:

Material tooltip

Colored ranges

Our range control has 2 states to adapt to so far (with idea it might need to flex):

• A scale without numbers.
• A scale that can also be increased by numbers.

I also wanted to explore later what a tooltip could bring in.

Making it bigger

I began by starting to increase the hit space for the slider.

Then I began to explore how this could develop.

Bring some color to it

Next, I brought in some tones and colors.

With numbers and arrows

How could this then scale to give both states? I first started with a larger version.

Then, I took it back a little to align more with the balance we have already.

Finally, what about making the control stronger so it really focuses?

With tooltip

My final exploration was into what a tooltip could bring to this.

Feedback

I would love some feedback on the directions I am going in. As you can see this isn't a final polished piece yet, more exploring what could be here. As the work on advancing the interface is moving on, I want to be sure to align there so cc'ing in @jasmussen.

One little point, I haven't included reset yet here as focusing on the control, but a final version would, of course, show that. I also think maybe that becoming a link makes sense, but another issue should have that discussion.

[ItsJonQ]

@karmatosed These designs + suggestions are wonderful! In working through the experiments and technical side of Global Styles, it became clear that we'll be needing and relying on a lot of Controls. Therefore, these Controls need to stable and awesome 🙌 , for block controls, global styles controls, and beyond 🚀

From simpler ones like Text/Number fields to Range and ColorPicker. Interfaces that enable users to modify values that are used in the Global Styles system.

I've looked into the RangeControl before, so I'm familiar with it.
I'll see if I can make some updates to refresh the design but also improve usability.

For example, I've struggled to grab/drag the controls in the past - due to the small(ish) hitbox.

[ItsJonQ]

Updates on my end!

This is what I have so far :)

Features:

• Uses native <input type="range" />. Get all the browser support for drag, keyboard, etc...
• Visual tooltip that displays current value. Follows the "thumb" (circle)
• Larger hitbox, making it easier to click/drag

• Renders step markers with a simple prop (marks)
• Tooltip auto positions top or bottom, based on ideal rendering position
• Respects reduce-motion to disable all animations
• Can easily change the color of the "track" using a color prop
• Can customize the tooltip's content with a custom renderProp

So far, the component's props looks like this:

export const RangeControlNext = forwardRef( ( {
	alwaysShowTooltip = false,
	className,
	color: colorProp = color( 'blue.wordpress.700' ),
	disableToolTip = false,
	disabled,
	help,
	id,
	label,
	marks = false,
	min = 0,
	max = 100,
	onChange = noop,
	step = 1,
	value: valueProp = 0,
	renderTooltipContent = ( v ) => v,
	tooltipZIndex = 100,
}, ref ) => {
  ...
})

Note: I'm going to be bringing functionality of the previous RangeControl into the new version for 100% backwards compatibility.

[jasmussen]

What about this?

Then we'd avoid any contrast issues with the light gray border around the white knob.

[karmatosed]

@jasmussen my only ponder with that is whether the control stands out enough, which I know is maybe unexpected saying with it being a bright color. Maybe on interacting it could show but I do wonder if it shouldn't change color, for example, it's not a button to click as much as move. I am very happy to be wrong there though as we're getting into the nuance of this.

[jasmussen]

The benefit of just using two colors is that it just uses two colors, which simplifies the look and the contrast equation. But the dark color works too, and the shadow that Q added in his lovely prototype is also a way to signal interactivity. That's all a way to say this seems on a good track as is. But the white knob with light gray border as is, likely won't pass the contrast needs.

[karmatosed]

I think the a11y point is really important. We might want to then open up both as a point to see which is more acceptable.

[ZebulanStanphill]

It's worth restating that from a usability and accessibility point, it only makes sense to use slider controls like this for things that don't require high precision. In other words, something like the number of columns in a Columns block should just use a simple number input rather than a slider, since the exact number of columns is really important in that context, and a slider doesn't add much to the experience.

I say all this because I notice that there are design mockups here containing tick marks, but I can't see why you would use a slider for such controls in the first place.

[ItsJonQ]

📹 Screencast to demo new RangeControl
https://www.loom.com/share/ab01335a805043ee86e470e3308e621a

@jasmussen + @karmatosed

Neat! Let me know what design/colours you'd like to go with, and I can make that update :)

... I notice that there are design mockups here containing tick marks

@ZebulanStanphill

Haii 👋 ! The native HTML input supports the rendering of marks/ticks, which is handy:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/range

Since this RangeControl components acts serves as an enhanced wrapper for that element, I believe that it should support that feature.

[ItsJonQ]

It's in a pretty good state! All previous RangeControl tests pass, without regression. The new one has feature parity with the old one with new features.

Tested within Gutenberg (above)

Here's the branch so far 😊

https://github.com/WordPress/gutenberg/tree/try/range-controls-ui-update

[ZebulanStanphill]

The handle seems to blend into the background a bit too much. Could it be given a darker border?

[ItsJonQ]

@ZebulanStanphill Good suggestion!

I've darkened it to use darkGrey.200 from the libraries colour palette.

Focus/hover darkens it a bit:

@jasmussen / @karmatosed
How does that look? 😊

Note: The selected range color uses the default WordPress blue color to make it look cohesive with the current component set. Open to any colour changes!

The code looks like it's in good shape. I can submit a PR first thing on Monday 💪

[jasmussen]

How does that look? 😊

Having worked so much on #18667 adjacent PRs, the only two colors I can think of when looking at these are shipping the new Blueberry color and applying it in as many places as possible, including the knob 😅— but that's a personal opinion.

What matters most is the border passes the contrast requirements, and it looks like it does so. Going back to the G2 efforts, they introduce a new singular "dark border color", which is used for all primary UI — toolbars, icons, primary popovers. If G2 was shipped already, I'd use that dark color for resting and hover both, and even remove the drop shadow and reserve that elevation for menus and dialogs.

But in absence of that, yeah looks good!

[karmatosed]

@ItsJonQ this looks great. I think maybe once G2 is in bringing in that blueberry for the slide measure would be great. However, without that maybe bring in the 'blue' we use now for hover/primary buttons? Thanks for this, super excited to see the iteration in a PR.

I would be ok with having the 'blue' showing on an interaction, even feeling what it's like for the dot. I think any could work there so let's go with whatever is consistent with new iterations.