Tuesday, April 23, 2013

The affordances of glass walls

James Gibson defined the term affordance in his 1979 book, The Ecological Approach to Visual Perception:
The affordances of the environment are what it offers the animal, what it provides or furnishes, either for good or ill. The verb to afford is found in the dictionary, but the noun affordance is not. I have made it up. I mean by it something that refers to both the environment and the animal in a way that no existing term does. It implies the complementarity of the animal and the environment.
Chairs, for example, afford sitting. Not just any chair, though, and not just any person, as you'll realize if you ever try to cram yourself into a desk built for a second grader. A chair affords sitting if its seat is the right height from the ground (about the same as the distance from your heels to the backs of your knees), if it's wide enough for your posterior,  if it's strong enough to hold your weight, and so forth.

We can look downward in size, to ask whether a coffee cup affords being held in one hand. (Some large cups have very small handles and when filled are too heavy to hold with just a thumb and forefinger.) We can think bigger, to ask whether a given architectural design affords the kinds of interactions between people that we might like to see. (Cabrini Green is one famous failure.)

And, as Don Norman points out in The Psychology of Everyday Things, it's critical that we're able to identify what can be done with objects and environments, to recognize their "perceived affordances." Which brings me to this:



That's not artistic purple shading around my eyes. Here's how it happened. I was heading to a meeting at the new Hunt Library on Centennial Campus, to give a presentation for our industrial advisory council. I saw one of my students in the lobby, just outside the main area of the library.


We talked for a minute or so about a new project, and then I turned to go to my meeting...


...and walked into the glass wall that flanks the turnstiles. This raised an enormous knot on my forehead, noticeable enough that the staff called a team of paramedics to look me over. (I checked out fine.) A few days later I look as if I've lost a fist fight.

And of course, being introspective, I think about the affordances of glass walls. They're great--you can see more of what's around you than with ordinary walls. You have a sense of openness, connected at a distance even with the outside. But for a specific person in a specific state of mind, it may not be immediately perceived that glass walls do not afford passage.

Friday, February 8, 2013

A four-minute introduction to computing

This is a draft script for a very short talk about computing concepts for a non-technical audience. It doesn't go deep, but I try to bring across some important ideas...

When I was a kid, I had a Play-Doh machine. You drop in a lump of colored clay, insert a little plastic stencil, and then push down on the plunger. You get a long tube with the cross section of a triangle or a star. Was it fun? Well, I still remember it today...

When I explain what computer science is about, I sometimes start with a machine like this. Except that computers mold information into different shapes. They're information processing machines. There's more to it, of course. Information is different from physical raw materials. Think of information as a stream of numbers that you could write down. We might be talking about data from a scientific experiment or quarterly business reports, or a DVD video--it's all information. That's what's going into the machine, as input, and a new stream of information is the output.

But here's something cool. Inside every computer is a controller. That controller treats some streams of information differently from other kinds of data: it interprets each number as an instruction to follow. A stream of numbers can be a stream of instructions--a program.

So unlike my Play-Doh machine, a computer can handle two different kinds of input. One is information to work on, the other is instructions for what to do with the information. And some of those instructions involve making decisions about what it should do next. This is why we talk about a computer as being a different kind of machine than we usually think of--a Play-Doh machine, a loom for weaving, and so forth--because it can make some decisions for itself, on our behalf. That's more than a stencil or a template for repeating actions; it's real automation.

And there's something else. Programs are information, right? And programs take information as input... This means that we can feed one program to another program. Now things get really interesting.

Think of the instructions that a computer can carry out as its language. To get the computer to do something useful, you need to speak its language. But machine language is incredibly tedious, and it takes forever to write down instructions in just the right way to make just the right things happen.

And what if I'm a video artist or a baseball statistician? I have information that I'd like to be processed--maybe color corrections or on-base plus slugging numbers--but of course the machine's language doesn't include anything close to these abstract concepts. But here's the thing--information is malleable, and we know a lot about translating it from one language into another. My information comes in abstract chunks of information that I can talk about in my specialized language of video artistry or baseball statistics. With a lot of work, I may be able to translate my own information abstractions into terms that a computer can handle. And I don't have to do this entirely by hand--once I figure it all out, I can write a program to do the translation for me.

So when I'm using my computer, I don't have to work at the level of the machine; I can express myself in the concepts I'm familiar with, and the computer will translate those concepts into its own language and do whatever work I tell it to do.

This is the practical side of computing, what programming is basically all about--building computational abstractions that help people solve problems. And on the theoretical side, you might be thinking, "So we can transform a computer to behave as if it's a completely different machine..." Yes. Computers are universal machines. I don't mean that a computer can do everything. What I mean is that when we think about what "ordinary" machines do, we tend to say that you have to pick the right tool for the job. You don't use a chain saw to drive screws, or a kitchen blender to paint your walls. If the job is processing information, though, we choose a computer. We might think about how fast it runs and how much information it can store (it's something like saying, "I need a bigger hammer"), but the practical details are less important than the idea that we don't need different kinds of machines for different information processing tasks. Every computer is theoretically equivalent to every other computer for solving problems--we can transform one into another. It's just a matter of which abstractions we build on top of it.

Computing is as general and as powerful as you can imagine.

Saturday, February 2, 2013

Usability problem of the day (Unix ln documentation)

In the courses I teach about human-computer interaction, I typically open each class with an example of a usability problem. I'm putting these online, in case others find them useful.

I've been using Unix off and on since the early 1980s. Although I still occasionally write shell scripts, I'm not anything like an expert.

Unix is still my go-to source, though, when I talk about command line interfaces in my HCI classes. The Unix command line is a canonical example of the interaction style: short, powerful commands with a flexible grammar for constructing and combining results. It's also different in abstract ways from more familiar graphical user interfaces, enough to make it worth discussing. For example, on the command line you enter a command and then an optional sequence of flags and file names; in a GUI you typically first choose objects, such as file icons, and then choose a command, such as a menu item, to execute on the objects. The different grammars are appropriate for the different metaphors.

Friday, January 25, 2013

An unexpurgated interview

In the pulp science fiction novels I read as a kid, the authors tended to work within the social norms of the day with respect to language. Here's an example from E. E. "Doc" Smith's First Lensman:
Jack started to express an unexpurgated opinion, but shut himself up. Young cubs did not swear in front of the First Lensman.
And another:
Do you think you can get away with this?" she demanded. "Why, you..." and the unexpurgated, trenchant, brilliantly detailed characterization could have seared its way through four-ply asbestos.
I liked "unexpurgated", once I looked up what it meant. Hence the title of this post. I recently exchanged email with Nikki Stoudt, a writer for the NCSU student newspaper, for an article. Here's what was said... unexpurgated. (Not that the text needs it.)

Usability problem of tomorrow (Star Trek user interfaces)

In the courses I teach about human-computer interaction, I typically open each class with an example of a usability problem. I'm putting these online, in case others find them useful.

I sometimes take examples of interaction design from the entertainment industry, whether the systems involved are real or not. Star Trek: The Next Generation is a good standby.



Tuesday, January 22, 2013

Making computers seem a little less scary

The NCSU Technician has featured me in an article:

Making computers seem a little less scary
by Nikki Stoudt, Life & Style Editor
Though the computer science and English departments may not be known for their collaborative efforts, one professor has been working to break down the barrier between the “hard sciences” and the humanities.
More...

Me on youtube

For the Fabulous Faculty Series at the NCSU Hunt Library.


Thursday, January 17, 2013

On the WSJ and the D.C. gun ban

Jeffrey Scott Shapiro, in a recent Wall Street Journal opinion piece, writes about the D.C. gun ban:
The D.C. gun ban, enacted in 1976... had an unintended effect: It emboldened criminals because they knew that law-abiding District residents were unarmed and powerless to defend themselves. Violent crime increased after the law was enacted, with homicides rising to 369 in 1988, from 188 in 1976 when the ban started. By 1993, annual homicides had reached 454.
Later in the article, he writes,
Since the gun ban was struck down, murders in the District have steadily gone down, from 186 in 2008 to 88 in 2012, the lowest number since the law was enacted in 1976. The decline resulted from a variety of factors, but losing the gun ban certainly did not produce the rise in murders that many might have expected.
In written form, numbers and relationships like "369 in 1988", "188 in 1976", "186 in 2008", and "88 in 2002" are not always easy to make sense of. Here's what these specific numbers look like graphically. 


Wednesday, January 16, 2013

Usability problem of the day (not a Kindle killer)

In the courses I teach about human-computer interaction, I typically open each class with an example of a usability problem. I'm putting these online, in case others find them useful.

A couple of years ago I decided to test my students' abilities to analyze a novel design, an artificial one in which I'd deliberately inserted a number of design flaws. I'd just bought a Kindle for my wife. We were talking about its usability and thinking about ways in which it could be much, much worse. (This was an early Kindle with a miniature keyboard; while it's fine for reading, some of the navigation facilities are poorly thought out.)

Here's the set-up: Imagine that you've been hired as a usability consultant by a company interested in ebook readers. You're shown the diagram below, a prototype for a new design. The physical device would be about 7 inches wide; all the keys are hardware keys; it doesn't have a touch screen; it's meant to be held in the hand or hands in use. Your job is to identify potential problems.


Wednesday, January 9, 2013

Usability problem of the day (first impressions)


In the courses I teach about human-computer interaction, I typically open each class with an example of a usability problem. I'm putting these online, in case others find them useful.

First impressions can be important in user interfaces. We tend to judge the quality of a manufactured object, whether a physical device or a software artifact, by the fit and finish of its exterior. When I come across a Web site that looks if it it were cobbled together by a novice, I wonder about the resources that were available to build the functionality under the hood.