How to Best "Lock" an Object in a Collaborative Whiteboard?

[Aaron Davies]

I'm developing a collaborative whiteboard, in which all objects
(shapes, clip art icons, etc.) are synchronized between all
participants in a session. It's working well, but I'm running into a
problem: if two people try to drag the same object at the same time,
nothing prevents them from doing so, and whichever one them lets go
first will have his move be the one that takes effect. (The other
person's client will probably crash at the moment, but that's just
from assertions.) Obviously, some form of locking is needed.

My question is not about the technical aspects _per se_, but more
about the UI aspects: I'm looking for suggestions on how best to
implement this so as not to annoy or confuse the user, while avoiding
the race conditions that tend to come with poor locking schemes.
Several possibilities have occured to me:

Before "picking up" an object, press a button to request a lock from
the server. (This is a client-server architecture, not peer-to-peer.)
If the object is not already locked, the server will grant you the
lock, and you can move it. This is probably the safest, but also the
most annoying and unintuitive, IMHO.

During the "pick up" (i.e., in the mousePressed handler), request the
lock, and until the lock is granted, block any movement of the object
(i.e., in the mouseDragged handler). This will result in the odd
behavior that the object will not move for 500ms or so, then suddenly
start.

Allow provisional motion while the lock status is being determined,
but only "commit" (during the mouseReleased handler) if the lock has
been granted; otherwise, discard the change and snap the object back
to its "official" position. This seems the closest to the way
client-server computer games (i.e., networked Quake, etc.) work, but I
don't know how well that would go over with the users.

Incidentally, both the latter options seem more race-prone than the
first (especially the last one).

Any comments on my ideas, or other suggestions for how to solve this
issue, would be much appreciated. Thanks!

 

[Roedy Green]

Before "picking up" an object, press a button to request a lock from
the server.

that will annoy your users no end. It slows down their process, and
most of the time does nothing practical.

What if you try something like this.

As soon as somebody picks something up, you send a message to the
other end to both change its colour and to lock it. The message may
arrive a little too late. The guy at the other end may gave already
picked it up.

It should then start "going electric" is someway giving a tingling
effect to hint you should let go since the other guy has a hold of it
too. In the meantime it freezes position. If one guy lets go, he sends
a message to the other, which lets him continue. Otherwise the object
is frozen until one guy lets go. Normal social rules of deference
should resolve most conflicts quickly.

If neither lets go, the system should after X seconds break the
deadlock by giving control randomly to one party or the other, or to
the higher ranking one if that is defined.

This is roughly like the difference between polled and Ethernet
collision detect protocols.

 

[Chris Uppal]

[non-existant goups trimmed]

I'm developing a collaborative whiteboard, in which all objects
(shapes, clip art icons, etc.) are synchronized between all
participants in a session. It's working well, but I'm running into a
problem: if two people try to drag the same object at the same time,
nothing prevents them from doing so, and whichever one them lets go
first will have his move be the one that takes effect. (The other
person's client will probably crash at the moment, but that's just
from assertions.) Obviously, some form of locking is needed.

My question is not about the technical aspects _per se_, but more
about the UI aspects: I'm looking for suggestions on how best to
implement this so as not to annoy or confuse the user, while avoiding
the race conditions that tend to come with poor locking schemes.

Some thoughts:

Have you actually tried the option of /not/ doing any locking ? That way the
object would "try" to track both mice, and its position would reflect the last
mouse movement. Its final position would be determined by whoever finished the
drag operation /last/. I suspect (without having tried it) that that would be
the most natural thing to happen. Both users would have an intuitive sense of
/why/ it was behaving oddly, and of what to do about it. Any other solution
would add a confounding layer of unexpected behaviour that the users would have
to incorporate into their mental model in addition to the normally intuitive
notion of "moving something around".

If that doesn't work (i.e. you find that it /does/ confuse and irritate your
users after all), then one option would be to disable the object on the
whiteboards of all users except the one who dragged it first, and for the
duration of that drag. If another user attempts to drag the object too, then
it would just ignore them. Clearly this needs some sort of visual feedback to
show that the object is temporarily unavailable. If two users do start to drag
the same object at roughly the same time then the system would break the tie by
any convenient means. One user would see a drag operation that worked just as
usual. The other would have the same experience they would have done if they
had tried to initiate a drag a fraction of a second later -- i.e. nothing would
happen.

Speaking personally, I can't imagine that any other scheme would /fail/ to
irritate me.

-- chris