Quick Edit caveats or issues?

I am considering enabling QuickEdit on a table view in one of my apps to speed data updates. I’ve played around with it a bit in the development environment “preview” pane, but I sense there’s strong possibilities of problems being introduced since the way it works is a user can make a bunch of various edits to a bunch of records then “commit” them all at once with the “save” button.

I can see a scenario where a user starts QuickEdit by clicking the pencil icon, then proceeds to slowly edit dozens of records on their screen over the course of an hour or more. Meanwhile, other users are editing these records as well. The first user then commits their changes by pressing save, possibly overwriting or otherwise messing up the changes the other users made in the intervening time. In normal use this generally isn’t a problem because the same user could only change one record at a time, so the chances of overlapping edits is minimal.

Am I correct that the above scenario could occur? Any other potential hazards I’m not thinking of? Is there a way for QuickEdit to allow only one change before “commit”/re-sync? Thanks!

1 2 152
  • UX
2 REPLIES 2

Yes, that is exactly what would happen if you had users interacting with your system that way.

Maybe set an action to notify users , “I am editing this” , if the edits are rarely done , or a view in app that display this status message.

Top Labels in this Space