Tag Archives: mobile

usability grades: checking the flight status on an airline

Posted on by
Reply

I’ve tried checking the flight status from a mobile device for a number of different airlines this year.  Both flights I was taking to check they are leaving on time and for flights arriving with friends/family.  I then tried a few others for the purposes of this blog entry.  Care to guess which of these airlines inspired the blog entry?

Remember the goal is simple:
Check when a flight is departing or arriving given two airport codes for the current date.

Alaska Airlines – alaskaair.com
Steps:

  1. Click flight status
  2. Defaults to today, but the only option is flight number.  Click “lookup” to get the flight number
  3. Enter the two city codes.  One of mine was SAN (San Diego).
  4. Alaska comes back with a list of cities beginning with “san”.  The first is San Antonio. Um no. I meant San Diego which has the airport code I typed in.
  5. Then I have to pick month/day/year from drop downs. No shortcut for today?  No inference of the year?
  6. After all that work, Alaska shows Shows me the scheduled times of the flight.  I now have to remember the number and retype it on the flight status page

Grade: C.  This was a tremendous amount of work to get the answer. They did have a mobile view and each page loaded fast though some were 24KB – quite large for a mobile view.

American Airlines – aa.com
Steps:

  1. Wow there’s a lot of choices here.  I think the one I need is “Gates and times/wifi”.
  2. Enter codes with option to look them up.  Assumes we are talking about today.
  3. Lists departure and arrival times

Grade: B.  The double take at all the options wasn’t obvious, but possible to figure out.  Everyone else calls it “flight status” American.  Why can’t you?

Continental – continental.com
Steps:

  1. Click flight status
  2. Click “don’t know flight number”
  3. Enter two cities, assumes today
  4. Shows list of all scheduled flights.
  5. Click the one you want and shows departure arrival times.

Grade: A. Lots of options and easy to use

Delta – delta.com
Steps:

  1. Click flight status and updates which is conveniently the first option
  2. Enter codes with option to look them up and select the radio button for cities instead of flight number.   Assumes we are talking about today.
  3. Lists departure and arrival times

Grade: A-.  I shouldn’t have to select the radio button.  Once I type in an airport code, it’s apparent that is the option I want.  Presenting me with the screen with an error that I didn’t enter a flight number is less friendly than it could be.

JetBlue – jetblue.com
Steps:

  1. Click Flight Status
  2. Select departure and arrival cities from a drop down menu.  I suppose this is easier than expecting people to know/lookup the code, but it took me a couple tries to select the correct entry from the drop down.  Defaults to today.
  3. Lists departure and arrival times

Grade: B+. I have to subtract for the drop down.  It assumes extra and unnecessary dexterity.

Southwest – southwest.com
Steps:

  1. Click flight status
  2. Choose cities from the same style pulldowns I didn’t like on JetBlue
  3. Lists departure and arrival times

Grade: B+. Same reason as JetBlue.

United – united.com
Steps:

  1. Click flight status
  2. Assumes talking about today.  Enter codes with option to look them up.
  3. Lists departure and arrival times

Grade: A. No unnecessary obstacles.

    Conclusion
    Quite the range in usability here.  I was happy to see that Alaska was by far the worst.  They prompted this blog post after all.

    Live from TSS-JS – Mobile Development with Mark

    Posted on by
    3

    Currently attending “Comparing, Contrasting, and Differentiating Between Mobile Platforms” by Mark Spritzler, a fellow CodeRanch moderator.  The presentation is in part an open discussion with the audience of what people have tried and works well in the Mobile environment.

    1.  What is out there?

    • Android OS (Java)
    • Apple iOS for iPhone/iPod/iPad
    • Web applications with custom UI for mobile applications.  CodeRanch currently offers a mobile web version of the website
    • J2ME (not common)
    • BlackBerry (custom Java)
    • SymbianOS (C)

    2.  Android OS Review
    Built by Google and uses Java and can run Flash.  UI built with declarative UIs using XML primarily and supports visual tools such as Droid Draw and/or Interface Builder.  MVC-like architecture with view as XML, and control/model as Java classes.  The API is quite open so there’s a lot of ability to customize for developers.

    There is currently a large variety of Android devices so splintering of the code base could be in the future.  Some devices cannot upgrade the Android OS, leading to permanent branching of code base.

    Also, Android requires a lot of manual work to integrate with a database, such as SQL Lite, whereas Apple iOS has this built in.

    3.  Apple iOS Review
    Built by Apple and uses Objective-C, and cannot run Flash.  Developers must manage memory manually.  The API is completely proprietary and there are limit tools for developers.  For example, the developer must have a Mac and use an xCode.  Closed APIs but Apple promises stability (although it did change in iPad with split/view feature).

    Dicussion on Apple’s strigent application approval process followed.  One participant commented that they waited 1-2 months for Apple to approve it.  Apple has also stopped approving ‘pointless’ apps.  I asked Mark if he thinks the delays are worth the improvement in quality, to which he replied that it does lead to better applications.  He also informed the audience that Apple wants you to use certain visual controls in particular manners to help build a consistent UI, and may reject applications based on improper usage.  Apple sometimes comments on why applications are rejected but not always.

    4.  J2ME Failure Review
    Idea was to develop using Java and runs on a variety of devices.  One of the major problems is Sun certified J2ME mobile phones that didn’t properly or fully implement the spec.  Also, lead to splintering of code base and very inconsistent results across devices.

    5.  Native vs Web applications
    Web applications have greater reach since they can run on many devices, but have weaker performance and require the developer to self-promote them.

    6.  App Generating Frameworks
    Build mobile applications from predefined templates using a CMS system often entered in a web browser, such as MobileRoadie, but it is a paid service.  Builder frameworks (often open source) that generate mobile applications based on existing code including Appcelector, Rhomobile, PhoneGap.

    Write once and run on many devices through generation.  They may have limited functionality since they use a subset of features available in the language.  Multi-touch is also very limited in Android over iOS.  HTML5 does support location-aware so it can help in application generation.

    Conclusion
    Mark ended the presentation with an open discussion asking people to share their own mobile development experience.  He pointed out that there a lot of pros and cons to using different mobile platforms and mobile devices, and you should consider the resources on hand when deciding how to proceed in development.

    javaranch forums go mobile

    Posted on by
    Reply

    Want to know what went  on behind the scenes of JavaRanch’s mobile site creation?

    Timeline

    • January 2009 – We started talking about how poorly the site renders on a BlackBerry
    • July 2009 – I got a BlackBerry for work.  And ugh.  The forums do look horrible.
    • August 2009 – Tried out BlackBerry emulator and explored the minimalistic approach possible to creating a mobile version (see next section.)  That didn’t work and I wasn’t prepared to spend a lot of time on it in the summer.
    • mid November 2009 – Start discussing design/UI.  Noted it took 4 minutes to edit a post via BlackBerry.  Very excessive.
    • late November 2009 – Restart development using approach #2.
    • December 2009 – Weekly deployments to production using “secret URL that only the moderators know” for beta testing.
    • January 3, 2010 – Mobile URL announced to public and added to e-mail notifications

    Approach #1 – Mobile CSS

    My original theory was that the easiest thing to do would be to just add a mobile stylesheet that would hide some columns.  It wouldn’t shrink the pages of course.  But as a first step: slow and readable beats slow and un-readable.  I quickly ran into some problems:

    1. The BlackBerry doesn’t like mobile stylesheets.  Bushido covers the options in a lot of detail.  Search for “Alright, alright. Gimme the code already!” for the ugly CSS imports.  The real problem is that you don’t have a mobile stylesheet with this technique.  You have a stylesheet that everyone uses called mobile and the main stylesheet which cancels out the main one.  Developing for this is crazy as you are compromising what stylesheets appear to do.  And it will break when RIM finally gets their act together.
    2. JForum uses a largely table based layout.  This doesn’t go well with CSS for hiding things.
    3. The table layout made changing anything incrementally very difficult.

    Approach #2 – An actual mobile site

    This approach is definitely more mobile friendly as the pages are designed to be mobile sized.  They are also written from scratch and get to use <div>s.  Basically what I did was take the real page, pick the most important parts and create div layouts for them.  Once I had one done, the rest followed easily.  There are a few limitations documented in the JavaRanch announcement site.  But overall, I’m happy with it.  It is certainly way better than what we had before.  And we will continue to tweak it.

    Testing

    I tested locally using the BlackBerry simulator and later with the Droid emulator. I also tested using my real BlackBerry after deploying to the test server.  The aggravation of using a real mobile device isn’t captured on the emulators!  It is possible to use testiphone.com as an emulator.  It is not completely accurate though.  In particular, it didn’t show the viewport problem.

    <meta name=”viewport” content=”width = 320″ />

    We also tested on a variety of real devices.  Many moderators tested on their personal handhelds and we got a good variety that way.

    I’d like to thank a few people in particular.  Thank you to everyone who let me test on their device, especially

    1. Gregg Bolinger – for instant feedback in testing the viewport fix at 11pm on both the iPhone and the Droid.  (And more testing than anyone else.)
    2. A few coworkers (at my real job) – for the wide variety of devices I got to put my hands on.  The simulators really aren’t the same.  Five minutes on the real handheld at lunch really helped.
    3. Chuck from the NYC Spin for offering his tiny touch screen device (the smallest I’ve tested on) without my even asking!

    Marketing

    You know how sometimes marketing picks a ship date and it overrides “doneness” ?  Well, I really wanted to announce this on January 3rd – the one year anniversary of us being on Java based software.  There are some things that I wish were more resolved like why Google Mobilizer is injecting itself in links. Overall, I think it is in good shape and ready for people to try out though.

    —

    What do you think of the new site?  Share in the JavaRanch announcement thread or as a comment here!