Smart Software: Listening and Taste
I learned a life lesson from drum teacher Pierre Beluse at a gathering of Canadian Youth Orchestras back in 1988. It was during a lesson on snare drum technique. I was good, my skills were at a peak. Like most things, being at a peak meant that to go any higher I needed to be knocked down to where I could try for a higher peak. Good teachers are like sherpa guides that way.
I played and Pierre listened. Then he played the same passage and I listened. We went back and forth a few times before he finally spoke. "It's good, but when you play, listen. To be artful requires listening, and taste. While you play you need to listen, and then you express yourself with taste."
Listen, and then express yourself with taste. Reflect, and express. The yin and yang of performance. Be aware and react appropriately.
* * *
Computers should take a lesson from Pierre. We want computers to act smart. Intelligent. Not so much HAL or Turing Test-intelligent as we want them to simply take our input and respond appropriately. We want computers to listen and respond with taste.
Successful programming methodologies emphasise the human (interface) experience. Apple wrote a good book on human interface design. Extreme Programming requires the continuous feedback of a representative user. Alan Cooper asks people to build technology for specific user "personas." Simply covering feature lists is not enough, build for specific users to accomplish specific tasks.
In The Timeless Way of Building, Christopher Alexander writes that for a building or town to breathe with life it needs to be in harmony with the people who live there: its users. In creating or maintaining buildings or towns, designers give these structures qualities which either lend to life or stagnation. People thrive or stagnate in response to their environment. Communities contain endless cycles of awareness and reaction.
Alexander also writes that the discomfort people feel in certain places reflects a lack of natural features. These places lack life. The places we feel good tend to have a certain amount of "flex." They respond to us, they invite interaction. Living places like the seashore or a bustling outdoor market give us the feeling that no two experiences there are exactly the same.
The characteristic of life Alexander describes is what most software fails at. I once thought the measure of computer perfection was invisibility: technology so seamless it goes unnoticed. No more. For gadgets, sure, but computers, no. Computers need to be intelligent and active. User interfaces need to "flex," and should invite interaction. Interfaces should be malleable. Applications need to listen, and react appropriately.
Every application is an expert system. The point of involving users in the design process is not to collect and implement feature lists, to “meet their needs.” That approach gives us orphaned features and prioritised wish lists, not natural or intelligent software.
The process is about art. It is about listening and taste. The point of involving users in the design process is to reflect their expert knowledge and work patterns in the product. To reflect their world inside the expert system. The best way to meet user expectations is to define the product through their experience. The art imitates life.
The goal is to automate and improve the efficiency of the user's labour (5LF). Quark is not successful because it is easy for laypeople to use, it is successful because it performs the functions and speaks the language used by typesetters and publishers. Ditto CorelDraw or Illustrator for graphic artists, and AutoCAD for architects.
For non-specialised software this mindset is just as important. Though the interface should seem as inviting and malleable as sand on a beach, a designer should still intend software to behave as an expert system to facilitate specific tasks. If you can not do one thing well, you are useful to no one. The lesson is to always ask, "How will this be used? By whom?"
Some people argue that every feature should be implemented two or three different ways, once for each style of user. In reality, when you aim to please everyone you please no one. But when you build for a specific user you create a champion of your app. Success happens when you please one user at a time. When you please one user, you please a thousand others who think and work the same way. When you need to please more than one user, do not think of it as two ways of doing the same thing, think of it as two separate applications that you happen to run with the same icon. Build for each user from start to finish.
Every feature should be useful. Adding features for the sake of adding features is decoration, not substance. People get bored with decoration, they crave substance that helps them do their jobs and get home in time for dinner. Substance is form with purpose. Substance is a concrete goal, its realization, and each step in between.
Challenge yourself. Make software smart. Be an developer of intelligent apps. Write software that knows why the user is involved and reacts appropriately, flexibly, naturally. And when you get there, keep an eye out for a higher peak.
[Last edited September 14, 2003]