Monday, May 24, 2004

The Naming of Parts

A sure way to subtly please customers: Ensure that the UI text (button labels, link text, and so on) is synced up to the text in Help, FAQ, and other references in UI.

In the not uncommon event that the UI designer and documentation writer are different people, communication between these parties is critical!

Seems like a no-brainer, but... speaking from experience this week in trying to set up a new ISP, there is nothing more frustrating than attempting to follow instructions and finding that what you're looking for does not exist in the place where the instructions say it exists.

Thursday, May 20, 2004

Static Text and Screen Readers

Burning issue: Acommodating low-vision users

Here's something that sometimes falls through the cracks when designing UI: people with low vision might need to use a screen reader to work their way through your interface.

Several issues arise in this scenario, but let's just touch on one for now: You might have static text on a screen (that is, text that's not affiliated with a control such as an option button). This could include explanatory text for a dialog box or explanatory dynamic text that changes depending on what's been selected.

Because the user can specify how much information to have read aloud, this text might not get read as the screen reader moves down the screen; and if the user simply presses TAB to move quickly among options, this static text will probably not get read. If at all possible the UI should mitigate this by making control label text as clear as possible.

Wednesday, May 19, 2004

More Bloopers - GUI Bloopers by Jeff Johnson

More Bloopers - GUI Bloopers by Jeff Johnson

Acronyms in UI

Burning issue: Using acronyms in UI text

Some folks use acronyms whenever the mood strikes. One problem when writing for a wide audience is that many (most?) acronyms are pretty arcane. If using an acronym is unavoidable, you should ensure that the user understands it -- if it's not a common one (such as DVD), is it spelled out on first use on the screen?

Also if your content is translated into other languages, you should ensure that this won't raise localization issues pertaining to the acronym.

Check your in-house style manual, or guides such as The Chicago Manual of Style, for additional guidelines about using acronyms in headings and titles. The Internet can be a good usage resource too, although not wholly consistent. At any rate, you should ensure that the acronym is spelled and capitalized correctly in your UI, and used consistently.

You also should check with your legal department, if you have one, to ensure that there isn't a trademark issue.

Only pluralize an acronym when it's appropriate to the context, unless the spelled-out version is itself plural. For example, adding an s to FAQ isn't necessary because the Q already stands for questions.

It might be advisable to avoid acronyms unless necessary -- for example, if you have space constraints.