Tangled in the Threads
Jon Udell, August 29, 2001Web Travel Planning
Awesome capabilities, but still major frustrations too
I'm taking my family on a trip to Europe next month. I haven't planned such a complex itinerary since the early days of the web -- yes, I know, I should get out more! -- so this turned out to be my deepest plunge into the waters of web travel planning. It was exhilarating and frustrating in equal parts. In the end, I concluded that we have come an amazingly long way in five years, that there is still a long way to go, and that there are some fascinating opportunities right around the corner.
The good news, which is not news at all for readers of this column, is that you can accomplish so much so easily. I most enjoyed looking for hotels in Paris. I well remember the neighborhood where I stayed years ago, and the many long walks I took in and around that area. Using Expedia, I was able to focus on that neighborhood and then list all of the hotels within the boundaries of the current map, sorted by price. In general, we take this kind of thing for granted nowadays. But once in a while, you have to step back and acknowledge that this is a stunningly cool and wonderful thing to be able to do. Your 1991 self, looking over the shoulder of your 2001 self, would be wildly excited. Sometimes, your 2001 self should still get excited too.
I've got to admit, though, that a lot of this excitement wore off as the planning proceeded. I kept a list of the things that spoiled the illusion of perfect information and frictionless commerce, and I think it says a lot about where things are headed next, and why. Here are the top three items: "the unstated occupancy requirement," "the credit card security check," "the unavailable train."
The unstated occupancy requirement
The hotel we picked in Paris offers a standard rate for a room which, Expedia allowed me to assume, would accommodate our family of four, perhaps with an added charge for cots for the two kids. I didn't find out otherwise until I'd gone all the way through the booking process, and pressed the Confirm button. "Room will not accommodate proposed number of guests," said the message. This despite the fact that I had told Expedia that we were two adults and two kids.
The following questions arose to which, infuriatingly, Expedia had no answers:
Well, how many guests will this room accommodate?
What rate gets me a room that will accommodate 4 guests?
How do I switch to another rate, without backing up and restarting?
I'm not trying to pick on Expedia. I landed there, in this situation, because its hotel finder enabled me to explore Paris neighborhoods, and it did that job really well. Part of the problem was that, like a great many other web services, Expedia doesn't enable you to flexibly adjust orders midstream. Or maybe it does, but I didn't discover a straightforward way to do it -- in the end, to the customer, that boils down to the same thing.
A subtler problem is the failure to integrate deeply and cleanly with partner systems. In this case, it would have been quite possible for me to provoke the "Room will not accommodate..." message a few more times before discovering, the hard way, what rate the hotel really wanted to charge for a family of four. But being a Perl hacker, and knowing that There Is More Than One Way To Do It, I took another tack. This hotel is part of a franchise, so I looked up the franchise's website and went to its reservation system. Like Expedia, its surface view allowed me to assume that the standard rate might apply to our family. But unlike Expedia, it coughed up the "Room will not accommodate..." message in response to the first form submission, long before I would have invested (and perhaps lost) a lot of time and keystrokes.
In the end, armed finally with the knowledge of which rate the hotel would allow me to buy, I went back to Expedia -- which had, after all, memorized some keystrokes I didn't want to retype -- and booked the room.
The credit-card security check
I looked at flights through a number of different lenses, including SideStep, Travelocity, Expedia, and Orbitz. I wound up at Expedia again, but I don't think the problem that arose was Expedia's fault. It's another integration issue that, I think, would equally have affected any of the flight-booking services. Here's what happened: my credit card was rejected, with the message "Insufficient credit, or invalid address."
I was quite certain that neither of these conditions was true, so I called Expedia to talk to them about it. The agent, who believed I wasn't deluded about my credit line, guessed there might be a problem with the address-verification protocol. This seemed a plausible hypothesis. I've seen for myself, as an implementer of services, that address verification can be quirky. So the agent volunteered to disable address verification and retry my transaction. (Yes, I know, this is questionable from a security perspective.) And then, since she lacked access to the session that existed between my browser and the service, I had to dictate all the information so she could retry the transaction.
Of course, it didn't work. So I called the bank to check the only other evident possibility -- that the credit line was indeed insufficient. It wasn't. The bank's agent saw nothing wrong, verified that the charge from my earlier hotel transaction had been posted, and suggested that I retry. Back to Expedia (via the browser): same result, of course, no joy. (Definition of insanity: do the same thing, expect a different result.)
I called the bank again. This time, as it was pretty clearly their issue, I was referred to the "authorization department." That agent immediately saw that there was a lock on the account, and released it. What triggered the lock? Probably the fact that this was the second largish charge in the same day, on an account that doesn't see much activity. "Try it now, it'll go right through," said the agent. He was right.
The unavailable train
Our itinerary takes us from Brussels to Paris for a return flight home. As the schedule will be tight then, a Belgian friend referred me to Thalys, the high-speed train that could take us from Brussels to the Paris airport in just 1.5 hours on the morning of our 11AM flight.
What happened here was, oddly, the inverse of the hotel case. In that situation, the generic service (Expedia) was less useful than the specific service (the franchise site). Here it was the other way around. The specific service -- the Thalys site -- didn't find any seats available on the day I wanted. (Nor, in fact, did it find seats on other days, and for other trip segments, which I had been separately considering.) But a generic service, Rail Europe, did.
As my Belgian friend later realized, there are apparently blocks of seats reserved for the American market, which is Rail Europe's target. These seats are invisible to users of the Thalys site who (as the currencies supported there should have clued me to) are Europeans.
Optimizing web services
As technologists, we tend to suppose that APIs, protocols, and standards are the way to address these kinds of problems. I can, for example, imagine a stricter room-reservation API which would force hidden assumptions to the surface. I would argue that the "Insufficient credit, or invalid address" should have plainly said what the Expedia agent and even the first bank agent did not immediately know: "Security lock on account." And I could fault the Thalys site for not noticing my US-based IP address and directing me to a more appropriate service.
It's still early days, in terms of large-scale integration of web services, and I'm sure we'll see lots of improvements along these lines. But I can't help noticing that the flies in the ointment are all examples of information hiding. Transparency and frictionlessness are not, in general, what sellers want to provide. They are, in theory, what buyers crave -- but not at the expense of effort. Market-research friends tell me that people are very loyal to commerce sites. My mix-and-match approach, which for example can lead me to use Amazon's reviews to evaluate something that I'll then buy elsewhere, is apparently atypical. Most people, it seems, have neither the time, the skill, or the inclination to optimize systems of web services.
Since such optimization is often contrary to the interests of the providers of services, where can it come from? I have a hunch, inspired by a software-support system invented by the folks at HandsFree Networks. Their system hooks into Windows at a deep level (VxD, device driver) and scans API calls and return codes for patterns that reflect known common problems. To the user, these are "quirks" like a printing sequence in Word that leads to a protection fault. To the system, they are (if known to the database) recognizable genetic flaws for which new DNA (upgrades, patches) can be found and used.
I've written several columns about the power of local web proxies. I suspect we've only begun to tap their potential. In the web travel domain, an early example is SideStep, which in its MSIE plug-in mode snoops your Expedia, Travelocity, or Orbitz searches and displays its own results side-by-side with theirs.
Now let's combine these ideas. Take the HandsFree Networks pattern-detection-and-response technology, and apply it to a browser plug-in or local web proxy that looks for and responds to patterns in your HTTP traffic. It might notice that the hotel franchise you're investigating in Expedia has some non-obvious rate restrictions, or that as a US customer you should look to the Rail Europe site rather than the Thalys site.
There no technical requirement that this application run locally, and in any case, it will of course need to reach out to the web to access its ever-changing and all-important rulebase. But I suspect that culturally, for a while to come, we'll feel better running this kind of thing as a local application rather than a remote service.
How would such a rulebase get built? I'll bet you could identify enough common patterns -- the web equivalents of "Why can't I find the network printer?" -- to make a useful product without doing a lot of invasive snooping. But ultimately, the web is far messier and less predictable than Windows. So the real power would flow from building the rulebase in a collaborative way. There are lots of ways this could happen, some really creepy. Of course we'd need to control what is conveyed to the rulebase. But would you be willing to describe, in a structured way, the same kinds of problems and workarounds as I've mentioned here, things you might otherwise post to a newsgroup as an unstructured anecdote?
Dan Bricklin makes the following important claim in Peer to Peer: Harnessing the Power of Disruptive Technologies. "One can predict the success of a particular system for building a shared database," he says, "by how much the database is aided through normal, selfish use." In everyday web commerce, people learn things (the hard way) that providers of web services don't necessarily want them to know. This collective knowledge exists only in a potential form. A collaborative system that actualizes that potential knowledge would be incredibly disruptive, in the best sense of the term. Napster showed that people were willing to share their music, and musical tastes, in exchange for free music. Might people be similarly open with respect to their web commerce activities (pseudonymously, let's say), in exchange for more transparent and frictionless commerce? I don't know. But I'm sure that SOAP APIs alone won't guarantee us optimizations we're not meant to have.
Jon Udell (http://udell.roninhouse.com/) was BYTE Magazine's executive editor for new media, the architect of the original www.byte.com, and author of BYTE's Web Project column. He is the author of Practical Internet Groupware, from O'Reilly and Associates. Jon now works as an independent Web/Internet consultant. His recent BYTE.com columns are archived at http://www.byte.com/tangled/
This work is licensed under a
Creative Commons License.