Just had a long user experience discussion with coworker Marc about concurrency problems in settings.
His argument:
Everything on a screen should be atomic.
My argument:
Concurrency should be resolved as often as possible without forcing the user to make a choice.
Alice opens up our settings application.
Bob opens up our settings application.
Alice changes the background color on the “Quantity” column in column view “Alpha” and then save it up to our server.
Bob reorders all of the columns in the Alpha column view to the order he thinks is appropriate for their group.
Bob saves the column view up to our server.
Marc argues that Bob’s settings should be rejected and he should reload in Alice’s settings, then redo his work and save up to our server.
I argue that Bob’s settings don’t conflict with Alice’s because column order is a property of a column view, not of the columns themselves in the column view. Caption is a property of the individual column.
Consider that column order has no meaning for an individual column outside of a column view collection – this is true no matter how you represent these entities in a database.
Bob doesn’t care about Alice’s caption change, and we should avoid bothering him about it.
If he’s changed the caption of the column as well, then we have a conflict. Bob should get notified that Alice made a conflicting change, we should tell him why it conflicts, and then he should get a choice to either abandon his change and accept hers or overwrite her change with his.
Bob wants to change the order of the columns in this column view. Alice wants to change the caption of a column in that column view.
Because what they want does not conflict, we should not get in the way of what they are trying to do. We should just get it done, and let Bob know that Alice has updated some settings.
But wait, there's more
This work by MattK is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International