<?xml version="1.0"?>
<?xml-stylesheet href="/transform" type="text/xsl"?>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:bibo="http://purl.org/ontology/bibo/" xmlns:bs="http://purl.org/ontology/bibo/status/" xmlns:ci="https://vocab.methodandstructure.com/content-inventory#" xmlns:dct="http://purl.org/dc/terms/" xmlns:foaf="http://xmlns.com/foaf/0.1/" xmlns:owl="http://www.w3.org/2002/07/owl#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:xhv="http://www.w3.org/1999/xhtml/vocab#" xmlns:xsd="http://www.w3.org/2001/XMLSchema#" lang="en" prefix="bibo: http://purl.org/ontology/bibo/ bs: http://purl.org/ontology/bibo/status/ ci: https://vocab.methodandstructure.com/content-inventory# dct: http://purl.org/dc/terms/ foaf: http://xmlns.com/foaf/0.1/ owl: http://www.w3.org/2002/07/owl# rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns# xhv: http://www.w3.org/1999/xhtml/vocab# xsd: http://www.w3.org/2001/XMLSchema#" vocab="http://www.w3.org/1999/xhtml/vocab#" xml:lang="en">
  <head>
    <title property="dct:title">Computational Feasibility for Interaction Designers</title>
    <base href="https://doriantaylor.com/computational-feasibility-for-interaction-designers"/>
    <link href="document-stats#EwxleODP6MWt5eHbQyUWcI" rev="ci:document"/>
    <link href="elsewhere" rel="alternate bookmark" title="Elsewhere"/>
    <link href="this-site" rel="alternate index" title="This Site"/>
    <link href="http://purl.org/ontology/bibo/status/published" rel="bibo:status"/>
    <link href="" rel="ci:canonical owl:sameAs" title="Computational Feasibility for Interaction Designers"/>
    <link href="lexicon/#E-ZY5i7K1cqzfT0p1L9ajJ" rel="dct:audience" title="Digital Media Practitioner"/>
    <link href="person/dorian-taylor#me" rel="dct:creator" title="Dorian Taylor"/>
    <link href="person/dorian-taylor" rel="meta" title="Who I Am"/>
    <link about="./" href="3f36c30c-6096-454a-8a22-c062100ae41f" rel="alternate" type="application/atom+xml"/>
    <link about="./" href="f07f5044-01bc-472d-9079-9b07771b731c" rel="alternate" type="application/atom+xml"/>
    <link about="./" href="this-site" rel="alternate"/>
    <link about="./" href="elsewhere" rel="alternate"/>
    <link about="./" href="e341ca62-0387-4cea-b69a-cdabc7656871" rel="alternate" type="application/atom+xml"/>
    <link about="verso/" href="3f36c30c-6096-454a-8a22-c062100ae41f" rel="alternate" type="application/atom+xml"/>
    <link about="verso/" href="this-site" rel="alternate"/>
    <link about="verso/" href="elsewhere" rel="alternate"/>
    <meta content="computational-feasibility-for-interaction-designers" datatype="xsd:token" property="ci:canonical-slug"/>
    <meta content="feasibility-for-interaction-designers" datatype="xsd:token" property="ci:slug"/>
    <meta content="This is the first in a series of articles addressing the aspects of computational feasibility and computer and software engineering which pertain to interaction designers." name="description" property="dct:abstract"/>
    <meta content="2009-01-17T04:20:57+00:00" datatype="xsd:dateTime" property="dct:created"/>
    <meta content="computational-feasibility-for-interaction-designers" property="dct:identifier"/>
    <meta content="feasibility-for-interaction-designers" property="dct:identifier"/>
    <meta content="2009-04-30T20:59:45+00:00" datatype="xsd:dateTime" property="dct:issued"/>
    <meta content="2009-03-04T00:43:00+00:00" datatype="xsd:dateTime" property="dct:modified"/>
    <meta content="2009-04-11T23:38:04+00:00" datatype="xsd:dateTime" property="dct:modified"/>
    <meta content="2009-04-30T20:23:07+00:00" datatype="xsd:dateTime" property="dct:modified"/>
    <meta content="2022-05-31T04:18:52+00:00" datatype="xsd:dateTime" property="dct:modified"/>
    <meta content="2022-05-31T15:10:50+00:00" datatype="xsd:dateTime" property="dct:modified"/>
    <meta about="person/dorian-taylor#me" content="Dorian Taylor" name="author" property="foaf:name"/>
    <meta content="summary" name="twitter:card"/>
    <meta content="@doriantaylor" name="twitter:site"/>
    <meta content="Computational Feasibility for Interaction Designers" name="twitter:title"/>
    <meta content="This is the first in a series of articles addressing the aspects of computational feasibility and computer and software engineering which pertain to interaction designers." name="twitter:description"/>
    <object>
      <nav>
        <ul>
          <li>
            <a href="document-stats#EwxleODP6MWt5eHbQyUWcI" rev="ci:document" typeof="qb:Observation">
              <span>urn:uuid:c3195e38-33fa-4316-8b79-7876d0c9459c</span>
            </a>
          </li>
        </ul>
      </nav>
    </object>
  </head>
  <body about="" id="EFvFxxmlqXAUK39jqC2IVI" typeof="bibo:Article">
    <p><a href="http://en.wikipedia.org/wiki/Interaction_design" title="Interaction design &#x2014; Wikipedia" rel="dct:references">Interaction designers</a> know that if you use a computer to control any other kind of device or process, <a href="book/the-inmates-are-running-the-asylum" title="The Inmates are Running the Asylum" rel="dct:references">the computer takes over</a>. These computers can range in complexity from embedded chips on credit cards to globe-spanning distributed clusters. As long as it is possible to describe, and as long as economy favours them over a traditional mechanical or manual process, computer- and software-driven systems will prevail.</p>
    <p>Because of the tendency for computers to usurp the behaviour of whatever they are attached to, it is useful to know how they themselves behave. The purpose of this series of articles is therefore to outfit interaction designers with an understanding of the basic properties and behaviours of computers, to help them make more informed designs and interact more productively with software engineers.</p>
    <section id="EGllzR-7zkXAQqkx9w-IVK">
      <h2>Promises Kept</h2>
      <p>Our concern as interaction designers, with regard to computational feasibility, is primarily around closing the gap between what we <strong>promise</strong> the <em>people</em> who <em>use</em> and who are <em>affected by</em> the software-driven product and what we <strong>deliver</strong>.</p>
      <p>Some of these promises are explicit, but many are not. For instance, when we present a shutter button on a digital camera, we make a tacit pledge to capture what is in the frame the moment the button is pressed, <a href="http://www.kodak.com/global/en/corp/historyOfKodak/historyIntro.jhtml?pq-path=2217/2687" title="History of Kodak" rel="dct:references">as has been the case for a century</a>. In practice, this is a <span class="parenthesis" title="While this ultimately drives users into the higher-quality and more expensive digital cameras, recognizing this limitation in lower-end models, say, with a graphical timer, would likely sell more units overall.">difficult promise to keep</span>. We commit in similar ways when we offer to search a computer's hard drive for a piece of data like a telephone number, or expose a hypertext link on a <abbr title="World-Wide Web">Web</abbr> site.</p>
      <p>As often as not, computer-driven artifacts and processes offer us immediacy and then leave us to wait. They offer completeness and produce glaring omissions. They offer us certitude and return fallacies. They offer us reliability and then summarily collapse. Whoever coined the maxim <em>computers never lie</em> has obviously never encountered a computer.</p>
      <p>If we  arm ourselves with an understanding of how these machines work, we can help keep the word of the systems we design, or at least not unduly inflate the expectations of the people who come in contact with them.</p>
    </section>
  </body>
</html>
