Help systems must rely on automated capture of information system state and user action history.
With October comes the annual announcement of the Ig Nobel Prizes, awarded by the Annals of Improbable Research (www.improbable.com
) for "achievements that cannot or should not be reproduced," in the words of Marc Abrahams, editor of the Annals and chairman of the awards Board of Governors.
What put this years Ig Nobels on my radar was the award for psychology, given to Daniel Simons of the University of Illinois at Urbana-Champaign and Christopher Chabris of Harvard University "for demonstrating that when people pay close attention to something, its all too easy to overlook anything else
even a man in a gorilla suit." I shall make clear, I promise, the applications of this research result to information systems design.
Briefly, these intrepid researchers showed their consenting subjects a series of videos and gave those subjects various observation and analysis tasks. While watching two teams play basketball, for example, the task might be to count the number of passes made by members of one team while ignoring all other events.
At some point during the presentation, a spurious event would be introduceda woman carrying an open umbrella or a person in a gorilla suit would enter the video frame for several seconds.
Overall, 192 observers saw scenes including unexpected events under a variety of conditions: 46 percent of the observers failed to notice that anything unusual had happened, even when asked specific questions such as, "Did you see a ... ?"
There was nothing subtle about the way that the peculiar elements were introduced into the scenes. In their 1999 report of their results, titled "Gorillas in our midst: sustained inattentional blindness for dynamic events," the experimenters noted, "Observers in our study were consistently surprised when they viewed the display a second time, some even exclaiming, I missed that?!"
And speaking of not being subtle, Im sure you can see where Im going with this subject in connection with IT. There are three IT domains in which these observations ought to be of interest: user support; application development; and, especially, user interface design.
As to user support, its almost axiomatic among help desk operators that users are always wrong when answering questions about anything unusual that might have happened just before a problem appeared. Unless an explicit error message appears and remains on the screen long enough to be repeated over the phone to a support technician, its generally understood that users seem to overlook all sorts of useful indications as to what actually might be wrong with their machines.
Simons and Chabris findings make it clear that this is not help desk cynicism but rather a result of the way that were wired: We literally do not see things that dont matter to what were trying to do. Help systems must therefore rely, to the greatest possible extent, on automated capture of information system state and user action history, because any user who isnt actually trained in reproducing and documenting system bugs has to be treated as an unreliable witness.
As to application development, programmers themselves must be considered unreliable in their descriptions of what happenedeven what they did themselvesthat might have introduced a bug into formerly working code. The famous Jargon File (www. catb.org/~esr/jargon
) even has an entry"I didnt change anything!"that documents this phenomenon anecdotally; now, its official. Yes, the programmer almost always did do something. Again, automated capture of events and their history is the only reliable cure.
Finally, as to user interface design, the harder it is to perform routine tasks, the more its likely that people will overlook a "gorilla in the midst" of otherwise typical results. Its not enough to design our systems to help people get their normal work done. We must also design our analytics tools, enterprise dashboards or security monitoring consoles to make abnormal situations obviouseven to users who are busy with their jobs. Otherwise, well get our own ignoble results.
Technology Editor Peter Coffee can be reached at firstname.lastname@example.org.
To read more Peter Coffee, subscribe to eWEEK magazine.
Check out eWEEK.coms Application Development Center
for the latest news, reviews and analysis in programming environments and developer tools.
Be sure to add our eWEEK.com Application development news feed to your RSS newsreader or My Yahoo page