A scene is an implicit mode
Aliases: implicit mode · mode confusion · scene as mode state
What it is
A scene gives a set of device states a name, but it does not give the home a mode state: the system knows "the sleep scene was executed", not "the home is currently in sleep mode". The difference between a mode and a scene is persistence — a scene is a one-shot act of setting; a mode is an interval of time during which something continues to hold. Users invoke scenes but understand them as modes ("we're in movie mode now"); that mismatch is the implicit-mode problem.
"Implicit" means the mode exists in the user's understanding but not in the system's model. No state variable records entry and exit, no query answers "what mode are we in", no mutual exclusion or arbitration between modes — none of the machinery a mode requires is present.
Why it happens
Three consequences fall straight out of the mode's absence on the system side.
State drift. After a scene runs, any manual change leaves the scene untouched: the nightlight opened by the sleep scene gets switched off by a family member — the "scene" is the same scene, the reality no longer is. Label and devices go their separate ways with nothing to reconcile them, because the mode was never represented.
Stacking has no semantics. What happens when "movie" and "guests" run in sequence? Per-device last-write-wins: the two target lists merge in execution order, overlapping devices take the later value, the rest keep their own. With no mode layer to arbitrate, the user expects "switch modes" while the system "merges lists".
Mode confusion. When users cannot tell "which mode we're in now", they lose predictive grip over every subsequent action — the classic mode error of human-computer interaction: one action, different consequences depending on mode, interpreted under the wrong mode. The older findings on mode errors transfer wholesale: the fault lies not in users' memory but in the system's failure to keep the current mode perceptibly present. Implicit modes import that problem into the home and scale it up — a household may have a dozen "modes", none of them indicated.
Studying it
Mode errors come with a mature tradition: Sellen, Kurtenbach and Buxton's 1990 work established the mechanism and the preventive power of sensory feedback — mode-error rates fall with the salience of mode presentation, not with user training. The paradigm transfers directly: manipulate the visibility of the active scene (no indication / queryable in app / continuously perceptible in the environment) and measure correctness of "what state are we in" judgements and mis-operation rates.
Longitudinal smart-home studies supply indirect evidence: users name scenes after life situations and speak of them as periods ("put it in granny mode at night") — their language has already modalised what the system implements as stateless, a standing mismatch.
Where it stops holding
- Not every scene needs modalising. Terminal one-shots like "leave home" are not expected to persist; statelessness is the right simplicity there. What needs mode semantics are scenes that last and change behaviour meanwhile (sleep, do-not-disturb, holiday) — the test is whether anyone would ever ask "are we still in it?".
- Modalising has costs. Giving scenes a mode state means answering mutual exclusion, nesting, and concurrency — complexity returns to the product. Forcing mode semantics on scenes that don't need it buys none of the benefit and pays all of the cost.
- Environmental cues partially compensate. Real-world clues (light level, blind position) usually let users infer the "mode"; compensation fails exactly where cues are hidden (at night, checking remotely) — which is also where mode confusion concentrates.
Applying it
- Introduce explicit mode semantics for duration-type scenes: on entry the system records "current mode" and shows it; re-running re-enters; provide an explicit "end mode" operation (see the same group's discussion of exit paths).
- On a second scene, ask for mode intent: "Sleep mode active. Switch to guests (nightlight will turn off) — switch or stack?" Never merge lists silently.
- Put the current mode into the environment, not only the app: do-not-disturb lights an indicator and changes how lights respond — the antidote to mode errors is continuously perceptible mode presentation, not a more detailed settings page.
- Make mode-versus-devices reconciliation visible: entering "away" with the door failing to lock shows the conflict on the mode surface itself.
- How to check: at random moments ask any household member "what state is the home in"; score agreement between members and against system records. Wherever the two disagree is where drift and confusion live.