Inventing and Evolving Human-Computer Interfaces:
Five Spheres of Invention

Davis Foulger
Visiting Associate Professor
Oswego State University

April 15, 2002

The Study of Human-Computer Interaction:

(A small sampling of topics from the upcoming ACM SIGCHI meeting:)






  • Scenario-based usability Engineering
  • user-centered design
  • Interactive Design and Protyping


  • User Interfaces
  • Natural Language
  • Making Speech Browsable, Readable, and Searchable

The Web

  • Rapid and Automatic Site Evaluation
  • Navigation
  • Usability Guidelines


  • E-Business
  • Customer-Centered Systems
  • Availability and Interruption

Task Analysis

  • User Experiences
  • User Needs
  • Driving Invention from Field Data

UI Agents

  • adaptive interfaces
  • Socially Adept Technologies
  • Sensing systems


  • Collaboration
  • Collaborative Physical Tasks

Virtual Environments

  • Roomware
  • Presence
  • 3D

Usability Testing

  • Rapid Evaluation
  • Adaptive Testing
  • User-Based Evaluations


  • Gesture and Mobile Devices
  • Virtual Keyboarding
  • Gaze Interface Agenta


  • Foraging information
  • Visualizing Patterns
  • Visualizing Time Series


  • Identities and Understandings
  • Reputation systems


A study of computer conferencing:

I Observed a Process of Continuous Change:

Along the way, I found a problem with "problems"

And there seemed to be a pattern to the change:

  • Simons' The Sciences of the Artificial is a classic in artificial intelligence
  • But it is actually a pretty broadly based book. Other topics include:
    • economics, social behavior, simulation, cognition, memory, and complexity
  • For me, it is mostly about the design of "artifacts"
    • The interaction of artifact, interface, and environment (see upper model)
      • The artifact is its interface
    • The interaction of "mediators" (my term) and its attributes (see lower model)
      • Systems are designed to meet abstract goals
  • Simon is not entirely consistent here:
    • The constituents of an artifact can be in the inner system or the outer environment
  • But it gave me a start on explaining what I was seeing
  • Others seem to have found similar value: Henry Petroski, for instance

Simon's Notion of Artifact expressed graphically

The relationship of the system components of an artifact
to the attributes of an artifact. "Characteristics" and
"Mediators" overlay my vocabulary on his conception.

I extend Simon with invention processes in the outer environment

  • Five interacting spheres of invention and evolution:
    • Mediators, the stuff the system is made of and the way its put together
    • Characteristics, the essential qualities of the system
    • Uses, the things we do with the system
    • Effects, the things that happen as a result of use
    • Practices: the rules and practices we create to make the system more functional
  • Two+ cycles of change
    • of media (or artifact)
    • of genre (or application)
  • Used to describe media, but appears to be more general

Media are only one form of communication-enabling artifact:

A real world example (IBM Research; 1984):


the IBM XT ships with a 10 Megabyte hard disk and a subdirectory capable DOS


the root directory is limited to 254 files or directories


new users load up the operating system, a text editor, and start writing documents


because they didn't read the documentation and were used to VM, they saved all their files to the root directory


when they try to save the 255th file, it won't save


they call up their local PC Consultant


several hours are spent diagnosing the problem and moving files, one at a time, into a subdirectory structure


the user is instructed to save their files to subdirectories and shown how


other users have the same problem


a text editor is used to create a batch file that moves the files around


several hours are saved, but other users have the same problem


a batch file is written that automatically moves the files around


more time is saved, but users aren't happy with were the files are put


a direct file manipulation program is created (File Manager)


users can easily reorganize their own systems


they do, but notice that the file manager makes a good user interface


they start using it as a user interface


some things are hard to do


requests are made for new features


the file manager is given end user configurability features


a new game emerges as a biproduct: Hard disk roulette


the game is documented as a "dangerous" feature


the application features that enable the game are disabled


end users start using and sharing customizations

The Cycle of Genre

the file manager grows other uses, including "Backup"

The Cycle of Media

the file manager grows into, well,
  • "File Manager" (OS/2 and Windows)
  • "DOS Shell"
  • a pre-X-Windows UNIX shell
The original code is still being improved 18 years later (by its seventh "owner").


a default directory structure is built into a new user "workbench"
  • along with a configurable menu-based user interface system
  • a set of applications
  • and built in (hypermedia) documentation

The Cycles of Media and Genre

  • The workbench and all the tools in it grow too, but that's several more stories, and the file management story is pretty sketchy

Mediators are the "clockworks" of an medium

Characteristics are the essential qualities of a medium

  • Useful Groupings:
    • modalities
    • message
    • performance
    • production
    • participants
    • creator
    • consumer
    • channel
    • storage
    • interface
    • marketplace
  • Dimensions (see figure at right):
    • Amplification (vertical)
    • Dynamism (from left)
    • Bandwidth (from right)
  • Focus of Book


  • The things we do with a medium or artifact
  • Invention of a system with characteristics simply creates a possibility
    • a proto-medium
    • a proto-application
  • Use is itself an invention
    • it makes an artifact real
    • it makes it successful
  • A medium is the sum of its uses:
  • We recognize this in programming with use cases
  • We recognize this in marketing with:
    • application consulting teams
    • application packs

  • Use cases are a substantial improvement on simple requirements-based design
    • but this is often as far as we go designing and prototyping systems



The Disconnect in Development

  • Applications, Artifacts, and Media are developed in five spheres of invention
  • We generally develop in two of them:
    • Mediators
    • Characteristics
  • With use cases, we consider a third:
    • Uses
      • but the wrong uses
      • and the wrong users
  • And we generally don't consider effects or practices:
    • limited beta testing
    • limited or no research after first ship
    • limited or no end user configurability
  • Design patterns and anti-patterns are a step in the right direction
    • but every system is different
    • only observation of use will inform effects and practices.