[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

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

[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