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.



Comments (23)

    I’ve spent the past year working in a UI group (don’t worry, I’m not writing the UI, I’m doing infrastructure work), and I’ve gotten a good taste of just how much work UI programming is.

    Especially GOOD UI.

  2. Steve Hall says:

    I agree with all of the comments in the referred articles, as well as yours! I’m positive you’ve rooted out ONE cause of newer programmers not being good at UI design: total lack of computer science programs putting any sort of emphasis on that part of the programming effort. Contrare, most professors usually dish out enough attitude AGAINST being a "UI burger flipper" that most CS graduates in the past 15 years firmly believe that UI design is NOT part of programming, and they actively try to avoid out when interviewing for their first job. Too much emphasis has been placed on equating coding to programming.

    Almost EVERY single junior programmer that’s worked under me for the past 15 years has had this deficiency. But I think it’s much worse than you diagnosed. What’s been missing in CS curriculum is not just UI design course-work, but that of ANY analysis and design course-work!n (I.e., specifically, a "traditional system analysis/design" course or two…)

    Most CS programs have structured themselves around bottom-up design of entire applications, instead of proper top-down design. Most professors teach the algorithms side of coding fairly well, but fail miserably when trying to make that same application user-friendly (and deployable) by having a good UI. Quite often (according to my juniors…) they just tell their classes: "And then if you really want to, you COULD throw together a little GUI to go on top of it…if you want!" Essentially, trivilializing the UI design effort. (A lot of recent CS majors tell me that their professors give "extra credit" for turning a homework assignment with a GUI, and some actually will dock your grade for "putting form before function", f they spend a little extra time and "slap together a little GUI", even though their code was functionality correct.)

    But, it’s much worse than that! They also make it possible for CS majors to go from bottom-up-designed command-line driven little "algorithm exercises" to full-fledge app writing by skipping to full-fledged RAD tools like IDEs and application frameworks (like the Java class library or .NET BCL) WITHOUT taking ANY system analysis and design courses!

    Recently I found out (from several students), most California colleges have moved their single analysis and design course from being a 200-level course to a 300-level course, treating this course like an after-thought. Worse, more CS programs no longer list any systems analysis/design course as a CS degree requirement!

    (Sadly) I DO get a bit of entertainment value out of watching junior whips struggling to "think out of the box", namely the IDE or app. framework, when they run into some bit of functionality for which the IDE doesn’t provide a wizard or the class library doesn’t provide a convenient (high-level of abstraction) set of properties/methods/events……and, heaven forbid, they have to go spelunking down into lower-level APIs like Win32.

    The over-use of crutches in CS programs (and allowing the dismantling of those boring analysis/design courses) has stifled a lot of the creativeness and craftiness in CS majors lately: causing a lot of the general public to think that "software development" = "coding", which has brought us the off-shoring of what is thought to be a low-level job skill (coding). Sort of a self-fulfilling prophecy, notably caused by the deficient CS curriculums!)

    I have not met a SINGLE CS major in the past 15 years (out of over a hundred that have worked with or under me) that understood top-down design..including how to write a "functional requirements" spec (if the users were too lame to provide one), an "external spec" (aka UI/presentation layer spec), or an "internal spec" (aka functional/business logic spec) BEFORE writing a single line of code! Most seem totally incapable of writing ANY form of spec! When I do encounter someone that can write some sort of spec, it’s usually a mish-mash of functional requirements, external and internal specs that never approaches reality and is rarely ever used or updated.

    There’s something to be said about the old-school of spec. writing that the COBOL/FORTRAN world practiced during the 60’s, 70’s, and 80’s…whereby the application was fully designed top-down with spec’s before being coded.

    Of course, I know this probably labels me as an old fuddy-dud, but I guess this comes from growing up during the "space race" and adhering to the philosophy of Gene Kranz: "Failure is NOT an option!" Living for over 20 years in Silicon Valley, I’ve watched hundreds of projects (and companies!) fail when they trying short-cutting good up-front top-down design.

    Fortunately, at least Microsoft is paying heed to this need, with the advent of the Practices and Patterns website and books…encouraging coders to become programmers and programmers to become software developers. (A distinction that’s gotten lost over the years…)

  3. 2lmc spool says:

    <a href=’http://blogs.msdn.com/rick_schaut/archive/2004/04/02/106929.aspx’ >UI design</a>

  4. Eric Raymond: I&rsquo;ve just gone through the experience of trying to configure CUPS, the Common Unix Printing System. It has proved a textbook lesson in why nontechnical people run screaming from Unix. Eric Raymond: Good UI design, and doing the right thing by Aunt Tillie, ought to be a matter of gut-level pride of craftsmanship.&hellip;None of this is rocket science. John Gruber: What Raymond is proposing, in fact, is no change at all. This idea, that the hard work of development is in building the underlying foundation, and that the easy part is writing a &ldquo;GUI wrapper&rdquo;, has been…

  5. Check out Eric M. Burke’s post GUI Programming is Hard. In a related post, Rick Schaut talks about UI design. Both posts hit the nail right on the head and are considered a must-read. Yes, I’m talking to you, dear…

  6. David says:

    You’ve adequately explained why UI is hard to IMPLEMENT but you haven’t adequately explained why UI is the bastard child of technology. I’m not just speaking about the poor software UI but of user interfaces of hardware devices as well.

    Take mp3 players as an example (though you could choose cell phones, DVD players, VCRs, and the list goes on and on and on). Apple’s iPod is an exemplary example of a good UI. It isn’t perfect but it is quite good. Why is it that every so-called iPod killer released since 2001 has a largely braindead UI?

    Obviously companies recoginize they can’t just copy the iPod’s interface but surely they could study the iPod to determine what makes it good – and what it’s weaknesses are. Surely that study would result in the creation of a good UI that wouldn’t get the company sued by Apple. But so far it hasn’t happened.

    Why? Sure, we weren’t taught how to write UI in college. I took lots of classes to make me a better software designer – but that was all about algorithms and data structures and class design. It wasn’t about making the program easy to use. OTOH, as a longtime computer user I know what erks me (combo boxes and poorly organized tabbed dialog boxes for example) and what I like. I could develop a decent, if not stellar UI, right out of college.

    Frankly, I think one of the big reasons UI suck is because marketing can’t spin it. Hey, we can easily advertise 20 new features. "Now with automatic spell checking!!!" But will "new and improved interface" really sell? And given that reality, the suits want me to spend my time adding new features – not polishing the interface.

  7. Bruce Lieberman says:

    User interfaces still suck because they still aren’t valued 🙁

    This appears to _SLOWLY_ be changing.

    (although shockingly, tons of people still don’t understand the difference between a designer and a programmer)

    Finally, there are now degree programs available in Interaction Design

    (thank you Berkeley & Stanford)

    ROI is still tossed around, and some if it can be quantified, some of it can’t… the intangibles are often as important (if not MORE) and valuable as the tangibles that you can attach metrics to.

    I heartily recommend reading Alan Coopers book on Interaction Design – ‘About Face 2.0’, as well as ‘the Inmates Are Running the Asylum’ (should be required reading for everyone in the biz).

    Time spent UP FRONT learning what the functional parameters are, what the underlying structural parameters are, as well as understanding the applications function in the (human) organization… pays off in successful products, happy customers and drastically lower support costs.

    Yes, UI design is hard… when done properly.

    But the payoff is completely worth it.

  8. bart says:

    About the control in a dialog box to preview a full document : I do it all the time with Trolltech’s Qt in combination with their RAD tool. It’s actually incredibly easy.

Comments are closed.

Skip to main content