Interesting discussion on IxDA regarding consistency in user interfaces. My response to demands or inquires for consistency is that appropriate trumps consistent. Then I continue on to explain why the screens or controls being compared are not being handled in the same manner. It always comes down to what is appropriate in each specific context for the types of people using the application. This is the approach Jared Spool talks about in his article Consistency in Design is the Wrong Approach.
If you are asked to make software consistent, treat it like every other request and ask why. Continue asking why until you get at the real problem behind the request. If the request is just a vague, overarching cry for consistency then review the software to make sure you're being consistent with what is appropriate for the context and the users. And be prepared to explain your reasoning around any specific areas that appear on the surface to be inconsistent.
Chauncey Wilson details the various types and flavors of consistency and also describes a method for conducting a consistency inspection. Both articles are very helpful when reviewing your software applications for consistency.
I'm re-reading a classic Tog paper "Principles, Techniques, and Ethics of Stage Magic and Their Application to Human Interface Design" from 1993 and unlike many technology articles it remains just as fresh 18 years later.
Some favorite bits & pieces from the paper…
"Consistency is the key to conviction.... No matter how effective an inconsistent part may be, the damage that it does to the routine as a whole more than offsets whatever advantages it may have in itself."– Nelms. "Irregularities destroy naturalness and conviction. When naturalness disappears, and when something unnatural is evident, the spectator’s attention immediately becomes vigilant and alert. In the normal course of events, this is disastrous to deception."–Fitzkee (1945);
Showmanship does not mean, to use Ted Nelson’s term, "adding ketchup" (Nelson, 1991). It implies the application of a deep understanding of human nature to the task of making software seem vital, involving, and fun.
Showmanship is the gentle seduction of the users, leading them to accept, believe in, and feel in control of the illusory world we have built for them.
Maintaining an illusion on a computer requires the same level of commitment and fervor historically displayed by the Disney company. And it can be as easily damaged. The Star, Lisa, and early Macintosh displayed finely crafted illusions. Today, our system illusions are rent by inconsistencies, program crashes, and unfathomable conceptual models.
Programmers who have not made the transition to the design model’s illusion are easy to spot: they meet any attempt on the designer’s part to create a new and interesting design model with, "Yes, but that’s not the way it really works." The last thing a magician wants is for his spectator’s model of the act to bear any relationship to "the way it really works."
In the 1930s, a major high-rise office building was opened with what soon proved to be too few elevators. After a series of engineering firms were brought in, each confirming that there was no way to either speed up the existing elevators or add additional ones, the building owners, in despair, brought in an interior designer. The designer recommended that huge floor-to-ceiling mirrors be installed between each pair of elevators, and the complaints disappeared. People now had something to do while waiting: either gazing at their own magnificent image or peering secretively at others with little fear of being caught.
The engineers had concentrated on reducing objective time; the designer concentrated on reducing subjective time. Reducing subjective time works.
If users cannot trust the system, if they are occasionally but violently thrust into the programmer’s reality, they can not, will not, and should not believe in the world we are making for them.
"Pipelining"–drawing screens, gathering data before needed–is a form of anticipation. Printer buffering is a form of premature consumption. These techniques illustrate that the timing of the user’s illusion need not track the reality of the operating system or hardware.
One caveat: illusion is sometimes shattered on our computers when something goes wrong: telling the user that "the document has been successfully sent to the printer" when the document has in fact only been spooled to the computer’s internal print buffer would seem like a good idea, but not when a difficulty arises with the print buffer software and the user ends up dragging a properly-functioning 100 pound laser printer into the shop for repair. We need to consider the entirety of the user’s reality, and that consists of both the expected and unexpected.
A core skill of interaction design is understanding how people think — specifically in relation to software systems but also on a general level. Most of this knowledge comes from observation & experience and the occasional psychology book in my IxD reading rotation.
I've recently come across a couple great sites that are useful resources for understanding people:
What Makes Them Click
The author has a Ph.D. in Psychology and offers great tips on how people think and relating that to software design.
You Are Not So Smart
I love the tagline : "A celebration of self-delusion". There are not many direct ties into software design, however the stories around each topics are fun and very useful in understanding how people tick.
This site starts from a UX focus and many of the myths center around how people really think. Each article contains lots of links to supplemental material.