The following article is about the design process of the Rule Builder widget in Prototype-Widgets. Demos and source are available here: http://jsinglet.github.com/Prototype-Widgets/
Download as a PDF.
Nothing makes my nerd heart beat harder than good interface design. And one of the most interesting aspects about interface design is the issue of reinventing or improving well-established UI elements and conventions.
But while everyone agrees that designs can always be improved it’s not always clear what that means and more importantly, if it’s even possible.
I’ve overheard many heated arguments in which someone eventually says something like: “Everyone expects x to work like y, so you can’t change it!!” (This is usually the deathblow to the other person. They walk away, tail between legs, to go silently Facebook-stalk their ex-girlfriend.)
And you know what, this sort of system seems to work. Most of the time. But that’s only because most of the time we come up with terrible, terrible ideas. But sometimes new controls and ways of doing things do need to get designed. How to settle this age-old argument?
The first thing is to understand that it is okay to change things. This should be obvious. But when? Companies like Apple have invented entire new widget standards with phenomenal success while others have floundered. What did they do differently?
As a framework for discussing that, let’s start by classifying our UI elements. I suggest the following classification for thinking about UI elements:
- Semiotic Elements (eg: Radio Buttons vs Circles)
- Paradigm Elements (eg: Click/Drag vs Swipe/Touch)
- Functional Elements (eg: Clicking on a table header to sort vs pulling down a drop down.)
Naturally, each of these refers to either general or specific parts of a user experience as indicated by the image, below.
The Semiotic Element – eg: Radio Buttons vs Circles.
The most core relationship a UI element has to its user is its Semiotic meaning. This can be a property as simple as “is this element selected?” or “what does activating this control mean?” Controls in this category are things like check boxes, radio buttons, highlighted table cells. Why? Because they all mean one thing: “This thing right here.” And though, to a programmer/designer, the difference between a radio button and a checkbox is oceanic, to a user, all they mean to say when the click or check something is “this thing right here.”
If you want to convince yourself of this, check out the image, below:
The only difference between these two is the fact that on the programmatic form, you are not allowed to select more than one. On the paper form you are on the honor system.
So can components of this category be reinvented? Of course! With the following caveat:
Never change the meaning of a click or a highlight or placement meaning “This thing right here.”
Imagine if to select something a user had to unselect the item he wanted? Workable, but chaos. And the reasons for this are probably so hardwired into our brains that it’s probably not even worth exploring the alternatives. That is, if your goal is to make usable user interfaces.
The Paradigm Element – eg: Click/Drag vs Swipe/Touch
Paradigm elements have to do with the way we think about things. A good example of something in this category is the concept of basing the storage of a hard disk off of 1950’s office technology: Files and folders.
While “files and folders” are an overwhelmingly popular way to think about your data, it’s hardly universal. For example, Plan 9 doesn’t really use “file and folders” at all. And of course, more famously, the iPhone, from a user perspective, doesn’t even have a filesystem!
It’s surprising to realize it, but even things like the filesystem, or even files can be changed. That’s because as humans we are really, really good at inventing new ways of doing things. In fact, the term “Paradigm Shift” has practically become as bourgeois as the word bourgeois!
So paradigm shifts are ok. Just so long as the paradigm you replace it with is as complete as the one it replaces—or has really good reasons for not being.
The Functional Element eg: Clicking on a table header to sort vs pulling down a drop down.
There are lots of ways to skin a cat. Or at least that’s what elements belonging to the Functional Element group think.
Examples of this type of element are things like the OSX Dock, the Windows Start Menu, and sortable tables—all things that can be done a million ways. Also, all elements that use a combination of elements to provide the user with a much higher level function than saying “this thing right here.”
Functional components give the user the ability to say “I want all of the albums by 1972 David Bowie from the Ziggy Stardust tour, but I don’t know how to spell “Bowie” or what year the Stardust tour was.” Or even simply, “Is my package on time?”
These are arguably some of the most malleable components. Mainly because in creating their own language they use so much of the language of the Paradigm and Semiotic elements. For example, clicking on a table header might cause a highlight, which then highlights the sorted column. The meaning of “this thing right there” is preserved.
Really, the general rule of an element of the Functional type is simply that they allow the user to perform the function they expect to perform or that the function is possible given proper training.
This is where the problems start.
Designers and Programmers sense that this element is “ok” to change and they do. And because there appear to be no rules for doing so, the results are often terrible, unworkable, illogical interfaces that make users feel stupid and cost your company or project money and users.
Elements of this category are often incredibly hard to make and often represent the bulk of work done by programming and design teams.
My Dilemma – Designing the Rule Builder
So what is the practical impact of all this you ask? It’s something you can apply to your day-to-day work.
I recently had to do this on a control I was making: A Rule Builder.
The goal was to make a control, similar to the way a mailbox filter builder that would allow a user to build a very complex set of interactions.
So the question for me was: is it okay to reinvent this control? Is it even possible? Seeing as a rule builder would fall under a “Functional” element, I decided that it would be.
I asked myself: What is wrong with the current paradigm? The answer? A lot. The current paradigm works something like this:
One builds a “ruleset” by adding together these elements in rows. For an example of one of the better implementations of this, check out the Apple Mail filter builder:
Take the example of Apple Mail’s Rule Builder:
Here they’ve done nice stuff like added natural user language to the process and placed all the controls in the right places and even made the action of the filter very, very clear. But there were several things I didn’t like about Apple’s approach.
First, Apple’s implementation relies on over simplification of the problem. One cannot group together the logic of the filter.
Second this design uses the same “double drop down” approach that the standard UI convention uses. This itself has a number of problems. Mainly, a user has to click twice, and must then move between the “what to filter” and “how to compare” options of the form if they wish to get a complete picture of all of their filtering options. In other words, a user has no context.
And then there’s other approaches, some of which are just too bad for words:
Kill me now.
So in designing my own rule builder, I sought to overcome the flaws I found in Apple’s builder, as well as add a few more constraints. The original design document I wrote up went something like this:
- The element should allow the user to use natural language to describe what they want.
- It should absolutely minimize the number of clicks needed to complete the action
- It should be built in Javascript/CSS/HTML and require no images and a very minimal amount of markup.
- It should give the user the ability to see ALL of their options at once.
- The value of the control should be expressed as in a single value as a aggregate – in my case JSON.
- The state of the control should be easy to restore.
- The control should use all standard html form elements.
And you can see the result of all this work, below:
In the rule builder, the first drop down is replaced with a string label, and the user, when they click the drop down, can select from a hierarchical menu that shows them all of their options at once.
A couple of simple changes, but a lot better. In fact, I liked the control so much, I decided to open source it and a few other controls as a part of my Prototype-Widgets project.
You can see the source as well as an interactive demo over on github, here: http://jsinglet.github.com/Prototype-Widgets/
Well there you have it. Thanks for reading! Happy hacking!
I hope that helps some other Haskellers out there. Many thanks to #haskell for all the help while I was putting this together! 
