You got a driving log consisting of a chain of destination and origin points and times associated with them. How do you sort them within the app?
Paper is simple. App? Not so much
In the paper skeuomorph, the order is clear - you book the oldest trip first, starting from the origin to destination. You continue, and you get nice & contiguous timeline and "origin - destination chain".
Kind of simple. Except it does not really work in app context.
As you accrue trips, you got overhead of scrolling through those - something that is usually sorted by pagination.
Activity stream is such a dominant pattern within contemporary apps - with the most recent items displayed first.
The pattern has its own, by now deeply ingrained default refresh action - pull down to refresh. With the oldest trips shown first, this breaks entirely.
It happens in the best of families
Of course, we are not the only one with this problem. Android version of otherwise excellent Onefootball app has the same issue. As the day goes on, I am interested in results further down the page. Yet, they have only implemented "scroll down to refresh" on Android.
This means that I got to scroll all the way to the top, pull to refresh and then jump back down the list. Only to find out Arsenal spunking a healthy 2 or 3 goal margin, but that is another problem.
If you can't beat them, join them
So, you've got dominant presentation and navigation pattern and one that helps you natively show the objects that are most deserving of attention? Just make the trip log into an activity stream and you're done.
True. Now, how exactly do you sort the trips again? Remember, we are dealing with trips that have:
- time at origin; and
- time at destination.
Keep the line or chop it up?
My natural response was to sort the trips with destination on top. That way you get nice,contiguous line of times and of addresses too.
The only problem I see here is that readers tend to read from top to bottom, which in this configuration means reading "against the grain" with the destination appearing before the origin and in reverse of "time's arrow".
The alternative would be to sort the trips, but give up on continuos line. So that the first line of trip record will always be an origin. In testing, this works well for single trips, but requires reset every time another trip is being read out.
For what is worth, Automatic have also prioritised the continuous line in their trip record. They have also decided to add visual markets for destination and origin on mouse over.
My assumption is that they have done so in order to help the user make mental flip that the thing they are reading first actually occurred last.
You'd think this would be eminently testable problem. I thought so too, but it is eluding my half-hearted attempts to do so.
Yes, I've run both version past 25 users using Verify Preference Test. The results were inconclusive to say the least with equal split between both options. I don't think I've explained the context well, or maybe there is no preference.
I've also done some limited card sorting. With small sample, it is not quite apparent which one is better option.
Of course, we could bucket test it. If we only had enough users to get a meaningful result within a reasonable time-span. More importantly, if only we had clear conversion goal for each variation. It's not like we need to drive clicks to particular trips.
In the end, it came down to launching & learning. Or "fuckit-testing" - where you say fuck it, launch and observe further.
I'll let you know how we got on, you let me know if you have any feedback or input!