Matthew Paul Thomas has written a thoughtful and thought-provoking essay on the state of usability in Free and Open Source Software. In "Why Free Software has poor usability, and how to improve it" (via Gruber), he gives a concise and well-presented overview over the issues that often plague software projects maintained by volunteers and also lists some suggestions on how to tackle these very problems.
If that topic resonates with you, here's a trio of articles that make for interesting complementary reading.
Free Software UI
by Havoc PenningtonIn his response to an earlier essay by Thomas from 2002, Havoc Pennington shares an insider's point of view of the discussion: as a long-time contributor to the GNOME project, he explains where he sees advances in usability of OSS and takes an especially close look at handling application preferences.
Ten Ways to Make More Humane Open Source Software
by Jono DiCarloDiCarlo presents a handy list -- five Do's and Don't's each -- on what to keep in mind when designing a piece of software, and then goes beyond only theoretically dissecting UI design as he points out three real-world examples for what he considers well-designed OSS software: Firefox, Emacs, and Python. For each, he explains in great detail why he likes them and what decisions and processes during their development (may) have contributed to their exemplary status among OSS applications.
User Interaction 101
by Andy MatuschakIt often seems that programmers see UI design as slapping color, icons, and widgets onto existing code. Matuschak makes a clear case for UI design being, instead, all about interaction, and not (only) looks.
All three of these articles identify soft spots in how UI design is handled within the OSS community, and also provide easy-to-grasp and easy-to-follow advice on what measures to take in order to generally improve the usability of software. Considering that this discussion has been going on for years now, however, it seems that the real stepping stone is not the lack of expertise, but the attitude towards UI and interaction design, which for some of the more vocal OSS developers, still seems to lie somewhere between benevolent indifference and open contempt.
Just sift through the "somewhat" heated discussion on Thomas's article over at Slashdot. While there are some voices of reason to be heard, many of the comments still follow the lines of "designers who can't code should not do software", "if it's good enough for me, it's good enough for my users", "if you want changes, send me a patch."
As long as a developer focuses on well-written code and displays a lack of appreciation for well-implemented, user-targeted (vs. coder-satisfying) user interfaces, don't be surprised that their software is a royal pain to actually use even though its technical implementation behind the UI curtain may be superb.
Categories
Mac
Read More Entries by Jochen Wolters.
Become an O'Reilly Member
Visit the Digital Media Forums
Subscribe to the Digital Media Blog Feed
Subscribe to the Digital Media Newsletter
Travis:
That's a spot-on comment, I daresay.
The spec requirements for an application should reflect what the user needs to get done with it, regardless of whether she's a graphic designer working with an image editor or a webmaster configuring a webserver, and both the UI as well as the underlying code should then be derived from these specs, with the respective developers ideally working hand in hand.
I am not sure, however, how seasoned coders could be convinced that what UI designers or developers of, as you say, "user-facing code" do, is just as important for the quality of the end product as their hard-core algorithm and data structure hacking.
One of my favorite Jobs quotes is this: ""Design is the fundamental soul of a man-made creation that ends up expressing itself in successive outer layers of the product or service."
If you don't follow that principle through-out the whole development process, and you end up with a disconnect between the underlying "functionality" code and the UI, you won't be able to fix that properly without having to go back to the code and re-engineering it to get that perfect fit between what the user sees on the screen and what the app does behind the scenes.
Just as you said, the parameters and outputs must have a useful representation in the UI. Put another way, using the MVC methodology, no amount of View tweaking will fix an inadequate data Model.
Thanks again for your comment, Travis. I wish a coder would chime in with his or her view, too, but I'm afraid they're all busy exchanging the Same Old Arguments™ over at Slashdot…
I had an interesting thought when this issue came up on Jeffrey Zeldman's blog a few weeks ago. Really, code for programmers depends just as much on UI as user-facing code does; the difference is that instead of focusing on menus, dialogs and controls, you're focusing on calling parameters and outputs. But in both cases, the first thing you should be thinking about is how the code is going to be used, and how you're going to interface with it.
You think putting it that way might help some of these programmers understand where the concern is?