<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Which Consistency Are You Talking About?</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Claus Knapheide</string-name>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Siemens Corporate Research</string-name>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Inc. Princeton</string-name>
        </contrib>
        <contrib contrib-type="author">
          <string-name>claus.knapheide@siemens.com</string-name>
        </contrib>
        <contrib contrib-type="author">
          <string-name>KNIVES</string-name>
        </contrib>
        <contrib contrib-type="author">
          <string-name>MENUS</string-name>
        </contrib>
      </contrib-group>
      <pub-date>
        <year>2006</year>
      </pub-date>
      <abstract>
        <p>While chemistry describes substance by their degree of consistency, social behavior can, in English, either be consistent or not. Or rather, it can only be inconsistent, otherwise consistency is not a category by which we judge. I suggest to use a rather scientific concept and start talking about degrees of consistency - and, as in chemistry, abandon the idea of inconsistency altogether. Computers have not changed the ways users organize their knifes in their kitchens [Jonathan Grudin 1989], but computers do funny things. A knife that you just placed on the counter is suddenly gone and appears on the opposite end of the kitchen (visible only if you turn the monitor on); a dirty knife is magically cleaned and, best of all, by a simple: 'tidy up!' all your knifes are lined up from small to large. It's about time to assume that user interfaces are designed by people who know what they are doing. A serious analysis of artifacts is impossible if, at the same time, we try to fix the object when it doesn't fit into our explanations - or we have trouble finding the 'system' or 'rule'. Some people live in messy kitchens, some believe it natural to organize knives by the angle of their tips, and my grandmother occasionally threw a dirty one back into her drawer with silverware. In fact, nobody would accuse granny of inconsistency, but we would probably find that she has made a mistake: the system works, which allows to identify an error. Likewise, nobody would be surprised, confused, angry or malicious if a knife suddenly appeared in the bedroom: on the TV screen in the context of an ad for a steak restaurant.</p>
      </abstract>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>CONTEXTS</title>
      <p>
        Literature on consistency in UI design hints to the relevance of contexts: this typically is the task
        <xref ref-type="bibr" rid="ref2">(Grudin 1989)</xref>
        – a reference system that consistency as a topic simply inherits from the concept of
users whose actions, especially when productive activity is involved, are tasks.
      </p>
      <p>
        Let’s take this for granted, and let’s further assume that there potentially is a complex, stratified if you
will, system of contexts
        <xref ref-type="bibr" rid="ref2 ref6">(however, I disagree with the terminology used by Nielsen 1988 who talks
about dimensions, and Grudin 1989 who calls them types of consistency)</xref>
        , and that a given element
of the artifact is somewhat related to multiple of these systems, one of which is the task, another one
is the computer or application a user works with. The idea of context in the discipline of functional
pragmatics/ linguistics, however, is based on mental representations of user actions – I would
therefore argue that consistency is a function of the users knowledge, the computer she is using, and
the activity she performs. And that it is a system as a whole that is more, or less, consistent, and not
a single element.
      </p>
    </sec>
    <sec id="sec-2">
      <title>WE ALL DO THE SAME</title>
      <p>A very brief and amazingly exhaustive statement about consistency dates from 1990: it is not
important that the same function is always be performed in the same way, but it is paramount that the
same user action is always interpreted in the same way [Tognazzini 1990]. The relation between
form and function is not symmetrical.</p>
      <p>Going back to language: we have no way of knowing what someone will say to us if it was predicted
that this person now opens his mouth and greets us. Nobody would ever expect me to say ‘hello
there’ today because I had said ‘hello there’ when I saw him a week ago. And as you may have a
© 2006 for the individual papers by the papers' authors. Copying permitted for private and
scientific purposes. Re-publication of material on this page requires permission by the
copyright owners.
specific knife to cut raw meet, which one do you use for broccoli or to open a stubborn combi-pack of
coffee?
However, if someone greets me, I will in most places of the world understand it, and I can even hope
that somewhat complex explanations as I am about to write down here will be interpreted with an
astonishingly degree of accuracy. (This is why we can agree or disagree on my statements.) In the
kitchen: if you put your knives into the second drawer from the top, they will still be there if you try
and get one in an hour. Plus: the knife-ness of a knife is not impacted by its location in this or that
drawer.</p>
      <p>As we talk about this, I can expect to find agreement with you on the practical examples that I am
presenting, but of course not necessarily on my theses and underlying theories. Our beliefs and
methodologies may vary a lot, but the every day tools and mechanisms we use to do things, and the
means by which we communicate, are defined by their similarity, not differences.</p>
      <p>This makes user interface design possible: user tasks and expectations are predictable, and as much
as the user interface designer knows the relevant dimensions of user actions, she can cater to their
expectations (and perform usability testing to hear from 8 or maybe 18 people what the other
800.000 are thinking).</p>
      <p>In light of this document I believe we need to understand the systems a design decision touches on
and understand their rigidity. If the use of a certain value of red has been legally defined, this can be
assumed to be a very rigid set of rules which will hopefully create a very consistent system of use of
the legal color set. If you look at the color branding, rules may be much more flexible and the system
is less consistent, thus more design freedom.</p>
    </sec>
    <sec id="sec-3">
      <title>WHEN DO COMPUTERS BUILD A SYSTEM? – THE SCOPE OF</title>
    </sec>
    <sec id="sec-4">
      <title>CONSISTENCY</title>
      <p>Grudin 1989 included the putty knife and the Swiss army knife in his illustrative example, and I would
argue that in doing so he created a system of knives for the sake of his article that doesn’t exist in the
household he talks about: thus the perfect location for those two tools that was so unrelated to the
kitchen. Yet, for the sake of his article, or the point he wanted to make, we as readers followed him
and looked, for a moment, at the arsenal of knives as they together build a system.
It can be assumed (in fact hoped for) that we will ultimately redetect the world as it was before the
computer made us belief that there can only be a single stage that would give us all information and
provide the only workspace that we need. As was pointed out in an article in the New York Times
Magazine [Meet the Life Hackers, Oct 16th, 2005], the clock has not fallen from the wall or dropped
from our wrists, even though every single computer tells us the time. Ultimately, we need to discuss
what belongs on that monitor, and what can better be monitored if displayed elsewhere – this is for
another discussion.</p>
      <p>However, since technical integration can be expected to grow, since it can be assumed that pretty
soon a little something in the car will tell us that we forgot to turn the gas stove off, boundaries
between disjunctive systems are about to go away. Transportation authorities in Berlin are able to
send you the departure time of the next trams onto your cell phone via SMS. Does that make your
cell phone an integral part of the Berlin public transportation?
I’d rather say that public transportation AND your cell phone (plus the SMS service and the locator
number displayed on a pole at the bus stop etc.) are part of the system ‘commute’ when you are in
need to know when the next tram is coming.</p>
      <p>Some people may then expect that they can eventually pay for their tickets with a chip that has been
installed on your cell and that would directly deduct the amount from your debit card. Systems like
that have no limits, expectations grow endlessly. However, we do not detect the relevant elements of
that system by collecting all the different cell phones that people in Berlin may carry around. We do
not even need to understand the user interfaces of all these phones. But: we have to realize that
users will be very frustrated if the service works for trams and not for buses. It can be explained to
them (versioning, you know…). What could not be explained is if the systems only work on
weekdays, or if the number you have to punch in your SMS would depend upon the type of ticket that
you have.
What builds a system strictly depends upon the situation a user is in, and from the systematic
connections that the user is experiencing.</p>
    </sec>
    <sec id="sec-5">
      <title>WHAT IF…</title>
      <p>you cannot meet user expectations? While you look at the forms that you built to communicate a
function, you will realize that a design decision A seems inconsistent with c, while decision b will be
inconsistent with C. It is not clear which possible system will be prevalent to the user, and
Tognazzini’s recommendation to then create a design gap as wide as possible to point users to the
systematic context that you had identified, seems insufficient.</p>
      <p>Paul H. Grice described in 1975 that deviations in the use of language will be interpreted as
meaningful, using a mechanism called ‘conversational implication’. In language, it seems, no simple
systems can be identified (thus the unpredictability of utterances; at the very least speakers need to
always decide whether they want to be short or clear and have to place their speech act somewhere
on the continuum between these extremes). We always know that there are more rules violated than
observed. A newer theory looks at this from the angle of language development and calls for an
‘optimality theory’ of language, cf. [Blutner &amp; Zeevat 2004]. The idea, in short, is that there are
reference systems (and rules that build them) which are more or less rigid. And that a violation of a
more rigid rule comes at a higher price than that of a rather flexible one.</p>
    </sec>
    <sec id="sec-6">
      <title>SUMMARY</title>
      <p>In chemistry, consistency is an attribute of a system (the substance at hand) and not the relation of
one element to its reference system. In user interface we should look at the various overlaying
reference systems and try to identify their degrees of consistency. And if we are to design a form we
could identify the perils of misleading a user by the consistency of the reference system that we
place, or do not place, the element into. Reference systems with a lesser degree of consistency
would probably be more tolerant (thus allowing for a violation of a learned rule) than those with a rigid
structure of rules.</p>
      <p>In the workshop I plan to discuss authentic design examples, probably from the user interface design
center at Siemens.</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          <source>[1] [2] [3] [4] [5] [6] [7] [8] [9]</source>
          [10]
          <string-name>
            <given-names>R.</given-names>
            <surname>Blutner</surname>
          </string-name>
          , H. Zeevat (eds.) (
          <year>2004</year>
          )
          <article-title>Optimality Theory</article-title>
          and Pragmatics,
          <string-name>
            <surname>Palgrave McMillan H. P. Grice</surname>
          </string-name>
          (
          <year>1975</year>
          )
          <article-title>Logic and Conversation</article-title>
          . In: P. Cole &amp; J. Morgan (eds.) (
          <year>1975</year>
          )
          <article-title>Syntax and Semantics</article-title>
          , Vol.
          <volume>3</volume>
          , New York, Academic Press.
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          <string-name>
            <given-names>J.</given-names>
            <surname>Grudin</surname>
          </string-name>
          (
          <year>1989</year>
          )
          <article-title>The Case Against User Interface Consistency</article-title>
          .
          <source>In: Communications of the ACM</source>
          , vol.
          <volume>32</volume>
          , no.
          <issue>10</issue>
          ,
          <year>1989</year>
          , pg.
          <fpage>1164</fpage>
          -
          <lpage>1173</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          <string-name>
            <given-names>J.</given-names>
            <surname>Grudin</surname>
          </string-name>
          (
          <year>1992</year>
          )
          <article-title>Consistency, Standards, and Formal Evaluation…</article-title>
          <source>In: ACM Transactions on Information Systems</source>
          , Vol.
          <volume>10</volume>
          ,
          <year>1992</year>
          , pg.
          <fpage>103</fpage>
          -
          <lpage>111</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          <string-name>
            <given-names>A.</given-names>
            <surname>Happ</surname>
          </string-name>
          ,
          <string-name>
            <given-names>K.</given-names>
            <surname>Cohen</surname>
          </string-name>
          (
          <year>1989</year>
          )
          <article-title>Creating Consistency in the User Interface: Opinions and Procedures of Software Developments Experts</article-title>
          .
          <source>In SIGCHI Bulletin</source>
          <year>1989</year>
          , Vol
          <volume>21</volume>
          , no.
          <issue>1</issue>
          , pg.
          <fpage>85</fpage>
          -
          <lpage>87</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          <string-name>
            <given-names>C.</given-names>
            <surname>Lewis</surname>
          </string-name>
          ,
          <string-name>
            <given-names>D.</given-names>
            <surname>Hair</surname>
          </string-name>
          ,
          <string-name>
            <given-names>V.</given-names>
            <surname>Schoenberg</surname>
          </string-name>
          (
          <year>1989</year>
          )
          <article-title>Generalization, Consistency, and Control</article-title>
          .
          <source>In: ACM CHI '89 Proceedings, pg. 1-5</source>
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          <string-name>
            <given-names>J.</given-names>
            <surname>Nielsen</surname>
          </string-name>
          (
          <year>1988</year>
          )
          <article-title>Coordinating User Interfaces For Consistency</article-title>
          .
          <source>In: SIGCHI Bulletin</source>
          , vol.
          <volume>20</volume>
          , no.
          <issue>3</issue>
          , pg.
          <fpage>63</fpage>
          -
          <lpage>65</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          <string-name>
            <given-names>J.</given-names>
            <surname>Rieman</surname>
          </string-name>
          ,
          <string-name>
            <given-names>C.</given-names>
            <surname>Lewis</surname>
          </string-name>
          ,
          <string-name>
            <given-names>R.</given-names>
            <surname>Young</surname>
          </string-name>
          ,
          <string-name>
            <given-names>P.</given-names>
            <surname>Polson</surname>
          </string-name>
          (
          <year>1994</year>
          )
          <article-title>“Why Is a Raven Like a Writing Desk?” Lessons in Interface Consistency and Analogical Reasoning from Two Cognitive Architectures</article-title>
          . In:
          <article-title>Human Factors in Computing Systems</article-title>
          , CHI '
          <volume>94</volume>
          , pg.
          <fpage>438</fpage>
          - 444
          <string-name>
            <given-names>C.</given-names>
            <surname>Thompsen</surname>
          </string-name>
          , (
          <year>2005</year>
          )
          <article-title>Meet the Life Hackers</article-title>
          , New York Times Magazine Oct 16th, 2005
          <string-name>
            <given-names>B.</given-names>
            <surname>Tognazzini</surname>
          </string-name>
          (
          <year>1990</year>
          )
          <article-title>Consistency</article-title>
          . In: B.
          <string-name>
            <surname>Laurel</surname>
          </string-name>
          (ed.) (
          <year>1990</year>
          )
          <article-title>The Art of Human-Computer Interface Design</article-title>
          , Reading MS, Addison-Wesley,
          <year>pg</year>
          .
          <fpage>75</fpage>
          -
          <lpage>78</lpage>
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>