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.
Continue Reading →