How to create bands of number ranges for a field?

Question

I have a field in a system called "Score" which ranges from an undetermined negative number to an undetermined positive number. I am trying to figure out a UI for the user to create "bands" of numbers that can be labeled. (Example: Low, med, high)

The coverage of the bands has to be complete (to negative and positive infinity) and also be mutually exclusive (no overlap).

I have been experimenting with sliders, but this is a tricky problem. Has anyone done this before?

Answer 1

I'm a bit distressed that people living in a world exposed to things like Google Instant and StackExchange sites could possibly still be suggesting any "rigid" and "form-like" approaches! :-/ I'll paraphrase @BobbyJack and Wendy's by saying "Where's the beef?"

For instance, why should I have to sort the numbers as opposed to letting the computer do that for me? Can't I just give a list of split points and have it make the ranges? What if my data is coming from a source that has the numbers already in a list--how might automated processing help?

But it is better to light a candle than to curse the darkness, no? :) I'm on holiday and it's been a while since I've updated my blog, and Glen suggests there wasn't any prior art on this. So I thought I'd take a crack at coding it up which you can actually try out online (obviously "unfinished"):

http://jquery-numband.hostilefork.com

(Update: 20-Mar-2015 I have added a short demo video.)

You can enter freeform text. It picks out everything that's a number, discards duplicates, and generates the ranges. If you want to add a new number you can just type it in there (nothing stopping you from putting on more buttons too, but it's kind of nice to just edit the list of split points independently).

The arrows let you specify the inclusive/exclusive boundaries of the range. Click on an arrow and it will jump into the adjacent band group and flip direction. (So in the above diagram, "blah" is for anything greater than 20 but less than 40... while 20 will go to "Default" and 40 will go to "next".)

I did a simple history mechanism, but one can envision something much better. Basically if you just add a new split point and it wipes out a mapping you've entered... it keeps that old value around along with the memory of the range it was associated with. For the moment I only automatically pull history entries back in if a range with the same numeric bounds comes back. It would also be possible to make suggestions out of the history, or drag and drop from it.

It's open-source, MIT licensed, and making it better is left as an exercise to the reader :)

https://github.com/hostilefork/jquery-numband

Answer 2

First off, how well acquainted with the symbol for infinity will your users be? It's a small point, and I'm guessing they will be OK with it, but still worth checking.

Second, I can't see how a slider with infinity (positive or negative) at one end can ever work. Your example shows 20 near the middle; what value would be used close to one end? 1 million? 1 trillion? 1 googol?

If the values are genuinely unbounded, you need a fast mechanism to enter them, and any kind of slider or '+'/'-' buttons aren't really going to be suitable for huge numbers. Freeform text begins to seem like the only option, and it's certainly the most flexible, if not the most attractive.

Can you give an example of a set of bands? I really want to get a feel for whether they're something like:

-INFINTY - -100
-100 - 100
100 - INFINITY

or:

-INFINITY - -1,000,000,000,000
-1,000,000,000,000 - -500,000,000,000
...

or whether really anything is possible.

Answer 3

I 100% agree with HostileFork's approach of a textbox style entry. When I was reading the question it instantly made me think of the classic print dialog UI for inputting what pages are to be printer - it's a similar problem, and textbox input is still the best solution I can see.

I think there are a few more things to be considered as well:

• Users might want to sub-divide into equidistant bands, this would be fairly painful with a textbox UI because the user is forced to enter every bucket boundary manually (very painful if the bands are small compared to the value range of the data)
• I think it's important to visualize the bands to help the user realize they are potentially creating non-equal sized bands
• I think manually naming the bands is an edge case, the app can do this using a standard band-naming convention (with the user choosing to rename only if he/she so wishes)

Here is a mockup:

• You can imagine the blue range visualization animating the sub-divisions as you type the values in the textbox
• Because the range visualization is to scale there is the problem of buckets being created which are too small and don't allow any room for labels. The labels would appear where they can but will be dropped if there is no room; the user can hover of the blocks and get this info (and more) through a tooltip.

The problem of mixed units:
For hierarchical continuous dimensions (such as time) there is the problem of input from different hierarchy levels. For example, in the case of tenure, users might want to specify the first few tenure bands in terms of months and the rest in terms of years; however, the textbox UI requires all input to be in the same time unit (e.g. years). One option is to use a decimal years approach, with the input rounding to the nearest month (e.g. if user entered 0.27 it will round to 0.25, which is equal to 3 months). Of course, this isn't great usability - I can just see users sitting there with a calculator trying to figure out what is 5 months in years decimal format. Another approach would be to have a time unit toggle beside the textbox (mockup below). Regardless, I think the auto-naming of the bands should do unit conversion and avoid decimals!

Answer 4

One possibility a friend came up with.

Answer 5

I think you’re on the right track with graphically representing the ranges. My first thought to test is something like this, with range names clearly between the range bounds:

A plus button splits the range adding a default bound (perhaps midway) and default name, with focus placed on the new bound for adjusting. User can click or tab to either range name to change them if desired.

You need two Deletes per range, one to delete the name and the upper bound, and one to delete the name and the lower bound:

The spacing between the boundaries may be proportional to their separation, in which case you probably need to also support zooming in and out. You also may want to allow users to drag and drop a boundary to change its value. However, if your users can get an adequate sense of the size of a range just from the numeric values, then for the sake of simplicity you may want to pack the boundaries (like I’ve done) together so they only represent their ordinal ranking. In that case you may want to make the boundary controls spinners (like I’ve done) to allow an alternative to typing a value.

The above design is fairly self-documenting, although you probably have to fiddle with the graphic design, particularly for communicating how the two Delete buttons are different (my crude drawings are unlikely to be adequate). However, the design is also relatively space intensive and cluttering (although, again, better graphic design may help). If space is at a premium, you may want to sacrifice some self-documentation and consider an object-selection-action model, where each range name has an icon to support selection and a menu (both a pulldown and context ) to provide the options. It also allows you to include as an option copying ranges to a different score line:

This implies you support multi-select through the usual idioms.

I can think of two viable ways to handle the user changing a boundary value so it leap-frogs another boundary:

• Prevent. Simply don’t allow it. If the user types in a leap-frogging value, throw up an error message. If the user drags or spins up to another boundary, provide graphic feedback that the user is at a limit (e.g., the limiting boundary turns bold and red). This is best if leap-frogs tend to be errors (e.g., the user typed an extra digit). It’s easy to recover from this.

• Squish. Change the leap-frogged boundary (or boundaries) to equal the leap-frogging boundary. This is best if leap-frogs tend to intentional –that the user plans to adjust or delete the leap-frogged boundaries or ranges when they’re good and ready. It’s flexible but harder to recover if it’s an error since it changes the values of any number of boundaries, especially if you don’t support Undo (but you will have Undo, won’t you?)

Answer 6

I suggest labeling the axis with 0, -[big number], and +[big number] with a tail after each of those which will ascend exponentially