Ferret What Now!?

There are a thousand million different ways to make your website mockable. The very least you can do is make sure that your domain name isn't one of them. Remember that URLs are case insensitive. Also remember that while parsing words with no spaces, people mentally insert spaces between easily recognized words first. Try it yourself. Here are two examples.

• kidsexchange
• ferrethandjobs

If you're snickering right now, the very nice people at Kids Exchange and Ferreth & Jobs may take issue. I humbly request that you add the following Rule Zero to your website deployment checklist.

Print your domain name in all lowercase using a console font. Show it to five random people. (When using surnames as domain names, these people should not be relatives.) If three laugh, consider changing it.

The $300 Million Button

Someone asked me recently how to justify the expense of a usability test to those people who would need convincing. Stories like this one should help with that.

In Which Someone Else Makes a Really Good Point

Engineer Thinking, by Matt Legend Gemmell, is so full of good things that I really want to re-quote the whole thing. But I won't. Here's the penultimate paragraph that makes the broad point:

If you’ve exposed underling complexity or unnecessary choice in your software because you see those things as inevitable, it’s because your job isn’t finished. If you’re going to write GUI software for other people to use, do it properly, and treat those people like human beings instead of software engineers. If you want to expose complexity to the user and wash your hands of it, write command-line tools – or utilities that are used exclusively by other machine processes.

Push the button, Frank!

One thing that some interface designers sometimes overlook is button text. In a lot of contexts, buttons are given default values that seem "good enough". But consider your button text carefully. I'll give you the negative example that spawned this very thought process.

I'm installing a program with the standard Windows installer dialogs. There is some setup to do, and when it is finished, I'm presented with a screen that informs that everything is kosher and the install can commence. The default button that will kick everything off reads "Finish". Erroneous! I'm finishing nothing! Adding to surreal nature of the dialog is the descriptive sentence above the button: "Click Finish to begin installation."

"Click finish to begin" is going to be my new "get up to get down".

Verbs are good words for buttons. Buttons do things, and the word should describe what's going to happen. "Submit" is a popular, though vague, button word. "Cancel" is another popular one. In my example, the answer was staring the programmer right in the face when he wrote the description: the word should have been "Install", since that's exactly what's going to happen when the user clicks the button.

Give some thought to your button labels and make their purpose clear. If whatever IDE you're using provides defaults ... well, try to make it not to. Forcing yourself to fill in that text won't be a bad thing.

Order Up!

A quick note on form elements and tab ordering: if you are going to include links inside the form to provide more information on what a field is doing, you MUST unequivocally and without question, absolutely with no exceptions, positively set the tab ordering on your form so that those links are not included in the ever-popular keyboard shortcut of tabbing to the next item in the form.

Breaking the flow of "enter data - tab - enter data - tab" by highlighting help text interrupts the user's expectations, possibly to such an extent that said user will stop mid-form to write about it on his blog!

On Public Speaking

For my own future reference, and because it may interest others, here's an interesting post I found via Boing Boing today. Duncan Davidson's "Dear Speakers" - a few notes on public speaking from a man tasked with photographing talks and round tables and the like.

Usability Testing in the Wild

This post over at BoingBoing describes how Meetup does usability testing: quick, dirty, and often. This is my ideal approach, too.

You see, I recently did a usability test here at SEP for an internal project. Unfortunately, I haven't had a lot of spare time to compile my results (either from the test itself or my upcoming report, "Why Usabilty Testing Is the Best Thing Ever, I Mean, Really"). But, because the test took on a similar form to Meetup's, my lack of "finished report" isn't that big a deal - the tool's developers observed the whole test and were taking notes the whole time. That, coupled with a few ten-minute "here's something you might not have noticed" discussions, gave the team enough feedback to fix (hopefully - I haven't seen the latest revision yet) a lot of the usability problems.

P.S. Because I haven't mentioned it before, if you're interested in the whys and wherefores of usability testing, you can do worse than to start with Steve Krug's Don't Make Me Think, which covers usability testing in brief, including instructions (which I took to heart) on how to do it for cheap.