Interestingly enough, in this time of excitement and interest in building apps for mobile phones, Google did a refresh on their [i]web[/i] apps for iPhone and Android. Go figure, seems like the mobile web isn’t dead even on high end, high power devices. Even more, it would appear to make sense to build mobile specific web interfaces even for fully functional WebKit browser based devices. Imagine that!
Anyway, the news of the Google refresh got me thinking about what other things might need to be refreshed in the realm of advice for developing for the mobile web. As I pondered my favorite tricks for mobile, I also started thinking about the characteristics of mobile devices in the market place today. In addition to the ridiculously large number of touch screen devices that are being brought to market, there is also an accompanying rush for QWERTY based phones. Among the devices that [url=http://www.pcmag.com/article2/0,2817,2344007,00.asp,]AT&T announced at CTIA[/url] late last month six of six new handsets on the roadmap featured ‘full’ keyboards.
While I am a big fan of touching things, I am not a big fan of touch screen phones. However, I am a sucker for a 10 key numeric key pad. Maybe it’s just that I’m lazy and never get around to putting numbers in my address book. Maybe it’s that I’m better with numbers (I can tell you every phone number I’ve had since I was 12, and I’ve moved a [b]lot[/b]…), or maybe I just like pushing buttons (don’t get in an elevator with me).
Ok, so where am I going with this? One word: accesskey. Thinking back to the good old days of WML (yes, there were some good things about WML) the accesskey attribute was pretty universally supported, and as a developer you only had to worry about assigning keys 0-9. Sure, there were some other things to worry about, like if you had to number the list yourself, or if the browser would apply the numbers automatically on your behalf. When the OMA put forth the XHTML-MP spec, accesskeys were covered in an extension to CSS via the -wap-accesskey property. In addition, in XHTML 1.0, there is also the accesskey attribute that can be used within an tag.
So this brings me back to what’s going on with devices today. Clearly when you’re dealing with a touch screen interface, adding an accesskey attribute doesn’t help your users, but it also doesn’t get in their way either. However, it’s worth considering exactly [b]which[/b] accesskey to assign to your links. On a 10-key pad device, it clearly makes sense to assign numeric accesskeys. However, when dealing with QWERTY devices, often times the numbers are only accessible when used with a function key as well. It’s not much of a help if your users need to press more than one key to get at the ‘shortcut’
So the good news here is that the accesskey is not limited to numerics, but can also be any character. At this point, it’s time to start thinking of those numberd lists using alphabetic bullets insted of numbered. So while your traditional list with accesskeys might look like this:
[code]
[/code]
When serving content to a full keyboard device your users may be better served
by:
[code]
…
…
[/code]
So this is all fine and good in theory, but as we all know, when it comes to the mobile world there is often a pretty big gap between theory and reality. When it comes to accesskeys unfortunately there is no exception. Somehow despite the fact that they built their browser off of Webkit which has full support for the XHTML accesskey attribute, our friends in Finland managed to break support in their port to S60 WebKit [url=http://wiki.forum.nokia.com/index.php/KIC001108_-_Accesskey_attribute_not_working_in_Web_Browser_for_S60k](at least they own up to it…)[/url].
Similarly, the whiz kids in Mountain View have done the same thing when it comes to the version of Chrome that they’re pushing out with Android (at least the version that’s shipping in the 1.0 R2 SDK that supposedly matches what’s on the G1 shipping on T-Mobile. The next Android device in the pipe from HTC (the Magic) doesn’t really matter here since it’s touch only device…
Sadly, the RIM browser on the blackberry also ignores the attribute (at least it does according to their [url=http://na.blackberry.com/eng/deliverables/1143/browser_devguide.pdf]devguide (pdf)[/url])
On the plus side, there is support for the accesskey atttribute in WinMo/IE Mobile devices. Even more interesting is that the support is constructed in such a way to default the keypad to numeric mode. That is if you assign an accesskey of ‘1’ the user does not have to press the Fn key for the key to be recognized. If you wanted to assign ‘e’ as the accesskey, that works to. If for some reason you choose assign [i]both[/i] ‘e’ and ‘1’ as accesskeys, the key defined first takes precedence so the user will have to press the Fn key to get the second item on a shared key. Also worth noting is that you can use either the accesskey attribute or the -wap-accesskey style property interchangeably (even within the same document, though I don’t recommend that…).
Of those six keyboard based devices announced by AT&T last month, there is one S60 (E71x) and one WinMo (Samsung PropelPro). The other 2 LG phones will sport the Teleca/Obigo browser, and the Samsungs will have NetFront (both of which are a tad bit of a black hole when it comes to exactly what they will support).
If this leaves you with a sour taste, don’t despair. If you apply accesskeys they will at least get ignored silently. For now I’m going to go slip out to my local AT&T store and see how some of those QWERTY devices want to play (or not). If you’ve got one in your pocket, or in a drawer, give it a go and let me know. Be sure to also give the the WCSS -wap-accesskey a go and see what gives.
