the 200ok weblog

It has been noted, over at the relaunched Webmonkey, that Microformat support seems to have dropped out of Firefox 3.

What has actually happened is that FF3 has an API for microformatted content but no UI to display it. There was a concern about how to alert the user and then how to let them access the data.

The short story is that even with Firefox 3, you'll need to install an add-on like Operator to take advantage of microformats data on the web. The reason the user interface is missing is because, as Kaply says, "there was never any agreement as to how to expose (microformats)".

Mozilla and the Firefox developers variously considered a sidebar or a toolbar, but decided that both would take up too much screen real estate.

Is this really such a difficult question? Why not just display the microformats logo next to the RSS logo in the address bar?

It's extensible - after clicking you would get a list of available microformatted items, just like you get a list of available feeds. It follows an existing paradigm set up by the RSS logo, specifically that the data on screen is available in another format. It takes up a tiny amount of screen real estate.

Opera already adds a logo in this manner when the content is available as a widget:

It's hardly a stretch to imagine a Microformats icon as well (ignoring the fact that I'm no icon designer :)):

It feels pretty natural and you're already used to the RSS icon appearing in that location. Obviously there's an upper limit on how many logos you'd want, but that issue applies to the RSS icon too.

The security and maintenance issues of how to process the data do remain, of course. How do you update the processing routines, for instance? But even that seems like a minor issue when you consider how often Firefox updates get pushed out.

Updates seem like even less of an issue when you consider the frequency of new microformats being released - ie. not very often. Seriously, plenty get discussed but the list of actual "specification" grade microformats has barely changed in the past 18 months. In fact, off the top of my head I don't think it actually has changed in the past 18 months.

So, my suggestion to browser makers could be summarised like this:

• When microformat content is identified in the page, display a microformat icon in the same way the browser displays the RSS icon.
• Only support those microformats designated "specifications". Or even just support hCard and hCalendar, which are the ones most likely to be useful to the user in a browsing context.
• When the specs change, include the parsing changes in your next update.

It's just a thought. At any rate, the lack of UI to access the Microformat API in Firefox just means that nothing changes for the time being. People who want to use Microformats use something like the Operator extension. Sometime in future the UI issue will no doubt get resolved one way or another.

Labels: browsers, firefox 3, microformats, ui

Or, How I learned to stop worrying and love the stylus

Most people in IT are exposed a lot of different web-enabled devices, but we probably don't pay enough attention to their interfaces. Many web developers have a tendency to just think about desktop PCs running Windows, or perhaps they'll think about Macs too. But what about all the other devices?

I've been pushed into thinking about this over the last few days, mostly because I've been using a borrowed tablet PC while my desktop was having some niggly hardware problems. The way I've used the tablet is substantially different from any other device I've used before.

devices and their interfaces

Let's take a look at a few of the devices people are using. I won't dwell on desktop PCs of any flavour since they're reasonably consistent: keyboard, mouse, full size monitor. Walking across a university campus, you're increasingly likely to see any and all of the following devices.

laptop pc

Usual inputs

• keyboard and touchpad/joystick/trackball
• when docked, full size keyboard and mouse

Gotchas

• a lot of people are slower when using touchpads and joysticks

tablet pc

Usual inputs

• stylus and on-screen keyboard when undocked
• any combination of stylus, keyboard and mouse when docked

Gotchas

• forms with no submit button - the stylus "clicks" so you have to pull up the on-screen keyboard and use the enter "key"
• precise clicks - the stylus tends to drag a little when you're trying to click, so very small click areas and close-spaced links can be irritating
• links with no "active" style - when you're not completely sure if the click has registered (or if you clicked the right thing), you'll really wish there was an active style on the link

Notes

• absolutely awesome for any interface which uses click+drag (play Solitaire or Bejeweled to see what I mean)
• if the interface is sensitive enough, great for drawing
• users far more likely to switch between portrait and landscape orientation

mobile phones

Usual inputs

• keypad, sometimes joystick-style buttons or stylus
• some models have extras like little keyboards and so on, but they're not especially common

Gotchas

• apart from phones with Opera, the embedded browser is likely to be pretty limited with unpredictable support for standards, plugins, etc
• almost none of the browsers properly support media="handheld" ....yet, hopefully
• most phones have low bandwidth connections and/or can't load big files
• some interfaces forget the "enter" key and can only submit forms with the stylus (or the user won't know how to find the enter key, which is effectively the same)
• very small screens (relatively speaking)

pda and handhelds (including game devices)

Usual inputs

• stylus which is also used to enter text with graffito or on-screen keyboards
• many PDAs have addons like keyboards or mice, but they're not universal
• game devices often have cross-pad devices, some have joysticks

Gotchas

• all stylus-related limitations of the tablet pc
• all browser/UA limitations of mobile phones
• relatively small screens or even split screens (eg. Nintendo DS)
• some screens have glare/backlight issues
• some have very odd text input methods - eg. the Sony PSP takes some getting used to and URLs are a pain to enter

user familiarity masks problems

Users do find ways around many limitations, or become so used to poor workarounds that they no longer think of them as "problems". However if you have a system that needs lots of workarounds, users are also likely to simply stop using your system and go elsewhere. User familiarity should not be seen as a substitute for good usability.

connecting in the first place

Many of these devices have "wireless capabilities" but this can mean many things. Wireless LAN without security, wireless LAN with security, bluetooth, WAP, etc. A large number of devices can connect to a wireless network but won't get past corporate VPN requirements. For example there's no VPN client for the Sony PSP, which put an abrupt end to our wireless testing at work (although the PSP is actually capable of using most of our systems, so long as VPN is down at the time).

Even if you can connect, wireless networks (at least in Australia) usually aren't the nirvana you might wish for. Slow, prone to dropouts and generally not free, wireless is absolutely not "ubiquitous" and not necessarily "high speed".

so what do we learn from all this?

To a large extent, you could summarise by saying that - between all the options- users with devices other than desktop PCs have the same requirements as disabled users. That means some of the most technology-savvy, youngest and brightest users are actually the ones at risk of hitting problems. The user base also includes key decision-makers like managers, CEOs and so on who like to have the latest and greatest toys.

One interesting thing to note is that some users are essentially mouse-only users, which is less commonly considered than keyboard-only users. Most devices do offer a keyboard substitute but many of them are limited.

conclusion?

Here's the good bit. You can cater to varied devices by doing all the "right things": build to standards, don't use tables or fixed width layouts, let users choose or override style settings, keep page weight to a minimum.

It's not a new message, just a lot of new reasons for the ones we already know. Best of all, they're reasons based on the latest gear rather than any form of moral highground or expectation that everyone wants to follow Best Practice.

Standards are good for the boss's latest PDA; your kids' expensive new game handheld; and the tablet PC you kind of wish you didn't have to give back to your employer. They're not the most laudable reasons, but they sure do motivate people.

Labels: graphics tablet, hci, interfaces, keyboard, mobile device, mobile phones, mouse, pda, stylus, tablet pc, trackball, ui, ux