I wrote a post a couple of weeks ago in which I whined about the difficulties in creating a good user experience for a mobile client that authenticates with an OAuth provider.
I was pleasantly surprised (and a little honoured!) to get a comment on the post from Chris Messina reminding me that the way to address the usability issue isn’t to revert back to using usernames and passwords, but for us to all work to improve the usability of OAuth.
Sufficiently inspired, I went back and had another go.
It’s still not quite there, but I think it’s better.
As Andy pointed out last time, not everyone has a Windows Mobile device to try my code on, so this time I tried recording a screen capture of it.
Unfortunately, the Fire Eagle OAuth and Yahoo! login pages aren’t very mobile-friendly, but there isn’t anything that I can do about that. There is probably more the client app can do to warn the user of what to expect on the Fire Eagle website, but it’d be interesting to put it in front of a couple of potential users and see what they think.
What else can we do to make OAuth easier?
Update (2-Sep-2009): Tom Coates from the Fire Eagle team kindly got in touch to help me work on this. He gave me a couple of useful tips:
1) Add m. at the start of the URLs given in the mobile auth documentation to get mobile versions of the pages.
If the application sends the user to m.fireeagle.yahoo.net/mobile_auth/… instead of m.fireeagle.yahoo.net/mobile_auth/…, the pages render much better on the mobile.
2) Use a custom callback so that the web page returns the user to the application. This is not trivial in Windows Mobile. Registering the app to handle callbacks isn’t too hard, but only if the app isn’t already running – I don’t know how to get it to work when the app is already open.
I suppose I could get the app to terminate itself after launching the web browser to the Fire Eagle OAuth page, but that’s a bit clumsy. I’ll look into it more.
Tags: fire eagle, mobile, oauth
Re callbacks, what about having a helper program to receive the callback, pass a certain message to your main program, and then terminate itself? That works around the problem, doesn’t it?
That’s not a bad idea, thanks! 🙂