What is "Excise" and Why is it Important for .NET Developers to be Aware of it?
I'm reading a GREAT book! It's called About Face 2.0 by usability Guru and Father of Visual Basic Alan Cooper and his co-author Robert Reimann. In Chapter 10, Cooper discusses the concept of excise:
Cooper defines excise as "the extra work that satisfies either the needs of our tools or those of outside agents as we try to achieve our objectives". To explain, he relates software to a car. With a car, our objective is driving to our destination. Inserting the key, opening the garage door, buckling the seatbelt, adjusting the temperature and putting the car into gear are not actions that help us reach our goal; they are actions that our tool (the car) requires to function to our needs.
When excise tasks are eliminated, the user becomes more productive and efficient, and our software becomes easier to use. Chapter 10 discusses some of the types of excise such as:
- "Welding on Training Wheels" - This refers to all the things we try to do for novice users to make things easier for them. These same things become excise for experienced users. My best analogy to this concept is the Microsoft Office Assistant (or ms agent). To a novice user, this little guy is a friendly helpful addition to the user experience. However after one becomes proficient in Microsoft Office, he has no need to interact with that doggone paperclip anymore and he may indeed wish it dead - had not Microsoft Office designers been kind enough to provide the user with a method of turning him off and shutting him up for good. "No I do NOT need your help with this letter thank you!"....
- "Stopping the Proceedings With Idiocy" - Known as one of the most disruptive forms of excise, this can be easily avoided with some foresight. Error messages and confirmation dialogues are the greatest offenders. The average user is not interested with information portrayed in an error message. This is usually information the user does not understand or care about or it requires more action to fix a problem that should have been handled in the software. Using good error logging and smooth exception handling to eliminate the need for error dialogue is an essential way .NET developers can address this. Kirk Allen Evans gave a great talk about the wonderful ways you can handle exceptions in .NET at the last Atlanta .NET User group Meeting. Write him and ask any questions you might have.
- "Protecting us From Ourselves" - Developers need to remember that password protection is not necessary in all contexts. While appropriate for a professional setting, the novice user at home may not need them. There should always be a way to turn that option off, just as in the case of the MS Office Assistant.
Cooper sums up this chapter with a bulleted list of common excise traps. I'll quote them for you:
- Don't force the user to go to another window to perform a function that affects this window.
- Don't force the user to remember where he put things in the hierarchical file system.
- Don't force the user to resize windows unnecessarily. When a child window pops up on the screen, the program should size it appropriately for its contents. Don't make it big and empty or so small that it requires constant scaling.
- Don't force the user to move windows. If there is open space on the desktop, put the program there instead of directly over some other already-open program.
- Don't force the user to re-enter her personal settings. If she has ever set a font, a color, an indentation, or a sound, make sure that she doesn't have to do it again unless she wants a change.
- Don't force the user to fill fields to satisfy some arbitrary measure of completeness. If the user wants to omit some details from the transaction entry screen, don't force him to enter them. Assume that he has a good reason for not entering them. The completeness of the database (in most cases) isn't worth badgering the user over.
- Don't force the user to ask permission. This is frequently a symptom of not allowing input in the same place as output.
- Don't ask the user to confirm his actions (this implies a robust undo facility).
- Don't let the user's actions result in an error.
Now that you have this great information, run along all of you and EXCISE that stuff from your products!