Travel and visualization

I used to fly a lot. When I was growing up on an island in the pacific, I'd travel between islands, often riding along with my dad, a pilot, on his flights. In college I'd travel home on holidays and traveled to Europe for study abroad terms and a Eurail trip. My travel peaked a few years ago when I was doing technical sales for a software company and flying most weeks, often cross-country and sometimes across oceans. Along the way, it's been interesting for me to see how things have changed.

From my younger days, I remember talking to airline people at counters or over the phone, talking to travel agents, and looking up paper and building-posted timetables and fares. It's notable to me that all these options still exist, but some of them involve itemized extra fees. The only old school method that I used to use that seems to have essentially disappeared is printed timetables for airlines. Even a few years ago I would pick them up from the airlines I flew most often because they were easier to keep handy until I could get an electronic schedule on my Palm.

Also from my younger days hanging out with my dad at the airport, I looked over the other airline counter agents as they typed complicated keyboard commands and deciphered cryptic displays. It made sense to me that that had lots of information to show and lots of different things that they needed to do, but it seemed pretty awkward. Now thirty years later when I look over the shoulders of counter agents, I generally see what look like the same displays, but this time multiple text terminals in different windows in a GUI with a bunch of reminders taped to or printed on monitors and keyboards to remind people of the arcane commands. It's seems as anachronistic as driving by a grain field and seeing people harvesting with scythes.

In the mid-nineties (or "in the late twentieth century" as I think I remember Alexis Ohanian say at MIT's Startup Bootcamp), I started using web-based travel sites more and more. I liked that I could explore lots of options and make trade-offs with information myself more quickly than I could, even with a skilled travel agent I'd worked with for more than ten years. (Often I would find what I wanted online and then call my travel agent to book it.)

On one of my flights across the Pacific, I was struck by an idea for how to make an interactive travel information display that would make the understanding of options and making of trade-offs in complicated or very flexible itineraries much easier than the tables, lists and grids of existing web sites. I was busy with my day job, so I filed it away. I also realized that it was probably over-engineered for almost everyone. But every couple months I'd revisit the problem and my approach, hoping for some new insight to make more power available without as much complication.

Meanwhile, with the exception of the matrix display that I first saw on Orbitz, not much seems to have changed in the last fifteen years in travel planning sites. Lots of tables, lists and grids. They got better visual design and some handy interactive features, but fundamentally they were alphanumeric displays.

Just a few weeks ago, when I returned to thinking about my years-old fancy travel planning approach, a new idea came to me. I realized I was on to something and proceeded to elaborate on it to deal with more and more of its implications and possibilities. I was excited, but working on other stuff, too, so it stayed on the back burner.

Then I read about Hipmunk. I was both excited and disappointed -- they were doing the core of the insight that came to me a couple weeks before: a Gantt-chart-like display of flight times. I was excited because someone else thought it was useful and had actually made it real; disappointed because I wasn't one of the first. I told one of my colleagues about this and he mentioned that this had been around in another form for years. (He had already posted about it on Hacker News. Commenters on his post pointed out that similar things had been implemented other places, too.)

So as I've been thinking about this, three things seem clear to me:

1. Lots of interactions and technologies hang on for a long time: there are still travel agents and character terminals, bumping along side-by-side with Hipmunk's and others' much newer and richer interactions.
2. When an insight comes it may be the first time in the world, or it may not be. I'm often surprised to think of something that seems completely new and a breakthrough and look around and find other people have done it for years. Other times I think of some humdrum little thing that seems obvious and find that no one has done it but it would be useful.
3. Even when I don't invest something, I'm glad it's around so I can use it. I've already been using Hipmunk, and while I'd love to help them with elaborating and improving it, I'm more glad it exists than jealous that I didn't get there first.

Interaction Design "moves the pain up", and worth it

I was talking with an interaction design consulting client last week. After a few weeks of working on this project, I asked him about his experience of it -- was it proving valuable enough to keep working together. He answered in an interesting way: he said that the work was painful, and more specifically that it moved pain to the front of the design and build process.

Some context:

Our engagement roughly amounts to a selective teaching and coaching relationship where I try to understand what he needs to get done and I teach him how to do appropriate interaction design activities. Between his budget and his wanting to "learn to fish", he's planning to do the interaction design work itself.

The outcome that he's aiming for is that the system that he is programming and wants to offer as a commercial product has the appropriate relationship with the users of the system, particularly around teaching concepts in the work and an appropriate division of work between person and system.

He knows a good deal about users and their domain, having previously worked with a couple of user on consulting engagements and an early incarnation of the system he's developing. So he's calling the user and domain research work done enough for now and wants to work on the interaction and technical design of the software system. In particular

So, guided by the approach described by Kim Goodwin in Designing for the Digital Age, we started with context scenarios. At a high level, these were pretty straightforward for him to describe and me to outline on a whiteboard. After doing some work on his own to get done at a high level (like "user X reconciles information"), I suggested going to a fairly fine level of detail along these lines:

user X: sees 71 transactions in account CAT in system 1 and checks that against account CAT in system 2 and approves" 

system: records approval of account CAT and updates totals

note: need to check algorithm for updating to avoid double counting 

My client said this was painful. We talked about it a bit more. He said it was uncomfortable, even painful but also seemed worthwhile. I asked: what seems makes it worthwhile?

He said that all these details were going to be addressed anyway sooner or later (they were inherent in the work), and he knows that once code starts to be written, it carries momentum. Thinking through these issues in a text document, rather than in code and data, gets them addressed flexibly, without worrying about code that's already been written and how to adapt it or replace it. Since he knows something about finance, I suggested that there might be something like a "net present pain" that he's dealing with. Postponing the pain often makes it more costly to deal with, but just like large up-front payments rather than variable interest later, there can be savings and confidence.

He also explained that finding challenges in a scenario early gives time for inspiration for how to deal with them to come to him. (Since our discussion, it occurred to me that another way to put this is that finding challenges earlier gives you more showers for inspiration to strike before the challenge needs to be addressed.)

In The Simplicity Shift by Scott Jensen, one chapter begins with a pithy statement along these lines: "Months of programming effort can save days of critical thinking." Agreed.