The other day I had to send somebody a trio of multimegabyte TIFF files. She asked me to e-mail them. Instead, I figured I’d make things easier for her by uploading the files to my FTP site and e-mailing her the URLs. Bad idea. She tried to open the files in her browser but, being a Windows browser, it wouldn’t recognize them.
Actually, I hadn’t even intended her to try. I’d meant for her to use the right-click/Save-As idiom to download the files straight to her disk. There were two problems with that assumption. First, a lot of people don’t know that technique. Second, and much to my surprise, it turns out to be a browser idiom that doesn’t translate to e-mail clients.
Here we are, in the era of one-click Web publishing, still hammering one another’s inboxes with megabytes when tens of bytes would do, and arguably do it much better. And when large file transfers like this one are of interest to more than two people, uploading to a central store and distributing pointers is clearly the right thing to do.
But there is a method to the e-mail madness. A file handoff involves two actions: a transfer and a notification. An e-mail-with-attachment does both automatically. An e-mail-with-pointer decouples them for both the sender and the receiver. E-mail transfer is a more flexible and more powerful approach, in theory. In practice, hardly anybody can manage to pull it off.
“Persistent use of any interface will cause you to develop habits,” wrote Jef Raskin, creator of the Macintosh and the innovative Canon Cat, in his book The Humane Interface. “Our mandate as designers is to create interfaces that do not allow habits to cause problems for the user.” Easier said than done.
I helped one client overcome the e-mail habit by creating a Web application that transfers and notifies in a single step. It offers a comment field along with the HTTP upload widget, and a list of preselected and deselectable e-mail recipients, so the whole task requires fewer keystrokes than e-mail would. The icing on the cake is a central document store, canonically addressable and viewable by author, title and date. That’s a huge benefit, but nobody would get to enjoy it if the interface weren’t habit-forming.
The problem with Raskin’s mandate, of course, is that developers of applications are creatures who often have different habits than those who use their applications. For example, when I realized that the right-click/Save-As idiom wasn’t working in the body of an e-mail message, I packaged the three URLs into a Web page, added an explanation of right-click/Save-As, posted that page, and sent its URL in another message. That worked beautifully. Only later did I realize that this procedure – natural and almost unconscious for me – would be utterly alien to my recipient. There’s no chance she’d be able to duplicate it for another recipient.
It seems kind of unfair, doesn’t it? First, developers have to understand and accommodate users’ habits. Then we have to deliver solutions that add value while surreptitiously encouraging users to adopt better habits. Finally, we have to bring to the surface, examine, and modify our own deeply-ingrained habits. That’s a painful and psychologically hard thing to do. But happy users are not the only reward. The habit of breaking habits will serve you well.
Udell is a lead analyst in the InfoWorld (U.S.) test centre. He can be reached at jon_udell@infoworld.com.