The Lindley Hall Security System

Problem Description

Once upon a time, a student came to my office to talk about a problem. When we were taking a break, the student went out of the office for a drink. After waiting a while, I went to look for him, only to find that he had been stuck in the basement because the elevator wouldn't let them back upstairs.

On many occasions, I have had to rescue someone from being accidentally locked out because of the strange way the security system works.

HCI Analysis

Since Lindley Hall houses the computer science department, a lot of expensive equipment is stored there, and security is important. Many doors in the building, as well as the elevator, are equiped with a card reader to control access. The picture below shows a portion of the elevator's control panel; the card reader is on the left side.

The control panel in Lindley Hall's elevator. The card readers are rather cryptic. A steady green light means that the door is locked, and the reader is ready to accept a card. A flashing green light means that the door is unlocked. A solid red light means that a card has been swiped, but was not recognized. Flashing red and green lights indicate that a door that should be locked has been held open for too long.

Users normally associate green lights with "ok", or "ready to go". Using green to indicate a locked door is a violation of expectations. This forces a violation of Shneiderman's (1992) priciple that users should be able to predict what will happen in response to their actions.

There are three security levels associated with doors in the building:

  1. Always open - the door is always unlocked, either by having its card reader always inactive, or by not having a card reader on the door. The doors to the outside of the building fall into this category.
  2. Always locked - the door is always locked, and a card with the proper clearance is required to get through the door.
  3. Timed - The door is unlocked during the department's business hours, but automatically locks after hours (6pm on normal weekdays).
The elevator is particularly tricky. The card reader in the elevator is of the timed variety, but it only controls the buttons to floors 2, 3, and 4. The other elevator buttons work all the time. This is because the upper floors are "secure" floors, while the basement and first floor need to be open for students to access the public computing labs.

Suchman (1989) argues that a computerized system should be self-explanatory, in that a user should be able to easily determine the designer's intentions. If a user attempts to use the elevator during business hours, the system appears to be self-explanatory. The user simply pushes the button corresponding to the floor he wants, and the elevator takes him there. He builds a simple mental model of the system that assumes the elevator works just like other elevators he has used. Later, the elevator will allow him to descend from the upper floors, reinforcing the simple mental model. However, he will not be able to return, since the upper-floor buttons are now disabled. Pressing any of the disabled buttons will result in no response. At this point the user is likely to blame the wrong cause for the problem (Norman, 1988). One possible assumption is that the elevator is broken.

Only after a user has been locked out will he receive indication that his mental model was faulty. This kind of "one-shot" behavior violates the Apple (1992) design principle of "forgiveness".

Recommendation

Since it is possible to take the elevator down from an upper floor after hours, but not return, some sort of warning should be given. Apple (1992) suggests that users be warned before performing any irreversable task. However, the warning should not be so overt that frequent users are annoyed. A simple notice beside the buttons in the elevator could suffice.

Like the Wyndham Elevator, a greater amount of feedback would also be helpful. However, the form of this feedback is difficult to determine. Perhaps a short recorded message could be played if the elevator is taken to an upper floor in the hour before the buttons are disabled.

References

Apple Computer (1992) Macintosh Human Interface Guidlines. Addison Wesley. [Chapter 1]

Norman, D. (1988) The Psychology of Everyday Things. New York: Basic Books [Chapter 2]

Shneiderman, B. (1992) Designing the User Interface: Strategies for Effective Human-Computer Interaction. Addison-Wesley. [Chapter 1]

Suchman, L. (1989) Plans and Situated Actions. New York: Cambridge University Press. [Chapter 2]

rscherle@cs.indiana.edu
Last modified: Thu Mar 25 23:19:02 US Eastern Standard Time 1999