David Heller questions whether there can be affordance and convention in this digital world (via LukeW).

Dave talks about how we as children learn to mimick the behaviors of the people around us. We need only to look at a phone to know how to use it. Children see others talking on the phone, they hear voices through the phone, they have toy phones and most (at least in the so-called developed world) know how to converse on a phone by the time they are three years old. It is only intuitive after demonstration. It is learned socially, through what Dave calls “passive exhibition.”

It reminds me of Vygotsky’s theories of social learning. In his book, “Mind in Society” he notes that “human learning presupposes a specific social nature and a process by which children grow into the intellectual life around them.”

The example of the phone is interesting, since it is learned by both “passive exhibition” and by explicit instruction. Initiating a phone call requires quite a bit of teaching and some advanced intellectual concepts (a series of numbers associated with a person and a place, a series of steps to make the connection). In addition, the effects of the phone conversation are not intuitive or easily observed. I remember my son at three years old talking on the phone and showing off his new toys without realizing that the person on the other end couldn’t actually see him. When everyone else who talks to you can also see you, why should the person on the phone be any different?

David Heller argues that in designing computer software, we cannot take advantage of this social learning. “The computer, the PC more specifically, does not have an analog to that experience. The PC is primarily used as user in front of screen an keyboard. It is an isolating device that you seldom every see others passively exhibit.”

While its true that the occasions to learn how to use software through social observation are limited, I have noticed that people learn this way anyhow. How many times have you worked on a project with someone and picked up tips on using software from them? Only the geekiest amongst us learn from the docs, the rest learn from lore that is passed from colleague to colleague, whether verbally in the office or via the communal written work of blogs and forum postings. I believe that we as humans tend to seek a social learning situation even when the medium isolates us. This is why many writers have writing groups — not where they write together, but where they learn about writing through reading and talking.

“As IT systems finally make their way into the non-info service sector such as health care practices, blue collar e-learning, etc.we are starting to really see that our notions of ?conventions? even the most basic are just totally bogus. People can?t even use a mouse, let alone know that a blue under lined piece of text means something that will show me something else.”

Here are a few basic conventions of GUI:
* objects that are clickable provide feedback when you roll the mouse over them
* if you see a blinking vertical bar you can type text there
* blank bordered rectangles, often with labels, will show that blinking vertical bar if you click on them or tab to them

None of these conventions have anything to do with the real world, and I would guess that the vast majority of people who use computers learned these conventions from another human being. While its true that these conventions are not intuitive, they are none-the-less real conventions that persist across almost all software today.

Most people learn those basic lessons in their first experience using a computer and all the rest of our sophisticated user interface elements are built on that shared knowlege. As people move between applications, user interface elements that are shared between them are established as conventions. Objects such as scrollbars, radio buttons, and menus become familiar, if not intuitive.

While I would argue that current software UI conventions are valid, I completely agree with Dave that what we’ve got now is insufficient to make software and web sites approachable for the general population. I also agree that we can do better, that it is possible to create new UIs that feel familar and make sense to folks who are not members of the digital elite.


Oliver’s lovely illustrations make these abstract mathematical concepts concrete and simple.


Colin R. MacDonald has written a good essay about the challenges of giving a task to a junior engineer. As a manager or project lead, I’ve run into pretty much every situation he describes. When it happens on a software project, it can be very frustrating. As Colin describes it with a picture hanging project, it’s quite amusing:

“Why can’t we get a nail gun?”
“We don’t have the budget for it.”
“So we can’t afford to do things right?”
“There’s nothing wrong with driving nails with a hammer.”
“But aren’t we trying to do things better and faster? Are we going to keep using hammers just because we’ve always used them? It’ll pay off in the long run.”
“We don’t spend enough time driving nails around here to justify buying a nail gun. We just don’t.”

Every day I need to make decisions about how much time to spend talking about or writing down the details of a task. You don’t want someone to feel micro-managed, but you don’t want to leave them clueless. Sometimes there’s a surprisingly small difference between the two.

At the moment, I’m leading a team and also writing code for the project, so there’s additional balance between how much time I spend giving direction and how much time I spend on my own work. Its more of an art, than it is a science. I know the project will benefit if I write up checkin guidelines and best practices and write down all that info about the project that is floating around my head, but the project will also benefit from the code I would write in the same amount of time. The larger the team is the more benefit there is for written documents. I find that our culture of frequent code reviews provides a good time for reflection on whether I’ve got the balance right. Live feedback can be fun and low overhead, but if I find myself saying the same things over and over, its time to write them down. Also, no one wants to hear in a code review something that they needed to hear before they started to type.

ok, ok, I’ll go write that best practices document…