The actor wants the system to pick out cases by criteria of their own. Sometimes the criteria narrow what is shown right now: a smart playlist, a saved search, a segment of customers, an issue list filtered three ways. Sometimes they stand as a rule the system acts on while the actor is away: a mail rule that files messages, an automation that turns the heating down, an agent’s standing instruction about what not to touch. Rule composition is how the actor writes or changes the condition in either case. The condition is shown as one statement in plain language, built from parts the system offers, and the actor edits it in place.

Songs where genre is “country” and rating is at least 4 stars and last played is not in the last 2 weeks.

When an email arrives and it is not from someone in my contacts and it contains the phrase “Canadian Pharmacy”, label it “likely spam” and move it to the trash.

The first narrows a library the actor can see. The second does the same work over mail that has not arrived yet, with an action attached. The composing surface is the same in both; what differs is the set of parts on offer and what the actor has to do to check the result.

Selecting and acting

The test that separates the two kinds is whether the actor can see the matched set right now.

• A selecting rule narrows a collection that is in front of the actor. The result updates as parts are changed, so a wrong condition shows itself at once and costs nothing to fix. The rule may be saved and re-run, and because the collection changes, the result changes with it. Query builders, segment builders, smart folders and saved searches are all this kind.
• An acting rule attaches an action to the condition and runs it on cases that have not arrived. The actor is not there when it fires, the mistake happens to real things, and the rule runs alongside the other rules already in place. Mail rules, home automations, trigger–action recipes and an agent’s standing limits are this kind.

Many surfaces carry both halves. A mail filter is a search with “do this” attached, and the search link in the filter dialog is the selecting half used to check the acting half. Compose the condition the same way in both kinds, and treat the action clause as the thing that turns a selection into a rule. What changes between them is the checking, which is a move of its own: dry run.

Forces

• Reading vs. structure — a condition needs and, or and not, but a sentence reads in one line. Flat lists of conditions read fine. Nested groups do not, and grouping is where people make mistakes.
• Everyday words vs. logic — the sentence form borrows “and”, “or” and “not” from English, where they do not mean what the logic needs. “The blue ones and the green ones” is a union to most people, and how far a “not” reaches depends on what follows it. The words that make the statement readable are the words people misread.
• Exactness vs. the actor’s words — the condition has to use fields the system has, and the actor’s reason for wanting it usually does not map onto them.
• One rule vs. the list — an acting rule is written on its own but runs alongside the others. People hold specific wrong beliefs about how rules combine: that two rules with opposite actions cancel out, that rules run in the order listed, that a condition on one rule limits the others. A selecting rule has no list to run against.

Solution

Show the whole condition as one plain statement and let the actor edit it in place: each field, operator and value is a part that can be changed, and parts can be added and removed from the sentence. When the rule acts, keep the action in the same sentence as the condition. Splitting them hides what the rule does.

A flat run of restrictions on one thing can join with “and”, as the examples above do, and people read that as intended. The moment a group holds alternatives, or mixes the two, stop letting the bare word carry the logic. Name how the parts combine once, at the head of the group: “all of the following” or “any of the following”. Attach “not” to the single part it negates, as an operator on that part (“is not”, “does not contain”), never as a word in front of a group. The one place a join word is safe inside a line is a list of values under an operator that names the quantifier: “status is any of Done or Cancelled”, “label includes all of Audit and Design”. People read a list of values as a list, and the operator carries the logic.

When a condition needs grouping that one line cannot hold, break the sentence into lines, one per group, indented, with the head word of each group on its own line. A tree of conditions or a row of chips can show the same thing, but reads worse for the common flat case, and most cases are flat.

Events and states

Acting rules bring a distinction selecting rules never need:

• Trigger — something that happens at a moment. “When a file is added to the folder.”
• Condition — something that is true for a while. “While the project is archived.”
• Action — what the system does when the trigger fires and the conditions hold.

People confuse events with states, and the interface causes much of it: “if this, then that” uses the same wording for a moment and for a period. A sentence can keep the two apart with different words: “when” for the event, “while” or “and it is” for the state, then the action. Giving the two kinds of clause different words is an interface fix for what looks like a comprehension problem.

Research on this pattern

• Grouping is where composition fails, not operators: on the same tasks a graphical query builder produced two ordering errors against fifty parenthesis errors in SQL. This is a selecting-rule study, and it is the basis for the flat sentence in both kinds.
• The same “and” reads as a conjunction or a union depending on the sentence around it: 85% of people read “blue and circle” as both, but only 36% read “blue and the objects that match circle” that way, and 55% read it as either. This is the source of the common error of writing “and” where “or” is meant, and the basis for heading a group with “all of” or “any of” rather than joining parts with the bare word.
• How far “not” reaches depends on the operator next to it, and brackets do not fix it: 64% bound “not” tighter than “and”, 67% bound it looser than “or”, and people ignored the brackets that would have overridden them more often than they followed them. The basis for attaching negation to one part.
• A table that avoids the words “and” and “or” beat textual Boolean queries for writing, and tied for reading: one row per alternative, one slot per term, every slot on a row required. The sentence form has not been tested against it.
• Most acting rules people want are one trigger and one action, and shared rules are copied freely — the basis for starting from a draft rather than an empty statement.
• People confuse events with states, and the wording of “if this, then that” causes it; seven years later the confusion appeared in 21 of 50 unaided debugging sessions, and every one of them failed.
• A bug makes an acting rule harder to predict: shown rules with one of ten kinds of bug, people got worse at predicting the rule’s behaviour for most kinds.
• People hold wrong beliefs about how acting rules combine — opposite actions cancelling, rules running in listed order. The repairs that were tested belong to dry run.
• Untested: whether the sentence form with “all of” and “any of” group heads beats a match table, a chip row or a tree on the common flat case, and whether people make the same composition errors on selecting and acting rules.

Resources & references

• UI-Patterns — Rule builder — the selecting kind, with any/all switches, per-rule mini-forms and add/remove placement; binding a rule to an action is listed there as a variation
• Pane & Myers (2000) Tabular and textual methods for selecting objects from a group — “and” read as a union when the sentence lists groups, “not” with no stable reach, and match forms beating text for writing queries
• Young & Shneiderman (1993) A graphical filter/flow representation of Boolean queries — grouping, not operators, is where composition fails
• Ur, McManus, Pak Yong Ho & Littman (2014) Practical trigger-action programming in the smart home — 78% of desired behaviours are one trigger and one action
• Ur et al. (2016) Trigger-action programming in the wild — 224,590 shared rules, and how freely they are copied
• Huang & Cakmak (2015) Supporting mental model accuracy in trigger-action programming — events against states, as an interface problem
• Brackenbury et al. (2019) How users interpret bugs in trigger-action programming — ten bug classes; a bug makes the rule harder to predict
• Zhang, Zhou, Littman, Ur & Lu (2022) Helping users debug trigger-action programs — the wrong beliefs about how rules combine