Multiple Handles Range Slider

[hxltrhuxze]

Maturing the Range Slider component

With the current work on our v3 forms refresh, we've taken a deep dive into our form components, including reviewing how appropriate they are for the Royal Navy Design System.

We're proposing removing the current Multiple handles Range Slider variation for v3. It was originally created to solve a specific need for an exemplar project, but through our analysis, it isn't versatile enough to justify having in our library.

Proposal

Instead, we're looking to introduce a new Multiple Handle Range Slider variation based on standard industry best practices. It is worth noting, these aren't the proposed visual design of our new range slider variation - they're purely for illustrating the behaviour of our proposal.

Behavioural differences

Whilst the main functionality of the current and proposed Multiple Handle Range Slider are similar, there's a subtle difference in behaviour that is worth highlighting.

When moving the current slider handles, the colour of the slider bar does not track with the handle. Not only can this be visually confusing (as it doesn't display the true range between handles), but its behaviour is also counter to how other range sliders in our design system work. The expected behaviour should be that the two handles define a single range, which is highlighted over the slider.

The colours in the current slider imply that the handles are positioned in relation to each other. Particularly, depending on the initial state of the component, you cannot tell the difference in behaviour between a range slider where the colours follow the handles, and where they don't.

Taken from the w3c Design Patterns page:

A multi-thumb slider is a slider with two or more thumbs that each set a value in a group of related values. For example, in a product search, a two-thumb slider could be used to enable users to set the minimum and maximum price limits for the search. In many two-thumb sliders, the thumbs are not allowed to pass one another, such as when the slider sets the minimum and maximum values for a range. For example, in a price range selector, the maximum value of the thumb that sets the lower end of the range is limited by the current value of the thumb that sets the upper end of the range. Conversely, the minimum value of the upper end thumb is limited by the current value of the lower end thumb. However, in some multi-thumb sliders, each thumb sets a value that does not depend on the other thumb values.

In the current variation, there is an established relationship between the values of the handles - you can't reorder the handles inside the slider. Visually however, these values are 0-indexed, meaning the values on the slider are set independently from one another. This straddles two patterns in a confusing manner, and is something we'd like to rectify with this project.

In addition to this, using colour to define thresholds causes issues with A11Y guidelines, as it is currently the only indicator for each respective threshold.

---

Upgrading

The last thing we want to do is make upgrading to v3 of the Royal Navy Design System an unattractive prospect. To combat this, we have suggestions to help individual teams migrate to the new major:

• We're open to working with individual exemplar projects to find a better/alternative UX pattern for this slider variation, based on the updated form components we are introducing.
• Alternatively, we can provide the current Multiple Handles Range Slider code so it can be included in your applications after upgrading to v3. This option comes with the caveat that you would have to support this component variation yourself.

We will give plenty of warning to teams as to when v3 is due to be released.

---

As ever, comments, thoughts, and perspective is appreciated here. We want to make sure we continue to evolve the Royal Navy Design System into an indispensable tool that teams can rely on to build their applications. We do this by ensuring the components and variations we provide are versatile enough to be used in as many scenarios as possible. We are a small team, so it is important for us to focus on building components that serve the most amount of teams as possible.

This unfortunately does mean we have to make difficult decisions, such as the one proposed here. However, we believe this proposal is in the best interest of both ourselves and the teams that rely on us.

- Royal Navy Design System team

[ghost]

Would be great to chat about this when you have some time. Thanks.