Keyboard UI for SearchKit in-place editing
Overview
As of CiviCRM 5.66, SearchKit Displays offer "in-place editing" of some fields. The user interface requires a lot of clicking.
Current behaviour
To "edit in place", the user must
- click on the editable field (the resting version of the field turns into a single-field mini-form)
- click within the form control to edit the field's value; depending on the form control, the keyboard may/must be used to manipulate the value
- click a green checkmark button (the value is saved via an AJAX request and the field goes back into resting state) or a red "x" button (the field returns to resting state without any changes being applied); this step may also be accomplished using the keyboard
This process must be repeated for each editable field in every row.
Goal
Make it possible to perform edits within SearchKit Displays without any use of the mouse.
Questions
Design
- What should the UX be, specifically? I.e. which keystrokes should map to which behaviors?
- Should multiple editing modes be available? (e.g. single-field form, single-row form, whole-result set form)?
- How can the UX be accessible to users with various abilities?
Some possible design dimensions:
from | to | |
---|---|---|
emphasis on display | ... | emphasis on editing |
edit one field | ... | edit many fields fluidly (office app spreadsheet-style interface) |
civicrm-specific ux | ... | ux paradigm borrowed from elsewhere |
one-size-fits-all ux | ... | granular control over the ux for each column in each search display |
hard-wired ux | ... | ux can be modified by hooks/events |
Some ideas that have already been floated:
- Tab/Shift-Tab to navigate between editable fields of the existing single-field mini-form style (@noah in this PR)
- Excel-like spreadsheet UI (@civiuser in this comment)
- "Edit in place" action in the Display's "Actions" menu, which would switch on editing mode for a set of rows; save via "Save all changes" button (@civiuser in this comment)
- Replicate current "profile edit" UI ((@civiuser in this comment)
- add a new row to the table (e.g. Create a new entity) inline (@colemanw in this chat thread)
- (overlapping discussion) adding some minimal Aria controls to new FB/SK elements where there aren't native html elements (e.g. accordions/tabs) (@nicol in this chat thread)
Development strategy
- What is possible to implement with the least effort/least change to current code (low-hanging fruit)?
- Should we grab that low-hanging fruit even if we haven't organized a larger UX plan?
- How big should we be thinking — i.e. should this discussion extend to FormBuilder as well?