To many coders, application development is the more glamorous part of software development, as compared to building the user interface for the same. What most of coders ignore however, is that to the end-user, the user interface IS the system. And what most end-users want is a system, which is functional, intuitive, easy to use and has sensible defaults. Humans during their evolution from cavemen to the current society have come up with a number of rules, governing various aspects of social behavior. These are the rules that are commonly referred to as social manners. We argue that a large number of the behavioral patterns classified as “good manners” apply to software application interfaces also. Consequently, user interface designers who tend to ignore “good manners” run the risk of making their applications as bad or rude software citizens.
But what are good manners? Simply put, good manners can be summarized as show consideration, respect and care for others. It is somewhat surprising then that, whereas most of the creators of various software and web applications are well behaved and possess good social ettiquettes, some of their creations are truly rude and obnoxious in their interactions with end-users. It seems that many computer applications do not follow the basic tenets of social interactions which are common knowledge. The disconcerting fact is that some of the usability issues that underly such rude behavior has been identified and understood for decades.
Some examples of rude interfaces are summarized below:
- Irrevocable Steps: This typically refers to instances when the system decides to take some irrevocable steps, with or without user consent. Automatically applying patches and rebooting the system is a concrete example. This is seen on windows environments, wherein the OS is configured to automatically download some patch from windows update without informing/intimating the user, and after the patch is installed, auto-rebooting the system. This is the physical equivalent of your futuristic car deciding to clean itself, suddenly change directions from your current destination to the carwash, throwing all the users out of the car and washing itself.
- Pushy Behavior: Application developers want end-users to use their software as much as possible. But when their desire to promote their software to desktop users translates to the software adding itself in a number of places, including the startup menu, desktop icon, task bar, right click context menu and changing the default application for a number of file types to use itself, it can be termed as pushy behavior. Real player, and before that Paint Shop Pro was notorious for such behavior.
- Pot calling Kettle black: While doing application design, it is the responsibility of the programmer to not just anticipate, but even expect incorrect inputs from the end-users, who often are not technically savvy. In a lot of cases, however, instead of designing the software to be robust and fault tolerant, the programmers blame the end-users via vague and rude error messages. An example of such is when the application attempts to confirm some obvious condition from the end-user eg - The infamous DOS error Abort, Retry, Fail?
- Cryptic error messages: The HTTP status codes comprise of a list status codes that webservers return as a response for any HTTP request. In fact, all the HTTP status codes are very terse and to-the-point, but what is more puzzling is when website designers directly throw these cryptic error messages to end users. A very common example is, when a web server throws a “404 - page not found” error. It is fairly trivial for the website designers to put out a more graceful error message, or even re-direct it to a generic error page having a more polite error message.
- Threatening error messages: These are error messages that threaten the end-user with some sort of destructive behavior (typically data loss). That this is a very rude behavioral pattern for the application goes without saying, but what is worse is that the programmer has anticipated the condition that causes this error message, and instead of fixing the root cause, added a threatning error message to the end-user. eg - “Continuing with the operation may cause permanent data loss and cannot be undone. Yes/No?”
- Contract breaker: Windows GUI applications (typically) have a contract with the end-user that exiting the main window will close the applications. Applications that fall in this category satisfy the exit contract but keep running in the background hogging memory or CPU. Adobe is a prime example of such behavior.
We will be exploring some more such examples and analyzing their underlying patterns in upcoming posts. Please watch this space for more details.
