Following a tweet link from Smashing, I read a pretty good article by Shanshan Ma on UXmatters discussing the act of Flight Status checking on mobile devices. I’ve excerpted it below but couple of things.
First, interestingly, the article specifically asks for comments, yet (even when signed in) readers are never presented with a comment box. Frankly, I’dve just posted my comments there but now I feel compelled to write here.
Second, relative to the article itself … of all the sites presented, they all stink. The problem with Flight Status checkers is that fundamentally they all use similar methods, similar input tools, to acquire the data. What this means is that you get a screen with several selectors and several free-type inputs. Despite advances in the UI tools for both selectors and typing, they are still fundamentally difficult to use, particularly for situations that many users find themselves in when using these services (in my own case, I found myself driving in 6 inches of unexpected snow in NYC this October and trying to get a JetBlue status).
One of the nicest things about having been in the industry for so long is that I can reminisce and consider technologies that we don’t often see today but that may still have applicability. In this case I am referring to the “deck” principles used in HDML in early versions of phone browsers. The deck principle basically provided that multiple pages of data were transferred with each page call, reducing the number of times callbacks were required and increasing the individual interactivity by allowing data to be shuffled between “cards.” Couple that with good Ajax utilization, and you might have a pretty neat app.
For a good flight status checker to work, think in terms of the actual UI. In my own incident, I needed to not have to enter keyed data – just click and fire with easy-to-hit buttons and less on-screen information. What I propose is something more like this (and I apologize, I sketched this out real quick just now and sent it with my phone cam).
Here you get no more than a couple of selections per screen, always presented as click buttons. The beauty is that you can use Ajax effectively to pre-load all of the subsequent screens with minimal data transfer. For example, by coupling the Location Services data of the current location along with the user selections, you’d likely be able to guess the probable dates and flight numbers (no more than 3 days future, any given airport, within a 6 hour time window, the lookup is no more than about 40 flights).
Another problem I faced was that all of the interactions used POST, which means that it was impossible to go backward and still have the data intact (so I could modify one small bit and try again), forcing me to re-enter 6 fields of data each try. Using the hashtag approach, you’d also allow for backward and forward runs through the history.
Thinking through the user experience is part visualization, part interaction, and part data process and information architecture. Trying to remove any part of the puzzle leaves something to be desired in the final product. Flight status checkers are a great utilization of mobile web, but THINK the process, use it, determine what can be made better, and do it.
The article…
By Shanshan Ma [November 21, 2011] on UXmatters.com
Users visit mobile sites not only to consume content, but to get things done. Let’s take air travel as an example: tasks that users often find themselves performing on an airline company’s mobile site include checking flight status, checking in for a particular flight, and searching for and booking a flight. How does mobile user interface design support task completion? What are the optimal ways of communicating and displaying interactions on mobile sites? With the aim of discovering optimal ways of designing simple interactions on mobile devices, I examined the task of checking flight status. I’m hoping that my analysis sheds some light on this topic.
Travelers can initiate a status check for a flight by locating the flight using its departure date, plus either the flight number or the departure and arrival city or airport for the flight. Sounds simple enough, right? Analyzing this task, here are the steps that are involved in checking flight status:
It’s fairly easy to support this task on the Web. Simply present both options on a Web page, and users can proceed according to the information they have about the flight—whether flight number ordeparture and arrival cities. While it’s easier to type a flight number than city names or airport codes, users tend to remember flight cities better than airport codes or flight numbers. However, there are a few interesting details that you should consider: