Uninterruptible long tasks do not belong while driving

What it is

A long task that must be finished in one run, and that fails or restarts if put down, should not be available in motion. Uninterruptible names a structure that driving is not allowed to break: a modal lock, a countdown, a video that must be watched, a multi-step form that dies unsaved. It is not a slogan about clock time, and it is not a long glance. A task may span a minute or two if it can be dropped at any moment; a thirty-second forced sequence still does not belong in a moving cabin. Heuristics for total task time—including the often-cited band of about fifteen seconds—are filters for this kind of structure at design time, not a physical cap.

Why it happens

Driving reclaims the person at unpredictable moments: a lead-vehicle brake, a lane change, a junction. An uninterruptible task turns that moment into a loss—progress wiped, options expired, the system still believing a conversation is open. People then push through: they keep tapping when they should look, because the cost of dropping the task exceeds one more glance. A modal lock also blocks driving-relevant entries (cancel route, take a call) and lets the secondary task occupy the foreground. Long video, forced tutorials, and unskippable motion put a continuous entertainment or education timeline inside a control loop that must be breakable. The structural clash itself forces stretched occupation.

Studying it

Total task time from start to last relevant action can be measured, but the sharper test is whether the task still exists after an interruption. Insert a driving event that must take priority (brake, lane-change instruction) mid-flow, and watch whether people drop the task, push through, or the system kills it.

Independent variables: modal lock present or not, countdown present or not, whether interruption preserves, restarts, or fails the task, clock duration. Dependent variables: completion after interruption, glances and hands-off during push-through, restarts caused by timeout.

Lab “driving events” are scheduled, so people learn when to let go; on-road interruptions have no announcement. Squeezing total time under a guidance figure, while the structure stays uninterruptible, only shortens the push-through window. It does not remove push-through.

Where it stops holding

Short emergency flows (acknowledge a takeover, dismiss a false alert) must be finished on the spot; they are not deferrable long tasks, but they must be short and end in one look. Charger handling and parking payment happen while stopped and are out of scope. A passenger watching a full video on a secondary display does not occupy the driving loop, provided sound and picture do not spill into the driver’s seat. When automation is on, people may believe a video can be finished; a takeover makes interruptibility a hard constraint again.

Applying it

• Ban modal locks, unskippable motion, and timed questionnaires in motion. Every step must survive a driving event without penalty.
• Content that needs continuous attention (tutorials, titles, long forms) is offered after stopping by default, or marked “do this parked.”
• Use total-time heuristics as a design filter: if a flow looks as if it must be finished in one run, ask first whether it can be split or deferred, not whether the seconds can be shaved.
• Verify by dropping an emergency brake or a lane change into the middle of the flow. If the person must finish tapping before looking, or the system dumps what was already entered, the task should not be available while moving.

Related

• Within the group: K6.03.1 In-motion tasks must be completable across short glances · K6.03.3 Interrupted tasks must keep their place
• Adjacent: K6.02 Eyes-off-road Time · K6.06 Function Lockout While Driving · A5.08 Interruption cost and task resumption
• Search terms: uninterruptible task · total task time · modal lock