|
|
       |
|
 |
This Java Swing telephone book was for users with some experience on the internet and using word processors. We redesigned the appearance of the interface and made some recommendations for improving usability in a short time frame. The total cost of this project in 2001 was $2,600.
Our evaluation included a suggested redesign of the main window, which was intended to help the client visualize some of our ideas.
Before (Click to enlarge)
After (Click to enlarge)
The following is an excerpt from the evaluation report.
Assuming you do continue to use tabs as the main controls for the UI, there is a further problem with the Contact Profile tab. There are five tabs on the main control area of the interface. One of these tabs is not like the others.
The Contact Profile tab is normally greyed out. The user cannot click on it. The only way to get to that tab is if the user double clicks on a name in the Contact List (e.g. above he has double clicked on Hagan Rivers). When he does, he is switched to the Contact Profile tab.
The Contact Profile tab behaves differently from standard tabs:
If you are looking at the Contact Profile and then click on another tab (say, Settings), you cannot then return to the Contact Profile tab. You can never get to this tab by actually clicking on it. The only way to get to this tab is by performing a completely unrelated action. Users may obsess over how to get to the Contact Profile tab.
The computer should not be changing tabs for the user. The user is in control of which tab he's looking at. If the computer changes it, you take the risk that the user will not notice the change and will be lost.
There is also a risk that you'll be interrupting the user's task at the moment. Say, for example, that a user is trying to copy a phone number from "Elsa Rivers" to "Hagan Rivers" in the image above. He double clicks on Hagan Rivers, hoping to be able to view the Contact List and the information for Hagan Rivers at the same time, and instead finds that his entire window has changed. He may try to figure out how to close this new window (and he may succeed, thereby shutting down the entire application). He may not know where he was in the interface before and, thus, have no idea how to return.
In a more conventional interface, the Contact Profile information would be presented in a separate window. This has several advantages:
You could, potentially, show more than one Contact Profile at once, which would make it possible for users to copy and paste information or compare information on several contacts.
The user will have a better understanding of the relationship of the Contact Profile to the Contact List (and other areas of the interface).
The user's task and frame of reference won't be interrupted by a sudden change in the interface.
Recommendation: We would suggest bringing up the Contact Profile information in a separate window.
We'll also see this issue in the Search Results discussion.
On the Contact List window, the user is presented with a set of tabs that break up the list of contacts by last name. Each tab has 2-3 letters of the alphabet. This kind of interface reflects the old style address books that have a slider that you can move to a particular letter before opening the book. This is a much more conventional use of tabs in the interface and we see no particular problem with using this control here. However, we do have a suggestion for how to make these tabs more useful to the user.
The very first time a user comes to the product, each of the Contact List pages will be empty. And, in fact, there may be many users with no more than a few names per tab, even after months of using the Syndeo UI. Such users might be frustrated that they are constantly forced to flip through tabs to look at only 10 or 20 names. Other users might fill several pages in the contact list and wonder why they are forced to scroll on some tabs and not others.
What if the tabs were, instead, intelligent? What if the number of tabs and the letters on each tab were a reflection of the data that the user has entered. So the first time they use the product there is, perhaps, only one tab (or none). After filling that page with names, the user finds that the list of names is now broken evenly into two tabs. This might be "A-F" and "G-Z" for one user, and "A-Q" and "R-Z" for another.
For a user who knows many people whose names end with "R" and "S", perhaps his tabs will break these two apart into their own tabs. Eventually, the UI will require users to scroll through their list of names but not until the Contact List is very full.
In essence, these tabs respond intelligently to the information they contain. This will help the user to manage his Contact List more quickly and easily.
It's
very important that color never be used as the sole method through
which to convey essential information to the user.
Why is this? There are several reasons. The controls shown here require the user to figure out what is meant by the color yellow. There is no way to find out whether "Call Blocking" is on or off unless you can figure out what yellow is supposed to mean. This makes the user expend effort thinking about something which should just be immediately obvious to him. Color, by itself, cannot provide meaning.
This is aggravated by the fact that people don't generally agree on the meaning of colors. You might say, let's change the colors so that Red is off and Green is on. And there are many users who would agree that "red" means bad, error, or stop. But those opinions are not universal. The Chinese, for example, use red in celebrations and weddings, so perhaps it has little or no association with "bad" for them.
Finally, there is the important issue of colorblindess, which affects (conservatively) 1 in 12 men. If you rely on color in the example above, some of your users may be completely unable to tell your controls apart.
Recommendation: We suggest changing the appearance of this control so that it's more obvious what on and off are - perhaps a checkbox, which is the more traditional interface control in this situation. And in general, we recommend that the interface does not rely on color alone to communicate essential information.
The
same visual element is used for two very different controls in the
interface: buttons and checkboxes. In the image on the right we see
the aqua "pill" next to the word Save, on the bottom and
next to the words "Always Forward" on top. But these two "pills" will
do very different things when they are pushed.
Pressing the Save pill is like clicking a Save button. Buttons, when clicked, immediately perform an action. They have no state and are objects through which the user gives direct commands.
Pressing the Always Forward pill will cause it to change color, indicating that Always Forward is either on or off, depending on the current color. The color changes because these controls have a state that the user can set. This behavior is much more like the behavior of a checkbox or a radio button.
So, the first problem here is that the interface is combining several
different controls into one visual object. This will be difficult
for users who have certain expectations for how controls behave.
They won't be able to tell what a control will do until they click
on it and they may not even be sure after that.
The
second problem is, perhaps, more subtle. Using the conventional controls
helps convey information to the user. In the example above, the choices
appear to be Always Forward OR On Busy OR On No Answer OR Selective.
In fact, if the user selects "Always Forward" then it's not necessary to select any of the other choices. But this is not being conveyed by these controls unless you explore them.
Using more conventional controls (and some changes to the text), the image above shows how the interface might look. As you can see, the controls themselves provide information about what is happening and what elements control one another.
Recommendation: It is important to use generally accepted controls: buttons, radio buttons, and checkboxes. These are controls that users are familiar with and it's important to build on their knowledge and expectations. However, it's not necessary to use the Java Swing controls in the UI: there's no reason that the interface can't be more visually exciting.
| Home | Makeover | Design | Demo | Research | Who We Are | Portfolio |
Copyright ©2008 Two Rivers Consulting Corporation.
All Rights Reserved.
Telephone: 978.352.2585 and ask for Hagan Rivers
We are located on the North Shore of Massachusetts
Email: moreinfo at tworivers.com (we don't link to our email address so we won't get spam)
Two Rivers Consulting Corporation never sends mass mailings (spam). If you think you have received spam mail from us, then you have been misled. We detest spam mail and we do not support its use. The Coalition Against Unsolicited Commercial Email can help you track down and stop unsolicited email.