CS and the City Sean Lynch

How Microsoft and Nokia can avoid smothering their spark

At CES this month, Microsoft finally accomplished the impossible. Suddenly, everyone was talking about the Windows Phone. Of course, Microsoft owes much to Nokia for that result, given their gift of the acclaimed N9 hardware in the form of the Lumia 800. Unfortunately, nearly as soon as Microsoft/Nokia found traction, they immediately began to piss it away by introducing a raft of additional models with no release dates and vague technical differences. No sooner had they gain the limelight than they committed the cardinal sin of the mobile phone industry, ambiguous product line growth. I’m hoping it’s not too late for them to recover.

It’s my humble opinion that the N9/Lumia is the most beautiful phone hardware outside the iPhone. I’m intimately familiar with what Android has to offer, owning several Nexus-series phones myself, but their recent trend of monolithic form factors and hacky case tumors means the award for best design was very much up for grabs. The Lumia is not flawless, it still has quirks, but it’s a beautiful device only requiring iterative improvement rather than a ground up redesign. And it’s largely because of the release of the Lumia 800 that Microsoft is finally getting some of the smartphone market mindshare.

The 800’s availability is pretty sparse, with no American carriers (Microsoft will begin selling it unlocked next month from their stores). So to even have the level of excitement for an essentially unreleased phone is an accomplishment in itself. When they announced the 800, they also announced its chubby younger brother, the 710, which targeted the lower end of the smart phone market. This was their first infraction, but with only two devices that look drastically different, they could be excused.

But at the same conference, while the attendees were having their very first hands on with the 800, Nokia went and announced the next version, the Lumia 900, with no date (it’s rumored to be March), effectively killing any chance all but the most wallet heavy of potential early adopters will be picking up an 800.

While the replacement of the 800’s pentile screen on the 900 is a welcome fix, the fledgling Windows Phone market would have been happily served by the 800 for at least a few more months. Don’t let the tech spec nerds fool you, LTE just does not have the coverage to be a deal breaker at the moment.

And then today, only weeks after CES, they slipped another model into the pipeline: the 910, rumored to be released only another two months later in May. The difference? An additional 4 megapixels on the camera.

In a matter of weeks, Nokia went from having the flagship Microsoft phone brand to having a technically ambiguous family of 4 models, half of which aren’t released nor do they have confirmed dates. As a result, any brand awareness for the Lumia 800 is in danger of becoming completely diluted.

The tendency for consumer electronics companies to do this is shocking. But their insistence on a massive catalog of indistinguishable devices is one of the primary reasons that these manufacturers continue to lose ground to Apple.

Admittedly, some companies are realizing their mistake. HTC, one of the worst offenders (you’re forgiven if you don’t know the difference between the HTC Bland, HTC Dull, and HTC Generic) as well as Acer have both said that the low-quality, many-variations strategy is not working. The confusion introduced by so many competing products with minor (if any) technical differences is a classic example of the paradox of choice.

Handset manufactures (as well as most large scale consumer electronics companies) need not rely only on Apple as the only model of success. Take a look at any car manufacturer. Any given company has a limited number of models, but with high value brand names. For example, the Honda Civic. Everyone knows what to expect from a Civic because it has decades of brand credibility. The average person can probably pick the Honda Civic out of a line up of all Honda cars. They also can give a reasonably informed explanation to how it differs from, say, the Honda Accord. No one, outside the editor of your favorite gadget blog, is going to be able to differentiate between the 51 different HTC models.

Not surprisingly, the name of the product caries a lot of value with it. Consumers start to recognize it in multiple contexts: people on the street, friends that own it, TV ads and product placements, online buzz, and eventually, comparison shopping their next phone purchase. The name can also support minor technical variations: You can always customize your Honda Civic or your Macbook Air.

Now, here’s the trick. If you do it right, you end up with a recognizable brand name that has a lot of consumer value that you can then use to drive sales as you release hardware updates. What you don’t want to do is suddenly try and use that brand to sell a dozen of different devices, as you completely dilute the importance of the brand; it’ll go from “Awesome product a few of my friends have and love” to “generic term for every product that company sells”. Just look at the Motorola RAZR. It was launched in 2004 and was a massive success before smartphones began to take over. But the brand became diluted with half a dozen different models in various configurations, not to mention hangers-on in the form of the KRZR and ROKR (the ill-fated predecessor to the iPhone).

If you do it right, with each hardware update, you’re moving the legacy of that name forward. You don’t need to do a massive press conference the way Apple, but make a big deal that the new one is coming and why it’s better than the previous model (and it does have to be improved – a slightly updated camera doesn’t cut it). Samsung is actually getting the hang of this with the Galaxy. Microsoft needs to follow suit.

For Microsoft and Nokia, the recovery is easy: kill the multi model strategy and build brand recognition around a name or family of names.

  • First, Pick the name for your flagship. Lumia doesn’t completely suck and already has some value.
  • Second, make it clear that the 710 is the “budget” brand. The MacBook vs MacBook Pro. The Civic vs the Accord. Lumia 710 vs 910 is too subtle.
  • Third, pay attention to the reviews of the 710. They’re certainly not all positive, but the reviewers are giving a lot of concrete and addressable feedback. Fix the problems, add the features that are obviously missing, and learn from the mistakes.
  • Finally, bet big. They may have gained some buzz, but Microsoft and Nokia still need to bet big to compete against the dual titans of iOS and Android. Given that you can’t even get the Lumia 800 from any US carrier, it’s obvious they still need to figure out all the partnerships and marketing. They’re going to need to be aggressive to get customer and carrier traction. Microsoft should be giving these to any developer that asks and Nokia should be cutting margins to get these into as many hands as possible. They need to be aggressive (On being aggressive in a crowded hardware market, see the Kindle).

All signs indicate that Nokia and Microsoft have finally found their breakthrough device, their spark. For anyone that’s tried to start a bonfire before, you know how easy to smother that early flame. But with a focused strategy, they have the potential to grow the Lumia into a roaring fire.

Android, the Facebook SDK, SSO, and You

There seems to be near universal misunderstanding of Facebook’s Android SDK and the single sign on (SSO) feature Facebook added late last year. I originally wrote a response on Stack Overflow detailing the fix but I didn’t realize the connection to SSO at the time. I’m hoping this post can summarize the problem and solutions for the mass of similarly confused developers who get stuck here.


In November 2010, Facebook announced that they’re enabling Single Sign On in the Android SDK. Applications that take advantage of this feature will allow users to skip re-entering credentials and dive right into the action. What they do not mention is that SSO isn’t a feature developers opt into, it’s actually on by default. However, it only changes the way the Facebook SDK works IF the Facebook application is also installed. This causes the problem that most developers (including myself) see when they first set out to build an application.

The issue

The typical description of the problem goes something like this: You’ve downloaded the SDK and your application is running perfectly with shiny new Facebook authentication on the Android emulator. But when you deploy it to a device, it no longer works. The app loads but the Facebook login dialog disappears instantly. If you’re more familiar with Android development than I was at the start, you start up your copy of adb logcat while your application is running and you see logs that look something like this:

D/Facebook-authorize( 2194): Login failed: invalid_key<br /> W/System.err( 2194): com.facebook.android.FacebookError: invalid_key

At this point, you Google for solutions to the issue and quickly start pulling out your hair out at the number of people reporting this issue with no apparent fix. The problem is actually very simple, though not immediately obvious. The problem is that, when deploying your application to the device after developing on the emulator, you’ve inadvertently and implicitly enabled Single Sign On because your device has the Facebook application installed. This is why one of the reported fixes is to uninstall the Facebook application. Your emulator does not have the Facebook application installed (though the Facebook SDK includes it if you want to install it), but your device does, thus triggering the SSO code. And SSO has some special configuration requirements that non-SSO does not which causes the invalid_key error above.

Fixing the Issue

There are a few different ways to tackle this problem.

1. The ugly: Uninstall the Facebook app

Don’t do this. You’re not going to be able to ask your users to do the same anyway. The only reason this works is because the SSO functionality is triggered by the presence of the Facebook application and this simply removes the possibility of using SSO completely, which is also a crappy user experience.

2. The bad: Opt-out of Single Sign On

If you want, you can actually have your application skip SSO completely. You probably don’t want to do this, but it’s a reasonable solution if you’re convinced you do. To do so, you need to modify the code calling Facebook to specify that you want to handle auth on your own. You do this by passing FORCEDIALOGAUTH value into the authorize method’s activityCode parameter.

3. The good: Set up Single Sign On properly (recommended)

Unless you have a good reason not to, you should set up SSO. It’s a bit more work, but it’s the best experience for your users.

Buried in the Facebook documentation is a mention about hash codes. Although it’s not obvious in the documentation, Single Sign On requires applications to provide a Key Hash or certificate (I use them interchangeably) of the signature used to sign the application to Facebook. This is used as part of the validation with SSO. When applications are built by the Android development tools, they’re automatically signed using a debug keystore. You need to use this keystore to generate the certificate. Details about the Debug keystore are available in the Android Documentation – Signing Applications.

In order to provide Facebook with information about the signature, you need to pull it from the keystore. On OSX, you do this in the terminal with the following command:

keytool -exportcert -alias androiddebugkey -keystore ~/.android/debug.keystore | openssl sha1 -binary | openssl base64

This generates a short string of characters (which may include characters such as ‘=’ or ‘/’) that identify the signature. This is the certificate or Key Hash as Facebook calls it. Once you have this, you need to give it to Facebook.

Find your application on Facebook’s Developer page (or create a new one if you haven’t set one up already). Once you’re in the application summary page, choose ‘Edit’ on the Settings banner and then pick ‘Mobile’ on the left-hand side. Under the Android section, you’ll see a box for Key Hash. Paste the certificate string from the command above into this box and hit save. Give it a few minutes to propagate and try running your application again. The invalid_key errors should disappear. Keep in mind, when you sign your application for distribution, you’ll have to generate another certificate like you do here and provide that as well.

SSO Weirdities

SSO isn’t completely smooth sailing though, there are a few issues to watch out for.

1. authorize() always shows a page, even if the user is authorized
As far as I’m concerned, this is a bug in the SDK. The workaround is to store the token after authorizing the first time and simply use that instead of calling authorize again while isSessionValid() is true (Stack Overflow has a great example of how to save the access_token using Android’s PreferenceManager). However, unless you want to request an offline_access token, the token will only be valid every 24 hours.

2. Different Access Token formats
The token received from SSO applications are of a different format. There’s a bug open on Facebook’s bug tracker about this, but they can’t seem to track it down despite it being easy to replicate. This isn’t a huge issue, but unfortunately, you won’t be able to parse the user ID of the Facebook User out of the SSO token the way you can from standard access token format

3. UI is inconsistent between SSO and non-SSO
Non-SSO uses a nicer pop-over dialog to show the authentication panel while the SSO panel slides in from the right (and back out to the right after the user finishes). There doesn’t appear to be a way to change this UI, at least without hacking the SDK code directly.


To ensure the continuity of this blog’s timeline, let me announce that Friday last week was my last day at Google and I’ll be starting on a new project, the details of which I can’t go into yet, but I’m looking forward to when I can.

I’m not planning on talking any further on why I left Google as the blog post you tend to see from people leaving is almost cliche. But I will say that I absolutely loved my time with the company and could see myself returning some day. For now though, greener grass :)

Southwest Hates Its Customers (‘ Data)

I’ve been a user of AwardWallet for a couple months now, a site that keeps track of many of my travel reward programs. You can think of it as Mint.com for loyalty programs. It turns out that I’m far more likely to participate in programs and actually be loyal to the brands if I can monitor my account status.  AwardWallet isn’t perfect, but it serves a large need I have.

Unfortunately, Southwest either doesn’t understand this benefit, or doesn’t actually want its customers to use the loyalty program because they’ve blocked AwardWallet from collecting this information on my behalf.  The team emailed me this week with the disappointing news:

Dear Sean,

We are writing to inform you that unfortunately Southwest is no longer allowing us to pull data from their website anymore. You can update your balance manually and you can use AwardWallet to auto-login to Southwest’s website. From now on you need to track the expiration date of your Southwest miles manually.

we are writing to inform you that unfortunately Southwest is no longer allowing us to pull data from their website anymore. You can update your balance manually and you can use AwardWallet to auto-login to Southwest’s website. From now on you need to track the expiration date of your Southwest miles manual

Southwest’s response to another AwardWallet user was equally frustrating:

We regret your disappointment that Southwest does not participate with third party companies who offer frequent flyer information on their web sites. Our reasoning lies in the fact that we can only safeguard a safe and secure program by keeping our Customers flight credits and Awards within our own internal system. While Award Wallet’s intentions may be genuine, by allowing them to have access to Rapid Rewards Members’ account information, we could potentially jeopardize not only our program’s integrity, but our Members’ personal information.

The fact that I have 11 Rapid Reward points (I only need 5 more for a free flight!) is not, in any world, hyper secure information. If I as a customer, choose to have that information aggregated in a way that provides value, that is my prerogative.  I’m convinced they recognize this too and that their concern is almost certainly that I am giving some third-party my login name and password in order to collect this information.  This I do recognize as a security issue, but it’s a problem with an easy and well recognized solution.

What I propose is a MicroFormat for APIs.  I’d like to define a protocol to increase the use of loyalty program data with the follow features:

  • REST API for querying both the current status and the history of transactions for any given rewards program.
  • Simple JSON data structure with extensible fields so that programs can customize to suit their needs
  • OAuth based authentication
  • (Optional) PubSubHubbub-based notifications for status updates

If every loyalty program adopted this, web services and iPhone apps the world over could quickly expose this information to users in a meaningful way, and instantly make adoption of those programs a lot more valuable to their customers, and ultimately make those customers a lot more loyal.

I’d love to see Southwest actually push toward a solution that enabled this sort of usage.  Looking at the AwardWallet forums, there’s obvious demand from power users.  Seems to me, they might be the types of customers that Southwest would consider worth pleasing.

Saying so long to Flickr

My annual Flickr pro account renewal came up last month.  Looking at my renewal history, I can see that every time I’ve renewed it, I’ve never done it proactively.  I’ve always a month or so after my previous year’s subscription had expired.  This year was no different.  I let it expire, only to have to renew it again to unlock some of my older photos that I didn’t have a backup of (silly).  This time around, I seriously considered leaving it unrenewed.  I just don’t use it anymore.

I’m what I would call a long-term Flickr user.  I’m relatively sure I had my Flickr account before GMail.  I payed for the pro upgrade before I ever paid for generic web hosting. Flickr was great and I evangelized it to all my friends, as is evident in all the abandoned accounts on my Flickr friends list.

I was attracted to Flickr for three reasons:

  • The ability to publish my photos for my friends
  • Hosting photos for my blog
  • Getting feedback from the community on the photos I took

But four years later, the world has changed.  Now all my friends use Facebook, because they don’t have to pay for it, because Facebook actually innovated on photo sharing by indexing by the people in the photo, and because it integrates into a tool my friends already use.  For hosting photos, I can use the same web-storage I’m paying for already. Though the reality is that I simply don’t blog or photograph as much, and so neither of those are that important to me anymore.

The more revealing part is that, in those four years, Flickr hasn’t changed at all.  The only event that brought me back to Flickr was the account merger with Yahoo.  The only news I heard was the half-assed support for video and the addition of the Yahoo logo.  Beyond that, it’s stagnated. Where is the Twitter short-links?  Where’s the first party Facebook app?  (Edit: found both after digging through the profile settings, foot appropriately in mouth). I’m asking partially because I’m a geek and I love playing with new features, but also because this complete lack on investment on Yahoo’s part has made it so worthless that almost all of the people who used to engage in the photos have now gone else.  My pro membership doesn’t buy me anything.

Unless something major changes, this will be the last $24.99 (a number that, despite Moore’s law, has stayed constant this entire time) I give to Yahoo. I’m not rushing to Picasa Web either.  They’re just as guilty of price stagnation as Flickr (though Face recognition is very cool).  For now, I’ll stick with iPhoto and Facebook (which maintains their own iPhoto plug-in I might add). There’s plenty to do in this area, so I’ll be waiting for someone to come along and impress me.


For anyone trying to get their photos off of Flickr, take a look at PhotoGrabbr, a tool for downloading entire Flickr albums for the Mac. I definitely won’t be dealing with photo lock next year.