June 2010

Volume 25 Number 06

Don't Get Me Started - Chainsaw Development

By David Platt | June 2010

David PlattIt takes Microsoft three versions to get a product right, Windows itself being the classic example. Visual Studio 2010 and the Microsoft .NET Framework 4 represent the third release of Windows Presentation Foundation (WPF) and its tools. Right on schedule, my clients are telling me, “Yeah, looks about ready now, help us learn it, then we’ll try a pilot project.” But newcomers to WPF are often distracted by its glitz: They forget that their ultimate goal is making their users happier and more productive, not titillating their own vanity by cramming flashy gizmos into a program for the sheer pain of it. Above all, they forget that their program is just one of many that users switch among, all day every day, and that commonality among UIs—in other words, most Windows programs working more or less like each other—is the key to their users’ satisfaction and hence to their programs’ success.

Few people under age 35 remember DOS programs, when UIs had no commonality whatsoever. For example, most DOS programs had no menus, requiring snap-on keyboard templates to remind users of commands. (OK, I guess that’s some commonality.) A few DOS programs contained menus but didn’t show them until the user pressed a specific key, and naturally every program used a different key and showed the menu in a different place. Microsoft Word used ESC and the menu appeared below the document; Lotus 1-2-3 used the forward slash ‘/’ and the menu appeared above the document; Farsight (another spreadsheet) used F3. Every user had to (gak!) read the manual (remember those?) to even start poking at a new app, and then had to switch mental command sets every time he switched applications.

The biggest growth driver of the Windows user platform, besides Solitaire, is the standardized UI that its API encourages. The primary control structure is a menu at the top of a program’s window. Keyboard shortcuts are listed on the menu items as a teaching aid, toolbars provide graphic shortcuts and so on. These standards, like tool tips and right-click context menus, have evolved over time, and they continue to evolve today (the Office Ribbon control, for example). No one ever reads a manual. Users expect a new Windows program to instantly explain itself through its UI, and will dump any that don’t.

We don’t have these standards for the new features of WPF yet, and that’s a real problem. For example, many articles explain how to program animation in WPF. But besides my paper, “Using WPF for Good and Not Evil” (rollthunder.com/SoftwareThatDoesntSuck/WpfForGoodAndNotEvil.htm), I  see no discussions in the Windows community of what information an animation communicates to a user, what effects an animation therefore has on the user’s productivity and satisfaction, or any sort of guidelines on where animation should be used and where it shouldn’t. That’s why, whenever I teach a class on WPF, I always insist on devoting at least a day to UI design, teaching my clients not just to write WPF code, but to start from the user’s needs and work inward, rather than starting from the toolkit and working outward.

chainsawWPF is much more powerful than Windows Forms, as a chainsaw is more powerful than a handsaw. I see great exultation over that power, and the exalters are absolutely correct about its magnitude. But I see zero discussion of the careful thought needed to safely and productively manage that power to make users happier—which is our ultimate goal.

This needs to change, and it needs to change now. After four-plus years of experimentation, we ought to have some notion of which usage patterns in WPF make users happier and which accomplish the opposite. With WPF poised to become the mainstream of Windows desktop development, I call on Microsoft to publish UI design guidelines for it; not how to program this or that feature, but when and where and why to use it. A company that manufactures a chainsaw incurs a duty to teach its customers which end of it to hold.     


David S. Platt teaches Programming .NET at Harvard University Extension School and at companies all over the world. He is the author of 11 programming books, including “Why Software Sucks” (Addison-Wesley Professional, 2006) and “Introducing Microsoft .NET” (Microsoft Press, 2002). Microsoft named him a Software Legend in 2002. He wonders whether he should tape down two of his daughter’s fingers so she learns how to count in octal. You can contact him at rollthunder.com.