In my experience, I simply do this as a way of polling the app to see whether it's still working. A working app will often have the main gui loop running so you'll be able to see the GUI respond to clicks, focus changes etc. If the app doesn't do that, it's a sign that it's blocked waiting for something (network or file access, for instance). Experience then informs me whether it's normal for a certain app to behave in this way, and whether I should wait longer to let it finish or just kill it off.<p>So for instance, a long time ago I was an Opera user on Linux. In certain cases some bug would cause it to go on a memory eating rampage which would slow the machine to a crawl of swapping if I didn't react quickly enough to kill the process. I developed a very good sense at "smelling" when this was about to happen, so I could react quickly enough to kill the process before just switching over to the terminal would take something like a minute.
When I do this it's because I'm irritated that it's hanging and I hope that my clicks will queue up and punish the insolent program. Kind of like sentencing it to 2,000,000,000 cycles of hard labor.
In Windows, moving the mouse about can actually prevent certain processes from hanging.<p>eg.<p><a href="http://support.microsoft.com/kb/168702" rel="nofollow">http://support.microsoft.com/kb/168702</a>
My 17 month old plays with several numbers and letters apps on my Surface. If the app hangs even slightly, she taps over and over until the app reacts again. I find it interesting that even she does the rapid fire tapping as well.
A psychologist friend whom I just asked about this said that in animal models of behavior, this is called an "extinction burst." Animals that have been conditioned into a behavioral response through operant conditioning will often be found, after a reward is no longer given for the conditioned response, repeating the response often and with random timing. Sometime human beings are trained by their computers rather than exercising volitional control over their computers.
If someone was standing in front of you, and you asked him a question, and after a 30 seconds didn't get a response, would you just stand there, or would you prompt him again to figure out why he didn't answer? Maybe say it louder, because he didn't hear the first time. Or perhaps he's confused, and you can clear that up by asking your question in a different manner. You wouldn't just stand there waiting forever, however.<p>People begin clicking, typing for the very same reason. You're trying to figure out why a response wasn't given. You click again to make sure that your click registered the first time. If it wasn't the application will now respond. If it was, now you're trying to decipher whether the application is hung or not, or perhaps something did grab focus, like a pop behind, as a commenter suggested.<p>I guess I don't find this a particularly interesting investigation of human behavior. What's the alternative for the person? Sit there and wait forever?
I've been using computers for over 20 years and believe me, every one of these actions has worked at some point.<p>Clicking might get the application into another state, or at least get the operating system involved in killing it of. Pressing return might answer hidden input fields (wrong focus, broken modal dialogs). Pressing escape might help exit one of these. Pressing ctrl-alt-del gets the OS involved... etc. etc.<p>What UI experts ignore, is the fact that a crashed/freezing application is no longer in a well-defined state. Therefore the apps logic no longer applies.
An analogy that comes to mind - physical exercise. When you are stopped doing exercise (e.g. running at a traffic light), people often will jog in place. Obvious reasons - keep heart rate from large deltas, muscles warm/responding well, etc.<p>If you watch competitive PC gaming, you will notice that even professional gamers will often 'spam' their hotkeys in low activity periods, typically the beginning of games. Some people claim that it is simply for actions-per-minute stats, but I could see it as some kind of setting of mental/physical cadence.
This highlights what is in my opinion one of the biggest failings of modern operating system/GUI design (this and modal dialog boxes, but don't get me started). We are used to interacting with things in a physical world. When they fail it's their functionality that fails not their interface. If your DVD player breaks you can still push the buttons. Even if your computer breaks you can still press the keys, but when GUI apps break the interface itself stops working, and given all the work that has gone into helping you to believe that GUIs are just extensions of reality it's like reality stopped working.<p>I have always felt that GUIs should run in their own nonblocking thread at the system level so that you can still use the interface to interrogate the functioning of the program. I try to do this in my own programming. Even if the brains die, buttons still push, the focus still changes the menus still drop down, no bazar interaction queueing and if it's expectd behavior the app could respond by providing info like a waiting on IO light. If it's unexpected then the lack of response would be telling. As it is no information is communicated.
People want to feel they have some level of control over a negative situation. This is why people will take a way home that is 15 minutes longer to avoid a 5 or 10 minute delay caused by a traffic jam. It's also the reason people are sometimes afraid to fly but not afraid to drive, even though it's generally far more risky.<p>Perhaps clicking repeatedly is an outlet for trying to control an application that has developed its own agenda.
I remember that whenever a printer crashed at my university, its queue would fill up as people kept queuing additional copies of whatever document they were trying to print.<p>Thankfully the permissions on the print queue were loose enough that we lay users could purge the impatient people's documents from the queue rather than waiting for the printer to churn through their duplicate requests.
Actually this makes a little bit of sense these days on linux (or maybe it's gnome-specific?) An application that's unresponsive will just hang there, but if you try to interact with it and it doesn't respond you'll get the "do you want to kill it" dialog. Of course that's important only in case you really want to kill it - it won't fix anything.
Mildly related, and mildly humorous: After the last update to my phone I've started randomly experiencing dips in responsiveness. It might be doing GC or some other heavy tasks, but it remains in low (not zero) responsiveness for several seconds.<p>Whenever I experience it, I start tapping the back-button furiously, in a quick steady rythm, causing a pileup of tap-events. These will be dispatched in batches, each tap causing a small buzz in the vibrator engine. When the buzzes start happening at an even pace, I am back to having a responsive phone.<p>The purpose of this behaviour is to know when my phone is usable again, but it kind of evolved from me just wanting to see if I could provoke it or whatever. People are curious things.
I used to do this in the OS 9 days, but these days of no swapping (lots of RAM and SSD) and OS X where the window manager never hangs and we have the pinwheel cursor for apps that stopped responding to UI events, I've stopped doing it (at most I'll move the cursor around in circles frantically to ensure there's no hardware/disk freeze, or scroll up/down to see if there's one of the frequent Safari WebProcess freezes).<p>Do any other OS X users do this, or is it limited to Windows/Linux? Is it due to poor feedback?
It's the digital form of "Percussive Maintenance" - <a href="http://en.wikipedia.org/wiki/Percussive_maintenance" rel="nofollow">http://en.wikipedia.org/wiki/Percussive_maintenance</a>
Sometimes I do it to try and get the program to crash instead of just hang. Software is pretty stable these days, so sometimes it feels good to see a complete crash to the desktop.
I think a better question is "why don't we harness that behavior to make our apps 'feel' more responsive?" If we make UI for humans and humans act like that then why not give them a reactive but non-functional button to click to "make it faster"? While waiting for a light to change at a crosswalk I feel a lot better if I can hit a button on a pole instead of just standing there feeling helpless. Even if I know the button won't do anything.
For me its:<p>1. Click on chrome to see if the window responds<p>2. Click on enter to make sure any hidden modals are accepted<p>3. Alt+F4, die bastard die<p>4. Ctrl+Alt+Delete, kill it with fire
I suspect many people do this for the same reasons that we yell at other drivers from within the sealed environment of our own car. There's very little chance that the other driver will hear us, but it provides an outlet for frustration.
Possibly related to operant conditioning with intermittent reinforcement.<p><a href="https://en.wikipedia.org/wiki/Reinforcement#Intermittent_reinforcements" rel="nofollow">https://en.wikipedia.org/wiki/Reinforcement#Intermittent_rei...</a>
In India I found that there's a widespread belief that refreshing the desktop (on Windows machines) makes things go faster, and some people do so repeatedly while waiting for slow computers to load heavy programs.
Reminds me of the entry <i>plokta</i> in the jargon file so it must go back to the beginnings of time:<p><a href="http://www.retrologic.com/jargon/P/plokta.html" rel="nofollow">http://www.retrologic.com/jargon/P/plokta.html</a>
Quite a few very entertaining responses. Unfortunately the clicks aren't "random" as indicated in the question; therefore this is not an easily tapped source of entropy.
i click and highlight and such out of boredom, similar to how i tap my fingers when waiting or thinking. if i click while a program is 'hanging,' it isn't out of frustration or expectation of a response. people actually do that for those reasons?
Misclicks are common, and it's normal to click two or three times to get something right - how many times have you mousedowned on a button, but had the pointer move off the button before mouseup?<p>Also, very occasionally, an application will respond to a click where it previously wasn't, and faint hope is better than no hope.