Editing and viewing a record must not share an ambiguous state
Aliases: read versus update on one record · CRUD mode confusion
What it is
In CRUD, read and update often share one record layout: same fields, same title, yet the person may be looking or changing. The states must split means the surface itself has to answer “am I viewing this record, or editing it?” without a trial keystroke. This is the read/write collision on a single record in the four operations. Whole-page visual language for edit versus view, hiding the entry by permission, and keeping a draft after a crash live elsewhere.
Why it happens
When one field layout hosts two operations, people assume what they see they can change—that is the direct-manipulation expectation, not carelessness. A read-only detail dressed as inputs, or a writable page dressed as an article, misaligns action and consequence: typing in a read-only shell never lands, so they blame save; tweaking a label on a writable page feels like preview. A mode mark in a corner is absent while the eyes sit on the body. The CRUD-specific failure is picking the wrong verb: intending a read and committing an update, or intending an update and working in a read-only shell. That modes must stay visible is a separate, more general mechanism. The extra piece here is that one record surface carries both R and U; once the state blurs, those two operations contaminate each other.
Studying it
Give one record two shells (read-only detail, in-place writable). Alternate tasks of “check a value” and “change a value” without announcing which shell is up.
Independent variables: whether read-only shares input chrome with writable, whether the state label sits beside the field in use, default state when opening from a list. Dependent variables: typing attempts in the read-only shell, treating edits as uncommitted preview in the writable shell, post-task report of “could I change that.”
Lab instructions leak state (“please edit”). Use a goal instead: “confirm the due date” can be satisfied by looking or by changing. In products, count how often opening detail is followed by an explicit Edit—that is a readable read-default with a findable entry. Random field clicks after open suggest a write-default that was never declared.
Where it stops holding
Create is write; there is no view of a record that does not exist, so a fake read-only shell is unnecessary. Cell-level grid editing is a focus-and-commit state, not a page banner. A media reader with no update has one state: read. When permission already forbids write, an editor-looking surface turns a state error into a permission error—a different misread.
Applying it
- Render read-only detail as static text, not disabled inputs. Fields become focusable controls only after update starts.
- Opening a record from a list should land on read; update takes an explicit Edit. Objects that are writable by default (drafts, private notes) keep an “editing” mark in the title region, not a one-frame flash on entry.
- Save and publish appear only in the writable state. The read-only state offers close, share, copy—not the same primary label on both states.
- Verify: two versions of the same record, read-only and writable. Ask people to “see the due date” and “change the due date” without saying which version they have. Input attempts on the read-only version, or “I was only looking” after the writable version, mean the states never split.