Use inline edit when a displayed value can switch into a local edit control in place, with explicit save/cancel, validation, and dirty-state protection while the surrounding context remains visible.
Use inline edit when a displayed value can switch into a local edit control in place, with explicit save/cancel, validation, and dirty-state protection while the surrounding context remains visible.
Practice the judgment: Imagine this situation: Clicking away from a dirty inline edit silently discards the draft. Write the person's goal, choose one of these patterns, and show the state that helps the person continue. Use the decision rules and source trail below to explain your choice.
Review the underlying principle →| Dimension | Inline edit | Text input | Single-page form | Modal dialog |
|---|---|---|---|---|
| UI or UX | UI + UX - In-place value or row editing | UI + UX - Single-line freeform data-entry control | UI + UX - Short related multi-field submission page | UI + UX - Focused modal task layer |
| UI guidance | Render a read-state value with a visible edit affordance, then replace only that value, cell, or row with the appropriate input and adjacent Save and Cancel controls when edit mode starts. | Render a persistent label, appropriately sized single-line input, optional hint, visible focus state, and nearby error text that is programmatically associated with the field. | Render a clear form heading, short instruction, required or optional indicator explanation, grouped related fields, one primary submit action, and a visible error summary only after failed submit. | Render a titled layer above a dimmed or otherwise unavailable page, with clear task content, named actions, visible close or cancel affordance, and stable scroll boundaries. |
| UX guidance | Use inline edit when users need to make frequent, low-impact changes to one visible property while preserving surrounding list, table, or record context. | Let users edit normally, validate after interaction or attempted submit, preserve their typed value after errors, and explain exactly how to fix invalid or missing text. | Use a single-page form when users benefit from seeing, comparing, and editing a small related set of fields before one submission. | Use the modal interruption only for compact tasks that genuinely need temporary focus before the user returns to the page. |
| Good UI | A resource table shows an edit icon beside the owner cell; activating it turns that cell into a text field with Save and Cancel buttons while other cells remain read-only. | A reference-name field has a visible label, hint, medium width, focus ring, and error message beneath the hint when submitted empty. | A contact-details form shows one heading, a required-field note, grouped name and contact fields, communication preference radios, aligned field errors, and a Save details button at the end. | Account settings opens in a titled dialog with one display-name field, Save, Cancel, close control, and dimmed inactive page context. |
| Bad UI | The edit affordance appears only on pointer hover and is unreachable by keyboard or touch. | The only instruction is placeholder text that disappears when the user starts typing. | A long application with eligibility, address history, uploads, and payment fields is dumped onto one scrolling page. | A vague popup titled Popup floats over active page controls and offers only OK. |
| Good UX | A user clicks Edit owner, changes the value, sees Save become enabled, enters an invalid short value, fixes it beside the field, saves, and stays on the same row. | A user leaves the required field blank, sees an error only after submit, returns to the same field, and their later typed value clears the error. | A user reviews all contact details before submitting because the fields are short, related, and visible in one scan. | Opening moves focus to the display-name field, Tab remains inside the layer, Escape cancels, and closing returns focus to Open dialog. |
| Bad UX | A user edits a sorted table cell and the row immediately jumps to a different page before the saved value can be confirmed. | Validation fires on the first focus event and blocks typing before the user has had a chance to answer. | A validation failure clears completed fields, forcing the user to re-enter unrelated information. | Users can click background Delete or Navigate controls while the modal is still open. |
| Best fit | Users frequently update one visible value or one row property. | The answer is short and user-authored. | A compact set of related fields should be reviewed together before one submit. | A short task must interrupt normal page interaction but should return users to the same context afterward. |
| Avoid when | The edit affects multiple dependent fields or needs a review step. | The answer is a paragraph, comment, address block, or explanation requiring multiple lines. | The form is long, high-stakes, branched, or too hard to recover from on one page. | The workflow is long, multi-step, shareable, or needs browser navigation. |
| Required state | Read state with displayed value and discoverable edit affordance. | Empty untouched state with persistent label and optional hint. | Initial empty state with form heading, instruction, required or optional indicator explanation, grouped fields, and submit action. | Closed page state with an obvious invoking control. |
| Accessibility burden | Give edit, save, cancel, confirm, and dismiss controls accessible names, especially when icons are used. | Associate every text input with a visible label or equivalent accessible name that matches the visible question. | Keep field order in the DOM the same as the visible order. | Use dialog semantics with an accessible name from the visible title. |
| Common misuse | Using inline edit for high-impact changes that need a review or confirmation step. | Using placeholder text as the only label or instruction. | Using one page for a long complex application just to avoid designing steps. | Using a modal as a generic container for routine information that could stay inline. |