Trip Cards for Android

After the official Android style guide was released in early 2013, the TripIt Android app suddenly found itself in dire need of an interaction refresh, lest it lose its coveted “featured” status in the Play Store.

Luckily, we’d had a visual refresh in the works for some time; this merely bumped its priority up a bit. The iOS app had been redesigned the year prior, and though it looked snazzy, we had learned some lessons from it and wanted to avoid the pitfalls inherent to its design when we rolled out the android version. The main design centered on a card-based layout. Prior to “trip cards,” as they came to be called, all itinerary data was in table cells. Functional, but hardly elegant, and this gave us the opportunity to re-prioritize some of the data types you’d see on (for example) a flight detail screen.

The trip card concept is that every plan you have — flights, rental cars, hotels, etc. — are on cards, which you can flip through by swiping. Simple, on the face of it, and yet after a while we found that our iPhone users were having trouble navigating. In particular, we noticed the following problems:

  1. They really wanted the trip overview screen back. We’d assumed that being able to quickly flip through “plan” cards would obviate the need for the that screen, but as it turns out, users found it really useful and let us know when we took it out.
  2. The list of upcoming trips (the screen that could launch you directly into one of your incoming trips, skipping the interstitial cards) was difficult to locate — and when you did find it and clicked a trip, you’d suddenly find yourself back in “classic TripIt” view, with no cards anywhere to be found!
  3. There was no way to view past trips. Again, something we didn’t really think people wanted, but it turns out this is pretty important. Many of our users use their TripIt itineraries as a reference when they submit expense reports after the trip.

To solve the first problem, we needed to figure out the best way to show a trip overview inside the card timeline. The first thing I tried was to make every trip a “stack” of cards, with a summary card on top. When the summary card is tapped, the deck unstacks itself and all the plans line up in proper chronological order:
stacks

This ended up being too difficult. It was almost impossible to see the “unstacking” animation when it was displayed on an actual device. So, nobody made the connection between what they were seeing on the screen and a “stack” of cards.

The next strategy was essentially to take the existing trip overview screen, which was just an itinerary in list form, stick it on its own card, and have the list items “fast-forward” to the position on the timeline containing the appropriate card:

fastforward
This seemed to work pretty well. Most of the existing TripIt users we tested this on grasped the concept immediately, because they were already used to tapping on a plan on the overview screen to drill down to the plan details. But while testing, we realized we had an additional problem: people really hated having to swipe through all the plans of one trip to get to the next. So, we needed to find the best way of collapsing non-current trips down to just their summary card (current trips are always expanded — ideally, the first thing you should see when you launch the app is your next-upcoming plan). After a ton of back-and-forth between nearly everybody involved, plus several rounds of RITE testing, we decided that the itinerary items of trips starting more than a couple days in the future, or ending more than a couple days in the past, would be hidden from the main timeline. The plans go to a second-level timeline containing only plans from a single trip, and are accessible via that trip’s summary card on the main timeline. It’s much easier to show you; I’ll get there momentarily.

Since we were using a list of trip plans as the first card of a trip, it made sense to use that same pattern to solve the issue of the difficult-to-locate list of upcoming trips. But, keeping in mind that we also had past trips to display, this was a little difficult. I’ve summarized the several rounds of RITE testing we did below. You can view the exact prototypes we used to conduct the testing to get a much richer understanding of everything I’ve been talking about here — note, though, that we did test these prototypes on mobile devices, not on laptops, so the experience was a lot closer to that of a native app.  As always, if you have any questions about prototyping or rite testing, leave a comment below or shoot me an email.

Rite Testing

Round 1

Round 2

We tested two hi-fi versions in this round:

  • Version 1 contains all current plans on the main timeline (similar to v2 from round 1)
  • Version 2 removes past plans in the current trip from the main timeline (similar to v3 from round 1)

We found that people were having trouble discovering the drawer nav menu, which contains the link to the list of upcoming trips. They’d hit the screen title expecting the drawer to open, but instead got the view filters. This led to people not understanding the timeline fully (past trips were completely undiscoverable).

Round 3

We tested the same two versions in this round, but removed the view filters, linking the screen title directly to the nav drawer control. We also removed “teams” from the nav drawer, since it was part of TripIt’s enterprise offering that most normal users wouldn’t see, and several participants asked about it.

We found that participants were able to discover the drawer, and we started noticing a preference for the version that removed past items from the main timeline. We also found that people didn’t understand the concept of the swipable timeline and thought they had to go back to the itinerary card to navigate to another plan on their current trip. Past trips remained undiscoverable. Additionally, when the prototype was launched with the drawer open, everyone’s first action was to tap “upcoming trips,” which negated the utility of showing the next-upcoming plan immediately on launch (behind the drawer).

Round 4

In this version, we started the prototype from the device’s home screen and had participants launch the TripIt app. We launched the app without the nav drawer already opened, and instead added an overlay explaining how to swipe between plans. We also added a link to “past trips” in the nav drawer.

This was the winner! Once people got past the help overlay, they understood that what they were seeing was their next-upcoming plan, how to swipe between plans, and how to view past trips by clicking “past trips” in the nav drawer.

Leave a Reply

Your email address will not be published. Required fields are marked *