4

I'm building an application that requires individual accounts to be segmented by revenue. I’m trying to find the easiest way for the User to create these segments. This task involves breaking a single range of revenue — in this example $1-$10,000 — into multiple smaller ranges.

The relationships: - The application has a revenue range (the larger one). - Each segment has a revenue range within the application revenue range. - Each Account has a monthly recurring revenue number.

multiple segments

Above is my current solution—a table with the name of the segment and fields for the user to enter low and high ranges for the segment. I'm concerned that this will come off as confusing and it doesn't show where those ranges fall within the total range within the application.

I’ve considered moving to a series of sliders within a slider—perhaps how Photoshop handles gradients, but am worried that it is going to come off more confusing.

Overlap of these ranges is acceptable, but not preferred.

Has anybody tackled this problem before or have thoughts on the best way to solve it?

UPDATE 10.7.2016

I might have found a better solution for this problem. There is a library called Elessar, which attempts to do something like Photoshop's gradient picker.

slider

The library presents a slider with a range. Hovering over an area allows you to create a new range within the larger range. Once a new range is created The edges can be dragged to expand and contract in either direction. The tool does not allow for overlapping ranges.

Out of the box it does not appear there is a way to delete a segment. I think the easy solution would be to have an X that appears when hovering. Hover, click the X, Are you sure? dialog and then the segment is deleted. I am a bit worried about how this might look on the smaller segment.

Some other possible issues with this solution:

  • The sliders are not as accurate as inputing in exact numbers. For example, getting the slider to hit exactly at $499 could be difficult.
  • Very large ranges may make it difficult to be exact.

UPDATE 10.10.2016

I think Madalina's approach is probably the best one to take with this feature—keep the slider as a representation of the data but confine editing to the table.

multiple ranges with bar visual

By using the bar graph to represent the applications revenue range and the smaller ranges within it, the user has an easier time visualizing the size of the segments.

Additionally, this will take much less time to develop than with a slider.

Improve this question
1
  • Slider accuracy is always a problem - especially if you plan to take this into the mobile/touch market at some point. There are, however, a couple of work arounds for this. Dealing with the range of movement, you could ask your engineers to build it in such a way that dragging the mouse 2 pixels across the screen moves the slider by 1 pixel (or whichever ratio suits best) to allow the user a more fine control. Dealing with precision, I have found that a popup magnifier that appears as soon as the user starts to interact with the slider works well in certain cases.
    – Roux Martin
    Oct 7, 2016 at 14:43

1 Answer 1

Reset to default
3

I think you should keep the slider as a representation of the data modified in the table only, without the possibility to change the data there too.

After the update in the row, the interval can be highlight on slider too. If you find easy to use a range slider, you can use one in a modal/ popup when the user updates the row, but I prefer the inline edit. You said you need something less confusing, so keep it simple, not more complicated.

The solution with multiple range sliders is faster, but not really intuitive for saving data.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.