Use a data grid for dense interactive row-and-column work with managed cell focus; use a table for semantic comparison, inline edit for local value changes, and pagination to divide long result sets.
Use a data grid for dense interactive row-and-column work with managed cell focus; use a table for semantic comparison, inline edit for local value changes, and pagination to divide long result sets.
Practice the judgment: Imagine this situation: A static read-only table uses role grid and traps arrow keys even though users expected ordinary reading and tab order. 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 | Data grid | Table | Inline edit | Pagination |
|---|---|---|---|---|
| UI or UX | UI + UX - Interactive row-and-column data workspace | UI + UX - Semantic row-and-column data comparison surface | UI + UX - In-place value or row editing | UI + UX - Paged navigation control |
| UI guidance | Render the grid as a named work surface with visible headers, row identifiers, focus location, selection state, dirty and invalid cell markers, column controls, and status text for row count, sort, filter, and save state. | Render a table with a specific caption or heading, visible column headers, optional row headers, aligned values, consistent row actions, and enough spacing for scanability. | 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 labeled pagination nav near the affected results with current page, previous, next, nearby pages, optional first/last or ellipsis, and clear disabled edge states. |
| UX guidance | Use a data grid when cell-level interaction makes users faster and more accurate than opening each record separately. | Use tables when aligned columns help users compare records, find exceptions, audit values, or triage work faster than opening each item. | Use inline edit when users need to make frequent, low-impact changes to one visible property while preserving surrounding list, table, or record context. | Help users move through an ordered result set with a stable sense of position, progress, and returnability. |
| Good UI | An invoice-review grid shows frozen invoice IDs, column headers for Vendor, Amount, Due, Owner, and Status, one highlighted focused cell, two selected rows, a dirty edited amount, and a status line naming the current cell. | A payment review table has the caption June vendor payments, headers Vendor, Status, Due date, Amount, and Action, right-aligned amounts, and row actions labelled by vendor. | 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. | Current page, previous/next, disabled edges, page numbers, result range, and total count are visually clear. |
| Bad UI | A static report uses role grid even though users only read values and ordinary table semantics would be clearer. | Mobile stacking removes headers and turns rows into unlabeled paragraphs. | The edit affordance appears only on pointer hover and is unreachable by keyboard or touch. | Pagination jumps around as pages load or separates controls from the result list. |
| Good UX | A user presses Arrow Right to move from Amount to Due, presses Enter to edit the due date, presses Escape to cancel, and focus returns to the same cell in navigation mode. | A user sorts by Amount descending, filters to Pending, moves to page 2, and the table keeps its caption, active sort, active filter, row count, and selected payment context. | 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. | Users move through pages while query, filters, and sort persist. |
| Bad UX | The grid reports selection but the visual highlight is focus, or focus highlight is mistaken for selected data. | Mobile stacking removes headers and turns rows into unlabeled paragraphs. | A user edits a sorted table cell and the row immediately jumps to a different page before the saved value can be confirmed. | Changing page resets filters. |
| Best fit | Users repeatedly inspect or update many records in shared columns. | Records share comparable attributes that users need to scan in aligned columns. | Users frequently update one visible value or one row property. | The collection has many ordered results. |
| Avoid when | The data is read-only and ordinary table navigation is enough. | The task depends on rich previews, imagery, or uneven metadata. | The edit affects multiple dependent fields or needs a review step. | Users need uninterrupted reading or comparison. |
| Required state | Default navigation state with labelled grid, column headers, row headers or row identifiers, focused cell, and row count context. | Default table state with caption, visible headers, row values, and result count or context. | Read state with displayed value and discoverable edit affordance. | First page with disabled previous control. |
| Accessibility burden | Use grid semantics only for an interactive composite widget with managed focus. | Use native table semantics for tabular data rather than div-only rows. | Give edit, save, cancel, confirm, and dismiss controls accessible names, especially when icons are used. | Use a labeled navigation region. |
| Common misuse | Using role grid on a static table only to make it sound richer. | Using table markup to create page columns or layout spacing. | Using inline edit for high-impact changes that need a review or confirmation step. | Using pagination for a tiny collection. |