Monthly Archives: March 2011

Adding visual appeal: rome2rio’s evolving interface

We’ve spent a lot of time thinking about rome2rio’s user interface. The graphic design has had a major revamp over the last few weeks, thanks largely due to the contributions of my talented sister, Lara Cameron. Lara is now busy running her popular and eco-friendly hand-printed textiles business Ink & Spindle but was previously a web graphic designer. Take a look at this comparison of our UI before and after the makeover and it is clear Lara benefited from some creative, artistic genes that I missed out on.

Old-new-screenshots2

 

The other major aspect of rome2rio’s interface is the interaction design, that is, what is shown where on the page and how the user interacts with the site. Getting the interaction design right is certainly one of the big challenges of building a multi-modal travel search engine. There’s a lot of information to present about the various trip alternatives. Conveying these ways to get from one place to another clearly to the user is challenging. Even regular flight search engines such as Kayak, Orbitz, Expedia or Webjet struggle with the challenge of presenting just flight itineraries to the user. There are different carriers, stopovers, layover times, ticketing airlines, departure and arrival times, durations and prices that need to be shown. Hipmunk is a new valley startup that has focused on some new approaches to this challenging flight result layout problem. 

With multi-modal search rome2rio needs to tackle yet another level of UI complexity as the flight schedules are just one part of the itineraries we present. For a single search such as Melbourne to Stanford, rome2rio presents multiple routes of getting there. For example Melbourne -> MEL -> SFO -> Stanford is one route, Melbourne -> MEL -> SJC -> Stanford is another. Each route consists of various segments (drive, then fly, then drive again), each flight segment has various itineraries, and each itinerary has all of the components described above! 

Presenting all this clearly to the user is challenging. We’ve chosen to use different colors to differentiate the various modes of transport, and hide the flight itineraries behind a hover over pop-out. Each route has a short description like “Fly to San Francisco (SFO)” that explains how it differs from other alternatives. We’ve also decided to make rome2rio’s interface largely map driven so that routes can be easily visualized.

Map-screenshot

The map interface is perhaps the most immediately obvious differentiating feature of rome2rio. It certainly takes a lot of screen real estate (although this real estate is re-used for the flight schedules pop-out) however the value it adds varies a lot from query to query. For a search from one major city to another the map will display routes with stopovers, which may be of interest to the user. However the maps value really comes into play for searches such as Seattle to Yellowstone or Dublin to Le Havre where the visualization of the alternative routes really helps the user understand the tradeoffs between them. I suspect travellers with more flexible itineraries will also benefit from the map interface where they may notice one of the routes goes past a town or attraction of interest and decide to make a detour. 

So, what are your thoughts about rome2rio’s current UI? Too confusing and geared towards savvy, high-tech users? Nice and snappy and easy to use? Do you like the map? Would you prefer an interface without the map, or one where the map takes either more or less screen space? 

We’d love to hear your thoughts!

Advertisements

Snappy results: why performance really matters

We’ve spent the last few weeks working on cleaning up our UI, improving our flight results and increasing performance.

I want to talk a little about performance and how we went about improving it. Why? Because performance, in my opinion, is the most important thing we can work on. Huh, more important than new functionality, better results and a simpler user interface? Yep, let me explain…

First, let’s rewind a little and look at the history of our search performance. The graph below shows how long it takes to get results for a typical search – bigger numbers are worse. We log this automatically every minute of every day to make sure things are running smoothly. 

Rome2rio_perf

As you can see, we’ve had at least three big releases that impacted our performance. And haven’t been trending in the right direction until now.

So why did we get worse? Basically we improved the quality of the results. We have a set of test queries (a few thousand) the we measure ourselves against. That is, we know what ‘good’ results are but we don’t always find them all. So, we measure our actual results against these ‘good’ results, striving to improve over time. So, in the previous major release we improved the results but it cost us a lot in performance. That’s pretty usual for us nerdy programmer types –  there is always a trade-off.

We were really unhappy with the performance after that previous release. It really hurt our user experience because the site felt sluggish to use. It was also hard to demo in front of a crowd – wait time really stands out when the spotlight is on you! When I was showing rome2rio to the cool folks running www.99dresses.com, they apologized for their slow internet speed!

It’s not just about user experience. Bad performance also costs us money – because we need extra servers to scale. Also, remember that we trade time for quality. So, better performance means we can afford to spend some time on finding better results. Wow, improving performance means our site feels better to use (faster results), is better to use (better results) and costs us less money to run.

Do you want to hear about the details of how we improved the performance? Let us know if you do and I’ll whip something up. But let me warn you, it might get a little technical 🙂