Editable table cells IxD spec #2477
Conversation
fredvisser
requested review from
rajsite,
jattasNI,
atmgrifter00 and
mollykreis
as code owners
| - When inline editing can improve the user experience by reducing the need for separate forms or dialogs. | ||
| - When the table is used in scenarios where data accuracy can be ensured through validation and error handling mechanisms. | ||
|
|
||
| **When not to use:** |
There was a problem hiding this comment.
Should we state some non-goals to make it clear we're not trying to replicate a spreadsheet experience? For example:
- pasting values into a range of cells
- adding/deleting/reordering rows or columns
- advanced edits like formulas or autoformatting values to the expected type
| - Maintain compatibility with existing keyboard navigation behavior | ||
| - Consider resolving [existing ARIA gaps](https://github.com/ni/nimble/issues/2285) | ||
|
|
||
| ### Mouse Interactions |
There was a problem hiding this comment.
It would be good to be explicit about mouse cursor states. Right now the table mostly just shows the arrow cursor but switches to the hand/pointer for interactive things like action menus and menu button columns. Should we indicate when a cell is editable somehow?
|
|
||
| - Editable table cells show the same row hover state as non-editable cells on mouse hover. | ||
| - I.e. When hovering over a row, the action menu button appears. Depending on the table's selection mode, the row may be highlighted. | ||
| - Single clicking editable cell shows the cell focus state. |
There was a problem hiding this comment.
Should this be the case for all tables and cells, or just editable ones? It differs from the current behavior for non-editable tables.
| - I.e. When hovering over a row, the action menu button appears. Depending on the table's selection mode, the row may be highlighted. | ||
| - Single clicking editable cell shows the cell focus state. | ||
| - Double clicking the editable cell transforms the cell into an input control in the focus state. | ||
| - Clicking away from a focused editable cell sets the value and transforms it into the Cell focus state. |
There was a problem hiding this comment.
nit: throughout the document you switch between capitalizing the C "cell focus state" and "Cell focus state". I'd vote for the former but just prefer consistency.
| - Clicking away from a focused editable cell sets the value and transforms it into the Cell focus state. | |
| - Clicking away from a focused editable cell sets the value and transforms it into the cell focus state. |
|
|
||
| ### Out of scope | ||
|
|
||
| The client application is responsible for defining and implementing workflows for adding, deleting, and moving rows, as well as saving data. |
There was a problem hiding this comment.
We probably need to think through situations like if editing a value causes its sort order or grouping to change. Do we have a recommended experience? Are we ok with the value you just edited disappearing off screen? Should we scroll to it? Wait to apply changes until they finish a batch of edits?
There was a problem hiding this comment.
Yeah, it would be nice to know what our UX options are here, and some reasoning behind our preferred choice. For instance, here are two different approaches that the Radzen DataGrid provides:
What isn't made clear in these examples is how changes made in the table component make their way to the "bound" data (if they do at all). One thing you can see, however, is that changes made to the cells have no affect on their current sort position. This would be a pretty tricky proposition for us to "guarantee" if we liked that behavior.
| | Action button | Button to open cell context menu. Appears on row hover or keyboard focus | | ||
| | Editable cell control | Text or numeric control that supports entering or editing cell data | | ||
|
|
||
| ## Behavior |
There was a problem hiding this comment.
What's the scope of "editability"?
- Do apps mark the entire table as editable? Specific rows? Specific columns? Specific cells?
- Does every column type support editing? For pretty much everything except text columns that opens the door to questions about what the editor should look like and what kind of validation is available.
|
|
||
|  | ||
|
|
||
| #### Error State |
There was a problem hiding this comment.
Do apps need to be able to do their own validation and explicitly put a cell in an error state? Or is the table completely in control of the error state?
There was a problem hiding this comment.
I think this is ultimately a discussion for the HLD for the implementation of this feature. My preference, at the moment, would be for our error APIs to be very general provided via the table, and not by various columns (i.e. the table is not in complete control of the error state, it is managed by the user via APIs provided at the table level).
Pull Request
🤨 Rationale
Clients would like to use the Nimble table to allow their users to interactively edit tabular string and numeric data. This IxD spec proposes a set of interactions that builds upon the existing keyboard navigation work.
👩💻 Implementation
Defined Figma wireframes and IxD spec
🧪 Testing
N/A
✅ Checklist