User Interface Design Anti-Pattern: Pecked to death by ducks.

Here’s a user interface design anti-pattern I just ran into.

So I’m trying to complete my company’s on-line sexual harassment training program. I guess they teach you how to be better at engaging in sexual harassment; I dunno. And the reason why I don’t know is because when I logged into the program using Safari on the Macintosh, I got the error message:

“We’re sorry but your browser is not supported. We support Firefox and Internet Explorer.”

So I called up my copy of Firefox on the Macintosh, and got:

“We’re sorry, but your operating system is not supported. We only run on Windows XP, Windows 2000 or Windows Vista.”

Okay, so I called up my trusty copy of Parallels, launched Windows XP, and got:

“We’re sorry, but the training program requires RealPlayer or Windows Media Player.”

Which I’m now installing.

Each error landing page I got did not mention the subsequent limitations. Instead, it was just a terse error message, undoubtedly arrived with pseudocode like:

if (browser not in approved list) then
    print error "browser not in approved list"
    exit
else if (operating system not in approved list) then
    print error "operating system not in approved list"
    exit
else if (player plugin not installed) then
    print error "plugin not installed"
    exit
else ...

How stupid is this anti-pattern? I get to get pecked to death by ducks–making the whole on-line experience quite painful.

And it would have been so easy instead to write something like:

list missing = new list;
if (browser not in approved list) then
    add "browser not in approved list" to missing
end
if (operating system not in approved list) then
    add "operating system not in approved list" to missing
end
if (player plugin not installed) then
    add "plugin not installed" to missing
end
...
if (missing is not the empty list) then
    show missing on error page
    exit
end

That way you can display all of the missing problems to the user all at once. It’s not like each test couldn’t have been run in quick succession, and then the user warned about the missing requirements all at once.

Better, land the person on a succinct “requirements” page which lists, in simplified bullet form, the specific requirements of your product, after listing the stuff that is missing.

The rules for the pattern that should be applied here are:

  • Make what the user is missing clear
  • Make the requirements obvious
  • List the corrective actions the user should take immediately obvious.

And don’t peck your users to death.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s