August 19th, 2025
One would think, nearly fifty years after the rise of personal computers, and hundreds of thousands of software applications for computers, smartphones, etc, that the concept of interactivity would by now be thoroughly understood. One would be wrong.
I have been lecturing, writing, and preaching about interactivity for nearly forty years now, explaining exactly what interactivity is and, more important, what that definition means in terms of software design. Yet people STILL don’t grasp interactivity. Don’t believe me? Here are some examples of what I mean:
Interactice candy bar
Interactive rug
Interactive shampoo
Or how about some of these illuminating statements in books:
"By definition, the things people do on computers have always been interactive."
— Interactivity by Design, by Ray Kristof & Amy Satran
“Interactivity is a continuing increase in participation. It’s a bidirectional communication conduit. It’s a response to a response. It’s ‘full duplex’. Interaction is a relationship. It’s good sex. It’s bad conversation. It’s indeterminate behavior and it’s redundant result.”
— Pause and Effect: the Art of Interactive Narrative, by Mark S. Meadows
Have you any doubts now about the poor understanding of interactivity?
What Interactivity Isn’t
Let’s begin our examination of interactivity by establishing what interactivity is NOT. First, interactive doesn’t mean digital, and digital things are not necessarily interactive. There are lots of digital things that aren’t interactive (a digital clock) and there are lots of non-digital things that are interactive, such as sex.
Second, interaction isn’t turbocharged reaction. Imagine yourself watching a really great movie, and it’s just SO exciting, so dramatic, so emotionally intense that your heart is racing. The intensity of your reaction does not somehow transform your reaction into interaction. It’s still reaction.
Yet the software industry continues lurching down the same general path it has always been on, failing to grasp the its shortcomings when it comes to interactivity. Yes, I’m frustrated. Perhaps I should have spent more time selling my message; perhaps I should have brought dancing girls and fireworks to my lectures. Whatever; I take full responsibility for presenting my message as clearly as I can; what the world does with it is the world’s responsibility. Read Marcus Aurelius to understand this.
My definition of interactivity
Yes, I have a definition of interactivity. It is based on a conversation, which I consider to be the form of interaction most familiar to people. So let’s consider what happens in a conversation. My analysis of conversation breaks it down into six steps:
Step 1: You listen
Your interlocutor has just said something. The first step is for you to listen to what they said, to take in their meaning.
Step 2: You think
Next, you think about what they said. You consider, cogitate, and deliberate over their statement, and develop a reaction to their statement.
Step 3: You speak
In Step 3, you express your reaction back to your interlocutor. You SPEAK to them.
Step 4: They listen
Now the tables are turned and it is their turn to listen to what you said.
Step 5: They think
It’s their turn to mull over what you have said and figure out what they think about your statement.
Step 6: They speak
In the last step of the cycle, they express their reaction back to you.
These are the six basic steps. They repeat in a cycle. This leads me to the following definition of interactivity:
Interactivity is a cyclic process in which two active agents alternately listen, think, and speak.
You are welcome to argue as much as you wish as to whether this definition is correct; I don’t care. What is important about this definition is that it is useful.
Applying the definition
The value of this definition becomes apparent when we apply it to software design. In this case, the computer is one of the active agents:
The computer carries out the same steps that the human carries out, except that its methods aren’t the same.
Listening: this is what computer people call “input” — mouse movement and clicks, keyboard entry, and so forth.
Thinking: this is accomplished with algorithms.
Speaking: graphics and sound
Although these methods are technological instead of biological, they are functionally the same as what the human does. We converse with our computers.
Quality of conversations
We can apply what we all know about the quality of our human conversations to establish design principles for computer software. Let’s consider each of the three steps that each agent must execute in a conversation.
Listening
A good conversation requires good listening. I’m sure that you’ve had plenty of conversations in which your interlocutor just wasn’t listening well. You were expressing yourself clearly, but the other person just wasn’t hearing what you were saying. Isn’t that intensely frustrating? Aren’t conversations like that a waste of time?
I’m equally sure that you have many times experienced the software version of such conversations:
You: “Computer, do this.”
Computer: “That”
You: “No, do THIS”
Computer: “That”
You: “No, no, no! THIS!”
Computer: “That”
You: “!*!#$*^#@*!!!! THIS!”
Computer: “That”
You: “THIS! THIS! THIS! THIS!”
Computer: “That That That That”
Aren’t computers fun? This situation is one of the inspirations for Crawford’s Second Rule of Software Design:
When in doubt, shoot the programmer.
It’s not easy to design good software listening, which is why so much software listens about as well as your thick-headed uncle at Thanksgiving dinner. That’s because of the fundamental asymmetry in the language of communication between human and computer. When you converse with another person, you do so using human language, which is the same for both sides of the interaction. You both know the same words, (except, of course, when you’re trying to converse with somebody like me, who loves to show off their polysyllabic elocution).
But the language the user must use to speak to the computer is not human language; it’s a language created by the you, the software designer, and the user must learn your little language in order to speak to your software. This leads to an important precept in good software design:
In order to listen well, you must give your user the power to speak well.
This is how your user feels
I’ll provide details on how to design good listening in a later chapter.
Thinking
This is another area of software design in which the software industry has greatly underperformed. Would you bother having a conversation with an ignorant moron, even if that moron was a good listener and an eloquent speaker? If the person has nothing useful or interesting to say, there’s no point in conversing with them.
The computer’s thinking is the delivered product of software. Nobody pays money to learn the particular user interface of your software. Nobody pays money to behold the glorious graphics and inspiring sound of your software. If they want great graphics, they can do better watching a movie, and if they want great music, well, there are plenty of places on the Internet for that. The quality of your software’s thinking is what makes it worthwhile. That thinking is accomplished by means of algorithms that you design — and few software designers could algorithmatize their way out of a paper bag. I’ll provide details on how to design algorithms in a later chapter.
Speaking
Here at least is one area in which software excels. The development of superb graphics was driven primarily by the games industry. But all software benefits from advances in graphics presentation, as well as sound capabilities.
Trust me to point out the dark lining on every cloud. Yes, computers speak very well these days. But another driving force behind this is that we know from thousands of years of experience how to speak well. Every poet, playwright, author, sculptor, painter, actor, cinematographer, composer, musician, and photographer has contributed to the massive edifice of knowledge about expression that we have built up. Odds are that you know a great deal about how to express yourself with language, imagery, sound, and video. People quite naturally concentrate on what they do well, and tend to avoid the tasks that betray their inexperience. Hence, most software looks very good, but it doesn’t listen well or think well.
You can’t compensate
I have already established that good software design requires your software to listen well, to think well, and to speak well. Alas, too many people think that the overall quality of their design is the summation of the quality of the listening, thinking, and speaking. This leads them to believe that they can compensate for poor listening and poor thinking with excellent speaking. So they pour time, creative energy, and money into the speaking part and skimp on the listening and thinking. That’s naughty.
Harken back to the defining example of interactivity: the conversation. Imagine conversing with a person who listens poorly, thinks poorly, but speaks magnificently. Let’s say that you’re at a restaurant and you have a nasty allergy to peanuts. You want the waiter to understand that you must not be served anything with peanuts or peanut oil in it. But as you speak, the waiter is perusing his smartphone and answering text messages on it, occasionally muttering, “Yeah, peanuts…”
You: “Do you understand what I said?”
Waiter: “Sure… you don’t like peanuts.” (pauses to check his smartphone again)
You: “No, I can’t have any peanuts or anything with peanut oil in it.”
Waiter: “Of course you can! Our kitchen has a plethora of peanuts, peanut oils, and peanut sauces. What might be your preference?”
You: “No, I don’t want anything with peanuts in it!”
Waiter: “Then don’t order anything with peanuts. The menu offers a broad range of non-peanut dishes."
Can you recall analogous conversations you have had with software?
One reason for this confusion comes from our use of language. Consider my claim:
Good software should listen well, think well, and speak well.
Exactly what does that mean? Does it mean:
Good software should listen well AND should think well AND should speak well.
Or does it mean"
Good software should listen well OR should think well OR should speak well.
Or:
Good software should listen well OR should think well AND should speak well.
Or even:
Good software MIGHT listen well AND should think well OR should speak well.
The English language does not serve us well here. So I’m going to be explicit:
Good software should listen well AND should think well AND should speak well.
Do not fool yourself into believing that the interactivity of your design is determined by its greatest strength. No, it is limited by its greatest weakness.
I’ll go even further. Instead of using simple black-or-white phrasing, I’ll go numeric. Suppose that we could rate the listening, thinking, and speaking quality of any piece of software on a simple 0 to 10 scale, where 0 represents execrable quality and 10 represents transcendant perfection. Then this formula applies:
Quality of program = quality of listening x quality of thinking x quality of speaking
Most software these days would fill in this formula looking something like this:
Quality of program = 3 x 4 x 8 = 96
Suppose, however, that the designer could have increased the quality of listening and thinking by sacrificing the quality of the speaking, so that:
Quality of program = 4 x 5 x 6 = 120
Here the designer sacrificed two units of quality in speaking and “gave” those two units of quality to listening and thinking. The result was an increase in overall quality. Mathematically, you’ll get the biggest results when the three scores are close together — IF it takes the same amount of time, creative energy, and money to increase each of the quality dimensions by 1. If you have to spend more resource to increase listening by 1 than to increase speaking by 1, then you’ll optimize total quality by putting more into speaking than listening.
Time to move on.