Empty States for an Offline AI App

Direct answer

An empty state should explain what is absent and what the user can do next; it should not be a generic error page. “No model,” “no input,” “no history,” “task unavailable,” and “operation failed” describe different situations with different causes and actions. A good offline AI interface makes those states explicit, preserves useful navigation, and never treats the absence of an artifact as consent to download it. When the task requires a model that is not present, say so and offer only supported choices such as learn more, choose a source, start setup after disclosure, or continue with a non-model feature. Separate data absence from broken execution. No conversation history may be the expected first-use state. No selected photo may mean the user has not chosen a photo. A missing model may require user-directed setup. A permission denial may require a system permission action. An unsupported task may have no available route. A failed load means a prior operation did not complete. If all of them render as “Something went wrong,” a user cannot tell whether to provide input, install a model, grant access, retry, or contact support. Conversely, an empty state must not conceal a real failure by displaying a friendly “nothing here yet” message after data loss or a failed database query. Define the app’s task dependencies before writing copy. For each feature, record whether it needs a model artifact, a camera or audio permission, user input, local history, a network connection, or some combination. Then define an explicit UI state for each required prerequisite. Local inference removes a remote inference dependency, but it does not mean every screen works offline or that no other service is used. A feature can be usable offline only when its inputs, artifacts, runtime path, and required local data are available; this page does not assert that a specific Cove feature currently meets that condition. Design the primary action from the actual missing item. If there is no input, invite the user to select, capture, or import one through supported routes. If there is no history, explain that results will appear after the first successful task and offer a safe start action. If a required model is missing, disclose the transfer and network/storage implications before the first request. If a task is not supported, do not show a retry that can never succeed; explain the limit and route to an available feature. If an operation failed, report the stage and recovery option. Actions must correspond to implemented code rather than a hopeful mockup. Use consistent but informative visual structure. A short title names the state, body text says why the feature is unavailable, and a primary button initiates the next valid step. Secondary navigation should remain available where it does not conflict with user data safety. Use accessibility labels and semantic state descriptions so that screen-reader users receive the same distinction as visual users. Do not encode a state only by color or icon. A loading spinner should represent work that is actually in progress, not an empty database or a missing model. Reconcile UI state with its source of truth. A cached model status may be stale after process recreation; read the manager or repository state rather than assuming a previous screen remains accurate. An empty history list should be distinguished from a database access error. A download placeholder should not be displayed as ready. A fresh install, app update, user cancellation, revoked permission, lost storage volume, and failed model load can each transition into different states. The screen should update when those transitions occur and avoid reusing stale success messages.

Return after canceling first model setup

A first-time user canceled model setup and returns to an app with no history, no model, and no selected input. The absence is expected, but the app must not silently restart a transfer.

Decision

Show the missing-model and missing-input conditions separately, offer only disclosed setup or input actions, and keep safe model-independent navigation visible.

Expected outcome

The user understands why the task cannot run yet and chooses the next action without losing settings or granting download consent implicitly.

Evidence to collect

The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:

• State taxonomy
• Primary recovery action
• Accessibility labels

A completed byte stream is not enough. Final placement, integrity, runtime load, and recovery must also pass.

Implementation workflow

1. Inventory task prerequisites. For every screen, list required model, user input, permission, history, local data, and network access. Mark conditions as required or optional so the UI does not block features unnecessarily.
2. Define separate state transitions. Represent no input, no history, model absent, permission denied, unsupported task, loading, and failure distinctly. Record the source of truth and event that enters or exits each state.
3. Map valid actions to causes. Invite input when input is missing, offer setup only after model-transfer disclosure, use a permission action after denial, and point to an available feature rather than impossible retry for unsupported tasks.
4. Preserve other usable routes. Keep settings, explanations, and model-independent features reachable when safe. A missing artifact for one task should not block unrelated app functions without a documented dependency.
5. Provide accessible announcements. Give each state a meaningful heading, screen-reader announcement, visible action label, and semantic description. Color, illustration, and animation must not be the only signals.
6. Test fresh start and recovery. Cover first install, no input, empty database, canceled setup, process recreation, revoked access, missing artifact, runtime failure, and a successful first task; verify states neither start work silently nor hide errors.

Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.

Acceptance criteria

• No input, no history, absent model, unsupported task, denied permission, loading, and operation failure are separately observable.
• An empty screen never schedules a model transfer or consumes network without a clearly disclosed user action.
• Model-independent navigation stays available unless a specific documented dependency blocks it.
• Accessibility APIs announce the state and action without relying only on color or animation.

Decision table

Failure patterns to prevent

• One blank screen for all states
• Starting downloads without consent

Also prevent silent fallback, unpinned artifacts, missing cancellation, and conclusions that combine unlike configurations. Store unsuccessful runs alongside successful ones.

Minimum reproducibility record

Release checklist

• ☐ The primary query is answered without an unsupported number.
• ☐ Every artifact and runtime is pinned.
• ☐ The representative task and failure policy are explicit.
• ☐ Lifecycle, cancellation, cleanup, and fallback are tested.
• ☐ User-content and network boundaries are documented.
• ☐ Result wording applies only to the recorded configuration.
• ☐ The page links to raw method or evidence when results are added.

Sources and related evidence

• On-device AI architecture overview
• Android UI layer and UI state
• Build an offline-first app
• Compose accessibility semantics

Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.

Frequently asked questions