[Slider] Two Handles Defining the Range 🏖️

[janhassel]

Summary

It would be of great if the slider component would support two handles to enable the user to define a range instead of just one value.

Desired UX and success metrics

If the developer enabled it, the user has two handles instead of one to control two numbers, presumedly minimum and maximum (to define a range).

Available extra resources

This is an example created by the WH team

Tasks

Beta Give feedback

1. [Slider] Two Handles Defining the Range: Design spec #14050
   adopter: PAL component: slider role: design ✏️ +3
2. [Slider] Two Handles Defining the Range: Implementation #14567
   adopter: PAL component: slider needs: community contribution role: dev 🤖 type: enhancement 💡 +5
3. [Slider] Two Handles Defining the Range: Figma kit carbon-design-kit#725
   kit: figma role: design ✏️ type: enhancement 💡 +3
   
4. [Slider] Two Handles Defining the Range: website docs carbon-website#3730
   adopter: PAL component: slider type: docs 📖 type: enhancement 💡 +4
   
5. [Feature Request]: Range Slider - Handle Tooltip Hovers #14549
   component: slider needs: community contribution proposal: accepted status: waiting for maintainer response 💬 type: enhancement 💡 +5

[sakshiseth]

I would like to take up this issue.

[designertyler]

Thanks for the suggestion. We have some past explorations with this range functionality

@jeanservaas Could you share the past work and what you're exploring for data viz?

[dimitrihoffmann]

I am extremely interested in such a component. I am especially curious about how it will be handled for smaller screens (e.g. 320px width)? The current single slider still shows the value right of the slider itself in such small formats. I wonder how this would be handled for a range slider as it would probably not work out the same way.

[janhassel]

Hey @designertyler!
Since this issue was moved from "proposal: open" to "proposal: accepted", does this mean it's being worked on by the core team? Or is it generally wanted but open for help? In other words: how do we proceed from here?

[tw15egan]

@janhassel I'm not aware of any dev/design efforts for this enhancement. I think "generally wanted but open for help" fits the bill, we see the value but don't have any current plans to implement. If your team has any extra bandwidth to contribute an enhancement for this, we'd be happy to work with you to get it in 👍

[harsha0609]

Hi @tw15egan ,
I am very interested in this improvement for the component , any update on the development?

[tw15egan]

Hi there @harsha0609, there has been no new development on this enhancement.

[mbgower]

@tay1orjones There has been discussion of such a range selection component for carbon charts, and @DianaStanciulescu and I have written an article on accessibility considerations for it.

[DianaStanciulescu]

I've done some explorations for a range selector meant for a heatmap (in dataviz). Not finalized, and a bit of a different use case, but I attach it here in case it comes in handy at some point.

Heatmap-range selector_ds_v7.zip

[kubijo]

For what it's worth, I've been able to build a seemingly fine working implementation (it's obviously not been extensively tested yet) on https://github.com/tajo/react-range.

[KevinCamelo]

Hi all, it seems like many of us have built potential versions of this enhancement. This is my exploration for adding range to slider. Documentation here: #10164

@janhassel, I know this is a pretty old issue, however; if you have some extra bandwidth I know the Cloud PAL team is looking to get this in soon. Morgana mentioned you regularly contribute to Cloud PAL. Thank you for that!

Perhaps we could work together to contribute this back to Carbon?

Update: We're doing it! 🎉

[KevinCamelo]

Hi all, it seems like many of us have built potential versions of this enhancement. This is my exploration for adding range to slider. Documentation here: #10164

@janhassel, I know this is a pretty old issue, however; if you have some extra bandwidth I know the Cloud PAL team is looking to get this in soon. Morgana mentioned you regularly contribute to Cloud PAL. Thank you for that!

Perhaps we could work together to contribute this back to Carbon?

Update: We're doing it! 🎉

Update: I've created some documentation for the range enhancement to slider, including a working Figma file that can be used to test the multiple states included in this enhancement. If anyone is available, I'd love to get some visual, UX, and CDS feedback on these before moving forward. 😄

https://ibm.box.com/s/4s8h59gazpuxv0fyxb1xq1pcxx6qvcwl

[akanshag26]

Please can anyone confirm is this implemented..do we have slider range component available in Carbon?

[KevinCamelo]

Not yet @akanshag26— we ran into some accessibility considerations that needed some additional design work and then I ran into a backlog of other work.

Ideally once I can get back to a sprint where I can explore the issue further, we'll update on this thread. 😄

[jamiegodin]

@KevinCamelo Hi there :)
I'm a lead in Security looking for this exact thing. Where are you on the implementation of this wonderful component? We need to add this to our left-side filter panel when filtering numerical values in results from a search.

[mbgower]

@jeanservaas looks like a lot of interest in this, and some decent explorations

[KevinCamelo]

@jamiegodin Hey Jamie! Unfortunately this is still on the backlog. I'd be happy to take it up again when I have a moment!— @mbgower one of the main blockers was making this component accessible, would you be open to a meeting to discuss some potential solutions for the issues we saw?

[mbgower]

would you be open to a meeting to discuss some potential solutions for the issues we saw?

Sure @KevinCamelo. I'll mention that I wrote an article about this interaction on Medium a few years back you should probably read https://medium.com/carbondesign/not-dragging-our-feet-a03ea57150e

[joshkimmell]

Is there an update on this component? It's been a need for a few years now and keeps coming up for Security product teams.

[DianaStanciulescu]

so cool! when talking about this with Michael Gower a while back (for a slider for a data viz legend), one consideration was to have a click-only option for interaction (he wrote this article about it https://medium.com/carbondesign/not-dragging-our-feet-a03ea57150e)

so we were thinking that you could click on the line to have the closest handle move to that position. I think it's worth taking a look at this click-only situation

[andy-blum]

I don't know that I agree with the click-the-line approach. While a non-drag solution is important, it's equally important that it works intuitively and predictably when users want to move either of the handles. Imagine a situation on the slider below where we only want to select 30° to 40°. If the text inputs weren't present, how would a user be able to move the upper handle down without dragging?

Clicking the line on the HTML-native <input type="range"/> works because you know which handle will move, but when we add multiple handles we're introducing a level of ambiguity that we probably need to empower the user to rectify on their own. Either by adding additional number inputs like the above screenshot or by adding dropdown options if the ranges have discrete steps.

[mbgower]

Hi @andy-blum, yeah, we identified that as a problem area in the interaction. We weren't sure how often it would be a real problem. For instance, where folks want any precision, text inputs would probably be needed anyway. (See Figure 6 in the article.)

You are correct that the user would have to do a bit of experimentation with how to arrive at a result where the left marker remains essentially untouched and the right is moved significantly toward it. I don't have any data to support my belief that users would quickly learn the same thing I did -- which was to click to the left of the right thumb, but closer than to the other one, to advance it so there was no unintentionally moving of the left marker. It didn't take me many clicks to work out -- but then I knew the underlying heuristic.

Note that one of the nice things about this implementation is that it totally supports dragging by thumb slider (and keyboard operation). It just also supports single click for those who need it.

There are obviously a lot of other ways to tackle this. For instance, we could make each thumb handle toggle 'on', and when it is activated, provide some +/- controls apply to it. What we found is that most alternatives would require some instruction on how to operate, AND involve a number of tabstops/controls that get added to a UI. The option of having text inputs (restricted to numbers) seemed the least problematic.

Interested to see what you come up with.

[andy-blum]

It's definitely a tricky set of problems to solve - the main thing I wanted to do with the POC was see if we could avoid re-inventing most of the wheel by using two overlapping range inputs. That obviously works, but brings in the problems we've discussed above as well as another big one I don't really have a great answer to:

Each slider needs a form label, but we can't really call them "lower value" and "upper value" because they're not on the same track and can move past each other. We could update the labels dynamically, when the values are changed, but does that mess with the discoverability of the form elements in the VO Rotor (or the JAWS/NVDA analog)? Do we announce that label change as it happens?

As for the specifics of how to handle a non-drag single-pointer control of the ranges, I think we'll probably want a couple of options with the ability to enter/select precise values, but I wonder if there are designs using this element in context that could provide additional insight or constraints.

[mbgower]

Interesting question on the labelling. That speaks to be a higher-level functional decision: can one move one of the sliders past the other? That seems like an odd thing to allow -- like someone setting their arrival date before their departure.
So my inclination is to say that in practice, one control designates the low range and the other the high range, and they remain so. You cannot reposition either (or enter a value) such that it exceeds the allowed range, designated between the end point and the other marker (say 0 on the left and whatever the upper range marker is on the right). You could have some interesting discussions on whether you want to allow someone to 'pick up' the other marker as they drag, so that they are moving both controls in that direction. My gut says that would be a bit of a problem too.

Obviously that kind of question applies with ANY of these dual slider interactions.

[mbgower]

Oh, and if you accept the above approach, then I think it's fine to give them consistent labels (or I should say 'names'; I don't think we'd want text labels on the thumb sliders). The one most likely to fit any scenario is probably "start" and "end". That seems to work with a 0-100 value range, a date range and a time range. Are there any potential slider contexts where start/end would not work?

[DenisCor]

any progress on this ?

[andy-blum]

We have a meeting scheduled for this afternoon for the various parties to sync up on this issue.

[sstrubberg]

REF https://www.w3.org/WAI/ARIA/apg/patterns/slider-multithumb/examples/slider-multithumb/

[sstrubberg]

Updates for everyone paying attention to this thread.

• Tasklist created at the top of the issue with design and dev tasks to be completed against our definition of done.
• @KevinCamelo is on point to deliver an updated spec based on our discussion today. He'll meet with our design team at the next Carbon Design Office Hours to review. Further touch points to come.
• Once a spec has been finalized, @andy-blum will deliver the coded implementation.
• Designers on our team will update the kits and website docs, working with Kevin where appropriate.

Stay tuned!

[KevinCamelo]

Hello all. I presented an updated solution today at Carbon Design Office Hours. This solution offers an update to accessibility related issues that existed with the first iteration of range slider.

Documentation:
https://ibm.box.com/s/4s8h59gazpuxv0fyxb1xq1pcxx6qvcwl

Design:
https://www.figma.com/file/Jk3pWNBG6ZWIRoldq2tM1x/Range---Slider-Enhancement?type=design&node-id=425%3A22406&mode=design&t=h8RrPqWg49eJGbgO-1

Following the meeting, a few changes were requested:

Error States

• Include the error icon.
• Left align numerical values.
• Increase the text-input width to potential max of 96px.

Number Labels

• Change to secondary colors
• Consider displaying these range values as help text.

Icons

• Have a 24px clickable area for targets in response to WCAG Req. 2.2.

Additional work to be done on this soon before! @mbgower might request your eyes on this soon just for an additional check based on the changes made today! Thank you all.

[m4olivei]

Hi all 👋 . Looking ahead to the implementation, questions for you all as I get familiar with the existing Slider implementation in Carbon and look at other implementations in the wild, close to what we're looking for here:

Would we be open to using an open source library for the implementation? I've been looking at noUiSlider which a co-worker has used successfully in the past. It does a great job with multiple handles, has many other features which we could expand into for future feature requests (more than two handles, connected handles, pips, etc.). Looks like there is precedent for this approach in the DatePicker component, which uses flatpickr under the hood.

Would love to get some thoughts on this.

[tay1orjones]

Would we be open to using an open source library for the implementation?

@m4olivei Yes, but adding a dependency needs to be really thoughtfully considered. In the case of both flatpickr and downshift we have a tenuous relationship with these dependencies. In many ways they have outlived their usefulness and migrating to/away from implementations relying on third party dependencies (and keeping the dependencies up to date) has been a significant time sink. Additionally, many of them rely on inline styles which we cannot use to be compatible with CSP requirements of various teams using Carbon. I'm not sure in this case if the usage of a library would provide enough benefit to outweigh the maintenance concerns, but I think yes it's worth considering.

[m4olivei]

Thanks @tay1orjones! That makes a lot of sense to me, expecially having just gone through some struggles with flatpickr, which is also used in the C4IBM repo (we ended up needing to patch it 😬). After considering it, playing with noUiSlider in the context of Carbon and working towards an in place enhancement, I feel that an in place enhancement is reasonable to accomplish without incorporating a third party library. Especially given that we're constrained here to only having to support two handles.

Here is a very early draft of a range slider enhancement to the Slider component: #14297

Have not implemented any of the proposed design just yet, as it's still not finalized. In the meantime, I have been working on the underlying mechanics, using the existing design language. I have been able to get all the mouse and keyboard UX mostly working as expected.

For anyone following along with, if you have early feedback on direction of the implementation, I'm totally open to that.

[KevinCamelo]

Good morning all. We have some excellent updates on the status of range slider in #14297. @m4olivei has made some excellent development strides in translating the design to working code!

I will be presenting this version of Range Slider to the Design System Adoption Guild on August 17th. If you're interested in attending, please sign up here for the meeting (IBMer only). Any feedback is appreciated here as well.

[elycheea]

Notes from DSAG on August 17, 2023

Presentation

– Mural
– Deploy preview 🙌

Looking for use cases and need and ensuring we have everything covered that we need to cover.

Took WCAG minimum and maximum using arrows (thumbs). Airbnb never overlaps the thumbs.
The limitation overlap from
Includes an autocorrect behavior to the min/max.

Autocorrection feedback options

• Show a message that value was corrected to nearest allowed value.
• Fluid inputs to show the values
• Number previews on
• If teams need a minimum distance between values (e.g. minimum of 20 between min + max)

Feedback and comments

Are handles same size or smaller than the original handles?
Used to be 24px 24px and now 16px 16px so a bit smaller than the original.

From @thyhmdo Could add focus to the autocorrected range input when error message shows
From @tay1orjones Could move the handles by clicking on the track — Taylor will add comments on PR.

Any plans for fixed value step slider?
e.g. slider only moves in specific increments
Existing slider does already include a step value + also a multiplier with shift ...
Step values can be controlled through playground examples.

Number preview addition adds something — not really focused on the min/max values.

Handles are keyboard operable with same shortcuts that the slider already has.
Minimum and maximum guidance is set up for 3 digit values (e.g. -999 to 999)
Recommendation not to use for really large ranges and please not dates.

Difference from slider style but following WCAG — evaluated several examples.
Not really recommending an alternative for tooltip without text input for accessibility reasons.

When you're focused on an input, is there a way to also switch the arrow to blue? Was just a thought to reinforce the connection between the input and the slider
Can look into this further

Next steps

Voting on the potential options ... voting with fluid/number etc.
@KevinCamelo maybe do another call-to-action in the DSAG channel to remind people to share thoughts on this one?

[KevinCamelo]

Hi all. @m4olivei and I met today and decided that the version currently in experimental should move forward — with additional enhancements coming down the pipeline once we can get to it. I have made an issue for the tooltip enhancement that you can find in #14549.

Thus, the last thing needed past moving forward in the coded experimental phase is providing design guidance in #14050. Will coordinate with Carbon for the creation of this design documentation.

Coded: https://deploy-preview-14297--carbon-components-react.netlify.app/?path=/story/components-slider--two-handle-slider

[mbgower]

I think this is a really nice series of iterations towards an improved outcome. Awesome!
PS I realize this is a mockup, but thought I'd point out that the message value 42 doesn't match the actual value 30 entered in the string in the demo animation.

[mbgower]

PS, it looks like the heuristic for the mid-point for the 'move closest slider' may be a little off? It seems like it's biasing to the maximum slider being adjusted, even when the position is somewhat closer to the starting position. Maybe you have a factor where once one side is set the bias is to adjust the other one? I think that's fine (and maybe an improvement). Just wanted to point it out.

[m4olivei]

PS, it looks like the heuristic for the mid-point for the 'move closest slider' may be a little off?

Thanks for catching this @mbgower ! I had been errantly adjusting by the size of the handle favoring the upper handle. It should now be fixed. Note that in the case where the distance to each handle is the same, the algorithm picks the lower handle to break the tie.

Also note that the preview link has changed:

https://deploy-preview-14297--v11-carbon-react.netlify.app/?path=/story/components-slider--two-handle-slider