Perhaps the crown jewel of the labs so far, I set out to right some wrongs that were inflicted on me during travel research for a trip out to the San Francisco area. I had such a hard time finding the information I needed among walls of text and advertising that I decided to try my hand what I think flight search results should look like.
So, I hate flight search results. There’s so much information about the flight that you need to know, but no good, concise way to see it. There’s the airline, departure time, arrival time, flight duraiton, layover airports, layover times, price, reliability and the list goes on. For round trip flights (easily the most common), take every problem you see and double its impact and you start to see why I see a need for improvement.
What I set out to do was present flight search results in a single table, with just one row for each flight itinerary; not each flight, but each full flight plan, from origin to desintation. To get the data, I looked to the Kayak API, which provides a ton of information. After I got some HTTP issues figured out (hint: if you’re using
urllib2, be sure to change the User-Agent string to something other than the default), I had all the information I needed and could begin to visualize.
Since the number of available airlines is relatively small (compared to the other data, at least), I decided to just show the icon, with alt-text and a title that show the full name of the airline. This saves real estate when viewing the visualization, while maintaining as much accessibility as possible. The price uses Wilson Miner’s technique to the letter, except that it has to use some extra markup to use
position: relative inside a table cell. What goes in between, however, got interesting.
Right off the bat, I knew I wanted to show the whole flight plan as a series of bars, each representing a single flight. The gaps would then be layovers, but I figured I could enclose those in a border so it all formed one large bar. The number of black bars clearly displays the number of flights, while the length of the bars corresponds direclty to time: longer bars means longer flights and layovers. Since it’s all based on time, the lateral position of the bars also corresponds to their start and stop times.
All the times are shown on a relative scale, though, such that the lowest value is the earliest departure, while the highest value is the latest arrival. This makes it easy to compare flights in the same set of results, but difficult to process according to actual, real-world schedules. So, I added the actual departure and arrival times in their own columns as well, to make it all more clear.
If you’ve read my earlier posts on golf auto racing, this will start to look like variations on the theme, because it is. These are just the same bars as before, but styled a little differently to accommodate the difference between flights and layovers. Positioning uses the same
width combo trick used in the NASCAR experiment, though the percentages for layovers are inflated sever slightly, to account for rounding issues in the browser that would otherwise cause some gaps.
The finished product
All in all, I think this is a very successful experiment so far, and I’m really excited to see where it goes from here. I’ve shown it off to a few people privately and on Twitter, and the single most requested feature is a set of inputs for looking up arbitrary routes. Since the Kayak API does exactly that, I definitely plan to add that feature, but backend support is lagging behind at the moment.
In addition, I’ve gotten requests for adjustable filters for price and travel time, which I think would be great. Since flight results are so highly structured, it’s easy to buck the standard search result paradigm of paging through tons of results. Instead, filters are a great way for users to actually tell the system why the top results aren’t sufficient, so you can get better results with what’s left. Kayak already offers a lot of filters on their own search, and I hope to duplicate some of them, where they make sense, while adding some of my own.
In addition, I’d like to incorporate informationi from the Bureau of Transportation Statistics to add some probability information to the results. Essentially, I’d like to show the likelihood of an on-time departure as well as the probable duration of any potential delays. Combine this with layover time (already known) and you get warnings of likely delays that would cause a missed connecting flight. Also, having a tail number reference would help reduce the likelihood of duplicate results, which occurs when multiple airlines market the same flight using different flight numbers. This is currently happening a lot with Delta and Northwest, but it also tends to happen with foreign carriers making connections inside the US.
I’d also like to design it into what I think an ideal flight booking experience could/would/should look like. I don’t have this completely fleshed out yet (even in my head), but it’s an ideal goal, eventually. Of course, I don’t really want to be a travel booking service, so I’ll probably introduce some limitations that make it less useful to people doing actual trip research. I’ll likely just not include date inputs, so you can choose airports but the date is chosen for you.
I look forward to working with this one a lot more as time goes on, and with any luck, I can produce something good that real travel sites can benefit from.