Usable Interfaces – What UI Should Mean
I have always been a usability freak. Everywhere I go, and for as long as I can remember, I constantly look at everything and busily think how it could be improved. I am not just talking about computer software, but things like airlines, public toilets, government, and subway systems. In the last few years however I have spent a lot of time thinking specifically about software. I have presented many sessions as well on this topic.
What I have come to realize is that there are a variety of problems with today’s computer software. There are the obvious problems that are caused by individual developers. But there are also major problems with premises we use to design our user interfaces.
When I speak of problems caused by individual developers, I mean things like oddly
worded dialogs that confuse users, or functionality that is difficult to use. We have become so accustomed to such that generally it is expected and accepted.
When I speak of problems of premise, I speak of things that we all do because all software does it. We do it because it is “the accepted” way without really thinking why we do it. This comes about from something I call “incrementalism”. I will cover incrementalism in more depth in a future article.
I also strongly believe that developers learn better when I include non software examples to contrast and compare. It also demonstrates that the problem is not limited purely to our industry. In this article I will include both software and non software based examples.
Dastardly Dialogs
I feel as if I have collected such an archive of bad dialogs that I could successfully publish a nice coffee table picture book. Choosing which one to use in this article truly was a challenge.
Here is a picture of a set of signs taken in one of the world’s busiest airports. At first sight all appears normal. Can you tell me which way it is to gate C-13? To the right, correct? In fact could there be any dispute that C-13 might be anywhere else but to the right? After you see this sign, would you bother looking at any other signs?
But let me show you the other signs nearby.
Airport travellers are often rushed to transfer between planes for a variety of reasons. I am quite sure many travellers have seen the sign that says “C 1-23” and followed the arrow to the right. The problem is that if you follow the hall to the right the C concourse is quite far away. By the time you get there and find out there is no C-13 what do you do?
In fact when you get to gates C-12 and C-14, there is no mention of where C-13 is at all. Many buildings do not have a 13th floor because of superstition. And if you are holding a boarding pass that says C-13, what are you to think? I am quite confident that people have missed their connections because of this sign.
In software such dialogs are so incredibly common that we have just become used to them.
In software such dialogs are so incredibly common that we have just become used to them. As software developers we often laugh them off and use them for blog material. However for the average user these dialogs can cause real difficulties.
Here is a dialog from a trial version of Nero 7.
My options are “buy now” or “cancel”, on trial software? What happens if I click cancel? Can I still evaluate the software?
Here is another example from SQL Server Management Studio.
Here is a zoomed in version of the dialog in the center.
It must be important because there is an exclamation point icon! But what happens when I press ok? Should I be afraid? Will I lose data?
Problems of Premise
When you start a new desktop application’s user interface, where do you start? Most developers start with the premise of a main window that has a toolbar, menu, status bar, and a work area. The work area most often contains a document, overall status, a treeview and list of items, or an MDI workspace. Generally applications start out looking like WordPad.
As the application grows, we just add more and more items to the menu and toolbar. If we are very lucky, we end up looking something like Office 2003. However most applications are not so lucky, and the toolbar and menu end up being arranged in some order that makes little sense to the user.
There are several advantages to this approach. The first one is that it is a model that is consistent with other applications and will make most users reasonably comfortable. It is also easy for developers to understand the model and make a reasonable guess where new items should go.
But there are also several problems with this approach as well. As functionality grows, the toolbar and menu becomes so cluttered that things are quite difficult for users to find. This is compounded by the fact that usually no one owns the process of adding new menu or toolbar items and each developer just adds it wherever it seems fit to them.
I think Office 2007 is a step in the right direction.
The Office team realized this problem. It is why Office 2007 has a new interface.
Anyone who has used Office 2007 knows what a vast improvement this is. I personally cannot stand to go back and use older versions of Office. However implementing this new type of interface is not easy for developers. There are no standard tools available for implementing similar functionality. Some third parties offer components, but several of them are rather rough to use, and some are quite buggy. Even if you find suitable components, where do you put your functionality? How do you arrange things?
I think Office 2007 is a step in the right direction. I think we can go farther though, and will discuss some of my ideas in a future article.
Where’s the Beef?
Some of you may be upset that I have not really said much yet. I discussed a few problem dialogs and showed a quick history of Microsoft Office. But that is on purpose. So far all I strived to do is demonstrate that we have problems with our User Interfaces. Next I will discuss some preliminary things we can do.
Are you a User?
Are you a user of your own software? Do you use the software you build for anything other than testing? Some developers do, but the majority of developers are building enterprise or vertical software for users that are very different from themselves. Because of this, we as developers generally never use that software in real life. Most developers only use the software to test. Worse still, many users have little or no contact with actual end users.
Instead all information comes from business analysts, or business group owners. Some developers have actual contact with the real users, but real users usually do not know software and do not know how to properly communicate how they would like to see the software improved except for small changes.
What can be done?
In this article I will cover a few basic ideas. I’m sure you are sick of reading what I am about to say next by now, but I will dig deeper into these ideas in the future as well. For now I only have enough room and time to propose the problem and start you thinking about solutions. Here are several things you can start with.
Most developers only use their own software to test
Survey your Users
Have you ever surveyed your users? Ask them simple questions about your software and make it easy for them to answer. Stick to questions of usability and ask questions that are tied to different screens within the software.
Watch your users
Ask your users if you can sit with them, video tape, or screen record them for part of a day. If you can capture audio, this is even better as users can provide you with comments as they go. “I hate Y”, “Why can’t the software just do X?”, etc.
Record Menu and Toolbar Usage
Modify your software to log each menu item and toolbar option that the user chooses along with a timestamp. From this data you pick out several things easily. Also record each window as it is opened and closed.
First, look for places that the user often presses cancel in a dialog. If this occurs often on certain dialogs, find out why. Is the dialog prone to mistakes? Is the user using the dialog for something other than intended? Or could the user be just thrashing around in an attempt to find other functionality?
Look for repeated patterns of commands. If users are repeatedly issuing a group of commands in sequence, you should investigate making that a single option for the user.
Look for commands that are frequently used. Are they easily accessible? Or are they buried down in submenus? Look at commands that are easily accessible, are they used frequently?
Easy Feedback
Make it easy for your users to send feedback to you. Some software has feedback options on the help menu. Most link to a website. But when the user goes to the website they usually have to fill out a lot of contact info and this causes users to only send what is really worth their time. Software should have a once click feedback option that uses a built in dialog. The feature should use web services to send the feedback to ensure best chances.
You should only ask the users contact details once and keep them for future feedback. In addition, the web service connection should be checked first and if it is not possible to send the feedback alert the user before they have spent a lot of time composing a message.
At minimum this should be provided on the help menu, but better yet a new button should be added to each and every dialog that allows the user to send instant feedback. From there, the dialog and information about the dialog can be recorded and sent as well. For further functionality, allow the user to send a current screenshot of the dialog as part of the feedback.
Embrace Mistakes
As you catch users making mistakes in your software, do not simply write them off as “Stupid Users”. Especially if the same mistakes are being made repeatedly, or by many users this is a unique opportunity to see “why” the user is constantly making these mistakes. Remember Gate C-13? Who is at fault? Is it the traveller or the sign maker? Personally I don’t care who is at fault, missing planes costs money. Fixing the sign is simple and the logical action that should be taken.
Cautionary Warnings
Several of the proposed measures may carry privacy or other problems, especially depending on your industry. Be sure to check with your users first and make any participation optional. Also allow them to review any data before it is submitted back to you. If necessary, obtain a signed release form.
More Examples
If you would like to see more examples of UI and software problems, please visit my tech blog at http://www.KudzuWorld.com/