Home

Another user-interface post. At this rate, we’ll have sorted this out by 4082 a.d.

Ran into a problem today and I have _no_ idea on how to continue. Well, a few ideas, but they’re all terrible. I’m just going to ramble on about this hoping it’ll nudge my brain, but do not expect graphics or even halfway decent prose. I’m desperate, and in a hurry.

Most controls (textboxes, checkedboxes, radiobuttons, sliders, colour fields, …) are there to inform about and provide a means to change the state of the computer. Exceptions are passive controls such as labels or graphs that are merely there to inform, and controls which only do things, without showing information. Sometimes buttons fall in this latter category, but even buttons can have different text depending on state or may be disabled when it makes no sense to push them.

Let’s focus on three common controls for the time being; checkboxes, textboxes, and (number)sliders. It is easy to see how these all work pretty well considering their ultimate purpose. They allow the user to both see and change a boolean, a string, or a number state respectively. If the state is YES, then the checkbox will contain a check, clicking on it will remove the check mark and switch the state to NO.

But it is possible for the state itself to exist in more than one state. Either there is a single state (great, we know how to deal with that), there is no current state (this could be a problem), or there is a plurality of different states (we’re hosed). This is easy to see if we imagine our controls to represent some properties of a geometric curve in a graphics application. For example the checkbox could be bound to the curve’s printable state (YES=include when printed, NO=omit from printed output), the textbox bound to the object’s name, and the slider bound to the line-width of the curve. When a single curve is selected these controls will work perfectly well, but when no curve is selected there is no underlying state.

In this case the checkbox cannot be empty, because that implies an off-state, the textbox cannot be empty because that implies no-name, and every single slider design I have ever seen certainly doesn’t support an empty mode. So what do we normally do? We disable the controls, making them all look faded or sunken or transparent. It’s a kind of solution that kind of works well enough. The appearance of the control is significantly different from the enabled mode that we can tell the difference between a checkbox that is YES, NO or DISABLED.

But the real problems start when we select more than one curve. Now potentially we have a checkbox, a textbox and a slider that are associated with multiple, different states. The existing solutions to this problem are inconsistent and bad. Let’s begin with the least bad and least inconsistent one; the checkbox.

I think all decent UI platforms provide checkboxes that have an ‘indeterminate’ state. A quick Google Image search immediately yields plenty of examples. This is how Microsoft decided to solve the plurality problem for checkboxes:

Checkbox states

On, Off, and Indeterminate states of standard Windows checkbox controls.

So what’s bad about it? Well, first of all the INTERMEDIATE state is more prominent than the ON state, filling more pixels with the same green. This makes it seem more certain of itself rather than less. Secondly, plenty of people colour in entire squares when filling out forms, so the fact that we agreed that a check-mark signifies ON while a square signifies INDETERMINATE is an ad hoc decision that will not be obvious until after someone explains it to you. Thirdly, it tells you nothing about the imbalance of the plurality. Does this one ambiguous checkbox represent 50 YES and 50 NO values, or 99 YES and only one NO value? This is important information because a reasonably balanced ambiguity tells us it’s probably fine, whereas a heavily imbalanced ambiguity tells us that a few values are probably wrong. Lastly —and for the checkbox not particularly important— there is no way to go from UNDETERMINED to a specific state. When we click on an undetermined checkbox it will either turn YES or NO, either based on OS or App logic. The user doesn’t get to pick. Now as I said, for checkboxes that’s not that big a deal because the other option is only one more click away, but keep an eye on this.

What about textboxes? Here too there is a commonly accepted solution. If a textbox is supposed to display more than one string, the program will helpfully render the string “<varies>” instead. This is somewhat informative but exceedingly unhelpful. Again it doesn’t tell us anything about the balance, and it obscures all the actual data. There is no mechanism for us to pick one of the available strings and assign it to all states. It also doesn’t tell us whether we are dealing with two, three, four or fifty thousand different strings. Or for each string how often it occurs amongst the conflicting states. Or what the commonalities are between all the different strings, for example do they all start with “city:”?

I can see a solution to this, but it only really works in the case of a small amount of conflicting states. Instead of “<varies>”, the textbox could show “city:London city:Paris city:Berlin“, with each unit being clickable. They can be sorted from most-common to least-common, or some other order if that makes more sense. But this clearly doesn’t scale to a large amount of conflicting states, and also easily requires more screen space than the original textbox.

The case is maximally bad for number sliders. There are no common solutions, or even uncommon ones (if you know one tell me!). Most slider controls do not allow you to hide the grip, but even if they did where would you click to set a new value for all states? My imperfect solution would be to draw various grips, all very faded or transparent, and allow the user to click on one to copy a specific state to the entire set. But again doesn’t work if there are loads of different states, or if two states are very close together making it impossible to reliably pick one over the other. Maybe it makes more sense to show a statistical distribution instead of grips? I do not know.