Sure It Looks Cool, But Is It Usable?

So often developers (myself included) do or are tempted to do things because they are cool, because they show off the latest and greatest technique or plugin, or because everyone else is doing them. [Though not my proudest moment as a developer, I admit to using the < blink > tag when it was all the rage (for about a week) back in 1997.]

An error which is easy for developers to commit (and which I have been guilty of myself on more than one occasion) is to explain what users are doing wrong when they make a mistake. To see if you fall into this category, ask yourself the following: when a user can't figure out how to get from page "a" to page "b" on your Website, is your first reaction to explain to the user what he/she is doing wrong, and to point out the steps he/she needs to take to get to the desired page?
[I refer to this as the developer "Yes, but..." response. A couple examples: When a user says that he/she couldn't figure out how to turn down the sound, the developer says "Yes, but you didn't scroll to the bottom and click the graphic second from the left." When a user says that he/she couldn't access a certain part of a Website, the developer responds with "Yes, but you have to enable cookies in your browser."]

Because we want the user to succeed, explaining in as few words as possible how to accomplish whatever it is the user is trying to do seems to be the best way to help him/her. Also, because we developed the system, we know it inside and out, forwards and backwards. We know without having to think about it how to get to every screen of the system. If a user can't figure it out, it is easy to conclude that the error occured because the user is a novice computer user, because he/she didn't see the button or link he/she needed to click, or because he/she didn't read the instructions.

The more difficult (and more humbling) way to respond to user errors is to look critically at the system, and to ask yourself why the user failed.

Let's face it: users visit Websites because they are looking for something. Users will return to your site because of your content, not the cool navigation system you spent hours creating. Your Website's navigation system is the moyen through which users access your system's content. As such, the navigation needs to be as obvious and as simple to use as possible, thus making it a quick and easy process for users to get to the content of your site, which is, after, why they are using the site in the first place.

If a user can't figure out a Website's navigation system the first time he/she visits the site, something is wrong. Perhaps the problem is the result of a user error. More often than not, however, it is the result of a Website with poor usability. This is a hard pill for us to swallow as developers, but doing so will lead to Websites which are user-centered, have a high usability factor, and which result in a more enjoyable user experience. This in turn should lead to more return visits to the site and/or more sales, resulting in a satisfied client, and hopefully more future work from this client.

It occurs to me that a change in terminology may also greatly benefit all those involved (users, developers and clients). Rather than using the term user errors, we would do well to refer to them as system problems. This takes the blame away from the user, and forces us to ask ourselves what went wrong (which not coincidentally is the first step in fixing the problem). Though the problem may lie with the user (or some third-party hardware and/or software which he/she is using and which is out of our control), as noted above more likely than not the problem lies with the way we have designed and/or implemented the system.

Flashforward Conference in San Francisco

The 2003 Flashforward Conference will take place March 26-28 in San Francisco. In addition to the Flash Film Festival, there will be in-depth workshops, educational seminars, technology showcase sessions, ask the experts sessions and more.

What Is Flash? (.com)

The folks at WhatIsFlash.com do a great job of explaining what Flash is, and giving examples of things like good uses of Flash and sites which use Flash poorly. And while you're there, check out their Flash Hall of Fame.

The site's creators seem to share my belief that just because you can do something cool in Flash doesn't mean you should. For example, I had considered using Flash-based navigation on this site (at left), and even built and tested a prototype. The conclusion I came to in the end, however, was that I could create navigation which looked and worked well using JavaScript and DHTML. Since there was really no compelling reason to do it in Flash, my prototype navigation bar didn't end up being used on the site.

Gribble's Golden Rules of Multimedia Design

• Design for the user

(good design is transparent to the user)

• Test early, test often, test on all your target platforms

(aka test, test, test)

• Back up your work at the end of every work session


• Whenever possible, separate form and content.
  (forget about the < font > tag; think CSS)
  
• Just because you can do something doesn't mean you should

(creating fancy Flash movies may be fun, but are they usable?)

ActionScript for Flash MX

Oreilly has recently released ActionScript for Flash MX: The Definitive Guide, 2nd Edition. Written by Flash Guru Colin Moock, the second version of this very popular book is well worth a look for anyone serious about learning ActionScript.