Apple, of course, wrote the book on human interface guidelines by visualizing and documenting a range of interaction scenarios in meticulous detail. Today we have a variety of platform-specific guidelines -- for Windows, for GNOME, for Flash MX. But we lack general guidelines for how Internet applications should behave on all platforms. E-mail programs don't agree on how threading, foldering, and filtering should work. Web browsers don't agree on how drop-down search boxes should work. RSS readers don't agree on how the orange XML icon should work. Media players don't agree on how playlists should work.The impetus for this column came from this posting on S/MIME signatures, which argued that confusion about whether or how to trust a signature is a problem of UI, not cryptography. Robb Beal violently agreed. He wrote:
We need HCI (human/computer interface) guidelines more than ever. And we need them not only for Windows, OS X, GNOME, and Flash, but for the uber-platform that subsumes them all. We need human interface guidelines for the Internet. [Full story at InfoWorld.com]
Yes! Every technical spec that has user-facing implications should have a corresponding functional spec.
See my functional annotation of Mark Pilgrim's HTTP tests for an example.
Robb pointed me to some other examples as well. Why isn't this done more? Robb thinks it's because developers tend to want platform vendors to do this work for them. But even on a given platform, essential guidance about user interaction is often lacking.
Scanning the responses to my posting on S/MIME signatures, I realize some people took it as a condemnation of S/MIME. Not so. I was trying to illustrate how interactive context affects the implementation of a protocol, and how the nature of that context can be (but rarely is) specified.
I had suggested, for example, that a mail client displaying a signed message should always display the address in the From: header (not just a friendly name), should display a standard signature icon, and should link the icon to a certificate viewer. Outlook 2000 breaks the first guideline. Darrell Dykstra wrote to point out that Outlook 2002 and 2003 comply with all three guidelines, which is great. Except, of course, they aren't guidelines written down anywhere, and that's my point.
The other day, NPR's Day to Day ran a segment on phishing. In this clip, John Dimsdale interviews David Jevans, chairman of the anti-phishing working group, who says:
Typically it's the average consumer, who's quite Internet-savvy, and they get an email in that looks exactly like it came from their bank, with very compelling information -- it will have the logos, it will really try to fake the website.We have a technical solution: Aunt Tillie could evaluate the site's SSL cert or the email cert of the phisher. But there isn't a snowball's chance in hell that she will. For that, and for the countless other ways that we fail to contextualize protocols in standard and familiar ways, we should be ashamed.
Update: John Patrick on phishing:
The moral of the story is to be increasingly careful. Anti-virus and anti-spam are not enough. Anti-spyware is not enough. Hardware and software firewalls are not enough. All of these are essential but the other ingredient is common sense. Look at your email carefully. Even if the "from" address is one you recognize, look also at the context.
...
Digital ID's are essential to add authentication to email and software downloads. We need to be able to establish that we are who we say we are and to be sure that others (people, links, software) are who they say they are. You can read more about this in the patrickWeb Privacy and Trust series. [John Patrick: Phishing Update]
Former URL: http://weblog.infoworld.com/udell/2004/03/30.html#a958