Why do users click randomly and rapidly when an application hangs?

Question

This question came to me when I witnessed a collegue's behaviour on an application freezing due to a large operation. And it's something I've certainly done myself.

An app freezes for more than a couple seconds and we start clicking at it. Repeatedly. Often in no particularly meaningful place, as if that is going to somehow "wake it up." Even more bizarrely, users who have learnt that all those clicks will queue up and fire off when the program responds again will specifically choose to click in an area that has no known interactive ability (like an empty part of the chrome).

So users are clicking when they know it will have no effect and in areas that they know has no function, in hope that it will bring their program back to life. We all do it. But why?

Also, it seems the longer a program stops responding, the more random actions we start to throw at it. After a few seconds, it's clicking. Soon after, its keyboard tapping (the spacebar seems a favourite; but conversely people seem reluctant to try the Enter/Return key). Then the Escape key in heavy rapid fire (power users may break out the Ctrl-Alt-Del or other combos at this point).

Until finally, we reach the guaranteed fix-all of unresponsive programs [citation needed]: kicking the tower.

Why do we do this?

---

EDIT Excellent answers all-round! Can only choose one accepted, but I've upvoted lots of others too.

Answer 1

I believe the reason users click repeatedly is because they are accustomed to anticipating an update every time they perform an action and the clicking allows to find out if there is an expected behavior from the app or at least some reaction which informs them about what they could do.

Also this funny image might give an answer :)

With regards to the space bar key,I think it has to do with the large size of the key (Fitts Law) and the ability to easily click it again and again in the hopes of getting a reaction. With regards to the enter key, it is generally used as an affordance to move to the next step and users might hope that repeated presses of the enter key will help get past this troublesome stage and load the next stage which is hopefully working.

Finally the escape key is pressed as it has become the denotation to escape from what the user is doing on the a computer or the close something and hence an attempt to escape from this situation. To quote this article which talks about the psychology of the escape key

The button dates to 1960 and was created by I.B.M. programmer Bob Bemer. It was intended to help programmers switch from one computer language to another. Later, the key evolved and literally became an escape tool: users now press it to stop what function they’re engaged in, no matter what operating systems and brands they’re using. The naming of the key was likely meant to suggest a sense of panic. I personally think the language is effective: it’s powerful and to the point, somewhat fanciful and a little dreamlike–and definitely not as alarming as a button that would scream “help!”

Also to quote this NY times article about the ESC key design

Why “escape”? Bemer could have used another word — say, “interrupt” — but he opted for “ESC,” a tiny monument to his own angst. Bemer was a worrier. In the 1970s, he began warning about the Y2K bug, explaining to Richard Nixon’s advisers the computer disaster that could occur in the year 2000. Today, with our relatively stable computers, few of us need the panic button. But Bob Frankston, a pioneering programmer, says he still uses the ESC key. “There’s something nice about having a get-me-the-hell-out-of-here key.”

Finally the control +alt+delete option might be used in an attempt to shut down the application and start afresh.

I believe the user's mind flows in this pattern

let me check if there is a reaction (click stage) --> let me try to get past this stage (enter key) --> let me kill this application at the local level (ESCkey stage) --> let me shut this application at the root level or computer level (control-alt-delete stage)

Answer 2

People tend to think of their interface in physical terms. You think of a 'window' not a 'rectangle of lights on a matrix'. And so, when an application hangs, people revert to interacting with it in the way they might do with a physical object when it stops working.

Shaking things seems to be the way that many people try to 'fix' a physical object that isn't working, and the digital equivalent to this is to beat it with your clicking might.

Additionally in times gone by (thankfully), sometimes a click wouldn't be picked up by the computer for whatever reason, and so clicking again when nothing appears to be happening often solved the problem, because the computer would then often pick up the click. So the clicking was a way of making sure that you had indeed clicked, and it had been picked up. The fact that this often worked re-enforced the behaviour and so people 'learnt' to do it to be sure that it wasn't the click that was missed or at fault.

Answer 3

I recently read something about this called Extinction Burst from the book You Are Not So Smart. Here is the chapter that I'm talking about and this is an excerpt from Wikipedia:

Take, as an example, a pigeon that has been reinforced to peck an electronic button. During its training history, every time the pigeon pecked the button, it will have received a small amount of bird seed as a reinforcer. So, whenever the bird is hungry, it will peck the button to receive food. However, if the button were to be turned off, the hungry pigeon will first try pecking the button just as it has in the past. When no food is forthcoming, the bird will likely try again ... and again, and again. After a period of frantic activity, in which their pecking behavior yields no result, the pigeon's pecking will decrease in frequency.

Another excerpt explaining the potential benefits of such a behavior:

The evolutionary advantage of this extinction burst is clear. In a natural environment, an animal that persists in a learned behavior, despite not resulting in immediate reinforcement, might still have a chance of producing reinforcing consequences if the animal tries again. This animal would be at an advantage over another animal that gives up too easily.

Answer 4

In windows at least, a window will only 'grey out' and have its title suffixed with (Not Responding) after it has received new messages in its queue. A build up of messages is how windows detects a busy UI thread.

Speculatively, this may be why users do it on windows - to probe the system and assess if the application is frozen or the entire OS has frozen.

Answer 5

I'm guessing this is related to the tendency to re-press the call button on an elevator, or the "Press button to cross" button at a crosswalk: humans are impatient, and we find it hard to just wait idly for a response. In the case of a frozen program, this frustration/impatience is exacerbated by the lack of feedback and lack of trust.

Answer 6

Computers are very complex things and users learn behaviors they cannot necessarily explain themselves.

I remember reading about how computers in the '90's or so (I believe) actually WOULD sometimes operate faster when the mouse was moving because of interrupts being fired off by the mouse that would actually cause the process the user cared about to complete sooner. How many people would have known that? Probably a number statistically equal to zero. But I recall most power users doing this as a matter of habit when waiting on a program.

I would put my money on the behaviors you describe as being learned behaviors that have had positive results in the past. I'm sure some or even most have no causal link to the positive result (I happened to hit the spacebar just as the process completed, for example), but I would bet that some of these odd behaviors actually have caused better results than doing nothing.

Finally, some of these actions are also basic troubleshooting to verify that the application truly is non-responsive, which then leads to reloading and getting back to work.

Answer 7

One possible reason why users generate events into a freezing application is that they have the sense that the events are being dropped, rather than queued. This may be basic psychology. But the intuition is actually right, because badly loaded systems can in fact miss events, and I will argue below that if they are GUIs, they actually have to.

One familiar example is Firefox. When the browser is busy executing a script, then it actually loses characters if you try to type into some input fields. If you do not repeat the entry of some characters that have not appeared, they will not appear if you simply wait; they went into the bit bucket.

Queuing every event under load has downsides, because the user has no way to manage the queue. Mistakes get queued also, with unwanted results when the system gets around to servicing the events.

There are issues in queuing GUI events, which make it nonsensical to retain long queues of events. For instance, suppose we indicate to the system that I want to move a window, and then to click a button on that window, but the system is slow, and so these events do not actually happen until later. When the events are processed, should the click be referenced to the moved window? Or should the click be referenced to what was displayed under the cursor at the time the click was issued? The proper solution to the ambiguity is to drop the click event.

So:

1. sensibly designed graphical interfaces have to drop events such as clicks when the system is unresponsive, because delayed processing of queued events will lead to chaos.

2. this means that if a click does nothing, it has been dropped into the proverbial bit bucket, and the action has to be repeated in order to take place.

3. users are not provided with adequate feedback which indicates the system's readiness to handle an event such as a click: the only way to know whether an event will be accepted is to try it. (Though some user interfaces change to special cursors, or gray out parts of the UI, etc to indicate nonresponsiveness.)

4. therefore, users repeatedly click until a response occurs: rational behavior.

The real question is: Why do people click rapidly when an application has given clear feedback, such as a spinning hourglass cursor, or greyed-out window, that it is not currently accepting events.

This could be a combination of multiple factors. One is the basic instinct to just prod at something that doesn't respond, as if it were a living thing that needs to "wake up". It may be part learned behavior, from having used systems that do not have such a clear indication. It may also stem from not fully understanding the indication that the application is busy, or from the belief that clicking does in fact help. (The hypothesis that clicking helps cannot easily be disproved; there is no way that the user can be certain that the application would have recovered from that particular situation just as quickly without their rapid clicking efforts.) In fact, those users might be right: the operating system scheduler can take into account the user's impatience (measured by their clicks), and arrange to give more priority to the user interface tasks! And if it does not, perhaps it should! Furthermore, applications should be written so that all lengthy tasks are modeled as background process that allows the UI to remain responsive, and not as being in the same event processing thread so that the UI blocks.

Answer 8

This is a question which I came across when I was at University and working with GUI Heuristic expert.

Basically the users click when an application is unresponsive to ascertain if the application is really unresponsive or it is just that they havent interacted with the system as expected. As most of the places where a click will make sense will yield unwanted results - hence most users would test this by clicking on the empty space.

Regarding space bar - I think there are a few different opinions with regards to this. One is that it is the largest key on a keyboard and closest to you and often this is reason why that is tested.

When an application hangs or becomes unresponsive then by each second the application stops interaction or doesn't convey to the user that the application is working on something - the user's frustration level increases exponentially. You need to look at Sheffield uni phd thesis for further details and evidence of experiments undertaken by them.

Lastly, alot of times, when you click esc or combination of keys like ctrl + alt + del, then systems start responding as the system handles these keys as opposed to application. Typically users do not really care - and they think if particular key can do this in certain application - there must be some other key in this application and hence often starts tapping every key on their keyboard. Yes these actions and keys are queued up but with Win 7 and Win 8 - the queue has been reduced and if you grow it anywhere beyond this queue size - then windows tries to terminate the application - giving you as a user the option and responsiveness you are looking for.

Answer 9

I guess the best reason was already stated (user's anticipation for an update in the app after a click/any interaction with the app), but the question reminded me of a friend of mine:

The app was frozen when I asked him - "why do you rapidly click on the app?"

His answer was: "I believe the OS gives priority to apps I interact with" (in his case it was windows xp). He thought that by clicking on the app the OS will give it more resources, allowing it to unfreeze.

Answer 10

Sometimes (especially with heavily-loaded web apps) the request associated with a mouse click gets lost. Maybe it got round-robin routed to a server that was going down. In any event, performing the click a second time often resolves the problem, whereas the user may have waited forever on the doomed request, for a response that would never come.

Damned-if-you, damned-if-you-don't: if a user sat there forever waiting on a busy cursor, someone may well ask why this daft user doesn't give up and try something else.

As for the behavior of the increasingly frantic clicks, it's symptomatic of taking advantage of the limited choices you have available to solve a problem. A developer may examine a logfile, force thread dumps, etc. to directly investigate and address the actual cause of the problem, but typical users have very limited options, i.e., give up, or keep clicking.

Answer 11

For Windows Vista and up, typically if you click after the program is not responding, it pops up the window asking to restart/end program.

For XP, you have to get to task manager for that, so if your users are XP users, I am guessing that it has a psychological reason behind it such as deferred misplaced aggression from disappointment of hanging computer applications.