Top 5 Mobile Fails From My Google IO Trip

Google I/O was an amazing conference - everything I had hoped it would be.  With my emphasis on mobile technologies, having an entire day and track devoted to the Android platform was exciting! But while the conference itself delivered a home run, some of the peripherals left a little to be desired on the mobile front.  So today I present my top five mobile fails from my Google IO trip.

5) Mobile Boarding Documents Unavailable
When I first reserved my flight from Fargo to San Francisco (with a stop in Denver), I was surprised to received this message from United Airlines:

Mobile boarding documents are not accepted at one of the airports in your itinerary. Please visit united.com/mobileservices to learn more and see a list of airports currently accepting mobile boarding documents.

United has been using mobile boarding passes for more than two years now.  The technology to read in the boarding passes is cheap, and doesn’t require any more training than the standard barcode scanners.  So why is United, and all of the other airlines for that matter, so slow in adopting them on a nationwide basis?  I am not sure if this is a limitation at the gates or at the security checkpoints, but in 2011 there is on reason why mobile barcodes are not accepted at every international airport in the United States.

4) Conference WIFI and 3G/4G signal
Even though I was expecting this going in, it was still a disappointment.  With 5000+ attendees at the conference, each of which had at least two mobile devices, the WIFI networks in the conference center were over-saturated to the point of being literally unusable, and the 3G/4G connectivity was limited at best.  I am looking forward to someday going to a tech conference where we don’t need to listen to constant public addresses asking people to turn off their mobile hotspots because it is degrading signal performance in the center.

3) QR Codes in Airport Not Readable
If you are going to spend the money on a large advertisement in a central airline hub, you should probably do a little bit of user testing to make sure that it actually works.  In the Denver Airport, I noticed this ad in the terminal.

There are a couple of things that I noticed immediately that are apparent even in this picture.  First of all, the QR code is rather dense, which means that a cell phone will need a higher resolution camera to be able to decode it.  However, the QR code was big enough that this shouldn’t have been a problem.  The other issue, and the one that rendered the QR code unusable was the fact that it was behind a pane of class in a area without decent lighting.  You can see the reflection from the windows across the hall in the glass.  The ad itself was backlit, so it was easy for us to see it… but the ambient light and the reflection from the hall made it impossible for our phones to decode the QR code.  We tried it on several different phones, including the Droid Incredible which sports an impressive 8MP camera.  None of the worked.  I tried again on the return flight, to no avail.  I never did find out what this QR code resolved to.

2) Bad QR Code Bling
The last example was bad enough - but I am assuming that the code at least worked and it was just the environment that made it unusable.  For my next example, there is nobody to blame except the company itself.  After one of the keynotes, as 5000+ attendees were trying to all crowd onto the same escalator at once (yeah, that was fun), there was a group of people handing out business cards. On them they clearly have a QR code, along with the instructions, “Scan this code using your Android device to install.”  So of course I tried it.  The QR code resolved to an Android Market link… but the app that it was looking for didn’t exist on the Market yet.  It turns out that the link became valid the day after the conference ended.  The only thing that I can figure is that the application was submitted and they assumed it would be live in time for the conference.  But you know what happens when you assume…

1) Samsung Galaxy Tab Timezone
One of the coolest things about Google IO was when they announced that every attendee would be receiving a free 10.1 inch Galaxy Tab courtesy of Samsung. These devices are not even released yet - they come out in June.  It was like nerd Christmas as we all stood in line to get our tablets, opened the boxes, turned them on, and became collectively confused when the time zone was set to GMT +00:00 with no apparent way to change it.  It turns out that the vast majority of us made the mistake of selecting the “automatically set the time” option when setting up the tablet.  Unfortunately, this setting is actually used (I believe) to set the time based on carrier signals in a 3G version.  Our tablets, however, were wifi versions, so there was no carrier signal to send a timestamp to the device.  Without it, it simply defaulted to GMT.  OK, no problem, just change the setting, right? Wrong.  As luck would have it, there is no way to change this setting once it is set.  Samsung actually disables the setting, leaving users stuck in GMT for eternity (or at least until they get smart enough to go to the market and download an app that will change it for you).  This seems like a pretty big user interface oversight for the wifi only versions, which makes me think that most of the testing and development strategy was focused on the 3G models.  Granted, I am not complaining - even with GMT issue this was still a pretty sweet giveaway.  Couple that with a free 4G hotspot from Verizon with 3 months free service and a Chromebook on the way, this was a pretty decent conference for giveaways!