🚀 go-pugleaf

   - Foolish consistency is the hobgoblin of little minds.  (?eliot?)
   - For every principle of user interface design, there is an equal
     and opposite principle of user interface design.  clanton

Before arguing the principle of consistency, it is important to
understand what purpose is served by principles of interface design.
I can see two.  Interface design is a communications art much like
literature, graphics design (not to be confused the entirely different
subject of with computer graphics), photography and the decorative arts.  
How do you learn to write, take photographs, or become a doctor?  You 
can start with education, but the real learning comes from practice and 
experience.  A statement of principles has some value not because it 
defines what is right, but because it provides a hook on which to hang
examples and a focus for discussion and thought.  The goal for the 
budding interface designer is to develop taste and style.

Another purpose, equally important, of a statement of principles is to 
help mediocre designers produce competent interfaces.    Most software 
interfaces are going to be produced by ordinary programmers in the 
forseeable future.  Not everyone needs to be a James Joyce, but Strunk 
and White can help the majority of people to write an understandable 
paragraph.  In this sense, fashion (like the Mac "style" guide) can 
substitute for style (the ability of a skilled designer to create an
interface that is distinctive and usable).

Judged on the grounds of meeting these needs, the principle of
consistency has a serious problem of ambiguity.  What should be
consistent with what?  "Consistent with user expectations" is almost
tautological, and where it is not, it is wrong.  Software interface can
be analyzed in terms of three levels of interaction.  The lexical level 
consists of components like key presses and mouse motions.  The 
syntactic level organizes these components into distinct interactions 
such as menu selection and text highlighting.  The semantic level 
provides the users perception of the what the software is doing at the 
conceptual level.  As with natural language, there is much to gain from 
a consistent alphabet of components.  These should be consistent on both 
the input and output sides.  I would not typically design an interface 
to consist of double clicks, triple clicks, quadruple clicks, etc.  I 
strive for a small set of useful primitives.  All labels are in the same 
typeface, and only a small set of point sizes are used as needed.  
Redundancy is used to clarify the interface; user enterable fields have a 
different typeface as well as other indications of their distinction from 
labels.  The limited and consistently used lexical elements are composed 
to form the syntax of the interface.  The syntax is represented by 
interactors or widgets, two words gaining popularity to describe 
interactive software components for building interfaces.  Again, I 
believe that a small set of such components should be used to build an 
interface.  The user can learn how to interact with each widget then carry 
that understanding over to other instances independent of the semantics 
of the widget in the application.  

At the semantic level, the principle of consistency has little value.
Like language, lexical and syntactic consistency makes it easier to 
master the tools of expression and interaction, but the richness of what 
can and must be expressed is so great that I can not imagine reducing it 
to any regular form.  In the last decade, I have been involved in the 
design of perhaps a score of application interfaces, as well as the 
internal design of perhaps a third of those.  These systems range from 
process control to office automation.  One thing is certain, the face 
of these programs does not match the innards.  While the internal 
algorithms are often interesting, they are formal and regular because 
that is how you "design in" reliability, performance, maintainability, 
and all those other software engineering virtues.  User expectations 
are neither formal nor regular.  Matching the internal design to the 
user's needs is the job of the interface, which must clarify the 
relationship of the machine's world with that of the user.  My experience 
is abounding with proof that interface consistency at the conceptual 
level is unlikely to match the user's expectations and desires.  

Of course, I also have a theory to explain the highly irregular nature
of the user's requirements based on the sociology of organizations from 
which those requirements emerge.  In brief, reality presents complex 
challenges, and organizations evolve their models for addressing those 
challenges over time.  At any point in time, the current solution 
contains the entire ontogeny of the organization's past in dealing 
with a problem.   Like the layers of vegetation and rock in the earth's
crust, you can see this stratigraphy of solutions in the language and
concepts used to describe the requirements, as well as whatever current
systems are used which the software must reflect.  The QWERTY keyboard
of a color bitmapped computer workstation is a very simple example.
Another fundamental reason for inconsistent semantics has to do with
the complexity of modeling reality.  The behavior of the real world is
so complex that people and organizations use heuristics rather than 
analytic solutions.  A characteristic of heuristics is their limited domain, 
and sudden inapplicability when certain conditions are not met.  This shows
up in interface design requirements as irregularities and apparent
contradictions at the borders between two methods of solutions.