Logo. Two Rivers Consulting is Hagan Rivers and David Rivers, user interface design consultants located near Boston Massachusetts specializing in web application and enterprise application designtwo rivers flowing

follow us on

TwitterLinkedInDelicious
    writeto [at] tworivers.com or (978) 352-2585

UI design for Rule builder

Written by Hagan on May 8, 2012

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:

An example of a rule builder

An example of an icky rule builder

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.

Apple's iTunes rule builder user interface

Apple's iTunes rule builder user interface

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”

Apple Mail rule builder, initial state (rule builder user interface design)

Apple Mail rule builder, initial state

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.

Apple Mail rule builder, criteria selector (rule builder user interface design)

Apple Mail rule builder, criteria selector

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:

iTunes rule builder criteria (user interface design, rule builder design)

iTunes rule builder criteria

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:

Apple Mail rule builder operand for text (rule builder user interface design)

Apple Mail rule builder operand for text

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:

Apple Mail rule builder operations for date (rule builder user interface design)

Apple Mail rule builder operations for date

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:

Date operations in Apple iTunes Smart Playlist rule builder (rule builder user interface design)

Date operations in Apple iTunes Smart Playlist rule builder

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.

Date range rule builder (user interface design, rule builder design)

Date range rule builder

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:

Rule builder for relative dates

Rule builder for relative dates (user interface design for rule builders)

Now let’s look at operations for numeric values:

Rule builder operations for numeric values (user interface design for rule builders)

Rule builder 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:

Rule builder operations for true/false values  (user interface design for rule builders)

Rule builder operations for true/false 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:

Rule builder operation that incorporates value

Rule builder criteria that incorporates operation and value (user interface design for rule builders)

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:

Rule builder for multiple choice  (user interface design for rule builders)

Rule builder for multiple choice

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

Rule builder multiple choice values (user interface design for rule builders)

Rule builder multiple choice values

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):

Rule builder for multiple choice values when there are a lot of values (user interface design rule builders)

Rule builder for multiple choice values when there are a lot of values

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.

A chooser for picking a value for the rule builder (user interface design for rule builders)

A chooser for picking a value for the rule builder

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

Rule builder for rating  (user interface design for rule builders)

Rule builder for rating

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.

iPhoto doesn't let you build a rule for "there is no keyword" (user interface design, rule builder design)

iPhoto doesn't let you build a rule for "there is no keyword"

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).

iTunes rule builder (user interface design rule builders)

iTunes rule builder

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

iTunes rule builder (user interface design rule builders)

iTunes rule builder

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.

Apple's iTunes rule builder user interface

Apple's iTunes rule builder user interface

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:

Nested rule builder user interface elements

Nested rule builder user interface elements

  • 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:

iTunes nested rules, nesting several levels deep (user interface design, rule builder design)

iTunes nested rules, nesting several levels deep

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.

Use good defaults in your rule builder (user interface design, rule builder design)

Use good defaults in your rule builder

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:

Rule builder design clause defaults

Rule builder design clause defaults

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.

Wufoo rule builder (user interface design, rule builder design)

Wufoo rule builder

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:

Smart GWT Rule builder (user interface design, rule builder design)

Smart GWT Rule builder

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:

OSX file system rule builder

OSX file system rule builder

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

Rule builder with hundreds of possible criteria

Rule builder with hundreds of possible 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):

Choose criteria from a list

Choose criteria from a list

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.

 


Category: Musings Comments Off