Conditional rules are a high barrier for non-programmers
Aliases: TAP · conditional rules · if-this-then-that
What it is
The de facto standard for expressing multi-device orchestration is the condition-action rule: when some condition holds, take some action. The paradigm is trigger-action programming (TAP) — "turn on the porch light at sunset", "cut all sockets when everyone leaves". Natural to engineers, it is a genuine programming barrier for ordinary users: many people want automations yet fail to write — or write incorrectly — the rules they themselves want.
The barrier is not "can't work the interface" but the constructs of a formal language. A rule must be unambiguously executable, which demands expressive abilities that everyday speech never trains.
Why it happens
Three layers.
The syntactic layer. A correct condition must distinguish events (one-shot: the door was opened) from states (ongoing: the door is open), and needs boolean composition (AND/OR/NOT) and quantifiers (any/all). These are formal-language constructs with no everyday training equivalent. The same trigger word can mean an event on platform A and a state on platform B, so users never build stable expectations.
The semantic precision layer. The rule engine demands that fuzzy life descriptions be compressed into exact parameters, while intentions are inherently fuzzy. "When I get home in the evening" — what counts as evening, sunset or clock time? What certifies "home", entering a geofence or the door contact opening? Every "obviously" hides a decision the user never noticed making.
The vocabulary layer. Before assembling a rule, users must learn the platform's concept inventory: which devices, which properties, which comparators, where triggers end and actions begin. That noun space is itself a terminology to study.
Studying it
- Ur et al.'s "Trigger-Action Programming in the Wild" (CHI 2014) examined TAP ability in an internet sample: many users express automation wants, but success from want to correct rule is poorly distributed, and misunderstanding of rule semantics is common.
- Huang and Cakmak's 2015 experiment series tested how the form of expression affects non-programmers: packaging triggers and actions as semantic predefined descriptions (rather than bare comparison expressions) significantly improved rule-construction accuracy.
- Standard methods: give participants an automation want described in natural language and have them assemble the rule on a real platform or with paper components, scored for correctness. The reverse task — present a rule and ask for a paraphrase — is the more diagnostic one: paraphrase error rates expose comprehension failures better than assembly tasks.
One methodological caution: lab assembly accuracy overestimates real-world performance. Participants know they are being tested and can ask an experimenter; at home, users face a voluntary "should I create this rule" decision, where the barrier intercepts people at "didn't think it possible" or "afraid of getting it wrong" — the task never even starts.
Where it stops holding
- The barrier is a formal-language problem, not an ability problem. Users with programming experience are unaffected. Reading it as "users are not smart enough" produces the wrong remedy (more tutorials); the right one is a different form of expression.
- Simple rules clear the bar. Single-trigger, single-action rules with clear semantics most users build correctly; the barrier climbs steeply with compositional complexity. Evaluate it stratified by target complexity, not as a blanket "TAP is hard".
- Voice entry does not relieve the syntax barrier. Dictating a rule changes the input channel; boolean composition and parametric precision remain untouched.
Applying it
- Expose only a single-trigger, single-action structure in the default entry; fold boolean composition and multi-device actions into a secondary "advanced" layer so the first layer stays syntax-free.
- Replace bare comparators with semantic components: "after dark", not "luminance < 80 lux for 5 minutes"; keep parameters inside component defaults, expandable on demand.
- Make the event/state distinction an explicit choice ("the moment the door opens" / "while the door is open") rather than something users must infer from a trigger list.
- How to check: run a read-only paraphrase test with target users — show a rule, ask them to say in their own words when what happens. Constructs with high paraphrase error (boolean composition, time qualifiers, multi-action ordering) are the ones that need packaging.