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

Discussion in 'Java' started by Aaron Davies, Jun 24, 2004.

  1. Aaron Davies

    Aaron Davies Guest

    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!
    --
    Aaron Davies
    lid
    Aaron Davies, Jun 24, 2004
    #1
    1. Advertising

  2. Aaron Davies

    Roedy Green Guest

    On 24 Jun 2004 07:41:14 -0700, (Aaron Davies)
    wrote or quoted :

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

    --
    Canadian Mind Products, Roedy Green.
    Coaching, problem solving, economical contract programming.
    See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
    Roedy Green, Jun 24, 2004
    #2
    1. Advertising

  3. Aaron Davies

    Chris Uppal Guest

    [non-existant goups trimmed]

    Aaron Davies wrote:

    > 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
    Chris Uppal, Jun 25, 2004
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Navodit

    Whiteboard display issue

    Navodit, Jul 7, 2006, in forum: Java
    Replies:
    6
    Views:
    347
    Navodit
    Jul 7, 2006
  2. Replies:
    3
    Views:
    368
    Chris
    Oct 4, 2007
  3. Replies:
    0
    Views:
    361
  4. sapzz
    Replies:
    1
    Views:
    104
    John Carter
    Feb 7, 2006
  5. Gregory Brown
    Replies:
    29
    Views:
    267
    Gregory Brown
    Apr 16, 2009
Loading...

Share This Page