Messed-Up App of the Day

A couple of weeks ago, I returned from the Miracle Oracle Open World 2009 event held in Rødby, Denmark. I go just about every year to this event. This time, I had accepted an invitation from Chris Antognini to speak at his company's TrivadisOPEN event in Zürich. So my travel planning was a little more complicated than it usually is. Instead of finding a simple trip from DFW to Copenhagen and back, this time I had to book a triangle: DFW to Zürich to Copenhagen, and then back to DFW.

I was surprised at how difficult it was to find a good schedule at a good price; it was a lot harder than my normal booking. I ended up finding a suitable enough itinerary at Orbitz. I usually fly American Airlines, but for this trip, the AA flights were much more expensive than I wanted to pay. But I found an itinerary that used British Airways and Air Berlin that I liked. So I booked it.

The trip went just fine. On the morning of the final day of my trip, Dan Norris and I were standing together in Kastrup at the BA ticket counter when the BA agent noticed that I hadn't provided my American Airlines AAdvantage number for the itinerary. (BA and AA are oneworld partners.) So I gave him the number, which he attached to my itinerary, and he informed me that the number would map only to the segments of my flight that I hadn't consumed yet (I had CPH-LHR and then LHR-DFW left to go). I'd need to request credit for my flights prior in the week separately on the web once I got home.

Fine.

So on Monday after I got home, I went to AA.com to register my BA flights for mileage credit. There was a form to fill out. It took a while to type everything into it, because I had to find my ticket numbers, figure out how to isolate the carrier id from the remainder of the ticket number, and then enter date and flight number information for each segment of my trip for which I was requesting credit. It was probably a 10-minute time investment to get the form filled out.

So I reviewed what I had entered, and then I hit the Submit button. Instantly, I got feedback from the page saying that I couldn't request mileage credit right now, that I would have to wait 15 days before requesting mileage credit. So I recoiled a little bit—filling out that form was a bunch of work—and I opened my calendar application to log myself a reminder to go through the process again in 15 days.

There are a couple of problems here:

1. Why did the form force me to enter a bunch of details before telling me that I shouldn't be using this form?
2. Why was it necessary in the first place for me to type in the flight date, flight number, and origin and destination information for each segment of the itinerary? The ticket number should have been enough.

The simple way to fix both these problems is to do what ba.com does: it asks only who I am and what my ticket number is, and it figures out everything else.

Anyway...

The fifteen days passed, and my calendar reminded me to submit my mileage credit form. So I went to work again, gathering my ticket number information, my flight numbers, my dates of travel, and my origin/destination airport codes. I spent another few minutes typing it all in again. Then I clicked Submit. This time: joy. The form said that the submission was complete, and I'd hear back from AA.com via email.

A minute or so later, I got an email in my inbox thanking me for visiting AA.com and confirming that I had issued a mileage credit request. Good: request confirmed.

Then, just a second or two later, I got a second email from AA.com saying this:

Thanks for using AA.com to request mileage credit for your travel on British Airways.

I'm sorry to disappoint you but your transatlantic travel on British Airways (or a BA-ticketed flight) is not eligible for AAdvantage mileage credit. British Airways transatlantic flights to/from the United States are specifically excluded from mileage accrual or redemption in the AAdvantage program.

Grrrr.... I had to work this hard—twice!—just to find out that I wasn't even going to get to do what I wanted to do? Why didn't they tell me this fifteen days ago?!

The first experience was annoying. The second experience took the annoyance to a whole new level.

Here are some application design lessons that this story reinforces:

1. Don't ask for information you can derive.
   
2. Don't separate feedback from its prerequisite input by any more "distance" (measured in either time or user investment) than absolutely necessary. Especially when there's a chance you're going to deny someone his service, don't make him work any harder or wait any longer than absolutely necessary to let him know.

Of these lessons, number one is far and away the most important. If the AA.com site had asked just for the ticket number like ba.com does, the pain of the other problems wouldn't have been that big of a deal.

Messed-Up App of the Day

I hate to complain so much, but having spent my third 8- to 10-hour stretch using a really bad application this month, I'm compelled to say something. Today's Messed-Up App: the economy-class seat in an American Airlines Boeing 777 aircraft.

Alright, I get that in economy class, you're not going to get five feet of legroom, or 30-inch wide seats that lie flat or spin to face each other. That's okay. What I do get is transportation to Europe with a cash savings, relative to an upgraded fare, sufficient to purchase—if I wanted—this Rolex. And, actually, it's really nice how each seat in economy class has its own in-seat audio/video unit. You can watch whatever you want back there. Or nothing at all. That's very nice.

But the way someone designed the A/V remote control into the armrest is just wrong. Each remote snaps into a compartment designed into the top of the armrest. Here's what it looks like.

And so here's your decision tree: Either you'll rest your arms on the armrests, or you will not. Not much of a decision there. Even if you decide not to rest your arms on the armrest, you'll probably do it accidentally if you have the good fortune to fall asleep (which you better do, because you have to work tomorrow).

The remaining decision is influenced by the following observation: If you leave the A/V remote in its cradle, your arms inadvertently push buttons "TV On/Off" or "Channel Up/Down". Fortunately, the "Call Attendant" button is difficult to press accidentally. The other choice is to take the remote out of its cradle and put it in your lap so that you won't accidentally press the buttons while you're watching 30 Rock. The problem with taking the thing out of its cradle is that resting your arm on the resulting pointy-thinged-chasm becomes really uncomfortable by the time you've sat there for a while.

Oh, and you don't get to make a choice for your other armrest, which looks like this:

That's your neighbor's A/V remote.

...Whose buttons you're pushing accidentally with your other elbow, if you happen to be wider than your neighbor.

The only decent workaround I've found is to put your pillow underneath your arm on one side, and your blanket on the other. This brings other troublesome compromises into play, which I won't go into. One of them requires communicating with your neighbor.

The whole point, and what I believe makes this story relevant for software developers, even if you don't travel economy class to Europe very often, is this. People who design things need to actually use the things they design. If the person in charge of designing seats for American Airlines' Boeing 777 aircraft had been required to sit in a prototype of this particular seat for the 8-hour flight from DFW to LHR (or even better: the 10-hour ride back), this seat would never have made it into production.

People should test their designs by actually using them, under circumstances as similar as possible to the actual circumstances that the users of the design will endure.

Messed-Up App of the Day

Greetings from London Gatwick Airport. Messed-up app of the day: National Express self-service ticketing kiosk, London Heathrow Airport, Terminal 5.

I'm connecting through London on my way home. Unfortunately, my connection requires a bus ride from Heathrow (LHR) to Gatwick (LGW). Not my favorite, but I've done it before and survived. Bus is run by National Express. It's a £19 ticket; apparently only £17 if you're doing the BA/AA ugly connection thing I'm doing. I don't remember having to pay that myself before, but today I'm glad I did.

One way to buy your ticket is through one of the self-service ticket machines outside baggage claim. Here's approximately how that went:

Machine: Where will you be going?

Me: London Gatwick.

Then the machine I was doing business with popped a widget that showed the number of qualifying journeys the machine had found so far. It's one of those "watch the number change really fast" fields. I watched it count through 10, and then 50, and then 100 (jaw drop), and then eventually 500, until finally, about a minute later, the counter reached roughly 2,000. Finally, it said, "2,000 qualifying journeys found", or something to that effect.

Then it showed me the first half dozen or so of those "qualifying journeys."

• 11:10 Heathrow to Gatwick
• 11:20 Heathrow to Gatwick
• 11:30 Heathrow to Gatwick
• ...

It was 10:55 at the time. I chose 11:10.

"Brilliant."

Let me summarize. This thing computes the schedule for each of the next 2,000 bus rides you might want to take. You only look at six of them. The cost to you for all this information you don't look at is (N+1)*60 seconds of your time, where N is the number of people ahead of you in the queue for this machine. If there are six or more people ahead of you in your queue, then you're probably going to miss the next bus.

I don't know whether it's an Oracle application behind this or not. It doesn't matter. It's stupid either way.

There's a simple solution. Begin by asking approximately when the user wants his bus ride. The default value should be "now." I don't know what percentage of people would ever want to change that value, but I doubt I ever would. Then instead of returning 2,000 qualifying journeys sorted by departure time, return only journeys whose departure time is within ±1 hour of his choice. Of course, list only those departure times that occur in the future.

SQL like this would do it:

select   departure_time, origin, destination, ...
from     whatever1, whatever2, ...
where    origin = :here
       and destination = :there
       and departure_time between :your_time - 1/24 and :your_time + 1/24
       and departure_time > sysdate
order by 1

Okay, that's functionally dirty because what happens if someone specifies a :your_time value of 3am, and there are no buses scheduled anywhere within 2am-4am?

Then be clever and use analytic functions to find the 10 rows that have departure_time that are closest to :your_time. Be a developer.

The functional difference we're trying to achieve is to stop burning computing and communication resources producing 1,990 rows that nobody wants to see anyway. The benefit? Reduction of human suffering in situations wherein frustrated people who are trying to make their connections are missing buses because a machine that takes their money is spending time making calculations nobody needs.