Don't You Dare Ask for My Mobile Password More Than Once!

As more apps go mobile, the potential for the abuse of those apps' users grows. One of my biggest pet peeves in this regard is mobile apps that assume it's just as easy to enter your credentials on your phone as it is on your PC. This is a huge error in judgement as the mobile user experience is already fragile and throwing up barriers risks alienating some very tenuous connections. I'm probably more patient and savvy than your average mobile user and this just kills me.

With the current de facto web standard of email/password, there's quite a bit of typing to do (even if you're on an iPhone!). This doesn't bother me that much, but I'm grateful to those apps that pre-populate the user/phone field or otherwise are considerate of the fact that I am on a mobile device. What does really burn me is apps that are frequently asking me to re-enter my password or don't save text that I've typed in the past.

An early version of the J2ME GMail Mobile app would ask for my password whenever communication with the server failed. (No this isn't an authentication failure, it's a network failure!). Another problem was that the entered password wasn't persisted until I explicitly exited the app, which I never did. This meant I had to re-enter my password whenever I powered my phone off and on. I don't think either of these were bugs as much as they were design issues that neglected to focus on the users' intentions. At this point, it seems like GMail Mobile is content to have you just enter your password once.

Last time I used it, GMail's mobile web interface had the same policy as the regular web interface - a successful login drops a cookie on your browser that expires in 2 weeks. This means that every 2 weeks I have to type in my full password on my tiny little mobile keypad. Multiply this by the number of mobile apps you use and you have a recipe for a very frustrated user.

On the other side of this, because mobile phones are arguable more personal and less secure than PCs, maybe app designers should be forcing more frequent authentication. How many times have you or a friend lost a phone on the bus, had it drop out of a pocket, or otherwise enabled the possibility that it falls into the hands of someone who decides to use it to access your personal information?

Maybe the best solution here is just to add a password lock to your phone and make sure it works out of the box. Sooner or later, people will get the message that your mobile phone is the best vehicle yet for identity theft and will put up with typing in a 4-digit unlock code. (Better yet, the next version of the iPhone should add a fingerprint scanner for use with the existing slide-to-unlock feature.)

In the meantime, please be considerate of your mobile users and design with these issues in mind!

The iPhone SDK is BREW Part Deux

There should be little doubt in anyone's mind that the iPhone Store is a walled garden, albeit a very shiny and new walled garden. The SDK has been out for a while now, and people have figured out that there a lot of things you just can't do with it. The most obvious limitation is that Apple forbids applications that run in the background.

While there are obvious reasons for prohibiting these applications (security, battery life, performance, user experience), none of these reasons are very good. Fring actually resorted to releasing an app for Jailbroken iPhones, but you can bet this won't be available through the iPhone Store anytime soon. My own opinion is that Apple is not only protecting the iPhone's user experience, but also plans to add a lot of these interesting features in the future (VoIP, MMS, IM, etc.), and doesn't want third-parties to get in the way (unless Apple has a deal with them).

I stand by my first-blush statement that the iPhone SDK is more polished and professional than the Android SDK. If you're looking to build a game or a way to access your interactive web app, you'll be very happy. However, if you want to build an innovative new category of application that relies on background processing, you're out of luck - you should go with Android, Windows Mobile, Symbian, or maybe (gasp!) even BREW.

Background applications are easy to build in BREW, which might make you think that BREW is more open than the iPhone. As long as you get the permission of Qualcomm and the carrier you want to deploy on, these applications are allowed. On the other hand, the BREW APIs are clunky and feel like they were designed by hardware engineers, while Apple's APIs are well reasoned, aside from being tied to Objective-C. (I don't have anything against hardware engineers, I just don't think they should be writing software.)

The irony here is that of the current distribution models, the iPhone Store most closely resembles the BREW model, though BREW is much more closed. BREW has more, higher fees (registration, testing, etc.), while Apple has just a $99 or $299 developer fee. Apple gives the developer 70% of the retail price, while with BREW the revenue share is a complicated dance. Overall, the iPhone store should be a boon for developers compared to previous distribution models. While it's not as open as pure web-based deployment it does have the benefit of handling billing and putting your application in a common catalog where it should be easy to find.

Will New E-Ink Controller Lead to Less Sucky Kindles?

E-Ink is a unique display technology that relies on reflectivity rather than backlighting like LCDs. While the technology has been in development for more than a decade, its adoption has been slow due to production issues and its Achilles' heel: slow refresh rate (500-1000 milliseconds).

Refresh rate and flashing has hindered E-Ink's use in highly interactive applications to date. In my opinion, Amazon's Kindle is unusable due to the interface kludges perpetrated on the design in an attempt to work around these issues (though there are a lot of unrelated design flaws as well).

A new version of the E-Ink display controller is claimed to have refresh rates similar to those of an LCD (15 milliseconds or 66 frames per second). If these claims hold true we should see new versions of the Kindle and other reading devices with vastly improved usability. Add color and E-Ink might be able to compete with LCDs someday.