This blog has been moved to Redwerb.com.

Monday, July 30, 2007

Usability Rule #2: Stick with the K.I.S.S Principle

Keep It Simple, Stupid, or the way I like to phrase it, make the simple things simple and the complex things possible. This is a very common design mistake. Users ask for tons of features and developers work hard at delivering those features, but often times at the expense of a simple to use application.

Of course by simple, I mean "everything should be made as simple as possible, but no simpler" (quote attributed to Albert Einstein). If the interface doesn't make the most common way of performing a task as simple as possible, the interface has failed the user.

An example for good use of this principle is the Remote Desktop connection interface. When you start Remote Desktop, you see a UI with the absolute bare minimum interface for connecting to another computer (figure 1), a single textbox for entering the name of the computer you want to connect to and some buttons to perform what should be easy to understand commands (at least, easy to understand if you know what the application is supposed to do in the first place).

Figure 1: Simple interface for Remote Desktop.
Figure 1: Simple interface for Remote Desktop.

Of course there are a lot of options that you might want to change when connecting to another computer, if you are an advanced user with a special need you can select the Options >> button. This button opens another window (figure 2) that allows you to change the advanced settings of Remote Desktop, you can even save the settings so that you don't need to go through the options dialog again.

Figure 2: Complex interface for Remote Desktop.
Figure 2: Complex interface for Remote Desktop.

The term for this type of interface is progressive disclosure which simply means removing less frequently used interface elements from the primary screen while still providing a means of accessing those elements. This can be in the form of a secondary screen, such as in Remote Desktop, collapsing regions, or providing an Advanced tab within a tabbed interface (this can be seen in the options dialog in the Remote Desktop screenshot, figure 2).

If you want to see how not to design a UI, take a look at Bulk Rename Utility (figure 3). It seems to provide every possible option on the main form, regardless of how often it is used. Bulk Rename Utility is a useful tool intended for computer savvy people who can probably overlook a bad UI if it provides the features they need, but you would never want to put a UI like this in front of a technophobe.

bulkrename
Figure 3: Overly complex interface for Bulk Rename Utility.

So how do you know what the simplest interface is for the user? Asking the users is certainly a good start, though not entirely reliable (the mind has a tendency to assign equal importance to exceptional cases and common ones). Other methods include watching the user actually performing the task and logging feature usage and analyzing the results. Feature logging will probably result in the most comprehensive and accurate view of the current system, but it requires you to have a system in place already and for your users to be willing to share the information that is being logged.

By keeping the interface as simple as possible, the user is able to accomplish the task quicker with higher accuracy, less training, and fewer support calls. By providing a simple interface with the ability to perform more complex tasks you have taken nothing away from the user except a barrier to using the application.

Sunday, July 22, 2007

Usability Rule #1: Consistency is More Important Than Correctness

One of my favorite usability rules is "consistency is more important than correctness." Just to be clear, this is not intended to diminish the importance of correctness, it simply means that if you can't be correct everywhere, you should at least be consistent. Consistency can help lower training costs and reduce mistakes.

As an example of this rule, let's take a complex application with many forms. Dates are displayed on many of these forms using a hard coded format of Month/Day/Year. You have been tasked to create a new form. As a good, conscientious developer, you know that dates should be formatted differently based on the culture of the user and that there is a built in function for formatting the date that actually requires less effort on your part than formatting the date yourself.

What should you do?

  1. Format the date correctly using the built-in culture sensitive formatting.
  2. Use the same hard coded format as every other place in the application.

Of course, the best answer is C, fix all the other places in the application where the date is formatted incorrectly. Unfortunately, that's not an option you. You don't have access to the other source code, there is business logic relying on the date format, nobody has reported it as a problem before, there is not enough time to fix it, we don't have the testing resources to test in different cultures, etc. (I'm sure you have heard plenty of reasons why people don't want to fix incorrect code).

The second best option is B, format the date consistently with all the other dates in the system. If all the dates are formatted wrong and the user is forced to use the software, they will eventually learn how the date is formatted and will expect the date to always be formatted that way. If their culture reverses the month and day (Day/Month/Year) the user may not realize that you are formatting it correctly and read the date incorrectly possibly causing costly mistakes (a customer doesn't get charged for 6 months, the company's domain name expires, a patient doesn't get scheduled for treatment soon enough and dies, etc.).

Of course, data formatting is not the only thing that should be consistent. Here is a list of common things to look for...

  • Formatting of data - date, time, elapsed time, currency, numbers, etc
  • Theme (colors and fonts) 
  • Unit-of-measure - Be consistent where you can and always make sure the unit of measure is clearly marked.
  • Captions - If a field is called XXX on one screen, it should always be called that. Same goes with commands (such as buttons, links, menu items, etc) and any other non-data text displayed to the user. This applies to icons as well.
  • Shortcuts - Common commands should have the same shortcut across the entire application.
  • Messages - Decide on a common style and use it consistently (for example, friendly or professional)
  • Margins - Space your controls consistently. Different controls may require different margins, decide up front what those should be and stick with it.
  • Alignment - Are captions aligned left? right? top? bottom? Are numbers aligned to the left? right?
  • Layout - How do you group controls (group boxes, horizontal rules, tabs)? Where do you place commands that are related to data fields?
  • General flow - How does a user open a record? Save it? Delete it? Create a new one? Access related data? View messages? How are errors handled?
  • Consistent with other applications the user may be familiar with - If a user is already familiar with another application, you can leverage their skill from that application in your own.

Monday, July 16, 2007

SlickRun Review

Summertime has really effected my blogging schedule. I've been spending my freetime working on a website for my neighborhood and building a garden wall. I'm almost done with the wall, but we might end up extending it another 30 feet, so we'll see.

Just recently I've started using a tool called SlickRun. It's a very simple tool that is essentially just a textbox (no form, buttons, etc). It allows you to type in commands similar to the Run (Win+R) dialog built into Windows. The cool thing about SlickRun however, is that you can also add "MagicWords" to it so that you can perform more complex commands with a single word.

SlickRunConfig There are plenty of configuration options for SlickRun to get it to look and work the way you want (see the screenshot to the right). You can even setup SlickRun to run instead of the Windows Run dialog. This is a little tricky since you have to edit the config file (I'm not sure why this setting isn't in the SlickRun config dialog), but once you set it up, when you press Win+R you get SlickRun!

Instructions to setup SlickRun to handle Win+R in Vista
  1. Install SlickRun
  2. Open Windows Explorer (Win+E)
  3. Navigate to your profile directory (C:\Users\<MyUserName>\AppData\Roaming\SlickRun) - AppData is a hidden folder, however, you should be able to type in the path directly.
  4. Open the SlickRun.ini file in your favorite text editor
  5. Locate the GrabWinR setting and change the value to 1 (GrabWinR=1)
    SlickRunIni
  6. Save the changes