The way out of a scene must be explicit
Aliases: scene exit · scene rollback · undo scene
What it is
Entering a scene is one tap; leaving it is not. "Movie mode" — press, you're in. Afterwards? Do the lights come back, to what level, do the blinds open? Most products design nothing for exit: scene semantics contain "set to" and nothing to "restore to". Users either hand-adjust every device back (uncompressing the compressed), or build a second "exit-movie" scene (two configurations to keep mutually inverse by hand), or simply not exit, leaving the room at the wrong brightness overnight.
The problem is often misread as "missing an exit button"; what's missing is exit semantics: is exiting a return to the pre-entry state (restore), a move to another designated state (a dual scene), or the ending of a mode (see the same group's discussion of implicit modes)? Three semantics, three implementations — conflating them breeds worse confusion than having none.
Why it happens
The root is that set-state semantics keep no memory. Executing "set to" records nothing about prior device states — with no baseline snapshot there is nothing to restore. "Restore to" mechanically demands three extra things: snapshot on entry, write-back on exit, and handling of stale snapshots (devices changed by physical switches in the meantime). Mainstream scene implementations do none of them, so "exit" has no corresponding operation in the system — only another "set to".
The dual-scene workaround (build an "exit-movie" scene) converts a restoration problem into a configuration burden: the inverse relation is now maintained by the user; edit the entrance and forget the exit, and the two configs drift — state consistency has been moved from system duty to human memory, and is bound to drift.
Cognitively there is an asymmetry: the benefit of entering is immediate (the room arranges itself in a second), the cost of exiting is deferred (it lands after the credits). Users build scenes full of the delight of entry and never think about the way out — which is why the exit gap is never caught before use, and only shows up as a durable small friction in long-term living.
Where it stops holding
- Not every scene needs an explicit exit. Terminal scenes ("away" whose next stop is "home") are naturally followed by the next scene; adding an exit button is clutter. What needs a designed exit path are transient occupancy scenes (movie, guests, gaming) — ones that should hand the environment back, not define it.
- Snapshot restore is reliable only where no one intervened. If family opened the kitchen light during the two-hour film, writing the snapshot back on exit wipes that too — restore semantics must be designed together with "what happens to manual changes during the scene", or exit itself produces unexpected changes.
- For mode-like scenes, exit is mode-ending, not device-restoring. When "do not disturb" ends, where devices sit matters less than when the mode behaviours (mute, no notifications) stop — getting this exit wrong costs far more than a brightness level.
Applying it
- Force every scene, at creation, to answer for its exit: a dual scene (build "movie" and "intermission" together), an automatic expiry (timed scene, e.g. "guests, 3 hours"), or no exit needed (terminal). Three options; no silent default.
- Generate and edit dual scenes as a pair: editing the entrance shows the exit alongside, so the inverse relation is maintained inside the interface rather than in the user's head.
- Offer timed exit for transient scenes: a natural prompt before the end ("movie has run 3 hours — restore the living room?"), leaving the timing of exit to user confirmation rather than automatic action.
- For restoring exits, show the snapshot diff before executing: "Exiting will restore the living-room light from 10% to 85% and open the blinds — proceed / restore lights only / cancel." Make visible what restoration will change, before it changes it.
- How to check: observe the thirty minutes after a scene ends in real homes and count manual device adjustments. Every manual adjustment is a direct reading of the exit gap; the fewer there are, the more the exit design holds.