共用方式為

UI Design

  • 發行項

Eric Raymond posted a rant about the CUPS installer. Then John Gruber commented on the rant, and Don Box talked about Eric's idea of "The Luxury of Ignorance." I'd seen Eric's rant earlier, but found John's response via Don's post last night.

Today, Eric Burke said, "Creating good user interfaces is one of the biggest programming challenges." And I thought, "Wow! What a fascinating case of synergy." I wondered if Eric Burke saw John's post or Don's post before writing his article, though his article contains no links.

John almost hit on the most important point in all of this. No one else did. When you're working on end-user software, and it doesn't matter if you're working on a web app, adding a feature to an existing application, or working on a plug-in for some other application, you need to design the UI first.

This is hard for a couple of reasons. The first is that most programmers, particularly those who've been trained through University-level computer science courses, learned how to program by first writing code that was intended to be run via the command line (Terminal window for you Mac OS X users). As a consequence, we learned how to implement efficient algorithms for common computer science problems, but we never learned how to design a good UI.

The second problem is that the tools we use to create UI are often good tools for more simple usability issues, but tend to fall well short when it comes to designing UI for a more complex set of user scenarios. Forms designers are great when you're working within the problem domain that forms are intended to solve, but once you step outside those problem domains, the work gets much harder. Use a more flexible tool, like Xcode's nib tool and the Mac OS X HIView object, and you're going to have to write considerably more code just to manage the UI objects.

For a good example of a more complex UI problem, consider the preview controls in a number of Word's dialog boxes. At first blush, this seems simple: use some form of rich text edit control, and just make it non-editable. Unfortunately, this doesn't work for something like the preview in the Table Auto Format dialog box. To solve this problem, we needed to come up with a way of displaying a full Word document within a control that's inside a dialog box. Try doing that with any RAD tool on the market.

When people first looked at Mac Office X, they wondered why it wasn't all that different from Mac Office 2001. Unfortunately, the largest category of work required to move from OS 9 to OS X was re-implementing all of the UI. This is the software equivalent of picking a house up off its foundation, rebuilding the foundation, and setting the house back down on the new foundation. Of course, there are the inevitable cases where a new piece of plumbing in the foundation doesn't quite line up with the corresponding piece of plumbing in the house. Seemingly simple things, like making sure we didn't screw up keyboard input focus, ended up being very complex problems in certain situations.

John is quite correct. UI design is hard. And, when your UI design steps out of the box, which is inevitable for any innovative UI design, then implementing the code behind it is often just has hard.

 

Rick

Comments