October 30th, 2024
Harken thee unto the words of the sinner:
“Hey, what’s the big deal about listening? The user pushes buttons, moves sliders, drags things… all I have to do is accept the input and process it properly. Piece o’ cake!”
This idiot doesn’t recognize that the software designer creates the language that the users expresses themselves with. Suppose you are using a document-creation tool (word processor, program editor, spreadsheet, etc) and are presented with this dialog box upon quitting:
This dialog box offers a language consisting of only four verbs — none of which are useful to the user! We have all experienced many times situations of which this is a caricature. We have all experienced intense frustration when we want to do X and the computer permits us only T, U, V, W, Y, and Z. Here’s a classic example that has been circulating on the web for decades:
This browser cannot play the embedded video file.
If that user had the opportunity, he’d be doing that to the software designer. Keep that in mind as you design your creation. Imagine thousands of frustrated users screaming at you because they cannot do what they think they should be able to do.
A software designer bears the responsibility to design the language that the user employs to express their desires to the computer. The user can speak only the words that you provide. You must provide every word that the user might need.
Crawford’s First Law
The time has come for me to introduce a little idea I modestly call Crawford’s First Law of Software Design:
The first question you must ask in designing any piece of software is:
"What does the user
DO?"
Remember, we’re not designing “interSEEivity”, nor are we designing “interHEARivity”; we’re designing “interACTivity” — it’s all about ACTION, about the user DOING THINGS. Another, more specific way to express this idea is to ask
What are the verbs?
The verbs specify what a user can do with your software. You don’t believe me? I’ll bet you can figure out what a program is from seeing a list of just three verbs from that program:
Type text, select fonts, define tabs
Select color, select a shape, fill shape with color
Click on underlined text, go back, set a bookmark
Move forward, pick up object, shoot
Pretty easy, isn’t it? The verb list is the fundamental design document for any piece of software. Every creative effort has a design document that specifies the contents of the product. In architecture, it’s a blueprint. In cinema, it’s a storyboard. In electronics, it’s a schematic. And for software, it’s the verb list, because defining what the user can do specifies the essence of the software. Therefore, the first major task in creating software, after you have had the initial flash of inspiration, is to hammer out a verb list that realizes your goal.
A Useful Method
Here’s a procedure you can use to hone your verb list so as to avoid nasty problems further down the path. It involves two new concepts: accessible states and conceivable states.
Whenever, during the interaction cycle, the user pauses to think (Step 2), the computer program is in an accessible state. That is, the software is now showing a configuration of its data that it reached. The user has been manipulating that configuration, and has now reached the current state. This is most likely a good situation. Obviously, there are zillions of accessible states: configurations of the data that can be reached.
However, there are also conceivable states: states that a user — any user — can reasonably imagine. Most conceivable states are also accessible states. If the user desires to write War and Peace with their word processor, that’s certainly achievable. However, an especially strange user might desire to write a poem in the Kxzglmrst language as used on the planet Uaiooeua 533 light years away from earth. That poem is one conceivable state, but not a reasonable conceivable state — and it is most certainly not an accessible state because the designers cannot possibly know the characters that make up the Kxzglmnrst syllabary.
On the other hand, consider the user shown in the video above. It is obvious that he visualizes a conceivable state of the software, but that state is not accessible to him. He quite rationally concludes that the software is incapable of performing the task that he desires it to perform.
Every nontrivial piece of software generates more conceivable states than there are accessible states. The ratio of accessible states to conceivable states gives us a measure of how well-designed a piece of software is. The closer to 1 that ratio approaches, the better the software.
Here’s an example of the use of this method. Consider the old-time text adventure games. In these games, you typed a short sentence constituting a command to the software. The software would parse your sentence and execute the command — sometimes. Here’s a typical sequence in one of these games:
You are in a dimly lit room. You see a door to the north. There is a cabinet on the west wall.
Go north
You are outside the house. There’s a barn to the east and a cardboard box in front of you.
Examine box.
The box contains a chocolate-covered rutabaga.
Take rutabaga
Now, this all seems quite straightforward, but the sad truth is that the parser understands very little of the English language and little of its vocabulary. For example, had you typed in “Look inside box” instead of “examine box”, the parser would probably have responded with “I don’t understand”. The same would have happened had you entered “Check out box”, “What’s in the box?”, “search the box”, or any of a number of other phrasings. Thus, there were lots of conceivable states in these text adventures that just weren’t accessible. Ergo, the ratio of accessible states to conceivable states was probably less than 0.20. That’s the primary reason why text adventures never caught on with the public.
A Depressing Example
At the other extreme, it is possible to provide so many accessible states that the user is unable to access many of them. I just happen to be struggling with this problem just now, so I’ll relate it to show you how horrific it can become.
I have an iPhone. It can store images. Here’s a screenshot showing one of the images that I put into its database:
Now, the original image is in what’s called “landscape” format: it’s wider than it is tall. The other format is “portrait” format, in which the image is taller than wide. I wanted to see the image in landscape format, and I know that this is easily achieved by rotating the iPhone 90º. For years and years, when you rotated the iPhone, it would rotate images to show them in landscape format.
But yesterday my iPhone decided to refuse to rotate the image. Most likely I accidentally did something that the iPhone interpreted as a command to never rotate the image. I have no idea what that verb was or how I triggered it. It is an accessible state that is, to me, inconceivable. How’s that for a dirty trick?
OK, so I needed to fix the problem. Now, on my old iPhone 8, I had learned that I could correct the problem by carefully placing my fingertip at the very, very bottom of the screen and quickly swiping upwards. This would present a new display called the “Control Center”. It looks something like this:
Note that red-and-white icon on the left side, center. It shows a lock surrounded by a circular arrow. Does it mean “spin the lock”? No. “Turn the lock upside now?” No. In fact, it’s not really about a lock; it’s about the ability to lock out landscape mode and always have portrait mode. The icon is useless; it doesn’t convey its meaning from its appearance. It might just as well have been any of these icons; they are all pretty much as meaningful:
But I was using my new iPhone 14. The swipe-up-from-bottom verb that worked on the iPhone 8 doesn’t work on the iPhone 14. The Apple software designers had painted themselves into a corner by changing the physical layout of the iPhone, so that the old trick was impossible on the new iPhone.
I didn’t know any of this. Being an old hand at software, I figured that they had moved the verb to the “Settings” app, which controls just about everything in the iPhone. But there are 54 verb groups in the Settings app pertaining to Apple-designed apps:
Now, choosing from among 54 verbs is no big deal if you have burned them deep into your memory, as you have already done with thousands of verbs in the English language. But that isn’t the case here; many of these verbs you will never use! It would be stupid to memorize the meanings of verbs you’ll never use, which means that you’ll always have to look up their meanings. Fortunately, after studying this long list, I determined that only three seemed likely to contain the verb I needed: General, Control Center, and Display & Brightness. So I opened up each in turn. This what they looked like:
Gee, I have only 51 verbs from which to choose here. Yet not one of the verbs presented here addresses my problem. However, there’s a clumsy hint at the top of the middle column, where it says “Swipe down from the top-right edge to open Control Center.” But why would anybody choose to do that on a big page that already says “Control Center”? If you’re already looking at the Control Center, there’s no benefit from swiping down to access the Control Center — right?
This is idiotic user interface design. Apple has given the same name to two entirely different pages. Imagine a language in which the verb “smark” could mean either “kill me” or “kiss me”. Hey, the difference is only two letters, so what’s the problem? One would think that, with 160,000 employees, SOMEBODY at Apple would have noticed this dumb mistake.
Hidden Verbs
A less common blunder is to hide the verbs so that the user can never discover them. The incompetence of this technique transcends to a new plane of existence: plain evil.
Here’s an example of what I mean, taken from Apple’s Mail program. I was once helping a little old lady friend of mine with her Mac.
[Aside: one of the best ways to learn good user interface design is to help a little old lady learn to use her computer. Don’t assume she’s stupid because she doesn’t know how to use her computer — she isn’t. Her problem is that she hasn’t been so steeped in software culture that she isn’t intuitively able to see past design mistakes and make good guesses as to what might work. She assumes that the designers are smart and provided a good way to meet all her needs; that is her only mistake. Every time you show her how to do something, pause and ask yourself if a reasonable person could have figured out the problem all by themselves.]
Anyway, she needed to organize her emails, and she wanted to have special folder for emails from each of her most common correspondents. So I pulled up Macintosh Mail and showed her where the local mailboxes are presented:
Looking at the display, I drew a blank. I had added local mailboxes to my mail many years ago, but I could not remember who I had done it, and I could not divine from the display how it might be done. I went through all the menus, clicked on a bunch of things, and checked Preferences. No joy. The image I had inculcated in her that I was the omniscient software genius was quickly evaporating. Then, by pure chance, I happened to pass the cursor over the “Favorites” line just above “All Inboxes”. Mirabile dictu, the solution appeared out of thin air (pixels):
Two new mini-icons appeared to the right of “Favorites”: a plus sign in a circle and a micro-down-arrow. However, they were “greyed out”: drawn in a light grey color that, from time immemorial (i.e., 1984) has always meant that these items are inactive. For that matter, the word “Favorites” is also greyed out, meaning that it too should be inactive. Yet here was some activity from the supposedly inactive image. Well, I intuited, if “Favorites” is greyed out yet active, then perhaps the two mini-icons are also active. So I clicked on the circled plus sign and got this response:
Zounds! Something worked! My friend expressed her admiration for my genius, and I nodded my gracious assent. But I figured that I had better inquire further, so I tried the same trick with the “On My Mac” phrase at the bottom of the above images. Sure enough, I got this response:
Here was the solution to my friend’s problem! I nodded again as if to say, “Just as I expected…” as I secretly wondered how in the hell the designers could have blundered so foolishly. Hiding verbs has got to be one of the greatest software crimes I can imagine. The perpetrators of this outrage should have their hard drives lined up against a wall and erased. Imagine turning to a friend for help and having them respond, “Sure, there’s an easy way to fix that, but it’s a secret. I won’t tell you, but I will let you guess, and if you guess correctly, I’ll confirm it!” How would you wreak your revenge upon such a cruel monster?
I can guess how this atrocity was born. The user interface designers made the mini-icons visible in black in the original design. But then the evil graphic designer stalked in and threatened the UI designers with burning at the stake. “That’s ugly!” the graphic designer hissed. “It’s graphic clutter that befouls the clean, clear design I originally gave you. Remove it or die!” Trembling mightily, the UI designers pleaded that the mini-icons consumed only blank pixels and provided a necessary function for the user. “Insolent wretches!” the graphic designer roared. “You can leave them there but they must be the same color as my clean background!” And so it was done.
Graphic designers should be defenestrated from software companies, although as a humanitarian gesure I suggest that the defenestration be done from the first floor. The purpose of software is not to LOOK good but to ACT good. If you want pretty pictures, go to an art museum or a porn site. If you want software that works, use every resource available to make it easier to use.
Software designers should spend time in Software Boot Camp with me as the Drill Instructor, where I make them design software for the old 8-bit machines as I berate them with the most exquisitely brutal vocabulary. Here’s what they would have to work with:
The Apple II display permitted 280 pixels horizontally and 192 pixels vertically, for a total of 53,760 pixels. By way of comparison, my iPhone 14 with a 6.1 inch screen has 1170 horizontal pixels and 2532 vertical pixels, for a total of just under 3 million pixels — nearly 60 times as many pixels as the Apple II. Here’s how the Apple II screen compares with the iPhone screen:
The Apple II screen is down in the lower right; it’s a little bigger than an iPhone icon.
When you have learned your craft working under such tight constraints, you will learn the value of every single pixel, and you won’t go around throwing them away like some idiot graphic designer.
Inscrutable Icons
Oooh, how I hate these! Once upon a time forty years ago, there weren’t many icons in use and so they all made sense, even though they were a lot smaller than today’s icons:
But nowadays, everybody is making icons for everything. And sometimes these icons get piled into a program in ways that make no sense whatsoever. Here are some particularly undecipherable icons:
These are all from actual programs that I actually use; as you can see, none of them have any intrinsic meaning. Of course, in the context of the program, some of them are a bit more scrutable, but not much. Apple has a better system:
The icons are labelled with text. Now, you could argue that this is nonsensical because
Too Many Verbs
This user interface disaster comes from two fundamental problems that plague almost all software nowadays. The first is the huge number of verbs that now burden users. Perhaps you believe that the expansion of the verb vocabulary for software is a positive development. After all, more verbs give users more expressive power. As Crawford’s First Law notes, verbs are what users DO, so creating more verbs gives users the power to do more things. Isn’t that a good thing?
Consider: the English language boasts about half a million words in its vocabulary. The average person knows only about 30,000 of those words — just 6% of the total vocabulary. Words like mithridatize, jessamy, butwink, hain, lyddite, olefiant, and forquidder. Some of my favorites include bathukolpian (deep-bosomed), frigorific (making something cold), and deosculate (to kiss). How would you feel if the instructions for using your smartphone were written with such obscure words?
That’s the problem with most software these days. Few of the verbs are intuitively obvious; each must be learned by consulting an external source.
"That’s what user manuals are for”, you counter.
Oh, come on, be serious! The only people who read the manuals are those intending to use the software professionally. They can read the user manual on company time. Yes, I occasionally consult reference materials, but most of the time I’m checking a specific feature in a programming language. I should not have to read a user manual to use a photograph database application.
The Evil Internet
A major reason for the explosion of verbs is the rise of the Internet. Back in ancient times before the Internet, companies had to maintain large customer service departments to help users calling with questions about how to operate their software. If you sold a million copies of your software, you’d need thousands of people trained and ready to answer the tens of thousands of questions that came pouring in over the telephone lines. This was such a huge cost burden that software companies learned the hard way that it was imperative that their software be easy to understand.
But the Internet subverted this reasoning. You could set up a “user forum” on your website, where altruistic, experienced users would help the beginners cope with the complexities of the software. Suddenly all incentives to keep the software clean and easy to understand went flying out the window. The only pressure you experienced from users came from the aficionados who would demand the most picayune embellishments to the software. “Your software doesn’t let me turn some of the letters inside a word upside down! What’s wrong with you people?!?!?!” Thus was born the new “upside-downing” verb buried deep inside a tree of verb groups.
Too Many Verbs, not Enough Buttons
Another factor that ruins the user experience is the woeful shortage of input operations available to the user. Sure, some devices have a wide range of capabilities. A desktop computer has a mouse and a huge screen with hundreds of thousands or even millions of pixels, any of which can be clicked on individually. A smartphone has a smaller screen and a clumsy replacement for the mouse: a fat fingertip. A smart television has a remote with several dozen buttons. Worst are the clocks, electric blankets, and other electronic devices with a few buttons. In order to save a few cents on buttons, they overload each button. Many devices have four different verbs assigned to one button, reached by:
click
double-click
triple-click
click and hold for 3 seconds
Some go even further and assign verbs to combinations of clicks from two different buttons.
The problem with all these clever stunts is that not one of them is apparent to the user. In simpler times, a button had a label on it to inform the user what pressing that button did. No longer; many buttons are unlabeled because they can take multiple meanings.
The end result of all this input overloading is a user who is prevented from using the words.
The Eventual Solution
There is a solution to all these problems. It has been staring us in the face for sixty years now; here’s an example:
https://www.youtube.com/watch?v=QpWhugUmV5U
Computers will only be truly useful when we are able to engage them in conversation, just as we interact with humans. I should have been able to fix my problem with my iPhone by saying, “Siri, I rotated the iPhone but the image is not rotating correctly. Why not?”
The moral of this story: Give your user every verb they need: no more, no less; and make those verbs clear and obvious.