Editable table cells IxD spec

[fredvisser]

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

• I have updated the project documentation to reflect my changes or determined no changes are needed.

[jattasNI]

We probably still need a discussion about the interactions for entering the edit state and navigating between cells, but capturing some other feedback in the meantime.

[jattasNI]

Should this be the case for all tables and cells, or just editable ones? It differs from the current behavior for non-editable tables.

[fredvisser]

This should be the case for all tables and cells… Please let me know what is inconsistent with the current behavior for non-editable tables.

[jattasNI]

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?

[atmgrifter00]

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:

• In-line editing
• In-cell editing

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.

[fredvisser]

The least disruptive option is keep the new edited value in the same relative location after completing the edit, even if the column sort would move the row.

If that's not possible, and the row needs to immediately sort to the correct position, some affordance to indicate that the row is moving would be helpful. E.g., an animation of the row moving to it's new location. We shouldn't scroll to the new position.

[jattasNI]

What's the scope of "editability"?

1. Do apps mark the entire table as editable? Specific rows? Specific columns? Specific cells?
2. 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.

[fredvisser]

Specific columns and we'll need to start with text and numeric, and add select and checkbox later. We shouldn't need to support every column type (at least right away.)

[jattasNI]

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?

[atmgrifter00]

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).

[fredvisser]

Requirements-wise: Client apps need to be able to specify their own cell validation rules (e.g., max/min/invalid characters/format) at the column level and they should get that feedback while editing the cell.

[msmithNI]

Can we cover mousewheel behavior in this section? Due to the table's virtualization we need to be explicit about the behavior we want.

If a cell has Edit focus (potentially with an edited cell value), then the user scrolls the mousewheel, is that equivalent to committing or reverting the edited value?

[fredvisser]

I'd strongly prefer that we maintain the edit state even if the cell scrolls out of view, such that it can scroll back into view in the same state. While it's true the menu button dropdown closes on scroll, setting or reverting an edited cell value is a much more aggressive action in response to something as simple as scrolling.

Do we have any options for persisting this type of state as the cell is scrolled out of view?

[fredvisser]

If that proves too expensive, we should prevent the table from scrolling while a cell is in edit focus.

[msmithNI]

Discussed this a bit with Fred today. Maintaining an edited cell as 'still being edited' after a scroll will probably be difficult due to virtualization - as soon as you scroll more than 1 row's height, even if the row is still visible in the table viewport, the row elements have been re-bound to different data at that point. We can remember which row/cell was being edited (and the current edited cell value), but we'd need to reapply that to a new row visual again (since now a different row visual represents the data row that was being edited, after the scroll), and there might be visual artifacts/ visible flashing if we do that.

Assuming we can prevent mousewheel scrolling the table while editing a cell, that's probably the simplest approach (least work to implement).

[msmithNI]

In Meyer's prototype, once a cell has been clicked once (and focused), a 2nd single-click enters edit mode at that point. We should decide if we like that behavior, or if it should still take a double-click when a cell is focused. (Assuming we keep the cell focus state for mouse-clicked cells)

[fredvisser]

Current proposal is to immediately enter edit focus on single-click of an editable cell.

This resolves some issues with nested focus states (action menu within a focused cell), and reduces the clicks required to edit the table, but we should discuss any other drawbacks.