Brandon Walkin has just published a fascinating article on the topic of managing user interface complexity. “I’ve spent the past year redesigning a particularly complex application with my primary focus being on reducing complexity. In this article, I’ll go over some of the issues surrounding complexity and techniques that can be used to manage it.”
An interesting concept he starts out with isthat of progressive disclosure. Progressive disclosure is the act of hiding lesser used functions of a program behind a button, a menu, or something similar. This may seem straightforward, but it brings with it two dangers; as a programmer, you need to know which functions are used less often while at the same time not taking this concept too far, which will only make the application more complex instead of less.
Walkin offers a very good example of progressive disclosure gone awry: the Internet Explorer user interface. When in its default state, with Windows Live installed, this interface has a staggering 17 disclosure points. I’ve personally harped on Internet Explorer often for its poor interface, but I’ve always put off writing a more detailed article about it. With this article, Walkin puts the finger on one of the problem points.
Another issue he points out in Windows 7 is the lack of consistency with the print button. Because Microsoft has a fetish for removing the menubar from their applications, they need to find new places for commonly accessed features – such as printing. If you browse around the default set of applications and windows in Windows 7, you’ll see that the print button jumps all over the place, and because there’s no menubar, you can’t rely on that either to find the print option.
Another aspect Walkin touches on is that of alignment and visual hierarchy. The ideal is to align user interface elements as much as possible, and to employ a thoughtfully laid out grid. By comparing the inspectors in Microsoft Expression Blend and Adobe Lightroom, and making the element alignments visible, he shows quite convincingly just why exactly the Microsoft variant looks so cluttered and overwhelming.
There’s a lot more thoughtful stuff in there, so if you’re working on an interface, or you’ve always wondered why a certain application looked cluttered to you, but you could never put your finger on it – this article could provide some answers.
Just about cried at the last example…. oh dear.
Somebody has obviously had the bright idea of having the tool offer suggestions of what the current date might mean in terms of recurring events – that’s good.
Not applying some common-sense to it – that’s not so good. Based on a bit of experience (and a bit of polling around the office), I’d drop the “n’th last day” entirely, and replace “nth last Tuesday” with simply “last Tuesday” if applicable. If testing shows a handful of people find this insufficient, you can always add an “Other…” option and a popup to enter more complex setups…
Still, I suppose it could be worse – it doesn’t suggest “the third full moon after the winter solstice”…
That shows the problem of Microsoft’s UI designers. Instead of making their interfaces adapt to how people work, they require the user to parse a lot of text (really, how many lines do you need to explain something like UAC or a file overwrite operation?) and have the user adapt to the interface.
This guy has some ok points, but a lot of his comparisons are ridiculous.
He says “While contextual menus are a consistent and useful way of revealing contextual actions on objects, they’re hard to discover”
But that isn’t really true unless the user is completely new to basic user interface concepts. The reality is that in any reasonably complex software there are far too many options to _not_ hide them in context menus. That’s not a bad thing, because context menus are always exactly where you expect them to be, and are much easier to make keyboard accessible than context sensitive floaty menus.
In the alignment comparison, he makes the valid point that the lightroom inspector looks cleaner, but it’s a completely useless comparison, because the two dialogs do two completely different things. They have different widgets and are designed for two different tasks. You just can’t compare them. Sure the Expression Studio dialog could probably be cleaned up, but comparing it to something completely unrelated is stupid. It would be far more useful if he actually cleaned up the ugly dialog with some rearranging.
Then comes the visual noise examples. While his point to simplify the visual appearance is a good one, his examples are terrible. The address book which he says is nicer looks horrendous. It looks read-only even though it isn’t. It is impossible to tell what parts of the screen are supposed to be editable without (likely) moving the mouse over them. And the alignment is completely off. The little red icons don’t line up with the text, the text has inconsistent vertical spacing, there is way too much unused space, and the dialog has far less information than the Entourage one.
The Entourage dialog, on the other hand, is nicely aligned, is very clear on editable fields, and makes sense to anyone that has seen a paper form before. Sure it’s a little busy, but to me it looks way better.
Same goes for his Apperture example. The higher contrast one looks different, and arguable not as nice (since it is just a mockup that’s not surprising), but I don’t see how it looks more complex as he claims. He provides no reference or even explanation for his claim.
His points on icons are also largely useless (make icons more meaningful (duh), group related ones (obvious), and use progressive disclosure (repeat from earlier).
The recurrence calendar is amusing but hardly useful. While it is funny to point out bad examples, he doesn’t actually show how it could be made better, which is the actually useful (and difficult) part.
To get to the Address Book screen shown, you must click on an ‘edit’ button, which just might indicate that this is not a read only screen. What you may not know, once on this screen is that one of the editable fields always holds focus, projected forward with a drop shadow and pale blue highlight. Difficult to miss this hint at editable focus. Clicking anywhere in the interface changes focus to the nearest editable field. That interface is near perfection, only showing what you absolutely need to see at any time for minimal clutter and a pleasure to use. Actually fun to use!
Thanks for posting this article. Many UI articles point out a bad interface, but don’t explain what makes a good interface. This article describes what a good interface is, and why it’s good.
The standards for menus have been around FOREVER. Look at good old DOS edit. There is a file menu, and edit menu. Copy and paste. Woo hoo. These menus have essentially standardized across most platforms. My wife has no problem using my Linux laptop, because there is always a “File/Save”, etc. These standards have held true since DOS, through Windows 3.1, 95, 2000… and are generally followed on my Linux applications. I really find it offensive that these were chucked out the window because someone like morphing toolbars. You could not get your application “Windows-logo” certified without following these conventions. Businessses wrote rules that their applications must follow these guidelines. I write software, and had to ensure that all my applications followed these menu-ing guidelines. This ensured that if a user learned how to use one application, they could use any application. Now they are going to have to learn the joys of every designer’s morphing toolbars.
Sigh.
Yes, and it seems google is already going that route too with chrome. Chrome does look pretty though, and people seem to like it, but as i have pointed out in many post before here at osnews, applications shouldn’t *default* to this behaviour. But there should certainly be an option for those who want it like that.
The scary thing is that the big open source applications is going that route too (firefox 4, the new openoffice) wich is sad because they are key applications for many desktop distros.
The application should present a familiar face, and then ask, “would you want me to look like someone else?”. Not the other way around.
Interesting article but I have issues with many of his points, for reasons previously stated.
It’s 25 years after the famous 1984 article by Donald A. Norman on interface guidelines, and still we see that some of his points are lacking or are implemented in a faulty way (especially the issue of “feedback”; letting the user know at all times what is going on).
In the 2 months I’ve been using OSX, I’ve started noticing how the “Check for updates” feature is all over the place (though often in the application contextual menu or the “Help” menu). Why? Because even though Apple has its own Human Interface Guidelines (which is outstanding), this is not covered in the text and developers are left theorizing this logic on their own.