Are you designing a rule builder? It seems like I’m asked to design one or two of these every year. I’m often called into my client’s offices to look at a product with a rule builder much like this one:

Ugh. Good luck making any sense of that. I take screens like this one and redesign them so that they are clearer and easier to use. Maybe you’re thinking rule builders should only be used in hard core applications by the most die hard users. I certainly work on lots of hard core applications but you can find rule builders in Wufoo, MS Exchange, Apple Mail, Apple Finder, iPhoto, and iTunes, so I think it’s actually a fairly mainstream design.

I actually think Apple nailed the rule builder in iTunes (and Mail and iPhoto) – you can see an example below.

This is an example of a fairly complex rule: it looks for any item that hasn’t been played in the last week and either has a bit rate greater than 150kbps or was added after January 1, 2009 and is Music (as opposed to podcasts and video, which are also in iTunes). This design makes the rule “human readable” because it follows the general form of a sentence.  I think the foundation of all good rule builders is to use a natural language structure.

Criteria, Operation, and Value

So let’s dissect Apple’s rule builder. We’ll start with the very simple rule builder that they supply in Mail, which is quite similar to the work in iTunes. Here is how it looks when you say “New Rule”

Notice that Mail’s Rule has two sections: the rule and the action. We’ll focus on the rule for now. In this example the rule is unfinished, but it reads: “Any Recipient contains” Each rule is composed of up to three parts:

• The criteria (in this case Any Recipient)
• The operation (in this case Contains)
• The value (blank, for now)

Criteria

There are a lot of possible criteria for Mail messages.

Obviously for different types of objects you would have different types of criteria. You might see something very different for songs, files,  or photos. For example, here are the criteria in iTunes:

Operation and Value

The next item we see is the operation. The list of operations is different for different types of criteria. For example, here are the operations for a text item in the Mail rule builder:

Notice how this design handles the “NOT” logic – by including an operation that is “does not contain”. Also notice that this list doesn’t contain every possible operation for text. You don’t see “doesn’t begin with” for example – the designers concentrate on the very likely needs of the users, not on building something that can handle every possible bit of logic the user can dream up. In more complex applications you may find that you users require more flexibility with the operations – it’s useful to try and gather data about the kinds of rules your users would like to build. In general, I choose to start by designing light, then when users ask for more, build it.

Let’s look at the list of operations for Date Sent in Mail:

Remember that we’re building a rule for processing incoming Mail here, so that operations really focus on the common use cases around processing mail as it arrives. There’s not a good use case for processing an incoming mail message who’s Date Sent is a year old. On the other hand, if you look at some of the operations for Date Added in iTunes, you’ll see many more choices:

Again, note the use of “is not” and “not in the range” to handle the logical NOT. Also notice that they use “is in the range” to allow the user to pick a date range, as shown below.

The value for these choices is a date – the user can either type in the date or use a date picker to choose a date.

Users can also pick relative dates. First, they choose the operation “in the last” and then they can choose a time period such as “last 30 days” or “last 2 months”, as shown below:

Now let’s look at operations for numeric values:

In this example, the user simply types in a numeric value. It’s helpful to show units – and in some cases you may allow the user to change the units, as in the example using days, weeks, or months, above.

Here are operations for true/false (boolean) values:

There’s no need to show a value in this example, the operation contains all of the necessary information. In fact, you can find plenty of examples in Apple’s Mail rule builder where they don’t show the operation or the values, but rather include them both in the criteria. For example:

In the example above, the criteria “Message is junk mail” is all that’s needed. No operation or value is shown.

Here are operations for multiple choice criteria:

The user would choose an operation from a dropdown list and then also choose a value from a dropdown list.

If the number of possible values is very large then rather than using a dropdown list, you might want to use autocomplete along with a separate chooser, so that the user can find the values (neither iTunes nor Mail actually does this, so I’ve mocked it up in Balsamiq):

The user should be able to either type in a value and find matches (autocomplete) or click on the search icon to open a chooser window. The chooser window should have a scrolling list of all the values, with a search field so that the user can find the item he’s looking for.

What about other types of data? You may have unusual data types in your application. For example, here are the iTunes operations for ratings:

You’ll need to look at each criteria in your list, establish the type of data (text, date, number, etc.) and then develop a list of the operations and values that you expect your users to need. As we saw with Mail, you don’t need to include every possible option: just the ones that make sense for this data and the user’s tasks.

One thing I would suggest is that you give some thought to meta-rules for your criteria. For example, in music it’s useful to have a rule for “does not have a rating”, or in iPhoto “does not have a keyword” or “does not have a location”. The example below shows the iPhoto Smart Folder builder, which does not allow you to build a rule for “photos with no keyword”. That’s a shame, too.

When you’ve got a criteria, it can be very helpful to look for items that simply aren’t using the criteria – or items that are using it (examples: show me all photos that do not have any keywords, show me all photos that do have keywords, show me all photos with just one keyword).

Adding more Rules

Let’s move beyond the condition, operation, and value line and talk about how to add and manage additional lines (rules) in your rule builder. When you start building a rule in iTunes, the rule builder assumes that you’ll just have one rule, but provides controls for making more (the little “+” button, on the right, below).

Once you click the “+” button, a few things change, as you can see below:

Notice, first of all, that there is a phrase above that says “Match all of the following rules”. This is where the user can pick “all” (aka AND) or “any” (aka OR) to tie all of the rules together. This phrase is only necessary if there’s more than one rule, so it only appears when the user adds a second rule.

Next, notice that controls for removing rules have appeared, in addition to the controls for adding new rules. The user can press “-” to remove a rule.

Nesting Rules

Nested rules are an extra level of powerful. They’re not always necessary, but if you’re going to support nested rules you should do it right. Let’s go back to our original example, which includes nesting.

In iTunes 8, Apple introduced nested rules to the iTunes smart playlist builder. Users could add a nested rule clause by clicking the ellipses icon “…” (found next to the “+” icon for adding a row).  In iTunes 9, Apple removed the ellipses icon from the rule builder and decided to hide the nested rule feature. To add a nested rule iTunes 10 the user must hold down the Option key. When he does the “+” icon changes to an ellipses icon.

This is probably easier to show than talk about, so you can watch this movie of a nested rule being created: iTunes nested rule builder video. Let’s look at the elements of this video:

• 1 – this establishes the AND/OR logical operation for the items at the top level of nesting. All the items at the top level must be true, and the nested clause must also be true.
• 2 – this establishes the AND/OR logical operation for the nested clause – any one of the items in this clause can be true to make the entire clause true.
• 3 – Each rule has a “-” icon for removing that rule and a “+” icon for adding a new rule.
• 4 – In iTunes 9 and later, the user must hold down the OPTION key to see the ellipses to add a nested clause.
• 5 – Clicking the “-” icon here will remove nesting, but not the items within the nesting – in other words, the Genre items would be removed from the nest and promoted to the top level. Clicking the “+” icon here adds another item to the nested clause.
• 6 – Clicking the “-” will remove this particular rule from the nested clause.

Why did Apple decide to hide nested rules? My guess is that some users were confused about what nested rules meant, and were clicking on the ellipses icon and not understanding what they were doing. Apple kept the feature, but hide it from public view – a common way for them to treat “advanced” features. I don’t necessarily recommend this for your application – it will depend on your users. If you have users who, for the most part, don’t need nested rules then you may want to follow Apple’s lead. However, if you have users who are comfortable with the notion of rule nesting, then I think it’s better to make the control more obvious.

You can keep nesting rules and with each nesting, the rules indent a bit. Here you can see a more extreme example:

When the list gets very long, it scrolls – I think that’s fine, but the Rule builder should also be a resizable window, so that I can see more rules at a time and when the nesting gets very deep I can widen the screen to see more of the controls.

Do you need nested rules? Most rule builders do NOT need nesting. Don’t put it in unless you really need it. It adds complexity and it can be hard to understand. Apple’s Mail doesn’t use nesting at all. I wrote about it here because I work on a lot of projects that do need nesting, and because I so rarely see it done well, not because I think every app in the world should use it.

Good defaults

Even a very well designed rule builder can be quite clicky – there are a lot of dropdown menus to go through. Apple’s Mail rule builder handles this by bringing in defaults based on the currently selected mail message. The rue, by default, starts with “Any Recipient” and uses the recipient of the currently selected mail message. If the user clicks the “+” button Mail automatically chooses the “From” criteria and fills in the value from the currently selected mail message. All of this can save a lot of typing and choosing.

Another example of good defaults is when the user is working in a nested clause. Let’s imagine that the user has started to create this clause:

Now the user clicks “+” to add a new row. He’s already specified that Genre should not be Holiday and that this is an “Any”/”OR” clause. It’s a good bet that the next rule in the clause will also be “Genre” – at least that’s a good default to start from. Find ways to save your users clicks and they will thank you.

Other Rule Builders

The folks at Wufoo have a form builder – you can get a free account and try it out. It’s very similar to the Apple rule builder but has a few drawbacks. I don’t like the use of two separate +/- buttons (one to add groups of rules and one to add a rule). I’m also not wild about the presentation of the logic elements (big block AND and OR buttons). However, they’ve done a good job of using natural language and of presenting the rule.

The folks who created the Smart GWT toolkit created a rule builder, which you can test drive. On the one hand, it’s nice to see a widget like this come into a toolkit – on the other hand, this particular design is going to be very challenging for all but the most hard core users. It requires users to be able to read logic and features a lot of unintuitive controls. It doesn’t use a natural language structure, either. Here’s a sample:

Cherry on top

Let me close with what is, I think, one of the snappiest rule builders out there: it’s the one offered in the Apple OSX Lion file system. It lets you build nested rules, and you can pick from hundreds of different criteria. The results update live, while you build the rule and you can save the rule as a “smart folder” to use again and again. You can see it in action in this video: OSX Lion file system rule builder.

Or examine the screen shot below:

How can you choose from hundreds of criteria? The criteria chooser shows the most common criteria with an Other item to see all criteria.

From here you can choose a criteria and, if you wish, add it to the list of common criteria (by clicking the checkbox in the “In Menu” column):

Works like a charm every time. I think if you use the Apple designs for Rule Builders as your base design, you’ll be in great shape. From there, find ways to make it really sing for your users and their tasks and needs.