On Interruptions: Theory and Practice
This past week, I was given the assignment of conducing a brief lit review of HCI research on interruptibility. I was asked to comment and critique the work, and give my own suggestions for future directions for research.
Part I: Gone
I’ve traditionally been a pretty interruptible person: I get Growl notifications when I receive new emails and tweets, I get push notifications on my phone of Twitter mentions and direct messages, and my phone is always on me, subjecting me to potential phone calls and SMS messages. On top of that, I have a work-to-“reward surfing” ratio that is probably approaching 1.25-to-1 (although I haven’t done any work to confirm this with Slife or RescueTime). It’s pretty bad.
Partly so I could finish the paper in a reasonable amount of time, partly as an experiment in uninterruptibility, and partly to prove to myself that I wasn’t addicted to the constant stimulation of communications and information technology (“I could quit if I wanted to…I just don’t want to.”), I decided to take myself entirely off the networked communications grid for a large block of time.
I had toyed with this tactic before, abstaining from email and Twitter for 30 or 60 minutes at a time, but addictive behavior suffers from a slippery slope problem, so I inevitably was able to rationalize leaving Mail.app open in the background, convinced its interruptions would be negligible, which is, of course, a fantasy.
And so: my phone was in airplane mode in my bag; everything but the Airport, volume, keyboard (I use Dvorak), and Dropbox menu extras were gone, including the clock; Growl was stopped; the hot corner for Dashboard was disabled; the only apps I had running were Preview (gotta read), Pages (gotta write), and Safari (gotta find what to read); browsing was allowed for the sole purpose of finding and downloading academic papers, which meant primarily the university and ACM libraries. The goal was to block out any external information not directly related to the completion of the paper. I still kept approximate time, but the old fashioned way: by the clock tower.
And so I read and wrote, from 8:15 to 17:15. (Ok, I had lunch.) And the incredible thing was: it wasn’t that hard! By setting explicit rules up front rather than allowing myself to decide when I’d “earned” a break, I was able to stick to it because I gave myself no option, no opportunity to start sliding down that slippery slope. If the temptation to check something arose — which was surprisingly infrequently — I was able to refrain because I knew how angry I would be with myself later.
Another observation about this experience is that by not subjecting the mind to a constant bombardment of information, it is able to stay calmer and quieter, which, as I know because of the sabbath, can be incredibly refreshing.
Summary: it is possible to disappear for a day, it is a very productive tactic, and it feels very rewarding.
Part II: Supply-Side Interruptions
I read four studies on interruptibility (three from ACM/SIGCHI, one from ASIS&T). I also read two essays on the subject: a wonderful work by David Kirsh aptly titled A Few Thoughts on Cognitive Overload, and the classic chapter from Yoshiro Miyata and Don Norman, Psychological Issues in Support of Multiple Activities.1
I came to the following rather disheartening conclusion: the current vein of HCI research into interruptibility and notification ignores a substantial body of work, including some by the very authors I take issue with, that suggests that in order to be truly productive, people need uninterrupted blocks of time that are at least 15 minutes long; some say up to two hours. Yet the systems they are devising and testing, the aim of which is to delay interrupting notifications until appropriate “break points”, delay on the order of just 90 seconds. While there is some evidence to suggest that this might be helpful, I feel the real issue lies elsewhere, and is being ignored by the HCI community.
The demands that social norms have placed on users have led them to believe they are more capable of handling interruptions than they really are, and they expect their computing environments to satisfy that belief. Under the current interruption regime, people are never given a chance to engage in Miyata and Norman’s task-driven processing (a state in which a person is so engrossed in an activity that they essentially block out all external stimuli); an entire generation has been groomed to be entirely interrupt driven (a state in which a person is very sensitive to external stimuli, i.e., easily distractible), and until interruptions start coming at a much slower rate, people will continue to suffer from an inability to complete tasks uninterrupted.
While I can appreciate what the current work is trying to accomplish — making interruption more manageable and palatable — there is a failure to recognize that there are two sides to the HCI equation: human and computer. It is unquestionably easier to engineer computers than it is to engineer humans, yet the human mind has adapted, albeit for the worse, to the demands placed on it by computers, and those of us in the HCI field must take more drastic action to begin to reverse the chaotic, interrupt-driven, anxiety-laden demands placed on all of us by increasingly pervasive networked computing.
What is needed is a paradigm shift from purely technical solutions to the problem of interruption to one that also helps get at the root, social cause of the issue. Just because I can check my email while in the shower does not mean that I should, that I should want to, or that I should be expected to. This last point, social expectation, is what drives technical innovation. Perhaps it is time to push back the other way.
- References available upon request. [↩]
Comments
One Response to “On Interruptions: Theory and Practice”
Leave a Reply
I totally agree– I did my paper on interruptibility as well, though I think I read different papers. I was really surprised that they measured busy periods as lasting under 2 minutes for the majority of tasks. That just didn’t seem right to me.
As we talked about in class a couple of weeks ago, interruptions come pretty close to 4 times an hour, and each interruption delays work on average… 15 minutes. Do the math,and you’re not getting any work done. Thus, the natural conclusion should be to minimize the interruptions, not delay them. That approach has been working out pretty well for me so far… though I am envious of you having an entire day disconnected. I don’t think I could do that, though I’m sure I’d get a ton of work done.