UI race conditions

I’m sure this has happened to you once in a while: You’re doing several things at the same time on the computer, e.g. perhaps you click to launch some slow program, and while that is launching you go over to your web browser to kill a few seconds reading something. You try to click a link, but oops – just when you were about to click it, the other program finishes loading, and you have accidentally clicked something in it.

A variation of that happened to me just today. I decided to try Yahoo Chess (and I’m proud to say I won my game). You enter a room, e.g. the beginner room, and then there is a list of tables; you click to join a particular table. But every few seconds, the list of tables keeps refreshing, so the button you were about to click could have suddenly disappeared – or worse, turned into a button for a different table you didn’t intend to join.

What’s interesting to me (I don’t know why, maybe because I’m a geek) is that this is a real-life version (if using the computer is considered real life) of the sort of race condition horribleness we all run into when we write multithreaded code. Thread 1 tries to increment a variable, but oops, thread 2 sneaks in there and changes it! Urgh.

Does this ever come up in real real life (as opposed to real life while using a computer)? Yes, of course – one good example is the awkward little dance we all do once in a while when trying to walk past someone else who is coming the other way. Both step to the right, oops, both step to the left, oops!

In the case of computer UI, I can think of two ways to alleviate this problem (I am not claiming any incredible insight here, I think these are pretty obvious):

1. Animation can help. E.g. in the example of the Yahoo Chess list of tables, when the list redraws, rather than having it redraw instantly as it does now, maybe the individual rows of the list should slide to their new positions. That gives a person’s eye the visual feedback, “Wait, don’t click just now.” Animation is sort of the computer equivalent of what usually helps avoid this problem in real-life scenarios: Most of the time, the fact that you can see the other person moving and adapt to their movement gives your brain enough time to avoid a collision.
2. Maybe disable the mouse (and keyboard if appropriate) for a fraction of a second, e.g. maybe ¼ second, immediately after a change, e.g. immediately after the list of chess tables was updated, or immediately after a program opens a new window or dialog.

Of course, it would often be appropriate to combine both of those techniques: disable the mouse, do the animation, and then re-enable the mouse. If done that way, the mouse could be immediately re-enabled when the animation was done – no need to wait for ¼ second more after the animation is done, because the person has already had sufficient time to process what is happening and avoid an accidental click.

What do you think? I’m sure none of this is terribly original – I imagine lots of research on this topic has been done. I just haven’t come across it. (Sometimes blogging scares me, because the Internet is so huge that no matter how original a particular thought of mine might be, the odds are extremely good that someone else has already had it, and has said it on the Internet, and thus it’s already in the Google index, and so should I really bother. Reminds me of a joke that A. Whitney Brown made many many years ago in Saturday Night Live: “There are a billion people in China. Think about that. That means if you’re a one-in-a-million kind of guy, there are a thousand other people exactly like you.”)