In economic terms, when you add friction to a transaction, the transaction becomes less desirable. The illustration by designer Brad Colbow, “Why DRM Doesn’t Work (or how to download an audio book from the Cleveland Public Library” is a great example, as is a similar graphic from geekologie.com. (It’s also a great explanation of why I dislike animations that can’t be clicked past at the start of so many video games.)

Enabling good behavior (and discouraging undesired behavior) is an undercurrent in the change management literature as well as in the policy compliance literature I’m reading. It explains why lecturing is often the most ineffective method of teaching, because it requires attentive behavior in the listener, rather than enabling it.

It’s a concept I will certainly need to keep in mind as I prepare to teach next semester.

Maybe this is too obvious. You’ve probably already thought of it. Here it is anyway: Power users are comfortable experimenting with their system; other users are not.

Anecdotes

On the face, it may seem that it’s the incredible knowledge or experience, not willingness to experiment, that separates power users. But isn’t it experimentation (and, likely, troubleshooting) that precedes experience?

I think back to my time in high school. I had a 2400 baud modem, and no internet connection. There was no Googling for answers, just a few local dial-in bulletin board systems. It wasn’t easy to access specialists, so solving computer problems could be laborious process. Experimentation was inevitable. This, perhaps, led to exploring (read: tweaking, and in one instance, destabilizing) more than one school computer by prying open its operating system with ResEdit and changing system icons, dialogs, and messages.

Contrast this with how my father approched computers years ago: with copious notes and detailed step-by-step instructions. (Whatever level of detail you’re imagining his notes might have been like, double that a couple of times, and you’ll be closer.) With time his comfort level increased, and slowly, so did his willingness to try new things. I don’t know that I’d go so far as to truly call him a power user (except maybe with his geneology software), but over the past fifteen years he has certain gone from “etreme novice” to “competent.”

A couple of weeks ago, I was offering an acquaintance some one-on-one computer tutoring. She and her husband had done me a very significant favor (saving me several hundred dollars), so it was the least I could do. She had purchased a computer on a whim about a year ago, but wasn’t comfortable using it. I showed her the simple things: how to open her email, how to move windows around, how to close windows, etc. I knew I had my work cut out for me when, after I’d asked her to send her first email, she queried, “How do I make capital letters?” As I look back on the experience, I think the most important advice someone in her position could receive is to not be afraid to experiment.

What it means for design

When designing a good interface, it’s often good practice to create multiple ways of accomplishing common tasks. Toolbar buttons, menu commands, keyboard shortcuts, and context menus all provide different paths to the same funcionality.

More important though, is the awesome power of Undo. It makes the system safer, which makes it more likely to be used. It also encourages users to safely experiment—which is what they really need to do in order to understand software.

A quick Google showed a history of COM Exceptions and EndNote. The most helpful was an old blog post comment suggesting I delete ~/Library/Preferences/com.ThompsonEndnote.plist.

I closed both applications, deleted the file, and voilà, no more problems.

For the record, I don’t like EndNote. I get to use it because that’s what our advisor wants. Before this paper, I’d been using Sente, a Mac-only app that is actually usable and intuitive.

The article itself didn’t do anything for me, but the way John described the link connected some synapses for me. (I wish I could recover what it was—something about exposing government APIs to journalists.)

Utah does pretty well with e-government, but one thing continues to bug me: our election contributions reporting system. The key point is this: How much more powerful could it be if it exposed the data in a published RESTful XML format, suitable for use in mashups?

Untapped potential aside, I think the current system is flawed for the following reasons:

• Contributions aren’t tagged with the date their entered (only the date of the contribution). I’ve read of more than one instance where someone suspects a report was amended after the fact, but that information (if collected) isn’t exposed.
• Multiple pages of contributions/expenditures reports don’t have unique links. (e.g. each “Next” link goes to the same URL. Some magic is happening with cookies to enforce state.)
• Multiple pages of reports aren’t numbered.
• First/Next/Previous/Last links always appear, even for single page reports.
• PAC/PIC searches are broken. (Try searching for statements that “contain” some nonsense word. You’ll get the same results as if you’d searched for your own name.)
• Some expenditures are marked with asterisks, but there’s no explanation of what that means.

Let me put it this way: there are some pretty serious usability issues on the citizen side. Without having to go through the rigamarole of trying to remember the password I need only once a year (and it can only be set by contacting the Lt. Gov’s office directly—and no area code is provided when the phone number is first listed) let me just say that using the system as a candidate isn’t a walk in the park either.

Let’s be honest—it’s a simple store data/show data application. It shouldn’t be to hard to do well, if one doesn’t pick the lowest bidder. …

CAPTCHA (an acronym for “Completely Automated Public Turing test to tell Computers and Humans Apart”) has been on my mind ever since Phil Windley suggested a graphical CAPTCHA would make a good web service. I thought there might be those willing to pay to use it. Well, it’s been done.

There is a need for this type of test. Yahoo! and Hotmail use a CAPTCHA to stave off spammers when a user requests an email account. I suspect the most common use on other sites is an attempt block automated comment spam in blogs.

CAPTCHA excludes legitimate users

As the W3C points out graphical CAPTCHAs are a significant barrier to low-vision and blind users. Those with learning disabilities, such as dyslexia, may also be adversely affected. As visual CAPTCHAs become more sophisticated, busy, patterned background becomes more of an issue for color-blind users.

The U.S. Census Bureau estimated that in 1997 about 7.7 million Americans had difficulty seeing the words and letters in an ordinary newspaper. The American Foundation for the blind reported about 5 in 1,000 Americans are legally blind, and gives a low estimate of 1.5 million visually impaired computer users. That’s a fairly significant potential market to ignore.

Requiring users to interpret a visual CAPTCHA may lead to legal challenges. Earlier this month, the National Federation for the Blind filed suit against Target, claiming target.com discriminates by not being accessible to visually impaired users.

Audio CAPTCHA

Some companies are experimenting with audio CAPTCHAs, spelling out random letters with random noise in the background. However, aural disabilities are more common than visual ones, so the approach isn’t really more accessible. Speech recognition software is more advanced than character recognition, so the purported purpose of differentiating between humans and computers is not filled anyway.

CAPTCHA is broken

Several projects to crack common visual CAPTCHA algorithms, particularly The CAPTCHA Project (by the Carnegie Mellon School of Computer Science), the UC Berkeley Computer Vision Group, and Sam Hocevar’s PWNtcha, have had good success. Howard Yeend demonstrated a vulnerability in several public algorithms where he could reuse a solution several thousand times after manually solving it once.

Social engineering is often easier than fancy programming. The first widely recognized social engineering solution was “borrowing” CAPTCHAs from target sites and showing them at entry points to porn sites. Visitors to porn sites would solve the CAPTCHAs, allowing spammers to get essentially free labor. Amazon’s Mechanical Turk (tagline: “Artificial Artificial Intelligence”), which gives micro-payments for simple tasks is an example of another way CAPTCHAs could be defeated. Even at a few cents per image, the cost may still be too high for spammers, but it is a demonstration that the process can be outsourced. After all, the world is flat.

What is the underlying purpose?

The real reason for CAPTCHA is to screen undesirables. For low traffic sites, it means preventing automated access. This can be accomplished in a relatively simple way: add a single required question to the comment submit form. Something like “What color was George Washington’s white horse?” or “Enter the fourth word in this sentence.” This is enough to make the form non-standard, thus unusable by generic bots. Bypassing this added security would be very easy for spammers, the advantage is the relative obscurity of most blogs. To target multiple blogs, a spammer would need to address each one individually; individual attention is unlikely, so I suggest this method is the easiest for bloggers with a knowledge of web programming, and is as accessible as a comment form without a CAPTCHA.

Major sites like Yahoo! and Google have a bigger problem. After all, they are targets both because of the value of their services, and their size. When it first launched Gmail, Google limited accounts to those who had been invited by other active users. Initially there was a good bit of commotion in the tech community as gmail.com addresses became a sign of prestige. The invitation system allows Google to track which users may be abusing the service, and which users invited the abusers. Google has gone a step further, and now allows potential users to have an invitation code sent to their mobile phones. The number of accounts requested per phone number can be tracked. The potential gain from a limited handful of throw-away email accounts, and the cost of mobile phones (even disposable ones) is enough to deter spammers, because less troublesome alternatives exist.

If you look at Google’s account request page, you’ll see a CAPTCHA there. Google responsibly offers a way for users with disabilities to bypass the CAPTCHA, although it involves human-to-human interaction (and quite a bit more time) to complete—a costly alternative.

Real solutions

Several solutions to the problems with CAPTCHA have been proposed and debated. Most have major cost or accessibility problems.

It would seem the only good solution is some sort of federated identity system, which is really just offloading the trouble of user validation to someone else.

I picked up Head First Design Patterns last month, more to see the application of her learning theory than for the content of the book. Had I not been intrigued by her blog, I likely would have never even looked twice at it—although somewhat relevant to my work, it’s not an area that I felt I had time to study.

I love the book. Not only is it providing a good breadth of software design knowledge, but I’ve learned more about learning theory than I had hoped. I believe Kathy’s method of instructing has helped me plant the material more firmly in my mind. I can recall it better than I otherwise might, and I could explain most of it to someone else (although not as deftly as the author).

Calling it “learning theory” connotes a narrow field; it’s much broader than one might first expect. The principles apply to business presentations, marketing, and, well, every type of communication where we expect some sort of knowledge transfer. (As an aside, see a related article at Presentational Zen for a comparison of presentations by Microsoft’s Bill Gates and Apple’s Steve Jobs.)

At the beginning of the Design Patterns is a brief section on some of the teaching tools the book employs. One of biggest differences with the “Head First” books (that is, the most visually obvious difference) is the prolific use of pictures incorporated with text. Not just pictures with a caption, but words in the block of space we visually associate with the picture. It’s something you almost have to see to understand. (Pun only mildly intended.)

More than computer books, what I really want to see out of Kathy is a “Head First” book devoted entirely to learning theory.

Thanks, Kathy, not only for your breath of fresh air on computer texts, but for sharing your insights on teaching and learning. I know I am better for it.

Being able to easily replicate presentational effects across multiple browsers, from IE or Firefox, to a PDA or cell phone is a web developer’s Utopia. The ability to use semantic markup to not only accommodate users with disabilities and effect clean design, but also to reduce the weight of code and improve response times is a wonderful thing.

Molly Holzschlag has posted a scathing open letter to Disney Store UK, taking them to task for their new design, which is, from an HTML standpoint, a step backward, making some rookie mistakes like bad alt text for images. (I don’t know how it compares visually—I didn’t see the original site.) Like standards advocates frequently do, she cites total cost of ownership, server performance, and search engine rankings.

She’s right on some points: table-based layout and in-page scripts will result in slower downloads and slower renders. Even sub-second delays, while not consciously identifiable, contribute to a reduced level of trust. But Molly, and most of the comments, miss the point from the company’s point of view: does the new site make more money? It’s not until well over 100 comments that Adam brings this up. (Gee, it’d be nice to have that many people react to my blog.) Revenue, not web standards, is the primary driver for corporations.

As for the accessibility issues she brings up, she’s spot on. I think if she had made accessibility the main thrust of her letter rather than just another item in a over-long list of talking points it would have had more impact. But the fault isn’t really with Disney, but with the designer. As I’ve mentioned before, few managers have the skill set to evaluate the work of web programmers on anything other than a visual level. Who is training the managers?

The blogosphere has been accused of being an echo chamber, or as David Weinberger puts it, “Those Internet spaces where like-minded people listen only to those people who already agree with them.” The Web Standards community is no exception. The sole voice who suggested that an open letter criticizing the new Disney site may not have been the most effective course of action was attacked by multiple readers. There is merit in his position, and I was frustrated so many dismissed him out of hand.

Web standards are good. Designers who employ web standards are good. Evangelism does not need to include condescension or criticism. Until corporations with a major internet presence discover for themselves the benefits of web standards on the bottom line, they will not willingly change. Trying to push it on them won’t speed the process. Molly gets it right in her follow-up post (before burying the thought with more indignation): “Professionalism means taking responsibility for educating ourselves and each other.” And education happens best when the learner is excited about learning.

<label> tags are, unfortunately, one of least understood tags among amateur and self-taught web developers. I suspect it is because there are no obvious visual indicators when used. Differences do exist, however. Without peeking at the underlying HTML, can you tell me which of the following sets of radio buttons uses label tags, and which does not?

If you’re not familiar with what the label tag does, (or if you’re using Safari) you may not see the difference. The secret? For most visual browsers, the clickable area to activate the radio button now includes the text associated with the button. Most major operating systems work this way, as the button text is really part of the control, but Internet browsers don’t work that way. The browser doesn’t know what text to associate with radio button unless the developer explicitly associates it—and that’s what the <label> tag does.

There are other benefits too: form usability is improved for users with screen readers or motor disabilities. (See Dive Into Accessibility: Labeling Form Elements.) It’s an easy accommodation to make, and really benefits all users, particularly when you need to associate buttons and labels located in different places on your page—say, if you put them in different table cells (egad!).

Here is the second set of radio buttons again, with the clickable areas highlighted (again, not so for Safari users):

How do you use it? There are two ways: explicitly associate the <label>’s for attribute with the id of any <input> control, or nest the entire input and label text inside a <label> tag. It’s as easy as that. If you want to go a step further, associate access keys with your labels.

or

If you absolutely must duplicate the increased clickable area for Safari users, Chris Cassell has published a Javascript solution designed to do just that.