50 Interaction Patterns: Synchronization and Recovery

You now know:

• Commands need ids so retries do not create duplicate physical actions; pending commands need a timeout path such as 10 seconds.
• Polling every 30 seconds or 60 seconds creates stale-interface windows; push-based WebSocket or MQTT updates can reduce cross-interface lag to about 1-2 seconds.
• Support evidence should use the UI vocabulary, so “timeout,” “offline,” “confirmed,” and “changed while offline” mean the same thing in logs and screens.

Scenario: A smart garage door takes 8-12 seconds to fully open or close (physical mechanical operation). Network round-trip adds 200-500 ms latency. Users complained about unresponsive UI.

Without Optimistic UI (Original Implementation):

// BAD: User waits for server confirmation before UI updates
async function toggleDoor() {
    showSpinner();  // Show loading spinner
    const response = await fetch('/api/garage/toggle'); // 8-12 seconds total
    if (response.ok) {
        updateUI('open');  // Finally update UI
    } else {
        showError('Command failed');
    }
}

User Experience: Tap button → Spinner for 8-12 seconds → UI updates. Users tap multiple times thinking it didn’t work, sending duplicate commands.

With Optimistic UI (Improved Implementation):

// GOOD: Immediate UI feedback with reconciliation
async function toggleDoor() {
    const previousState = doorState;  // Save current state
    const targetState = (previousState === 'closed') ? 'opening' : 'closing';

    // Step 1: Immediate optimistic update (< 100ms)
    updateUI(targetState);  // Show "Opening..." immediately
    showProgressIndicator();  // Visual feedback: door animating

    try {
        // Step 2: Send command to device
        const response = await fetch('/api/garage/toggle', {
            method: 'POST',
            body: JSON.stringify({ target: targetState })
        });

        if (response.ok) {
            // Step 3: Poll for actual state confirmation
            const finalState = await pollDoorState(12000);  // 12s timeout
            updateUI(finalState);  // Confirm: "Open" or "Closed"
            clearProgressIndicator();
        } else {
            // Step 4: Rollback on failure
            updateUI(previousState);  // Revert to previous state
            showToast('Door command failed - check if door is obstructed');
        }
    } catch (error) {
        // Network error - revert optimistically updated state
        updateUI(previousState);
        showToast('Connection lost - door may not have moved');
    }
}

async function pollDoorState(timeout) {
    const startTime = Date.now();
    while (Date.now() - startTime < timeout) {
        const state = await fetch('/api/garage/state').then(r => r.json());
        if (state === 'open' || state === 'closed') {
            return state;  // Final state reached
        }
        await sleep(1000);  // Poll every 1 second
    }
    throw new Error('Timeout waiting for door state');
}

UI State Machine:

Time	Displayed State	Actual Door State	Visual Indicator
T+0 ms	“Opening…”	Still closed	Animated progress bar
T+100 ms	“Opening…”	Starting to open	Progress bar at 10%
T+4s	“Opening…”	Halfway open	Progress bar at 50%
T+8s	“Opening…”	Fully open	Progress bar at 90%
T+8.5s	“Open” ✓	Fully open	Green checkmark

Error Recovery Scenarios:

Error Condition	UI Response	User Communication
Network timeout	Revert to previous state + warning	“Connection lost - verify door state visually”
Door obstructed	Show “Opening…” then “Error”	“Door stopped - check for obstruction”
Duplicate command	Ignore if state matches	No change (already opening)
Door sensor failure	Show last known state + ”?”	“Cannot verify door state - sensor offline”

Measured Results:

Metric	Without Optimistic UI	With Optimistic UI	Improvement
Time to visual feedback	8-12 seconds	< 100 ms	99% faster
Duplicate command rate	43% of users	2% of users	95% reduction
User satisfaction (SUS)	52 (poor)	78 (good)	+50%
Support calls about “broken button”	28/month	1/month	96% reduction
Average taps per action	2.7	1.02	62% reduction in duplicate commands

Perceived Responsiveness Calculation:

$$\text{Perceived delay}_{\text{before}} = 12,000 \text{ ms} \quad \text{(blocking UI)}$$ $$\text{Perceived delay}_{\text{after}} = 50 \text{ ms} \quad \text{(optimistic update)}$$ $$\text{Improvement} = \frac{12,000}{50} = \mathbf{240\times \text{ faster}}$$

Key Lesson: For any IoT action with > 500 ms latency, optimistic UI is not optional—it’s required for acceptable UX. The actual door operation time (8-12 seconds) didn’t change, but perceived responsiveness improved 240× by acknowledging the tap in 50 ms instead of making users wait 12 seconds for confirmation. Always provide immediate visual feedback, then reconcile with actual state asynchronously.

You now know:

• For slow mechanical actions, show the transition state immediately, then confirm the final state after the device reports it.
• A failed command should revert or mark uncertainty, not leave the optimistic state looking final.
• Duplicate commands, obstruction, sensor failure, and network timeout need different messages because each asks for a different next action.

You now know:

• Pending and confirmed states must look and read differently, especially for locks, alarms, pumps, heaters, and access control.
• Accessibility is part of the state machine: do not rely on color alone, use text labels, and announce important status changes.
• A muted notification, dismissed notification, acknowledged incident, and resolved event are separate states, so store and display them separately.

Interaction patterns are the secret rules that make smart devices feel smooth and responsive!

50.8.1 Impatient Button Press

the microcontroller built a smart light switch for the living room. You pressed the button in the app, and… nothing happened for 3 seconds. Then the light turned on.

“Is it broken?” asked Temperature Terry, pressing the button again. Now the light turned on, then off, then on again! “I pressed it three times because I thought it wasn’t working!” groaned Sammy.

the LED had an idea. “What if the button IMMEDIATELY shows the light is on — even before the message reaches the actual light? That way, Sammy sees instant feedback!”

They called this trick Optimistic UI — the app shows “light is ON” right away and trusts that the message will get through. If something goes wrong, it changes back and says “Oops, the light didn’t respond. Try again?”

Next problem: Dad changed the thermostat using the wall dial, but Mom’s phone app still showed the old temperature! “Why does my app say 70 when Dad just set it to 72?” asked Mom.

“We need STATE SYNC!” explained the battery. “When ANYONE changes something — the wall dial, Mom’s phone, Dad’s phone, or even a voice command — ALL of them should update at the same time. Like a group text message for devices!”

Finally, the security camera was sending 50 notifications a day: “Motion detected!” for every squirrel, leaf, and passing car. Everyone turned off notifications… and missed a real delivery!

“We need NOTIFICATION ESCALATION!” said Sammy. “Squirrels get a silent note in the log. Delivery trucks get a quiet badge on the app. But a person at the door at midnight? THAT gets a LOUD alert!”

50.8.2 Key Words for Kids

Word	What It Means
Optimistic UI	Showing the result instantly (before it actually happens) so the app feels super fast
State Sync	Making sure ALL devices show the same information at the same time
Alert Fatigue	When you get SO many notifications that you ignore ALL of them, even important ones
Notification Escalation	Using quiet alerts for small things and loud alerts for important things

Related topics for deeper exploration:

MQTT Protocol: The pub/sub messaging pattern used in the state synchronization example is implemented via MQTT in production IoT systems. WebSocket Communication: Real-time bidirectional communication for push-based state updates mentioned in the Ecobee case study. Event-Driven Architecture: Notification escalation and geofence triggers are examples of event-driven IoT design. Accessibility Standards: WCAG 2.1 requirements for aria-live regions and screen reader compatibility in optimistic UI. Network Quality of Service: Understanding network latency variability helps design appropriate timeout and retry logic.