What is the best way(s) to keep the User from getting confused by this ‘Race Condition’?
This could be a really silly question.
One GUI, with a window supporting mouse operations of the objects in that window. Example, the User can move,push etc an object from A -> B. (This will have a impact on a couple of servers so it is a simple operation with a lot of power) If Another User already have done something with that object, the server(s) will take care of conflicts and merges etc. But our original User must be given some kind of feedback, beacuse this can happen at the ‘same time’. (That is, User moves the object in one thread, and Application recv notification in another thread)
This has nothing to do with the code even if one could argue that the recv thread is like a backend storage and the GUI could be a ‘Lock’ when doing the mouse push/drag.
You think you drop Object on B but it actually turns up at B’,B”,C,D(or has vanished).
I don’t like MessageBoxes at all and it is not even possible to pop one for every minor thing. And no, you can’t lock the object to a User when the user starts to drag it.(Think message passing instead)
Maybe one could use some animation that let the User see the Object land on B and then move, animate, to B’,B”,C or D (or evaporate).
I agree you don’t want to lock (or display modal messages) in the GUI when the concurrency occurs. I think can be really frustrating for a user when they don’t know why it is happening.
I think keeping the GUI responsive (as if there was no concurrency) and then when a conflict is detected, when you receive the response from your other thread, you correct the UI. I like the animation/evaporation effect to let the user know that their operation has been overwritten, perhaps with status bar (or similar unobtrusive notification) message to explain the reverted GUI.
If you can add some messaging when operations start, you could provide some additional feed back (again in an unobtrusive way) that there is a potential for conflict with another user.