People Already Use the Simplest Interface
People can coordinate surprisingly complex work through text. One person asks a question. Another answers. Someone states an intention. Someone else tells the group about a change before anybody asks.
The screen adds images, controls, animation, audio, and spatial arrangement, but it does not abolish that basic exchange. Showing an image on a screen is close to placing the image on a table. Following a link is close to accepting a document someone hands you. The delivery changes; the need to establish shared meaning remains.
Every participant carries an internal model of the thing under discussion. The models are never perfectly identical. Communication works by making selected parts of one model available to another mind, then allowing the recipient to inspect, revise, or act on what arrived.
The Four Active Moves
Four verbs cover much of the visible work in an interface:
- Listen
- Become available to receive a message through a particular channel.
- Ask
- Request part of a model: its current state, an explanation, a missing value, or a possible next action.
- Answer
- Reveal the requested part of a model in a form the other participant can use.
- Tell
- Offer a state change, fact, warning, or invitation without waiting for a question.
Listening deserves its own verb. A computer cannot answer a request it did not receive. A person cannot act on a notification delivered through a muted, hidden, unavailable, or distrusted channel. “The message exists” and “the other party was listening” are different states.
Ask and answer are not merely labels for HTTP requests and responses. A filter asks a collection to reveal a narrower model. A dashboard answers a recurring operational question. A disabled control answers a question too: not now, and ideally why not. A form tells the system what state the person wants to establish.
Observe and Ignore Are Real States
Not every moment is an active message. A person can observe and wait. A computer can wait for input. Either party can ignore the channel and do internal work.
That gives us a larger interaction alphabet:
- listen;
- ask;
- answer;
- tell;
- observe or wait;
- ignore or think.
An interface that cannot represent waiting often invents false progress. An interface that cannot distinguish thinking from abandonment becomes impatient. It flashes, nags, times out, or steals focus because it treats silence as an error.
Sometimes waiting applies to one medium rather than the whole conversation. After a loud noise, speech may pause while text remains available. During a network interruption, local editing may continue while synchronization waits. A good system knows which channel is blocked and which process is still alive.
A Message Addresses a Model
A useful message does not float freely. It points to a subject the receiver can identify: this order, that paragraph, the selected motor, tomorrow’s meeting, the current simulation, the file whose name just changed.
A question explores a model. An answer shares its state. An imperative attempts to change it. Even a casual announcement invites the receiver to create or update a model: the build passed, the door is open, the train is late.
This is why context loss is so destructive. The words may arrive intact while the addressed model has disappeared. “Approve it” is meaningless if the receiver no longer knows what it is. Restoring the model is not decorative interface work; it is part of delivering the message.
Links, selections, visible history, stable names, and local previews all help keep the subject attached to the exchange. They reduce the amount of model reconstruction each person must perform in their head.
Interruption Is Part of the Protocol
Answers can be stopped halfway. Questions can be revised before they are complete. A person can abandon an instruction after seeing an unexpected consequence. A machine can interrupt the person’s train of thought with an alert.
Interruption is therefore not an exceptional failure outside the model. It is a normal transition inside the interaction.
A robust interface should make four facts recoverable:
- What process was in progress?
- What part completed before the interruption?
- What remains provisional or unsent?
- What would resuming actually do?
Without those facts, “continue” is a gamble. The person must guess whether the system saved, submitted, duplicated, discarded, or partially applied the work.
Computers frequently interrupt thoughts that computers helped us create. A document, script, or task list can replay a model we recorded yesterday. When its reminder appears today, the machine is carrying our own earlier thought back into the present conversation. That can be useful. It should still enter politely.
The recorded model may also belong to somebody else. A message, drawing, program, or shared document lets another person’s earlier thought enter my present attention, complete with its own subject and unfinished requests.
Medium, Channel, Session, Process
These words are often collapsed, but they solve different design problems.
A medium is a general form such as text, sound, or visible movement. A channel is a particular route through that medium: this chat window, that display, a printed sheet, a spoken conversation across one table.
A session is one connected period of interaction over a channel. Pick up a pen and an interaction session begins. Put it down and that session ends. Pick it up again and a new session can resume the same larger task.
The interaction process is held together by intention. It can span broken sessions, changed devices, and long pauses. Drafting a circuit may move from notebook to browser to FPGA tool to workbench without becoming four unrelated projects.
Software becomes brittle when it identifies the process with one session. A closed tab then looks like the death of the work. A dropped connection looks like cancellation. A device change looks like a new person. Preserving process identity across sessions is one of the deepest forms of continuity an interface can provide.
Attention Selects the Active Conversation
A person may receive many signals at once, but conscious attention tends to elevate one interaction into the foreground. Selecting a window, looking at a tool, or reaching for an object loads a working context: what this is, what can be done with it, what just happened, and what I intended to do next.
People can perform familiar actions in the background, but automatic action is not the same as holding several equally detailed conversations at once. Interfaces that scatter one task across competing channels force the person to reload context repeatedly.
Focus is therefore more than keyboard routing or a highlighted border. It is the user’s current commitment of modeling effort. Moving focus should preserve enough state that returning does not require rebuilding the world from scraps.
This also explains why an object can feel as if it is “waiting.” The object need not possess a mind. The person maintains an unfinished interaction model: the editor is waiting for the next line, the instrument for the next measurement, the door for the next push.
Objects Answer Through Consequences
Manipulating an object is an interaction because the object responds. Pick up a pen and its weight, texture, balance, and movement answer the hand. Push a control and its resistance, sound, display, and resulting machine state answer the intention.
When reality differs from the anticipated simulation, the difference is a message. The drawer sticks. The motor stalls. The button moved but the action did not occur. A humane interface does not hide that answer merely because it is inconvenient.
Feedback is strongest when it describes the changed model, not merely the gesture. A ripple proves that a pointer landed. “Saved locally; synchronization is waiting for a connection” explains what happened to the work.
Computer vision is not the only way a machine senses a person. Keyboard and mouse input are sensors of human state. They receive deliberate expressions rather than guessing intention from appearance.
Optical recognition can be useful, but it is indirect. The machine sees pixels and infers a posture, identity, emotion, or action. A key press can say exactly which command the person chose. A pointer can state a precise position. Interaction is itself evidence.
This changes the design question. Do we need to infer what the person wants, or can we give them a comfortable way to express it? The second path is often cheaper, faster, more private, and easier to correct.
The same device or surface can also carry interaction in both directions. A display presents state and accepts touch. A keyboard tells the machine and signals back through motion, sound, and light. Push and pull, imperative and declarative, control and presentation are roles inside an interaction—not permanent properties of a device.
A Small Interface Test
For any important screen or device, ask:
- Which model are the person and machine trying to share?
- Who is listening, and through which channel?
- Is this action an ask, answer, tell, observation, or intentional silence?
- What happens if either party interrupts it halfway?
- Can the interaction resume in another session without losing its subject?
- Does feedback describe the resulting state, or only acknowledge the gesture?
- Are we inferring human intent when we could let the person express it directly?
Those questions do not prescribe a visual style. They expose the conversational machinery under the style. Once that machinery is sound, the screen can become quieter because it no longer has to compensate for missing context with noise.