mathemancer
commented
2 years ago Copied from an earlier discussion:
I'm a little late, but I'm really concerned about a detail here that was assumed in different directions (as far as I can tell), but glossed over: In spreadsheets, if I enter edit mode, then press
Esc(without navigating to another cell by clicking, tabbing, or returning), the cell returns to its original state. It seems like we are not planning to have that, but shouldn't that be the way it works? We don't actually need "undo" for that, and it's very expected by common users of spreadsheets. Kind of a freebie "mini-undo". All we'd need to do is avoid sending any requests until the appropriate navigation has taken place (which we should do anyway).Given that, I don't see the danger of following the expected "type from select replaces cell value with new character". All they need to do to "undo" is escape, and users are pretty familiar with that (I tried both Google Sheets and LibreOffice; they each use that setup).
For "delete from select", It's much more efficient to have a LibreOffice sheets style dialog pop up "delete contents?" than to have to delete each character. This would allow quickly deleting cells without spamming the delete key, but still avoid destroying data without confirmation. If we want to use a confirmation when "delete" (or backspace) is pressed, it might then make sense to also have a keyboard shortcut for users who know what they're doing to "nullify" a cell without confirmation from select (perhaps shared with edit mode).
github-actions[bot]
kgodey
Problem
Keyboard interactions need to be defined for all possible table interactions (including checkboxes, dropdowns, calendars, and other input types).
Proposed solution
We need to create a document with a set of guidelines for the keyboard user interface of Mathesar that will describe the following interactions:
Additional context