Is Your Software Polite?
This post is based off the politeness criteria mentioned in The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity
One way to produce quality software is to design it to behave like a good human workmate. Good human workmates are polite and therefore polite software should have the following human characteristics:
- It is interested in me. When people are interested in other person they will remember things about the person. Software should function similarly. If I set an option or open a file in a particular location, the option should remain set and the file location should be retained the next time I open the program.
- It is deferential to me. The software should let me do what I want. It does not shoehorn me into doing something in only one way. While the software should be able to offer its opinion on an action I take, it should never judge me.
- It is forthcoming. Common options are readily available and information is always available. Any information related to the user’s end goal should be intelligently presented. Any tools that would be implicitly available to perform the end goal should be available without making a special request to the software.
- It has common sense. Common options are not intermingled with uncommon options. Harmless options should not be freely mixed with irreversible options that only a trained professional should use.
- It anticipates my needs. A software program should be able to use its idle time to get ready for my future actions.
- It is responsive. Feedback should be instant. Extended spinning hourglasses and pizza wheels should be avoid. Long operations should be cancelable in addition to providing feedback. Options set in one mode should be retained the next that mode is entered.
- It is taciturn about it personal problems. A program should keep quiet about it’s internal problems. It should be able to intelligently fix them without bothering the user. The user should never be blamed for a problem. Information about hard a program is internally working is not needed.
- It is well informed. Information that affects users should be visible and options that are not currently available should not be present.
- It is perceptive. If a user consistently uses one mode of operation, the software should be able to detect this and automatically offer this mode to this user. If another user has a different mode, the software should automatically offer this different mode to this user but should still be able to offer the original mode to the first user.
- It is self-confident. The software should have confidence in its own abilities and not pass the responsibility onto the user. The software should realize that I am human. It should be able to anticipate my error-proneness and allow me to reverse any change.
- It stays focused. The software should be able to perform the function it was designed for and should not try to be a do-it-all. Focus within the application should stay where the user puts it.
- It is fudgable. A program should not crash if one small thing is wrong. It should be able to keep functioning with the temporary mistake and it should guide the user into correcting them downstream.
- It gives instant gratification. The program should provide information and work for the user without demanding a lot of initial effort. The user should be able to get up and running quickly.
- It is trustworthy. Software should behave dependably. If it starts operating erratically, it will lose any trust it has built with the user.
When software becomes impolite, it will annoy and irritate us. This politeness needs to be built into the system to begin with. It cannot be bolted on afterwards.
