simply-ehis AI Workspaces (Desktop)
AI features should help a person complete a concrete task. Do not make a chat panel the default answer if a structured action, preview, or inline suggestion better fits the work.
Establish the interaction contract
Before choosing components, state the user goal, what the system may do, what it needs from the user, what can change external state, and how a result can be inspected, revised, or undone. Match the interface to that contract:
- Use inline assist for a local, inspectable suggestion in the current work.
- Use a task/run view for work that takes time, spans files or tools, or needs a durable history.
- Use a chat surface when conversational refinement is genuinely the fastest way to express the task.
- Use a form or command when inputs are known and repeatable; it is more scannable and safer than a prompt box.
Make AI state observable
Never represent a run with a vague spinner and a comforting sentence. Show the meaningful state: queued, preparing, waiting for approval, working, needs input, completed, failed, or cancelled. For a long task, show a concise activity summary and elapsed time; reveal detailed logs on demand without forcing every user to read them.
Separate three things visually: the user's instruction, evidence or source context, and the system's proposal or action. Preserve provenance where it matters: generated text should identify its sources or uncertainty; file or data mutations should name the target and show a diff, preview, or reversible consequence.
Approval and recovery
- Put approval immediately before the consequential action, with a plain-language summary of scope. Do not bury it in the initial prompt.
- Make the safe path obvious: cancel, edit inputs, retry, or keep the partial result. Do not make a failed run feel like lost work.
- Treat destructive, financial, external-message, credential, or broad file changes as a higher-risk tier. Require an explicit review surface, not a generic "continue" button.
- Do not imply certainty the model does not have. Say what was found, inferred, or unable to be checked in a compact, useful way.
Density and calm
The primary work remains primary. Avoid a permanent, oversized prompt composer, animated thinking theater, token counters, rainbow status pills, or a card around every message. Let a compact composer expand only when the task needs more context. Use color for run state and warnings, not as decoration.
For model choices, lead with capability and trade-off in task language (for example, "fast draft" versus "deep analysis"); expose identifiers, quotas, and advanced parameters behind a details affordance unless the audience is expert.
Accessibility
Announce state changes without repeatedly interrupting screen readers. Keep streamed content keyboard-reachable, preserve focus when a run updates, and ensure cancellation, approval, and result actions are available without pointer precision. Respect reduced motion; streaming should never make text jump beneath a reading user.
Review format
| Before | After | Why |
|---|---|---|
| A generic chat window is used to configure a repeatable export task | A structured export panel with an optional "refine with AI" field | Known inputs are faster to scan, validate, repeat, and audit than an open-ended prompt |
| A long agent run says only "Thinking…" | A compact run status shows current phase, elapsed time, controls, and expandable activity | The user can decide whether to wait, intervene, or safely leave the task running |
| "Approve" is shown without consequences | The approval names the target, proposed change, and review/undo path | Consent is meaningful only when the scope is legible |