49 Interaction Patterns: State and Feedback

49.1 Start With the Decision

A phone can show success before the device has changed. The design must separate a request from a confirmed state.

49.2 Route Overview

This is part 1 of 2. Continue with Interaction Patterns: Synchronization and Recovery.

49.3 Part Objectives

• Model pending, confirmed, failed, and stale states.
• Choose feedback that exposes delay and system authority.

49.4 Start Simple

49.5 Learning Objectives

By the end of this chapter, you will be able to:

• Implement Optimistic UI Updates: Provide immediate feedback while commands travel to devices
• Design Distributed State Synchronization: Keep multiple interfaces synchronized with a single source of truth
• Apply Notification Escalation: Create intelligent alert systems that avoid fatigue while ensuring critical events get attention
• Match Feedback to Action Importance: Design appropriate response timing and modality for different action types

49.6 Make Delay Visible

IoT interaction patterns exist because a user action often crosses an app, cloud service, gateway, radio link, device firmware, sensor, and actuator before the result is known. The interface must respond immediately while staying honest about the final device state.

The core pattern is not “pretend it worked.” It is “acknowledge the intent now, show the pending state clearly, then reconcile with the authoritative device state.”

Before deciding how via Cloud shapes make delay visible, inspect Figure 49.1 beside IoT. Together, via Cloud and IoT frame the make delay visible claim: interaction patterns coordinate feedback across local controls, mobile apps, cloud services, notifications, and support views instead of treating each screen as an isolated interface.

Read via Cloud alongside IoT in Figure 49.1; their named relationship makes interaction patterns coordinate feedback across local controls, mobile apps, cloud services, notifications, and support views instead of treating each screen as an isolated interface concrete. For make delay visible, via Cloud supplies visible evidence; IoT constrains the decision. In Figure 49.1, retain via Cloud beside IoT so make delay visible remains explicit.

Consider a thermostat, smart lock, garage door opener, or security camera. The person does not care whether a delay came from Wi-Fi roaming, a sleeping radio, a gateway queue, a cloud rule, or a firmware retry. They care whether their intent was received, whether the physical world is changing, whether they can safely act again, and what to do if the result does not match the request. Good interaction design turns those questions into visible states.

An optimistic update is one part of that contract. It lets the interface acknowledge a command quickly, usually within a perceptual instant, while marking the result as pending rather than final. A thermostat can show the requested temperature immediately but add “sending” until the device reports the applied setpoint. A lock can show “locking” and suppress duplicate toggles while still exposing that the bolt is moving. A garage door can show “opening” for the mechanical travel time instead of leaving the button unchanged.

The companion pattern is reconciliation. When the authoritative state arrives, the interface either confirms the optimistic state, corrects it, or explains why it was rejected. That explanation should be practical: device offline, permission denied, low battery, blocked sensor, local override, safety interlock, or command timed out. Without reconciliation, optimistic UI becomes misleading decoration. With reconciliation, the user sees both responsiveness and truth.

Synchronization and notification patterns extend the same idea across touchpoints. If a physical panel changes a setpoint, the app, dashboard, voice assistant, and support console need a consistent story. If a camera detects motion all day, notification design must separate routine events from unusual events so people do not silence every alert. Interaction patterns are therefore product rules for state, timing, escalation, and recovery, not only visual components.

49.7 Design State Pairs

For each interaction, design both the optimistic interface state and the authoritative state that can confirm, correct, or reject it.

• Optimistic command: show the user’s intent quickly, such as “locking…” or a temporary selected state, so repeated taps do not create duplicate commands.
• Authoritative update: replace the pending state only when the device, gateway, or service reports the outcome.
• Conflict case: explain when another interface, physical control, permission rule, or safety condition changed the result.
• Escalation path: move from silent status to badge, push, sound, alarm, or support handoff based on risk and user response.

Start with a command-state table before drawing the screen. Useful columns include trigger, affected device, optimistic copy, disabled or allowed follow-up actions, command id, authoritative event, timeout threshold, rollback state, user-facing explanation, accessibility feedback, and support evidence. This table keeps the team from hiding distributed-system uncertainty behind a single spinner.

For a temperature stepper, the optimistic state might be “72 degrees requested” while duplicate taps are merged for a short debounce window. The authoritative event might be a reported setpoint from the device shadow, MQTT topic, or WebSocket stream. If confirmation does not arrive before the timeout, the UI should show the last known actual value, the requested value, and the next action: retry, queue for later, check connectivity, or use local controls.

Design each pattern across at least two touchpoints. A smart lock test should include the mobile app, the lock reader or keypad, and the support view if support handles failed commands. A camera notification test should include phone settings, in-app notification preferences, event history, quiet hours, activity zones, and the escalation rule for night or unknown-person events. A facilities dashboard test should include a live value, stale timestamp, source device, threshold rule, acknowledgement owner, and exportable incident record.

Accessibility belongs in the state table. Pending, confirmed, rejected, stale, and escalated states need non-color indicators, readable text, focus behavior, screen-reader announcements where appropriate, and input paths that do not depend on precise tapping during a moving status change. A disabled control should explain why it is disabled or expose a nearby status detail. A high-priority alert should not rely on sound alone; it should leave a persistent, reviewable state.

Acceptance criteria should test both speed and honesty. The interface should acknowledge intent quickly, suppress accidental duplicate commands, update when another touchpoint changes the device, recover from offline or permission failure, and maintain the same vocabulary in logs and support tooling. If the pattern only works on a perfect network with one user and one interface, it is not ready for an IoT product.

49.8 Synchronization as UX Problem

One command now has user-visible states. Next: many interfaces changing the same device at nearly the same time.

State synchronization failures look like interface bugs even when the backend is working. A dashboard, app, physical switch, voice assistant, and support console can all show different truths if freshness, source, ordering, and conflict policy are not visible.

Good UX therefore exposes enough distributed-system behavior for the user to act safely: pending, stale, unreachable, overridden, denied, confirmed, and reverted are different states and need different feedback.

The implementation needs explicit hooks for those states. Command APIs should return a command id or idempotency key so retries do not create extra physical actions. Event streams should include device id, sequence number or timestamp, source, desired state, reported state, and error reason. A device-shadow model such as desired versus reported state is useful because it separates what the user requested from what the device has actually applied.

MQTT and WebSocket updates are common ways to push authoritative changes back to interfaces. MQTT retained messages can help a newly opened dashboard learn the latest reported state, while WebSocket streams can keep browser or mobile sessions synchronized. Both still need freshness policy: a retained value from yesterday should not look the same as a value received five seconds ago. The UI should render timestamp, connectivity, and source confidence when the distinction changes the user’s next action.

Ordering is another product concern. A physical button, mobile app, automation rule, and voice assistant can all send commands close together. Last-write-wins may be acceptable for a lamp, but it can be dangerous for heaters, locks, pumps, or access control. The backend may need conflict rules such as role priority, safety interlock, monotonic sequence checks, lockout windows, or explicit acknowledgement. The interface should expose the result in plain language instead of leaking internal phrases like race condition or stale write.

Notification escalation also depends on implementation detail. APNs and FCM can deliver push messages, but the product still needs event classification, duplicate suppression, quiet-hours policy, acknowledgement state, escalation timer, digest generation, and audit history. A dismissed notification is not the same as an acknowledged incident. A muted camera zone is not the same as a resolved event. Store those as separate states so the UI can preserve signal without flooding the user.

Finally, support and observability should share the same state vocabulary as the interface. Logs that include command id, account role, device firmware, gateway id, network status, battery state, retry count, notification severity, and correlation id let support explain what happened without asking the user to reproduce the failure blindly. The implementation is doing its job when the interface can be fast, truthful, accessible, and diagnosable at the same time.

49.9 Prerequisites

• Interface Design Fundamentals: Understanding of UI patterns and component hierarchies
• Communication Networks: Knowledge of network protocols and latency characteristics

49.10 Core Interaction Patterns

49.10.1 Optimistic UI Updates

Network latency is a fundamental challenge in IoT interfaces. Optimistic UI provides immediate visual feedback while commands travel to devices:

Before deciding how CLOUD shapes optimistic ui updates, inspect Figure 49.2 beside USER. Together, CLOUD and USER frame the optimistic ui updates claim: optimistic ui pattern: immediate feedback with graceful error recovery.

Read CLOUD alongside USER in Figure 49.2; their named relationship makes optimistic ui pattern: immediate feedback with graceful error recovery concrete. For optimistic ui updates, CLOUD supplies visible evidence; USER constrains the decision. In Figure 49.2, retain CLOUD beside USER so optimistic ui updates remains explicit.

Why Optimistic UI Matters:

Scenario	Without Optimistic UI	With Optimistic UI
User taps button	3-second wait, no feedback	Instant visual change
User perception	“Is it broken?”	“Command acknowledged”
Repeated taps	Multiple commands queue up	Single command sent
On failure	Confusing state	Clear error + recovery

49.10.2 Distributed State Synchronization

IoT devices often have multiple interfaces (app, voice, physical controls). All must stay synchronized:

Before deciding how Voice shapes distributed state synchronization, inspect Figure 49.3 beside Physical. Together, Voice and Physical frame the distributed state synchronization claim: distributed state synchronization: multi-interface consistency via mqtt.

Read Voice alongside Physical in Figure 49.3; their named relationship makes distributed state synchronization: multi-interface consistency via mqtt concrete. For distributed state synchronization, Voice supplies visible evidence; Physical constrains the decision. In Figure 49.3, retain Voice beside Physical so distributed state synchronization remains explicit.

Synchronization Principles:

Single Source of Truth - Device state is authoritative. Publish/Subscribe - Changes broadcast to all interfaces. Last-Write-Wins - Simple conflict resolution. Offline Queue - Commands stored when disconnected.

49.10.3 Notification Escalation

Alert fatigue occurs when users receive too many notifications. Smart escalation ensures important alerts get attention:

Before deciding how 2 min shapes notification escalation, inspect Figure 49.4 beside 1 hour. Together, 2 min and 1 hour frame the notification escalation claim: notification escalation strategy: five severity levels with auto-escalation.

Read 2 min alongside 1 hour in Figure 49.4; their named relationship makes notification escalation strategy: five severity levels with auto-escalation concrete. For notification escalation, 2 min supplies visible evidence; 1 hour constrains the decision. In Figure 49.4, retain 2 min beside 1 hour so notification escalation remains explicit.

Escalation Levels:

Level	Trigger	Notification Type	Example
1 - Silent	Routine	Log only	Tree motion, car passing
2 - Badge	Low	App badge update	Mail delivered
3 - Push	Medium	Standard notification	Package at door
4 - Sound	High	Alert sound	Unknown person at door
5 - Alarm	Critical	Siren + phone call	Break-in detected

49.10.4 Feedback Design Principles

Effective IoT feedback matches the importance of the action:

Feedback should reflect the consequence and expected duration of an action, not apply the same spinner or alert to everything. The timing chart in Figure 49.5 aligns urgency, modality, and timing so the interface can set an honest expectation.

Across Figure 49.5, a Critical safety alert pairs immediate visual, haptic, and sound feedback with a target below 100 ms. An Important device-state change tolerates 100–300 ms but still needs haptic or sound plus visual confirmation. A Routine settings adjustment in the 300 ms–1 s band calls for a progress indicator, while a Background sync or firmware update moves to a non-blocking notification and longer progress. The hierarchy links the chapter’s interaction patterns to consequence: stronger feedback is reserved for the actions that demand attention fastest.

Response Time Expectations:

Delay	User Perception	Design Response
< 100 ms	Instantaneous	Direct manipulation feel
100-300 ms	Slight delay	Acceptable for most actions
300 ms-1s	Noticeable	Show activity indicator
1-10s	Slow	Progress bar + status
> 10s	Broken	Background task + notification

Responsiveness Gain Calculator

Calculate how much perceived responsiveness improves with optimistic UI:

Key Insight: Even small improvements in feedback timing create dramatic improvements in perceived responsiveness. A 3-second actual delay with 50 ms optimistic feedback feels 60× faster to users.

Checkpoint: Pattern Selection

You now know:

• Use optimistic updates when the user needs feedback under 100 ms but the device confirmation may take longer.
• Use publish/subscribe when app, voice, wall panel, dashboard, and support views must share one authoritative state.
• Escalate notifications by severity, response, and context; routine motion should not use the same channel as a break-in.

49.11 Code Example: MQTT State Synchronization

The following JavaScript example demonstrates real-time state synchronization across multiple IoT interfaces using MQTT. This pattern keeps phone apps, wall panels, and voice assistants in sync:

// MQTT-based state synchronization for IoT dashboards
class DeviceStateSync {
  constructor(mqttClient, deviceId) {
    this.client = mqttClient;
    this.deviceId = deviceId;
    this.state = {};
    this.pendingCommands = new Map();
    this.listeners = new Set();

    // Subscribe to device state updates
    this.client.subscribe(`devices/${deviceId}/state`);
    this.client.on('message', (topic, payload) => {
      if (topic === `devices/${deviceId}/state`) {
        this.handleStateUpdate(JSON.parse(payload));
      }
    });
  }

  // Send command with optimistic update and timeout
  sendCommand(property, value) {
    const commandId = crypto.randomUUID();
    const previousValue = this.state[property];

    // Optimistic update: show new value immediately
    this.state[property] = value;
    this.notifyListeners(property, value, 'pending');

    // Track command for rollback on failure
    this.pendingCommands.set(commandId, {
      property, previousValue, timestamp: Date.now()
    });

    // Publish command via MQTT
    this.client.publish(`devices/${this.deviceId}/command`, JSON.stringify({
      commandId, property, value
    }));

    // Timeout: revert if no confirmation in 10 seconds
    setTimeout(() => {
      if (this.pendingCommands.has(commandId)) {
        this.pendingCommands.delete(commandId);
        this.state[property] = previousValue;
        this.notifyListeners(property, previousValue, 'timeout');
      }
    }, 10000);
  }

  // Handle confirmed state from device
  handleStateUpdate(newState) {
    for (const [key, value] of Object.entries(newState)) {
      this.state[key] = value;
      this.notifyListeners(key, value, 'confirmed');
    }
    // Clear any pending commands that are now confirmed
    this.pendingCommands.clear();
  }

  notifyListeners(property, value, status) {
    for (const listener of this.listeners) {
      listener({ property, value, status });
    }
  }

  onStateChange(callback) {
    this.listeners.add(callback);
  }
}

// Usage: Connect UI elements to synchronized state
const thermostat = new DeviceStateSync(mqttClient, 'thermostat-001');

thermostat.onStateChange(({ property, value, status }) => {
  const display = document.getElementById('temp-display');
  display.textContent = `${value}°F`;
  display.className = status; // 'pending', 'confirmed', or 'timeout'

  if (status === 'timeout') {
    display.setAttribute('aria-label',
      `Temperature change failed. Showing last confirmed: ${value}°F`);
  }
});

State synchronization design decisions:

49.12 Continue to the Next Part

Carry this evidence into Interaction Patterns: Synchronization and Recovery, which begins with Ecobee State Synchronization.