Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wait until user is done editing a cell before saving #928

Closed
seancolsen opened this issue Jan 3, 2022 · 4 comments
Closed

Wait until user is done editing a cell before saving #928

seancolsen opened this issue Jan 3, 2022 · 4 comments
Labels
affects: ux Related to user experience good first issue Everything in "Help wanted", PLUS being relatively easy and straightforward to implement. help wanted Community contributors can implement this ready Ready for implementation type: enhancement New feature or request work: frontend Related to frontend code in the mathesar_ui directory

Comments

@seancolsen
Copy link
Contributor

seancolsen commented Jan 3, 2022

Current behavior

  1. Double click a cell to enter edit mode.
  2. Modify the value by typing something new.
  3. Wait 1 second.
  4. Expect nothing.
  5. Observe the value of the cell is saved.
  6. Press Esc.
  7. Mode changes from edit to select.
  8. Expect the cell value to be its original value before edits began, because I pressed Esc.
  9. Observe the cell value to be changed.

Proposed behavior

  • Follow the same UX that spreadsheets use. LibreOffice Calc and Google Sheets both behave as follows... The cell value does not get saved until you leave edit mode with one of the following options:

    • Enter
    • Shift+Enter
    • Tab
    • Shift+Tab
    • a click outside the cell

Notes

  • I think this is relevant to our recent discussion about data integrity during editing. If our users expect the same behavior that I expect, then they might be annoyed that pressing Esc did not "undo" (so-to-speak) the edits they made to a cell.
@seancolsen seancolsen added status: draft type: enhancement New feature or request work: frontend Related to frontend code in the mathesar_ui directory affects: ux Related to user experience labels Jan 3, 2022
@seancolsen seancolsen added this to the [06] Working with Tables milestone Jan 3, 2022
@kgodey
Copy link
Contributor

kgodey commented Jan 3, 2022

This sounds good to me.

@seancolsen seancolsen added ready Ready for implementation and removed status: draft labels Jan 3, 2022
@seancolsen
Copy link
Contributor Author

Thanks @kgodey. I'm marking this as ready now that we have support from one other person.

@ghislaineguerin @pavish you two might still like to weigh in if you have any concerns here.

@seancolsen seancolsen added good first issue Everything in "Help wanted", PLUS being relatively easy and straightforward to implement. help wanted Community contributors can implement this labels Jan 3, 2022
@seancolsen
Copy link
Contributor Author

#1080 seems to have fixed this, so I'm closing it.

@pavish I noticed you marked that PR as "related to" this issue instead of "fixes" this issue. Is that just because of the difference in behavior with regard to the Esc key? (If so, I'm planning to open a separate issue for that where we can discuss it.)

@pavish
Copy link
Member

pavish commented Mar 2, 2022

@seancolsen Yes, I left it open to discuss the behaviour of esc key. I'm fine with opening a separate issue for it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
affects: ux Related to user experience good first issue Everything in "Help wanted", PLUS being relatively easy and straightforward to implement. help wanted Community contributors can implement this ready Ready for implementation type: enhancement New feature or request work: frontend Related to frontend code in the mathesar_ui directory
Projects
No open projects
Development

No branches or pull requests

3 participants