Chat interface

Problem Context

• A chat can include user messages, assistant messages, system or product notices, tool calls, file references, source citations, streaming deltas, blocked content, and saved history.
• Follow-up prompts may rely on current session context, persisted conversation state, selected files, page context, workspace data, tools, memory, or no carried context.
• Users may start a new chat, resume an old chat, rename or pin a conversation, delete history, export a transcript, copy an answer, stop generation, regenerate, retry, edit a previous turn, or branch a conversation.
• Long conversations introduce scroll anchoring, virtualized message lists, mobile keyboard overlap, transcript search, older-history loading, citation focus, and source availability issues.
• Enterprise and regulated products may have retention, audit, privacy, external-model, sensitive-data, and human-approval requirements that change how chat history is shown.

Selection Rules

• Choose chat interface when the user task depends on turn-taking, follow-up prompts, assistant responses, and conversation history rather than a single request field.
• Use prompt box when only the editable AI request composer is being designed and transcript state belongs elsewhere.
• Use threaded discussion when the conversation is among people and needs nested replies, human authorship, moderation, and unread human activity.
• Use comments when messages are object-level annotations, decisions, or review notes tied to a document section, task, row, or artifact.
• Use feed when users browse chronological updates or content items and do not need a composer anchored to a turn-taking transcript.
• Show a conversation identity when chats can be saved, revisited, renamed, pinned, deleted, exported, or used across sessions.
• Make follow-up context explicit when the next prompt will use previous turns, selected files, work data, web data, tools, memory, or a prior response ID.
• Use a sequential live region or equivalent status strategy for new transcript items so assistive technologies can announce appended messages without moving focus unnecessarily.
• Keep current draft, submitted prompt, assistant response, tool progress, citation state, and copied answer state separate.
• Do not claim chat history is off while still carrying prior turns into model context without a clear current-session explanation.

Required States

• Empty new chat with conversation title, mode, history or retention status, and a labelled composer.
• Typing draft, submitted user message, assistant thinking, streaming response, complete response, stopped generation, failed response, and retry states.
• Follow-up turn that shows whether prior messages, files, tools, memory, selected sources, or web/work mode are included.
• Regenerate, edit follow-up, copy answer, cite source, export transcript, delete chat, and new chat states.
• Long transcript with older-history loading, scroll-to-latest, reading older turn, active citation, and preserved draft behavior.
• History disabled, history unavailable, expired conversation, deleted conversation, signed-out session, offline, rate-limited, sensitive-content, and policy-blocked states.
• Mobile keyboard state with composer anchoring, accessible send and stop controls, transcript reading space, and preserved scroll.

Interaction Contract

• Every user-visible answer is tied to the exact user message and visible context that produced it.
• New turns append in reading order and do not interrupt a user who is reading, selecting, copying, or inspecting an older turn.
• The current composer controls the next message only; conversation-level controls such as New chat, Delete history, mode, memory, and export are labelled separately.
• Stop generation leaves a partial-response state rather than pretending the answer completed.
• Retry resends the same turn or clearly shows when the prompt, model, tools, or sources changed.
• Regenerate preserves prior answer identity or makes version replacement explicit.
• History settings explain whether they affect saved history, personalization, current-session context, or future conversations.
• Focus remains predictable after submit, stream complete, stop, retry, copy, delete, history open, or older-history load.

Implementation Checklist

• Model conversation data as ordered turns with stable IDs, role, prompt text, response text, status, sources, tool events, timestamps, copy state, version state, and retention metadata.
• Separate draft composer state from submitted messages, response streaming state, conversation list state, and saved-history state.
• Implement controls for send, stop, retry, regenerate, edit follow-up, copy, cite, export, new chat, rename, pin, delete, and history settings according to risk.
• Validate scroll anchoring, focus return, mobile keyboard behavior, virtualized older messages, long answers, code blocks, citations, tool progress, failed streams, and offline recovery.
• Expose transcript updates, streaming status, errors, copied state, source availability, and history changes to assistive technologies without forced focus jumps.
• Log or audit high-risk assistant actions without treating private draft text or deleted history as retained evidence unless the product explicitly says so.

Common Generated-UI Mistakes

• Treating chat as a large textarea plus latest answer with no durable turn identity.
• Auto-scrolling during streaming while the user is reading an older message.
• Letting regenerate overwrite a response and citations with no version history.
• Showing a history-off toggle while the next turn still uses prior messages without explanation.
• Mixing human comments, task activity, and assistant chat in one transcript without role and purpose boundaries.
• Hiding tool calls, file references, and source scope until after a response fails or produces a risky answer.
• Using chat for a deterministic workflow that needs structured fields, review, or approval.

Critique Questions

• Can users identify the active conversation, each turn's role, the exact prompt for each answer, and what context carries into the next turn?
• What happens to focus, scroll, draft text, copied text, and source inspection when a response streams, fails, stops, or regenerates?
• Are history, retention, memory, grounding, and tool-use settings visible at the level they affect?
• Does this need chat, or would a prompt box, form, command, comments thread, or activity feed better fit the task?
• Can users recover or audit the transcript after weak output, source loss, policy block, deletion, or session expiry?