Tuesday, June 27, 2006

Cross-Device Application UIs

Good critique of one-size-fits-all soft key mapping for mobile software, spotted via Tom Hume who makes a good case for using in-house carefully designed UI frameworks that understand the differences between handsets and remap the application accordingly.

I've always hated the newer Nokia soft key mappings, hiding everything under an Options menu even when there is only one option - why have more clicks than you have to? Assuming users of other phones will also work that way is very bad practice. It's good to see that Polish is adding more flexibility, I've always thought it was a good tool for the more 'casual' mobile developer who has got to grips with lcdui and needs to make the app look better on a budget - though the code is just a bit too bulky and OOP for serious dev on lower end devices (64Kb is amazingly easy to fill, and don't get me started on needlessly arbitrary DoJa 30Kb jar limits on multi megabyte devices...).

One common mistake I've seen people make is to assume that the lcdui UI objects are 'native' therefore must work in a method familiar to users, and so the best way to make an intuitive UI is to use them. This is flawed for two reasons:
  1. As the article mentions, the lcdui may have been ported by some people who don't really understand UIs/the specifics of the handset's UI, or it may just be a straight port of the rather ugly Sun WTK UI and therefore nothing like the phone's UI.
  2. Users use a very limited subset of the phone's UI components, so they may intuitively expect default soft key mappings but they almost certainly won't be intimately familiar with the way a gauge or an options list works.
When it comes down to it, the mobile user experience is rife with flaws and potential problems, and your users will encounter many difficulties just finding and installing the content - for mobile content to take off these problems must be solved by the manufacturers. But once the dedicated few have got through, it is our duty as developer to make life as easy as possible for them - if your budget doesn't stretch to spending time on usability and UI, you really shouldn't bother starting. As Tom Hume suggests you might just be better off letting the experts handle it (FP or any of their equally competent competitors...)