CODEWITHSUNDEEP
user-interface
Jonke
Jonke

Reputation: 6533

GUI concurrency

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).

Upvotes: 1

Views: 488

Answers (3)

Jason S
Jason S

Reputation: 189796

I think the bigger question is, why is such an action allowed? If more than one user can do something that involves a significant amount of time (in human-scale perception), it would complicate things significantly to accurately portray interactions between multiple users in real time.

A better way to approach the situation would be to treat the objects is read-only (and hence w/o concurrency problems) until the user claims exclusive use of one or more of them. At that time, an exclusivity lock either succeeds (at which point the user can make whatever changes are necessary) or fails (in which case the user would get a feedback e.g. in a status bar "Objects A,B,D,G have been reserved for exclusive use by other users.").

Upvotes: 0

ninesided
ninesided

Reputation: 23273

In this case I think a warning message telling the user what is happening is the only appropriate course of action. You can jazz up your GUI all you want with animating B moving to somewhere else (or vanishing) but all you'll do is confuse the user further - "WTF I didn't want to move it there!".

edit: I should add that I like the idea of the animating, it was more that I don't think it is enough on its own.

Upvotes: 1

RedBlueThing
RedBlueThing

Reputation: 42532

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.

Upvotes: 1

Related Questions