Archive for June, 2009

Zen and the Art of Elevators

I work in a high-rise building that secures its elevators with keycards.  In principle, the access system is simple and intuitive: employees and visitors are given keycards that they swipe past a sensor inside the elevator before pressing their floor button.  In reality, the building’s access system has a bad user interface, which regularly frustrates both employees and visitors.  During one early morning ride, the frustration was so bad that it almost boiled over into fisticuffs.

When I’m riding the elevator, I enjoy observing how various people react to the security system’s quirks.  I view it as a sort of a Rorschach test that exposes how people interact with technology.  A couple small quirks in the security system make the familiar interface of elevator floor buttons awfully cumbersome.  Only people who take the time to think about the implementation details succeed in calmly selecting their floor.  Those who take the Zen approach, avoiding any detailed thought of the elevator’s control system, typically end up spastically jabbing the buttons or missing their floor.

I drew up a simple flowchart that describes the security system’s behavior.  When the elevator doors open in the building lobby, the system is in the non-blinking state at the top left.  To keep the drawing simple, I haven’t drawn what happens when two people swipe cards or press buttons simultaneously.

Elevator Control Flowchart

Elevator Control Flowchart

The correct path for trouble-free operation is marked with bold arrows that move counter-clockwise around the drawing.  To follow this path, you must:

  1. Swipe your keycard past the sensor.  Be sure nobody else swipes their keycard at the same time.
  2. The sensor’s red light starts to blink.
  3. Wait 1 second.  Do not press the floor button too quickly because the press will be ignored.
  4. You’re now able to press the floor button.  The sensor is still blinking in the same way.
  5. Press the button for your floor.  It will light up.
  6. Everybody else must wait 5 more seconds for the sensor to stop blinking before they can swipe their card.

This description and the flowchart make a few design flaws apparent.  Most glaringly, any deviation from the correct path causes confusion or delay, and the flowchart depicts many potential detours.  The most common detours are:

  1. A person swipes their keycard and immediately presses their floor button.  The button doesn’t light up, and access is delayed.  The typically causes the person to start jabbing at the button.
  2. After somebody has selected her floor, but before the red light stops blinking, somebody else swipes his card and tries to press his floor button.  The swipe is ignored and the button press is rejected.  Everybody must wait roughly 5 seconds for the little red light to stop blinking before starting the process over.
  3. Two people swipe their card at roughly the same time.  Neither are sure which swipe, if any, was accepted.  The more aggressive of the two people starts jabbing their floor buttons while the other person steps back.  Typically all the button presses are ignored until the red light stops blinking and somebody tries again.

With such a poorly designed user interface, there’s no surprise that temporary visitors usually get confused.  I’m somewhat surprised that long-time employees remain confused.  In the terminology of Robert Pirsig’s Zen and the Art of Motorcycle Maintenance (which I’m re-reading now), these people are taking the Zen viewpoint toward technology.  They don’t want to trouble themselves with taking the time to think about the system’s details, which causes frustration when they encounter a problem.

If you visit my building, beware of the elevator.

Leave a Comment

Odd crashes lead to easy Linode upgrade

I’m hosting RankBuzzard on a virtual server hosted at Linode.  I initially signed up with their least expensive offering of $20/month.

This weekend I started observing some mysterious crashes on the server.  First I saw some failed queries into the Postgres database which stores RankBuzzard’s Django models.  Then, as I was investigating the cause of these errors, my Emacs quit with a simple “Killed” message.  Odd for sure.

I wondered if RankBuzzard’s database had outgrown the minimal 360MB allocated to my Linode 360 VPS.  After some basic resource checks that confirmed my suspicion, I decided to upgrade to a Linode 720.  The entire upgrade process, from filing a support ticket to clicking reload on RankBuzzard’s main page, took under 30 minutes.

All I had to do was:

  1. Submit a ticket requesting the upgrade,
  2. Shutdown my virtual server,
  3. Click a button that kicked off the migration process,
  4. Boot up the new virtual server.

The entire process was flawless.

Comments (1)