While doodling on a pad today thinking about user interfaces, I started to wonder how I could demonstrate by UI that two sets overlapped and had common members. (In DOM parlance, this would be two ranges overlapping in the same document, or two overlapping selections.) Given a DOM node tree, how would you show that a node belongs to two different ranges? My solution: add in a few narrow columns to the left, and shade the columns by row for each selection. If two ranges overlap (or have adjacent boundaries), then put each range shading in different columns.

In other words, just add bars to the left of the main objective to show where the sets and their overlaps are.

So far, so good. But at the same time, I had this “brilliant” idea: why not make each selection’s shading in the column a different color? Read on for more details.

Of course, they couldn’t be just different. #ffffff is different than #fffffe, but I dare you to look at a webpage with a background of pure white and a fair-sized square of this odd color, and tell me where the square is, using only your eyes (no mouse, no keys). No, they had to be as different as possible so that people could recognize each one.

(These unique selections would also have unique number codes in them, as another aid.)

So instead of the 1.6 million plus colors I could choose from, I decided to restrict myself to the “web-safe” colors. But then how would I choose colors that were the most distinct from one another, so that a little 10-pixel-square marker could clearly be distinguished from another.

Enter combinatorics, the well-known art of mathematics where you try to find as many combinations as you can of something. (For fans of PBS, I first heard about this on the show “Square One”, which I still think is one of the best shows there could have been for a young elementary school student.) There are six generally recognized web-safe levels of color intensity: 00, 33, 66, 99, CC, and FF. There are three types of colors the computer monitor shoots through electron guns: red, green and blue. Combinatorics tells us, then, there are 216 possible web-safe colors (six to the third power).

But combinatorics wouldn’t help me define a preferred order to these colors. At least, not in so simple a calculation.

I then started drawing up a table of two axes, one for a “on” color and one for a “off” color

. My thinking was the most diverse combinations of color intensities (brightness) would produce the most distinct colors. #ffffff compared to #000000 is much more distinct than #ffffff compared to #cccccc, for example. So for a pair of on-off brightness values, there would be eight combinations (on-off for red times on-off for green times on-off for blue). But how to select the most distinct pairs?

At this point, I started throwing numbers on the table, making intuitive guesses. Almost half the table I threw out immediately, since an on-off pair reversed would match another on-off pair, and give me duplicate results. Also, where on and off matched, there could be no pairs. I wrote up an algorithm that would give me about 120 colors in an order that probably would start with the most distinctive colors, and descend to colors that grew a little too close for my comfort. Since in most cases I couldn’t imagine anyone using more than about, oh, 32 of them at any given time, I figured this would be more than enough.

Until I started thinking about the possibility that I was ignoring some combinations.

The above on-off idea means you could have combinations like #ff00ff and #99cccc, but it would exclude combinations like #33ffcc. So I started over on a new sheet of paper. I assumed three levels of brightness. Harkening back to my days in high school television, I called these three key, back, and fill (for the three main lights used in lighting a subject for the camera). The key, or primary, would always be ff. The back light and fill lights would be any of the other five brightness levels. This meant a table of 25 options, of which 10 had to be discarded right away (again, one back-fill pair would be another’s fill-back pair, and mean more duplicates.) That left fifteen options of up to twenty-seven different colors. I discarded six where the combinations just seemed too close, and ended up with nine sets of 27 — potentially 243 colors in all.

Now, if I had my wits about me at that moment, I probably would have realized that I had too many colors. There are only a possible 216 web-safe colors, where I was claiming to have found 243 candidates. It didn’t take me long to realize another flaw, though: where the back and fill colors matched, there were only 8 possible color combinations (not 27). Take that into account, and I still had an algorithm for finding and ordering 148 relatively distinct colors.

(I think my math is still off here. 148, when you consider the earlier guess of 120, seems too low.)

So I had two algorithms which would likely yield me good orders for colors, at least at the front of the pile. Somewhere in the final bus ride home, I realized the biggest fallacy of all with regard to this little scheme, and it had nothing to do with mathematics or intuitive guessing.

In a perfect world, where everyone could see all these colors, it would have been a very good solution. Certainly it would have been more than adequate in either variation for my purposes. But we don’t live in a perfect world. We live in a human world, with human frailties, such as color-blindness.

Now, when I work on user-interfaces, I generally want them to be accessibility-friendly. This means taking into account a lot of different things, such as color-blindness. Some of the colors my algorithm would have generated, to at least one family member of mine, would have appeared identical. This completely defeats the scheme of multi-color highlighting, as I originally imagined. It was a “brilliant” idea, but an impractical one.

Not all is lost. I can still give each selection the standard dark-blue selection highlighting (and a background of white for non-selected portions), plus a little number code in the highlight identifying the selection.

The best part about this mistake I made is that it cost me only a couple hours of deep thinking in an area I’ve never been great at within the realm of mathematics and logic. It was good practice, too. I’m not really writing this blog to say, “Woe is me, I’m a dumb guy again.” But I am writing it to say, “Here’s another mistake you can learn from.”

Overall, I don’t regret going down this path, as I often do when I make fundamentally wrong assumptions. I learned a little bit more about good UI design. What I’ve just explained has probably been covered in UI design books before, but it bears thinking about by programmers in general.