Conquer the command line with a hands-on bash workshop!

2007-10-20: mobile devices: just add keyboard

At WDS07 people were going nuts over the iPod Touch. Legend has it that the infamous Perth gang roamed the wilds of Sydney, buying every Touch in their path! While those reports might be slightly exaggerated, the buzz was certainly high since we don't officially have the iPhone here in Australia - so the Touch is the next best thing.

I was briefly caught up in the moment and spent a heady 45 seconds or so planning to buy one myself. Then I heard about the disappointing capacity, particularly against the price. Since my current iPod holds my entire music collection, sixteen gigs just isn't going to cut it for me! ...and while the interface is cool, that alone doesn't justify the price.

but add a keyboard...

Still, after playing with one for a minute I realised what would be a killer app for me: an iPod Touch and a portable keyboard. The sort of fold-out arrangement you can get for Palm Pilots would be ideal:

Palm Wireless Keyboard

why a keyboard?

Why? Because an iPod with a portable keyboard would be the ultimate conference and meeting note-taker for me. I don't need to do fully-fledged web dev at a conference, I just need to take notes. I generally use Dreamweaver since that means I don't have to reformat my notes later if I want to blog them; but any text editor will do.

So a laptop is overkill and just weighs me down on the way to the pub. An iPod Touch and keyboard would weigh bugger all compared with a laptop. The keyboard would need its own power, so it could easily contain a kickarse auxiliary battery and still be relatively light. The touch screen also means you don't need a mouse.

Of course I could just go get a Palm Pilot and a wireless keyboard... but the Touch does have a damn fine screen (rivalled only by the PSP) and the touch interface means no stylus to lose on the bus. Not to mention that, yes, the Touch is cooler than a Palm Pilot (don't try to tell me geeks aren't into shiny toys ;)).


Adding a keyboard to some of these devices might also have an accessibility benefit. Touch screens currently lack tactile feedback (you can't feel a touch screen "keypress"), so on-screen keyboards are pretty useless to a blind user. Adding a keyboard would also help anyone who sends a lot of text messages - including hearing-impaired people.

Obviously a keyboard alone won't make devices accessible - many of them don't currently vocalise their menus and so on. But a keyboard would certainly help on the input side of things. They might even prevent a bit of SMS-thumb RSI!

It's a case where accessibility moves into the realm of usability. Sure, the little keypad on a phone works just fine to send texts and peck out short emails - but a full size keyboard is more usable. I can also see full-size keyboards being popular as the mobile-savvy baby boomer generation ages, since the tiny buttons on most phones are hard to use if your eyesight is going or you're not quite as dextrous as you once were.

ultraportability (is that even a word?)

At the end of the day I don't specifically have to have an iPod with a keyboard, it could be any small, web-enabled device with a reasonable screen. Data charges aside, a phone would have the significant advantage of being able to connect even when there's no wifi available. Currently in Australia that basically means "anytime you're not at home", although Meraki mobs may change that.

I'm really just looking at the potential of adding a real keyboard to an existing web-enabled mobile device. As John Allsopp recently highlighted, the mobile web suffers from poor text input. Adding a keyboard would take many devices from "annoyingly slow" to "quick and easy", without adding three kilograms of dead weight to your bag.

Here's hoping more devices start getting portable keyboard options.

2007-10-12: source order: navigation or content first?

The source order question came up again on an email list recently - ie. should content or navigation be first in the source order?

This is a "jury is still out" issue since so far nobody has comprehensive data, just studies with a small number of respondents and opinion informed by observation of a relatively small number of users.

The paper Source Order, Skip links and Structural labels is the best research currently available; and its findings suggest either that the order is less important than other factors, or that there's a slight overall preference for navigation first.

However, the small number of participants in the study means we can't be 100% sure if the findings would be the same with a larger sample size. It's likely and it's backed up by anecdotal evidence, but it's not confirmed.

So, what I think we can say for sure about the source order of content and navigation:

  1. No matter which way you go, be consistent across the site so users can learn how your site works and trust it to work the same way as they move through the site.
  2. Either way, include skip/jump links; but...
    • Include visible skip links where possible, or use invisible-but-accessible skip links (ie. do not use display: none; to hide skip links as a very large number of users will never be able to access them).
    • If they are hidden, try to make them visible on focus so sighted keyboard users can see them.
  3. Use meaningful link text and a logical heading structure. Not only is this just good practice and good for SEO... the accessibility-oriented reason people say this is that some (many? most?) screen reader users don't actually read a page from top to bottom. They use features which extract all the headings or links into a list; read just that list then use that to jump around content. Once they identify that they're on the page they really need, then and only then will they read the whole page.

Please note that I am not saying all screen reader users navigate by link and/or heading. Screen Reader users have habits which are just as varied as other web users. No two people use the web in precisely the same way - but overall trends and common approaches can be identified. Enough disclaimer? :)

Related links

Blog Archive