Inline edit

Problem Context

• The user is viewing a record, list, table, or details page and needs to update one low-impact property.
• Keeping surrounding context visible helps the user choose the right value or compare rows.
• The edit can be committed or canceled independently without reviewing a larger form.
• The system can preserve the original value and reliably report save, validation, and failed-save states.

Selection Rules

• Choose inline edit for frequent low-impact edits to one displayed value, table cell, table row, or resource property.
• Use text input instead when the user is already inside a normal form and there is no separate read state.
• Use single-page form when several related values should be reviewed and submitted together.
• Use modal dialog when a short edit needs focused explanation or secondary controls but should not become a whole page.
• Use complete complex form when changes span sections, dependencies, or review-before-save consequences.
• Do not use inline edit for irreversible, high-impact, bulk, or cross-record changes without stronger confirmation or review.
• Avoid inline edit where clicking a value already opens drill-down, selects text, expands a row, or triggers row selection.
• In tables, account for sort, filter, pagination, refresh, row selection, and one-row-at-a-time editing before enabling inline edit.
• Make editability visible through an edit button, icon, hover affordance, or row action with an accessible name.
• Keep Save disabled or clearly unavailable until the draft differs from the original value.

Required States

• Read state with displayed value and discoverable edit affordance.
• Read-only or unavailable state for values that cannot be edited.
• Edit mode with focused input and adjacent Save and Cancel controls.
• Unchanged draft state where Save is disabled or explained.
• Dirty draft state where Save is available and Cancel restores the original value.
• Validation error state shown beside the edited input.
• Dirty click-away or navigation state that asks whether to save, discard, or keep editing.
• Saving state that prevents duplicate commit without losing the draft.
• Saved success state that returns to read mode with the new value visible.
• Failed-save state that keeps the input editable and reports recovery.

Interaction Contract

• Edit changes only the targeted value, cell, or row into edit mode and leaves unrelated content in read mode.
• Only one table row or one conflicting edit scope can be active at a time unless the product explicitly supports batch editing.
• Save commits the changed draft, reports validation errors in place, and returns to read mode only after success.
• Cancel discards the draft and restores the original displayed value.
• Click-away with no changes can exit edit mode; click-away with changes must save, discard, or keep editing by explicit user choice.
• Sorting, filtering, pagination, and refresh should not make the edited item disappear before users can understand the saved result.
• Keyboard users can enter edit mode, move through editable fields, save, cancel, and recover from errors without relying on hover.

Implementation Checklist

• Identify which values are editable and which are read-only before adding edit affordances.
• Give every edit trigger and icon-only Save or Cancel control an accessible name.
• Store the original value separately from the draft so Cancel and dirty comparison are reliable.
• Disable Save until the draft differs from the original, or explain why save is unavailable.
• Place validation messages directly beside the edited input and keep the draft editable after errors.
• Implement dirty click-away and route-change handling before enabling inline edit in dense tables.
• Decide how active sort, filter, pagination, and refresh behave after a value changes.
• Prevent conflicts with row drill-down, row selection, text selection, bulk actions, and keyboard shortcuts.
• Test keyboard entry, Escape or Cancel, Enter or Save, focus return, screen reader labels, validation, failed save, and mobile hit targets.

Common Generated-UI Mistakes

• Using inline edit for high-impact changes that need a review or confirmation step.
• Making static text secretly editable with no visible affordance.
• Removing Cancel, so users cannot restore the original value.
• Saving every keystroke while presenting the interaction as explicit save/cancel inline edit.
• Letting sorted or filtered rows jump away immediately after the value changes.
• Allowing multiple table rows to enter edit mode when row selection and bulk actions are still active.
• Using inline edit for a large multi-field form that belongs in a page, modal, or complex form.
• Replacing text with an input on hover and blocking users from selecting or copying the displayed text.

Critique Questions

• Is the edit low-impact enough to commit locally without broader review?
• Can users discover which values are editable before clicking them?
• What happens to the original value if the user cancels or clicks away?
• Does Save stay disabled until a real change exists?
• Where does validation appear and can users fix it in place?
• Will sorting, filtering, pagination, row selection, or drill-down conflict with edit mode?