|
This month I've been doing a fair bit
of travelling and encountering the worst that the travel IT
systems industry has to offer. My bags got lost at Heathrow twice
within 10 days. Amazingly, the computer is really good at telling
you where they are and how long it will take before the reach you.
Sadly, the antiquated baggage system, manages to lose them in the
first place.
Much more interesting was my
encounter with the Air
New Zealand, seat reservation system, or more
accurately, my second hand encounter. It wasn't me who was
wrestling with the poor computer system but the unfortunate
collection of stewardesses on the other side of the desk.
My wife and I checked in at Glasgow,
on a four leg flight which tooks us through London and Los Angeles
and on to Papeete and eventually to Bora Bora. As is the custom
nowadays, we were issued with boarding cards for 3 flights all at
once. The 4th flight was on Air Tahiti and couldn't be reserved in
advance. The problem was that on the LAX to PPT leg of the
journey, the system simply refused to give us seats together. The
British Midland girl at Glasgow was perplexed, she made a phone
call to technical support. No Joy. She was advised (wrongly) that
the fault was with Air New Zealand and could not be fixed by a
British Midland operator. We should ask again at Heathrow. No
problem she assured us, the flight was almost empty. So we took
the first flight.
At London, we made for the Air New
Zealand transfer desk and explained. The girl ( a real Kiwi) was
really very nice, polite and helpful. No problem, she would just
enter into the computer.
"Oh" she exclaimed, and
read out the exception dialog box to us. She wasn't allowed to
change the details because we hadn't checked-in at London. She
tried again and again. No luck. She called technical support. She
was becoming increasingly embarrassed. I felt like an accomplice
in the crime. Afterall, one of my so-called "professional"
colleagues had perpetrated this inhumanity! It really wasn't her
fault but she felt stupid and Air New Zealand looked stupid.
Finally, she offered that we ask again at LA. No problem she
assured us, the flight was only half full! :-)
At LA,we were shepherded into the Air
New Zealand holding pen. A facility which prevents
through-passengers from needing to complete a US Immigration form
and clear US Immigration. All passengers contuining on with
another airline had to do this. Another Interaction Design
nightmare. People who are only spending a few hours in the airport
have to clear immigration. Huh? Who's idea was that? Its the
equivalent of sticking a Dialog box in someones face and forcing
them to complete it even though they don't need to.
So, we waited in line for our transit
card, and again asked the stewardess about the seating. "But
the flight is very full", she insisted. :-O "I cannot
possible change your seats now." We insisted that she did.
Grudgingly, she entered the computer system and again we watched
the face as she agonised with it, wrestled with it, again and
again. Eventually, she looked up.
"I'm sorry, it won't let me
change the seats. There are two seats together further back. I
reserved them for you. She took a pen, scored out the seat number
on our boarding cards, and wrote in the new ones. When all else
fails - resort to pen and paper.
<Rant>
If the designers of this system are
listening - YOU OUGHT TO BE ASHAMED!
The truth is that seat reservation
systems are inhuman. The goal was to achieve two seats together by
the window. The system should ask the right question, be prompted
with a selection of check boxes, input box and radio buttons which
tell it that our request is 2, window seats, together, near the
front. It should then go away and make a suggestion.
The problem is routed with the
database techies who designed it and its lack of professional
interaction design. The design is there to facilitate the
multi-user high contention problems in the database. It uses so
called "optimistic locking".
OPTIMISTIC LOCKING IS NEITHER
OPTIMISTIC NOR DOES IT LOCK!
The user is presented with an "unlocked"
grid of seats. The user is responsible for making the decision
about which 2 seats, together, by the window, near the front, to
select. They then "submit" a request. The database then
tries to fulfill that request by locking the seats requested. Any
failure, because someone else got in first on either seat, causes
a database exception. What happens then is anybody's guess.
In our case, it appears that the
allocation for 1 seat was changed to some randomly chosen one. NOW
THAT'S A REAL GOOD EXCEPTION STRATEGY ISN'T IT? NOT!
Furthermore, the allocation could not
be changed. Whether this was due to some failure of functionality
or simply that the interaction required to make such a change was
too hard to decipher by three stewardesses and two technical
support personnel, we will never know.
Designing the User Interaction based
on the needs of the database underlying technical architecture is
WRONG!
</Rant>
|
