I admit that my intelligence is easily insulted. It’s probably because I’ve got so little of it left – raising a child, running a business, and working in the software industry take their toll, after all – that I’ve got to defend it with the ferocity of a rabid fruit bat. But, as I review the state of the art in desktop publishing software, I’m left with one nagging question: Just exactly how dumb do these guys think I am?
I’ve worked for companies that develop desktop publishing software, and have developed quite a bit of it on my own – so I’m familiar with the fact that many computer users are stupid. I’ve taken more than my share of technical support calls that plumb the depths of human ignorance (“Is the computer plugged in?”), incompetence (“The mouse doesn't have to touch the screen”), and depravity (“You cannot do that with a floppy”). It’s no wonder they think we’re dumb. I’m often stupid, myself, when confronted with an entirely new piece of software.
But we aren’t stupid forever.Put an overworked desktop publisher and a piece of page layout software together through a few dozen deadlines, and you get a very smart user. Someone who often knows the program better than the engineers who developed it, and far better than the marketing and sales people who sold it.
And that’s where the trouble starts. By the time we really know what we need to do, and know how we shouldbe able to do it, we find ourselves either blocked by limitations of the program we’re using, or annoyed by the water torture of the little things that slow us down hundreds or thousands of times a day.
Though I think today’s publishing programs are excellent – and think that their maturation in the last fifteen years is nothing short of astonishing – I think they could be better. I think the key to making the programs better is for software developers to start giving users credit for their intelligence. Stop expecting the worst of us, and start encouraging the best. In this column, I’ll outline a few little things that might help.
“Easy-to-learn” is not the same thing as “easy-to-use.” The on-screen gadgets that make learninga program easy are often the very things that interfere with usingthe program in a high-pressure, production-oriented publishing environment. It’s kind of like buying a bicycle with training wheels, learning to ride, and then, when you’re ready to take the training wheels off, finding they’re welded to the frame and cannot be removed.
Take, for example, the Layers palettes in Adobe’s applications (notably Illustrator, PageMaker, and the forthcoming InDesign). In these palettes, a small square appears next to the layer’s name when you have objects selected on that layer. The square is a “proxy,” a stand-in for the selected objects. To move the objects to another layer, drag the square up or down in the Layers palette, and drop it on the layer you want to move the objects to. That’s pretty simple (once you figure out the relationship between the selected objects and the square – which one reviewer had the audacity to call “intuitive”).
In FreeHand, by contrast, assigning objects to layers is more direct: select the objects, then click the name of the layer in the Layers palette. The objects move to that layer. The trouble with this approach is that new users often find themselves moving objects from layer to layer when they don’t intend to.
The design of the Layers palette in the Adobe products protects the new user – it’s actually fairly difficult to move objects from one layer to another. This approach also makes it impossible to move objects from multiple layers to a single layer in a single action. Once you know what you’re doing, FreeHand’s approach is better. When you’re new to a program, or are a casual user of a program, dragging the mouse to work with on-screen controls isn’t painful. When you’ve really got a lot of work to do, however, a click is always better than a drag, and a keyboard shortcut is better than any mouse action.
Bad, bad user!
Most desktop publishing programs (XPress, PageMaker, and InDesign) won’t let you apply formatting to text in a text container when you select the container using the object selection tool (the names of these tools vary – it’s the Item tool in XPress, the Pointer tool in PageMaker, and the Selection tool in InDesign). You forgot that you must select text using the text selection tool (the Content tool in XPress, the Text tool in PageMaker, or the Type tool in InDesign) if you want to apply formatting.
Why do you think these programs prevent you from doing this? They’re not thinking that you might want to quickly apply formatting to text in a series of unlinked text containers – which is something you’d probably like to do. Instead, they’re worried that you’ll apply formatting to a text container that’s linked to other text containers, and that having the formatted characters flow into text containers before or after the current container might frighten and upset you. They’re doing this for your own good, really.
Why prohibit what does little harm (particularly if your program has a robust “Undo” feature) and much good?
What did you think I was thinking?
Here’s a test. Select the object selection tool (the Item tool in XPress, the Pointer in PageMaker or FreeHand, or the Selection tool in Illustrator or InDesign) and double-click a text container. What happens? For the most part, nothing. Only FreeHand guesses (correctly, I believe) that you want to edit the text in the text container and positions a text cursor in the text where you clicked.
Nothing? Nothing?Of all of the infinite number of possible things you might be trying to do when you double-click a text container, nothing comes in dead last. I guess this protects you from accidentally editing text. Next, try clicking the text editing tool on a blank area of a page. What happens? In XPress, and InDesign, nothing.
These are conscious, overt actions. Somethingshould happen. If you, as a software designer, are not sure what that “something” should be, implement a few of your “best guesses” and let the user decide (through a preference, as in FreeHand, or through a set of predictable behaviors, as in PageMaker).
The (slightly) bigger picture
Don’t get me wrong – these are all great products, and I’m glad we have them on the market competing with each other and getting better with every release. There are some definite bright spots – FreeHand and InDesign, for example, are far less restrictive and modal than the rather authoritarian XPress.
I admit that the examples I’ve used are small things, taken separately. I can think of dozens of other examples. Collectively, I believe these “little things” are indicators of a software design attitude that hasn’t kept up with the times.
The desktop publishing market has matured, and users have gotten smarter. It’s time to start building software tools that empower us, rather than dictate to us the ways in which we’ll work. We’re not afraid to make mistakes, and we should be allowed to.A software engineer’s “mistake,” after all, might be a graphic designer’s stroke of genius or the page layout trick that gets the tired production artist home to bed.