What is an affordance?

One of the most frequently appearing terms in the Human-Computer Interaction literature is the notion of Affordances.

While exact definitions occasionally vary, we adopt a strict view that an affordance is a design element that can be perceived as suggesting its actual function.

Some times really bad design leads to a faux affordance, which is a design element that falsely suggests its function.

For example a round door knob that does not rotate and needs to be slid up vertically to release its catch, or a squared off bracket shaped handle that does have to be rotated.

In the computer realm, this could take the form a button shaped graphic that is purely decorative or an "elevator box" in a scroll bar whose operation violates the User Interface Standards of the platform on which it is deployed, having perhaps to be slid upward to scroll downward.

Controllers with no visible on screen representation are not affordances since they offer no way for an End User to know how they are activated or what they will do. So if clicking in a 50 pixel square region at the top left corner of the screen brings up a screen saver, it is a screen saver for where there is no affordance.

A long time ago, before our current era of ever more realistic 3-D Avatars roaming large Virtual Worlds with their nearly photo-realistic faux-natural scenery, there was TEXT.

End Users would log into systems called MUDs and MOOs that offered text-based virtual worlds. Rather than providing a real time animated visualizations of cloudscapes and rolling surf, the system would periodically send out messages like "A large seagull swoops gracefully into view before diving down to snatch a fried clam off of a dinner sitting near you.".

These effects would be produced by writing small programs that ran in-world and one of the most elaborately architected communities of this era was a system called Media Moo. It was a textual simulation of the MIT Media Lab championed by a brilliant and energetic grad student named Amy Bruckman, who is now a faculty member at Georgia Tech.

Sadly as more visual alternatives its participants realized that any programs and content they developed for the MOO platform would essentially be locked into that environment. So while the MOO environment offered many exciting possibilities, the inability to readily port content (both text and source code) from the MOO Platform to future systems insured that new development quickly ended.

This lead Mr. Wasilko to make the central observation that for an online community depending on End User generated content to remain viable in the long term, that content must be loosely coupled to the community's implementation platform so it can, in practice, be readily exported in a form that is useable elsewhere.

We call this The Principle of Severability.

This is orthogonal (i.e. independent) of the question of whether the implementation and data formats involved are open or proprietary provided that suitable export filters or runtime support modules are provided. In other words, all that is required to achieve Severability is the ability to embed fully functional representations of the content in other environments so it can be painlessly moved in world and out.

For example, if standard png, gif, and jpeg files can be dragged in and out of a virtual world, they are severable. If an End User can write a program that runs in world and that same program can also be run as a stand alone program on the Desktop or a Webserver, it is severable. However, a program that has dependencies only supported in world (e.g. it is written in a proprietary language that can't be automatically translated into a general purpose language outside the virtual world or it invokes functions not provided by an independent runtime) it is not severable.

Interestingly, with the right sort of component architecture, the severability property need not be absolute. Posit, a simulation that employs a Blackboard Architecture and merely posts a suggested state change like "daylight begins". In world this could trigger a 3-d animation of a sunrise, but in a stand-alone mode it might just invoke an empty "sunrise" stub function that could be edited to display a textual dialog box reading "The sun rises". This level of loose coupling would be severable in that the core of the simulation would be readily useable elsewhere, but it wouldn't be as severable as if it provided the full sky dome visualization runtime.

In many situations one approach will prove to be more flexible, more elegant, and easier to work with once it has been implemented, such an approach is said to be The Right Thing.

Unfortunately, it often takes a lot of work to do The Right Thing, leading to a countervailing approach known as Worse is Better which is generally easier to pull off in the short term, since its negative effects only build up over time.

R. P. Gabriel, Patterns of software : tales from the software community (New York: Oxford University Press, 1996), pp. xx, 235, R. P. Gabriel, "Worse Is Better," (http://www.dreamsongs.com/WorseIsBetter.html, 2000), R. P. Gabriel, "Worse Is Better Is Worse," (Published under the pseudonym Nickieben Bourbaki, 2000).

Software is compositional by nature, so in even a moderately large system countless ideas are drawn upon. Since Patent Law grants monopolies in such ideas, independent origination of an idea (i.e. not copying anyone else's work) is no guarantee that one's work isn't infringing on one of these monopolies. As the number of issued patents has exploded and the quality of many of these patents has been called into question (i.e. patents have been erroneously issued that prohibit the practice of existing techniques) it becomes impossible for small players without the financial wherewithal to hire lawyers and rack up patents to trade to create a large program without being blocked by at least one or more patent holders.

See C. Shapiro, "Navigating the Patent Thicket: Cross Licenses, Patent Pools, and Standard-Setting," (New York Marriot Marquis: NYSBA Antitrust Law Section Annual Meeting, January 24, 2002 2002).

Early Human-Computer Interaction research largely dismissed Natural Language User Interfaces because they don't provide any affordances to help End Users know what subset of the infinite number of possible sentences a program could understand.

It was correctly observed that presenting a user with a naked command line offered no more guidance that dropping someone into a Text Adventure Game. But unlike a game where the difficult challenge of trying to inductively solve the puzzle of how the interface works is seen as a good thing, when one is trying to accomplish a task with possibly irreversible consequence it is not.

The problem with raw natural language is that of pervasive ambiguity that humans resolve through contextual knowledge. In a command and control context, this can be particularly problematic.

At the opposite end of the spectrum is the conventional Programming Language with an unambiguous grammar, fixed semantics, and a notation optimized for making it easy to write a computer program to parse its syntax.

The problem with conventional programming languages is that they were often designed to minimize their learning curve for skilled programmers who had already internalized the idiosyncrasies of earlier languages. Worse, since there are many new languages based on earlier notations system but with subtly different semantics working in a multi-language environment is fraught with the danger of miss-encoding a program as a syntactically valid program that does something different. This is a function of the lack of redundancy of artificial notations that is not found in Natural Language where referents are often identified by extended phrases that could never be substituted by a one letter typo.

Thus at conferences we often see a researcher put up a slide of some programming language source code and then transliterate it into its unambiguous English equivalent drawing on shared programming language independent concepts that don't depend on any particular terse symbolic notation. So '(car users)' becomes "the first item in the user list".

We call this approach Quasi Natural Language. It is the use of unambiguous stylized natural language constructs to express corresponding programatic concepts that can be directly manipulated or executed.

The learning curve of such a notation can be dramatically reduced through the use of an Inverse Parser to provide visual affordances when constructing new expressions.