In UI terms, a lightbox draws the user’s attention to a dialog box, error message, or other design element in the middle of the screen by dimming the rest of the screen.

Yes, the lightbox has some benefits. It shows you an Important Message within the context of the page you were just looking at. It doesn’t get blocked by popup killers. And it looks super-cool, especially when used as a slideshow.

But lightboxes are starting to crop up everywhere. In my Yahoo mail (I hope the developer got paid a lot for that), in half the applications I interact with, even in my own website (OK, I put it there, but that was 2 years ago when it was very cool and cutting edge).

Is anyone else starting to suffer from lightbox fatigue?

Share/Bookmark

eBay reported record profits for Q1. This despite the fact that the number of auction LISTINGS only increased by 2%. However, merchandise SOLD increased by 14%.

In presenting the record numbers, the CEO, Meg Whitman, said that “the company had been benefiting from changes in the user experience that had increased the number of auctions leading to sales” (as quoted in The New York Times, April 19).

This is a great example of the benefits of usability for e-commerce: income comes from multiplying the amount of use with the conversion rate. The more you improve the user experience of finding products, researching them, and buying them, the higher your conversion rate.

Advertising is important, but it only brings customers to the site. A good user experience is what convinces them to stay there. Careful usability testing and a minimum of user annoyances is at least equally important. Usability affects whether the customer makes a purchase or clicks off to another site.

In eBay’s case, user experience is so important for profits that it’s one of the main things the CEO mentions to the financial press in presenting the quarterly results. eBay has a particularly competent user experience department, but smaller companies usually find that a smaller usability effort can increase their financial performance materially. Your first usability test will uncover a gold mine of low-hanging fruit, to mix metaphors.

Good design isn’t just pretty, it’s also good for business.

Share/Bookmark

As the question of top, right, or left aligned form labels comes up often for designers, here’s a short overview of the pros and cons of each method. For illustrated examples and more details, take a look at the full document: Best Practices for Web Form Design (3.9 MB PDF).

Another recent article related to web forms addresses instructional text in the user interface. Embedded user assistance can quickly become more complicated than you might think. Too much assistance clutters the screen, but if you hide the form field explanations under tooltips, your users might never see them.

Mike Hughes offers up the compelling idea that contrary to the logic of flow, instructions should appear below the form element rather than above it. When completing a form on the web, people tend to go straight to the action–so if the help text comes first, they skip over it:

Users skip static elements, such as instructional text, because they focus immediately on downstream actionable objects. Effective user assistance design accommodates users’ natural workflows by providing instruction immediately beside or following interactive elements that constitute points of need for more information.

Now that average Internet users are more accustomed to interacting with web forms, they have higher expectations for usability. Written best practices like those above help to make these expectations explicit, so we can better understand what makes a form easy vs. annoying.

Share/Bookmark

Some surfers may not understand the difference between the address bar and the Google search bar. Other people do this intentionally as a shortcut. The comments offer some insight: one poster writes, “If I want to search amazon I type [into Google] ‘amazon mybook’, wikipedia is ‘wiki somesubject’, or ‘weather san diego, ca’.”

A parallel development is that some people choose a search term and make up a domain name to match it–like “aromatherapy.com”–rather than entering “aromatherapy” into a search engine.

In summary, we can observe two opposite trends: People who “should” type domains into their address bar end up typing them into their search bar or search engine. And people who “should” use search engines to find what they’re looking for, make up domains on the fly and type them into their address bar. You could call it the Battle of the Clueless. And the battle has only just begun.

Those of us who have been using the Internet since the first GUI browser tend to forget that newer users don’t necessarily follow the “rules”. People find surprising ways of using software that may never have occurred to its designers. “Clueless” or otherwise, users run the show and designers must adapt.

It will be interesting to explore how this phenomenon impacts search engine rankings, pay-per-click advertising, and the value we place on website hits statistics. If search engines aren’t used only for searching, traditional methods of measuring clicks and referral sources may need to be rethought.

Share/Bookmark

I love that it’s free and very easy to install, but for my purposes there are a few drawbacks:

• can’t enable it for one link and disable it for another one
• no previews of PDFs or images within the same site

Still, it has great potential to make a site more usable (and beats learning how to code a preview-on-hover yourself).

Share/Bookmark

The issue: we designed an application that requires users to fill out a form, then displays their errors in a popup window. It’s a lengthy form that can present many errors, so showing the errors on the form itself wasn’t a good solution. We chose the dreaded popup window. Certainly our choice warrants further debate, but the coding is done and here we are.

Our thinking: we’ll explain to people how to allow popups for our site, and their popup blockers won’t be a problem. (Tools – Options – Popups – Allow. Not so hard.)

Not so. In end-user testing, we realized that some people don’t know they have popup blockers in the first place. Hence, they don’t try to unblock our site.

Example: “I didn’t need to remove the popup blocker — the site worked fine. However, I didn’t get a confirmation message when I submitted the form.”

Hmm…. what the? … lots of chin scratching. Aha! She didn’t get a confirmation message because the form had errors she didn’t see. This user never knew she was missing the popup windows.

So here’s the solution, after a bit of Google searching: Will Bontrager’s popup killer test. Thanks Will! His site explains very clearly how to implement this code.

Basically, create three small blocks of javascript code in the Head section of the page; then call the function in the body tag, put one bit of script inside the body section, and you’re done. The javascript tries to launch and close a popup window when the page loads. An alert message displays after the test, informing the user that she either can or can’t see popup windows from that site.

Problem solved.

Share/Bookmark

Designing this is tricky, especially if the list of items is longer than one screen (more than 20 items). If the contents of the list are known entities (for example, product names that the user is familiar with), data entry would become faster once the user has filled out the form a few times. For a new list or a list of lengthy items, however, the task has more usability issues.

I worked out three different approaches to desiging this question, each using standard form elements: radio groups, pull-down lists and text fields. Advantage and disadvantages are given after each example.

1. Radio groups

Example:

Advantage: With radio groups it’s easy to restrict the user’s choice to one first, one second, one third. It’s easier to scan and visually compare items, especially those that are sentence-length or longer.
Disadvantage: If the list is longer than one screen, the ease of scanning is reduced.

2. Pull-down lists

Example:

1st Choice:

2nd Choice:

3rd Choice:

Advantage: Saves a lot of screen space. Easier for the user to verify her choices at a glance before submitting.
Disadvantage: If the list is very long, or the list items are longer than a few words, scanning inside a pull-down can be very difficult.

3. Text entry

Example:

Generally I prefer option #2—pull-down lists—because they take up the least space on the page. For a list of sentence-length items, however, radio groups are probably best. You could also create a list of abbreviations to represent long items (such as paragraphs), but this requires the user to take the extra step of interpreting the abbreviation before evaluating it.

Ultimately, the question should probably be written differently in order to avoid the cognitive overload of prioritizing a long list. But, as we all know, the designer doesn’t always have that option, hence the task at hand.

Share/Bookmark

We are all passionate about the brain and metacognition, most especially–how the brain works and how to exploit it for better learning and memory. Oh yeah, and how to recognize when someone else (including one of us) is applying brain-based techniques to get you to do something.

“Hacking the legacy brain” is one of their core concepts:

A big part of the learning theory we use in the Head First books is figuring out how to “trick” your brain into thinking that learning Java is as important as watching for tigers. We pay a great deal of attention to what your brain cares about, especially when the concerns (tigers-but-not-java) are in direct conflict with what your mind cares about (java-but-not-tigers).

I’m going to run out and get one of their Head First books–not because I care about learning Java but because I’d really like to see the cognitive science aspect incorporated into a software guide. Now, back to the tigers…

Share/Bookmark

Search? Go? What’s the difference? Why would they make such a simple task so confusing, especially on a site that is otherwise very user-friendly?

Curiosity about such things being part of my job, I tried “Searching” for a term (“latte”) versus “Going” for it (which, of course, makes me think more about going for a latte than working on usability issues).

Turns out that “Go” produces the wikipedia entry (if any) with the same name as the search word, while “Search” produces a result set of all wikipedia entries containing that word.

On the German site it’s much clearer: “Artikel” vs. “Suche.” Certainly the English language is also flexible enough to offer a choice more specific than “Go”!

Share/Bookmark