Interface Design Is Trickier Than It Seems
By DAVID POGUE
As more and more gadgets and programs combine more and more functions, interface design is becoming a burning issue. The interface -- the layout of the controls -- determines how easily and effectively you can use the product: which buttons go where, how many layers down you have to burrow to find an important function, and so on.
Here's good interface design: A Palm organizer's Address Book screen has a New button—but the Delete command is hidden in a menu, because you add names much more frequently than you delete them. Here's bad design: Cell phones that make you dive into menus just to turn off the ringer.
I may sound like a harsh critic, but far be it for me to suggest that it's easy to design excellent interfaces. Quite the contrary.
Years ago, I wrote the manuals for a piece of sheet-music software called Finale 2.0. In those days, computers were so slow that just scrolling from one page of an orchestral score to the next could take nearly a minute—an excruciating delay for composers in the heat of inspiration.
I phoned Phil, the software's programmer, and laid on him a brilliant idea: Why couldn't he write a utility program that could stitch together a series of smaller files? That way, a composer could write his composition in sections, as a series of small files that scrolled quickly. When the pieces were ready, my proposed utility program could merge them into a full, finished score. I sat back and waited for him to congratulate me on my genius.
"Well," said Phil, "what would the interface look like?"
"It's really, really basic," I began confidently. "Just two lists. On the left, all the Finale files on your computer. As you click the ones you want, in the order you want them merged, they show up on the right, like a playlist."
"So what if you make a mistake in the order?"
I hadn't thought of that. "OK, you'd need to be able to rearrange the pieces. So we really need to add an Up and a Down button."
"What if you add a file to the list by accident?"
I sighed. "All right, add a Delete button."
He wasn't finished with me yet. "So what happens if you choose individual Finale files that are in different keys or time signatures? Which one wins? "
I kept at it, failing to realize that I was being led down the garden path. "Just put in some kind of control that lets you designate one file as the master," I said. "The one whose key and meter take priority."
Phil was clearly enjoying this. "OK, so far we've got two lists, up/down arrows, a Delete button and a Master button. But won't some composers want to stitch their orchestral scores together from the top down—the flute part in one file, then the clarinet part below that, and so on—instead of horizontally, in chunks of the piece from left to right?"
In 10 minutes, Phil had talked me into designing a horror of an interface, something that nobody would ever understand or use.
He also gave me a lesson in the difficulty of good interface design that I'd never forget -- and a lasting respect for the people who know how to do it right.
Оригинал статьи [»]