A Summary of "Chapter 3: Natural Interaction" from "The Design of Future Things"

Citation
Norman, Donald A. "Chapter 3: Natural Interaction." The Design of Future Things. New York: Basic Books, 2007. 57-90.

Summary / Assessment
In this chapter of the “Design of Future Things”, Donald Norman discusses ideas surrounding the incorporation of natural communication within designs. He draws a distinction between communication and signaling. He writes that “interactive” devices of today signal their users, rather than provide an effective means of natural communication. A dishwasher beeps when the dishes are done. A microwave beeps when food is ready. Such signals may be useful in isolation, but a cacophony of these types of signals may prove to be distracting, un-interpretable, and potentially dangerous. We should use more natural communication and sounds in our designs. Natural sounds (i.e. - sounds we encounter everyday, not sounds generated by an electronic device) can provide the location of an object, reveal their composition, and reveal their activity. The primary example of natural sound/interaction given by Norman is the whistling tea kettle.

This natural communication is referred to as implicit communication. Implicit communication also includes communication afforded by the natural side effects of people’s activities. The messy research laboratory provides the implicit signal that it is being used. Footprints in the sand implicitly tell us that someone has passed by earlier. The presence of sticky notes or underlined passages in a book tells us that the book has been read. These “non-purposeful” clues can inform us of what is happening or what has happened, provide awareness of the environment, and let us know if we should take action or continue on with what we are doing.

Affordances are “the range of activities an animal or person can perform upon an object in the world.” For example: a chair affords sitting or hiding-behind for an adult, but not for an elephant. Affordances are not attributes of an object, but rather, relationships between agents and objects. Affordances exist whether or not they have been discovered; the design challenge is to make affordances apparent to users. If affordances are easily apparent, they guide users’ behavior, and they make object interaction intuitive and natural.

Interaction with autonomous, intelligent devices is particularly challenging because communication has to go both ways (person-to-machine and machine-to-person). Norman offers horseback riding as a good example of interaction between intelligent agents. An important aspect of horseback riding is “tight-reign” and “loose-reign” control. In tight-reign control, power shifts from the horse to the rider; in loose-reign control, power shifts from the rider to the horse. Loose-reign control allows the horse to be more autonomous; however the rider can still provide some oversight through natural interaction of verbal commands, and heel kicks. This idea of allowing the natural variance of independence and interaction is powerful and can be incorporated into designing human-machine interactions.

In the remainder of the chapter, Norman makes a few other points germane to the design of human-machine interaction.

• Be Predictable. - Intelligent machines of the future should not attempt to read user’s minds or predict users’ next actions. There are two issues in doing this: firstly, predictions could be wrong, and secondly, it makes the machine’s actions unpredictable. Unpredictability leads to the user guessing at what the machine is trying to do.
• Don’t distance users from implicit communication. – Today’s automobile isolates its users from certain implicit communication, thereby reducing situational awareness. The user relies more and more on the technology in the automobile (such as automatic lane-keeping). This distancing and reliance can potentially make the automobile more dangerous to operate.
• The best designs compensate human intelligence, rather than supersede it. – For example: power-assisted devices can augment human capabilities, but they also can limit human capabilities where needed.

A Framework for Online Charitable Giving

This paper presents a framework that can be utilized by charitable organizations to increase online giving. The framework offers a systematic approach to thinking about online giving, and provides tools to construct robust mechanisms for eliciting and collecting donations. The framework consists of three components: a persuasive design component, an emotional design component, and a donation-usability component.

Direct Link to PDF
http://romalley2000.home.comcast.net/documents/OMalley_Charitable_Giving_Framework.pdf

Embedded PDF

A Summary of "Beyond the Interface: Users’ Perceptions of Interaction and Audience on Websites"

Citation
Light, A.; Wakeman, I. "Beyond the Interface: Users’ Perceptions of Interaction and Audience on Websites.” Interacting with Computers 13 (2001) 325-351.

Summary / Assessment
In “Beyond the Interface”, the authors present results of a study to measure user behavior and thought processes during website interaction. The authors’ intent is to describe how the process of interacting with websites brings about two levels of awareness in the user: (1) awareness of the interface, and (2) awareness of the social context beyond the interface.

The study is grounded in several HCI theories that place focus on using the Web as a medium for communication, rather than using it as a tool for problem solving. Perhaps one of the most important theories suggests user interactions follow similar rules to the “turn taking of spoken engagement”. When these rules are violated, users have a hard time understanding the behavior of the software. Another theory leveraged in the study deals with the idea of “ritual constraints”. “Ritual constraints” are social rules inherent in the nature of human interaction. Here, the user is cognizant of the implication of his or her acts, specifically, how the acts are interpreted by others in the social setting.

Data was gathered from twenty participants on various computer-related activities such as downloading software, using search engines, and subscribing to magazines. Accounts were collected using a retrospective interviewing technique (Vermersch’s Explicitation Interviewing Technique). Behavior and thoughts of the users were recorded in audio for analysis. The goal of the analysis was to discover patterns in the users’ accounts and differences between the accounts.

The study revealed the main point regarding user awareness. Users are aware of the two levels of interaction, one with the interface, and one with the recipients behind the interface. The second awareness seemed to present itself when users were actually entering data/interacting with the website, as apposed to simply navigating the website. The corollary is the importance for developers to adopt a communication metaphor when creating interactive components on a website. The study revealed another interesting point regarding the user’s perception of the recipients of inputted data. Recipient identity is constructed from a combination of the user’s expectations of a commercial brand, the user’s experience with interactive portions of the site, and the user’s purpose in visiting the site.

The paper concludes with recommendations on how to apply the findings of the study. The findings suggest that interactive websites would benefit from: proper identification of the recipient of the user’s data (especially if the data is personal in nature), confirmation pages after the entry of data, statements about how the recipients will use the submitted data, and an explanation of why the recipient is collecting data that does not appear to assist in the completion of the user’s task.

I think the ideas expounded upon in this paper are of great importance to the HCI professional. They help us to understand not only what users think, but how users think when engaged in discourse with interactive web applications. We can use this information when designing web applications, or any other artifact, to help us predict how users will internalize the artifact (i.e. - what mental models the users will build).

Leveraging Social Psychology Theories in Software Requirements Elicitation

I wrote this paper for my Theory and Research in HCI master's course at RPI.  The paper discusses exemplary social psychology theories that can be leveraged in the elicitation of software system requirements. Firstly, social psychology theories such as the covariation model and halo effect are presented, each theory is then explained in terms of social context, and finally, links between the theories and requirements engineering are explicated.

Direct Link to PDF
http://romalley2000.home.comcast.net/documents/OMalley_Social_Psych_Requirements.pdf

Embedded PDF

Tools for Aligning Mental Models with Conceptual Models

Introduction
As HCI professionals, a major goal is for our users to construct mental models that are closely aligned to our conceptual design models.   If the two models match up, the users will understand the system and how to use it.   We typically don't speak directly with the users, so our only means of communicating the system is through what Norman refers to as the “System Image”.   The system image is comprised of the user interface as well as any other artifacts related to the system (e.g. - user manuals and training materials).  Therefore, in order to meet our goal, we must construct an appropriate and functionally accurate system image for our users.

To construct the system image, it is important to (1) understand our users and (2) understand the tasks our users need to perform.  The reading material from this week describes methods for understanding users.  We can leverage ideas from Light and Wakeman to understand how users perceive certain aspects of the system interface in regards to awareness.  We can also leverage the differential psychology theories mentioned in Dillon and Watson to understand our users' cognitive abilities.   In understanding users' tasks, task analysis and requirements elicitation methods can be utilized.  Furthermore, a lot of work has been done on the application of cognitive task analysis to draw out tacit knowledge that users may hold about their business processes.

Beyond the Interface
In “Beyond the Interface” from the Human-Computer Interaction Handbook, Light and Wakeman present results of a study to measure user behavior and thought processes during website interaction.  The authors’ intent is to describe how the process of interacting with websites brings about two levels of awareness in the user: (1) awareness of the interface, and (2) awareness of the social context beyond the interface.  The study is grounded in HCI theories that place focus on using the Web as a medium for communication, rather than using it as a tool for problem solving.  Perhaps one of the most important theories suggests user interactions follow similar rules to the “turn taking of spoken engagement”.  When these rules are violated, users have a hard time understanding the behavior of the software.   Another theory leveraged in the study deals with the idea of “ritual constraints”.  “Ritual constraints” are social rules inherent in the nature of human interaction.  Here, the user is cognizant of the implication of his or her acts, specifically, how the acts are interpreted by others in the social setting.

The study revealed the main point regarding user awareness.   Users are aware of the two levels of interaction, one with the interface, and one with the recipients behind the interface.  The second awareness seemed to present itself when users were actually entering data/interacting with the website, as apposed to simply navigating the website.  The corollary is the importance for developers to adopt a communication metaphor when creating interactive components on a website.  The study revealed another interesting point regarding the user’s perception of the recipients of inputted data.  Recipient identity is constructed from a combination of the user’s expectations of a commercial brand, the user’s experience with interactive portions of the site, and the user’s purpose in visiting the site.

The paper concludes with recommendations on how to apply the findings of the study.   The findings suggest that interactive websites would benefit from: proper identification of the recipient of the user’s data (especially if the data is personal in nature), confirmation pages after the entry of data, statements about how the recipients will use the submitted data, and an explanation of why the recipient is collecting data that does not appear to assist in the completion of the user’s task.

User Analysis in HCI
In their paper from the Human-Computer Interaction Handbook, Dillon and Watson assert that user analysis in HCI can benefit from the application of differential psychology research.   User analysis is normally relegated to understanding users in general terms such as educational background and technical expertise.  (Nielsen's three dimensional analysis of users is cited.)  The authors argue that such general user analysis is highly context sensitive and it does not offer solutions that can satisfy unique users/user groups.  The aim of differential psychology is to understand user behavior and specific aptitudes of users such as memory, perceptual speed and, deductive reasoning.

Dillon and Watson go on to describe studies of how work done in differential and experimental psychology was leveraged directly in the design of user interfaces.  One study focused on logical reasoning, the other on visual ability.  They concluded that appropriate design of the interfaces/training material can reduce discrepancies in cognitive abilities amongst users.

Application
I think it's apparent how we can apply the ideas presented in both papers mentioned above. They demonstrate not only how users think, but what users think when engaged in discourse with interactive web applications.  Also demonstrated is how this knowledge can be applied directly to user interface design.  I think the idea of the “conversation” with the system is a huge factor when measuring how closely the user's mental model matches up to the conceptual design model.  I believe its the best way we can describe software systems.  After all, “conversations” define software use cases, and software use cases define a system.

Values Engendered by Revision Control

Introduction
This paper presents a Value-Sensitive-Design (VSD) conceptual investigation of revision control. It focuses on revision control as it is employed when constructing software applications. Firstly, the sociotechnical problem space is explicated by 1) defining revision control and 2) explaining how organizations can implement revision control through the use of specialized tools. Next, implicated values are identified and defined in terms of interactions with version control tools. Finally, stakeholders are identified and the effect of implicated values on stakeholders is analyzed

Sociotechnical Problem Space
Revision control (also known as version control) is used to manage changes in documents, source code, or any other type of file stored on a computer. Revision control is typically used in software engineering when many developers are making contributions/changes to source code files. As changes to a source code file are committed, a new version of the file is created. Versions of a file are identified either by date or by a sequence number (i.e. – “version 1”, version 2”, etc.). Each version of the file is stored for accountability and stored revisions can be restored, compared, and merged.

The fundamental issue that version control sidesteps is the race condition of multiple developers reading and writing to the same files. For instance, Developer A and Developer B download a copy of a source code file from a server to their local PC. Both developers begin editing their copies of the file. Developer A completes his/her edits and publishes his/her copy of the file to the server. Developer B then completes his/her edits and publishes his/her copy of the file, thereby overwriting Developer A’s file and ultimately erasing all of Developer A’s work.

There are two paradigms that can be used to solve the race condition issue: file locking and copy-modify-merge (Collins-Sussman).

File locking is a simple concept that permits only one developer to modify a file at any given time. To work on a file, Developer A must “check out” the file from the repository and store a copy of the file to his/her local PC. While the file is checked out, Developer B (or any developer for that matter) cannot make edits to the file. Developer B may begin to make edits only after Developer A has “checked in” the file back into the file repository. File locking works but has its drawbacks. File locking can cause administrative problems. For example: a developer may forget to check in a file effectively locking the file out and preventing any other developer from doing work. File locking also causes unnecessary serialization. For example: two developers may want to make edits to different parts of a file that don’t overlap. No problems would arise if both developers could modify the file, and then merge the changes together. File-locking prevents concurrent updates by multiple developers so work has to be done in-turn.

In the copy-modify-merge paradigm, each developer makes a local “mirror copy” of the entire project repository. Developers can work simultaneously and independently from one another on their local copies. Once updates are complete, the developers can push their local copies to the project repository where all changes are merged together into a final version. For example: Developer A and Developer B make changes to the same file within their own copies of the project repository. Developer A saves his/her changes to the global repository first. When Developer B attempts to save his/her changes, the developer is informed that their copy is out of date (i.e. – other changes were committed while he/she was working on the file). Developer B can then request that Developer A’s changes be merged into his/her copy. Once the changes are merged, and if there are no conflicts (i.e. – no changes overlap), Developer B’s copy is then saved into the repository. If there are conflicts, Developer B must resolve them before saving the final copy to the project repository.

A development organization may implement revision control through the use of specialized tools dedicated to source code management. There are several open-source and commercial tools available, each with their advantages and drawbacks. Subversion, an open-source software package, is a well-known and widely used tool (Tigris). Subversion (“SVN”) uses a client-server model. Source code files are stored on the SVN server (aka “repository”) and can be accessed by any PC’s running the SVN client. This allows many developers to work on source code files from different locations/PC’s. Some key features of SVN are: utilization of copy-modify-merge (and file-locking if needed), full directory versioning, atomic commits to the repository, and versioned metadata for each file/directory.

Values Defined
The use of a good revision control methodology engenders several values within a development organization. This section identifies and defines some of these values.

By leveraging revision control, an organization fosters collaboration between its developers. Gray defines collaboration as “a process of joint decision making among key stakeholders of a problem domain about the future of that domain” (Gray, p.11). Source control permits developers to work in teams where each individual can contribute to the overall goal of delivering a quality software product. Each individual makes decisions on which piece of code will work best to reach that goal. The future of the domain, or software release, is defined by the collaborative effort of developers within the workspace.

Revision control usage also engenders accountability. In their book, Friedman et al write: “accountability refers to the properties that ensure the actions of a person, people, or institution may be traced uniquely to the person, people, or institution” (Friedman). Upon change commit (i.e. - submitting a change to the repository), revision control tools record the responsible developer and place a timestamp on the new version of the file. Moreover, the developer can enter comments to describe changes that he/she has made. For these reasons, revision control tools provide a good mechanism for accountability as a complete audit trail of change is recorded.

Another value brought about by revision control is work efficiency. This is especially true when the copy-modify-merge paradigm is utilized. The major advantage of this paradigm is that it allows developers to work individually and concurrently, thereby maximizing available development time. Compare this to the file-lock paradigm where developers can be locked out a file at any given time. Additionally, copy-modify-merge minimizes the coordination effort and expense between developers.

Along with the values stated above, revision control also: enhances communication between developers, prevents loss of work through backups, enables better coordination of efforts, manages code merges, and provides code stability by allowing organizations to rollback to previous versions of the code (O'Sullivan).

Stakeholders
The most apparent direct stakeholders are the software developers. Revision control benefits developers by providing them with a more stable work environment. Without revision control, it is very easy to experience loss of work. Race conditions can occur if multiple developers are sharing the same copy of files. The danger of overwriting updates is real, and it increases exponentially as the project size and organization size increase. Moreover, a complete loss of data can be avoided as copies of code files are constantly being generated and backed-up.

Another benefit for developers is comprehensibility of the system code lifecycle. Developers can review the ancestry of files and by reading other developer’s comments they can elicit the reasoning behind code changes. This information helps ensure that they stay the course of the current branch of development.

In a hierarchical organization, the indirect stakeholders are members of management (ex. - IT Team Leaders). IT Team Leaders are rated on how well their teams meet project timeline and budgetary expectations. Development teams have a better chance at hitting targets with a revision control strategy, as pitfalls that cause delays and unexpected costs can be avoided. Consequently, benefits of meeting targets get cascaded up to higher levels of management within the organization.

End users of the constructed software product are also indirect stakeholders. All of the benefits garnered from revision control are ultimately parlayed into building a more usable and functionally accurate software product that is intended for end user consumption.


References
Collins-Sussman, Ben. "Version Control with Subversion". Tigris.org. 10/20/2009 http://svnbook.red-bean.com/en/1.4/index.html.

Friedman, B., Kahn, P. H., Jr., & Borning, A. (2006). Value Sensitive Design and information systems. In P. Zhang & D. Galletta (eds.), Human-Computer Interaction in Management Information Systems: Foundations, (pp. 348-372). Armonk, New York: M.E. Sharpe.

Gray, Barbara. Collaborating: Finding Common Ground for Multiparty Problems. San Francisco: Jossey-Bass, 1989.

O'Sullivan, Bryan. "Making Sense of Revision-control Systems". ACM. 10/20/2009 http://queue.acm.org/detail.cfm?id=1595636.

Tigris. "Subversion Home Page". Tigris.org. 10/19/2009 http://subversion.tigris.org/.

Terry Winograd's Shift from AI to HCI

Introduction
In a more recent paper [1], Terry Winograd discusses the gulf between Artificial Intelligence and Human-Computer Interaction. He mentions that AI is primarily concerned with replicating the human / human mind whereas HCI is primarily concerned with augmenting human capabilities. One question is wether or not we should use AI as a metaphor when constructing human interfaces to computers. Using the AI metaphor, the goal is for the user to attribute human characteristics to the interface, and communicate with it just as if it were a human. There is also a divide in how researches attempt to understand people. The first approach, what Winograd refers to as, the “rationalistic” approach, attempts to model humans as cognitive machines within the workings of the computer. In contrast, the second approach, the “design” approach, focuses on modeling the interactions between a person and the enveloping environment.

During his career, Winograd shifted interests and crossed the gulf between AI and HCI. In his paper, he mentions that he started his career in the AI field, then rejected the AI approach, and subsequently ended up moving to the field of HCI. He writes “I have seen this as a battle between two competing philosophies of what is most effective to do with computers”. This paper looks at some of the work Winograd has done, and illustrates his shift between the two areas.

Winograd's Ph.D. Thesis and SHRDLU
In his Ph.D. thesis entitled “Procedures as a Representation for Data in a Computer Program for Understanding Natural Language” [2], Winograd describes a software system called SHRDLU that is capable of carrying on a English conversation with its user. The system contains a simulation of a robotic arm that can rearrange colored blocks within its environment. The user enters into discourse with the system and can instruct the arm to pick up, drop, and move objects. A “heuristic understander” is used by the software to infer what each command sentence means. Linguistic information about the sentence, information from other parts of the discourse, and general information are used to interpret the commands. Furthermore, the software asks for clarification from the user if it cannot understand what the inputted sentence means.

The thesis examines the issue of talking with computers. Winograd underscores the idea that it is hard for computers and human to communicate since computers communicate in their own terms; The means of communication is not natural for the human user. More importantly, computers aren't able to use reasoning in an attempt to understand ambiguity in natural language. Computers are typically only supplied with syntactical rules and do not use semantic knowledge to understand meaning. To solve this problem, Winograd suggests giving computers the ability to use more knowledge. Computers need to have knowledge of the subject they are discussing and they must be able to assemble facts in such a way so that they can understand a sentence and respond to it. In SHRDLU knowledge is represented in a structured manner and uses a language that facilitates teaching the system about new subject domains.

SHRDLU is a rationalistic attempt to model how the human mind works. It seeks to replicate human understanding of natural language. Although this work is grounded in AI, there a clear implications for work in HCI. Interfaces that communicate naturally with their users are very familiar and have little to no learning curve. Donald Norman provides several examples of natural interfaces in his book “The Design of Future Things” [3]. One example that stands out is a tea kettle whistle. The tea kettle whistle offers natural communication that water is boiling. The user does not need to translate the sound of a tea kettle whistle from system terms into something he/she understands; it already naturally offers the affordance that the water is ready.

Thinking machines: Can there be? Are We?
In “Thinking Machines” [4], Winograd aligns his prospects for artificial intelligence with those of AI critics. The critics argue that a thinking machine is a contradiction in terms. “Computers with their cold logic, can never be creative or insightful or possess real judgement”. He asserts that the philosophy that has guided artificial intelligence research lacks depth and is a “patchwork” of rationalism and logical empiricism. The technology used in conducting artificial intelligence research is not to blame, it is the under-netting and basic tenets that require scrutiny.

Winograd supports his argument by identifying some fundamental problems inherent in AI. He discusses gaps of anticipation where in a any realistically sized domain, it is near impossible to think of all situations, and combinations of events from those situations. The hope is that the body of knowledge built into the cognitive agent will be broad enough to contain the relevant general knowledge needed for success. In most cases, the body of knowledge contributed by the human element is required; since it cannot be modeled exhaustively within the system. He also writes on the blindness of representation. This is in regards to language and interpretation of language. As expounded upon in his Ph.D. thesis, natural language processing goes far beyond grammatical and syntactic rules. The ambiguity of natural language requires a deep understanding of the subject matter as well as the context. When we de-contextualize symbols (representations) they become ambiguous and can be interpreted in varying ways. Finally, he discusses the idea of domain restriction. Since there is a chance of ambiguity in representations, AI programs must be relegated to very restricted domains. Most domains, or at least the domains the AI hopes to model, are not restricted (e.g. - medicine, engineering, law). The corollary is that AI systems can give expected results only in simplified domains.

Thinking Machines offers some interesting and compelling arguments against the “rationalist approach”. It supports the idea that augmenting human capabilities is far more feasible than attempting to model human intelligence. This is inline with the “design approach” (i.e. - placing focus on modeling interactions between the person and his/her surrounding environment.)

Stanford Human-Computer Interaction Group
Winograd currently heads up Stanford's Human-Computer Interaction Group [5]. They are working on some interesting projects grounded in design. One such project, d.tools is a hardware and software toolkit that allows designers to rapidly prototype physical interaction design. Designers can use the physical components (controllers, output devices) and the accompanying software (called the d.tools editor) to form prototypes and study their behavior. Another project, named Blueprint, integrates program examples into the development environment. Program examples are brought into the IDE through an built-in web search. The main idea behind Blueprint is that it helps to facilitate the prototyping and ideation process by allowing programmers to quickly build and compare competing designs. (more information on these projects can be found on their website (link is below))


References
[1] Terry Winograd, Shifting viewpoints: Artificial intelligence and human–computer interaction, Artificial Intelligence 170 (2006) 1256–1258.
http://hci.stanford.edu/winograd/papers/ai-hci.pdf

[2] Winograd, Terry (1971), "Procedures as a Representation for Data in a Computer Program for Understanding Natural Language," MAC-TR-84, MIT Project MAC, 1971.
http://hci.stanford.edu/~winograd/shrdlu/

[3] Norman, Donald (2001), The Design of Future Things, New York: Basic Books, 2007.

[4] Winograd, Terry (1991), "Thinking machines: Can there be? Are We?," in James Sheehan and Morton Sosna, eds., The Boundaries of Humanity: Humans, Animals, Machines, Berkeley: University of California Press, 1991 pp. 198-223. Reprinted in D. Partridge and Y. Wilks, The Foundations of Artificial Intelligence, Cambridge: Cambridge Univ. Press, 1990, pp. 167-189.
http://hci.stanford.edu/winograd/papers/thinking-machines.html

[5] The Stanford Human-Computer Interaction Group
http://hci.stanford.edu/