A few days ago, Josh Gruber took a potshot at an admittedly dreadful looking Windows utility, the aptly named “Bulk Rename Utility.” For some reason, something just felt off about the post — yes, it looks like hell at first glance, but it also looks powerful.
Then it hit me; I’d used this app a few years ago (back when I used Windows), and it had saved me the trouble of renaming about 300 JPGs that had the always sexy “DSC_000.JPG” pattern. It took me less than a minute to figure out how to use the program, and to get it to work perfectly.
What is bad?
Shortly after the DF post, the always insightful Chris Fahey took up the task of defending Bulk Rename Utility’s UI on the grounds that it’s 100% transparent — it shows you everything, all on one view. While that is an admirable design goal (the best navigation is the least), I don’t know if that’s enough to justify the dense, cluttered interface. Really, there’s just not much defending the application on its UI aesthetics or organization.
But that’s just the thing — in rare cases, it’s actually better to pose a little bit of difficulty and confusion to the user. Not every task we perform on a computer is an easy one, and therefore not all interfaces must be designed to make things easy. Presenting a complex, slightly non-traditional UI to solve a sticky problem can slow users down, and force them to consider each choice before clicking around.
Apple does it
Consider Time Machine. By many accounts, this is a terrible looking interface — it’s garish, cheeky, somehow reminds me of MS Bob, and looks absolutely nothing like what I’ve come to expect from well-designed OSX applications. But it’s wonderful, and a perfect UI for the task of restoring lost files.
File restoration is a very critical task — if you screw up restoration, you’re most likely screwed. As such, Apple went to great lengths to make you a bit uncomfortable, out of your normal environment, and focused on the task. The Time Machine interface blocks out all other apps, puts you in a fully single window mode of working, and you can only do the task of browsing through old files for restore. It works wonderfully because it’s different, and a bit clumsy. It slows you down so that you can make a considered, correct choice.
But bad is kinda bad too
Of course, you just can’t use this as an excuse for bad design — only in certain contexts (backup, bulk rename, system restore, syncing, etc.) is it useful to slow the user down. And even then, there’s room for good design. Apple’s Time Machine, while not my visual cup of tea, is thoughtful, well presented and considered. Bulk Rename Utility, not so much — there’s room for improvement.
In a follow up post, Gruber unintentionally reveals there’s never a simple recipe for design:
If your UI even vaguely resembles an airplane cockpit, you’re doing it wrong.
Of course, the complex interface of an airplane shouldn’t be anyone’s goal — unless you’re designing controls for an airplane! Context and use-case matter immensely, and must shape the overall design of a product or interface. While file renaming isn’t insanely complicated, it’s also a non-trivial task, and surely not as straightforward as a UI for a word-processor. Different use cases require different, sometimes unaesthetic design solutions.
In the end, Bulk Rename Utility probably won’t win any design awards. It did however, get a great design discussion going.
5 Comments
Dan Hallock
Dec 3rd
“Of course, the complex interface of an airplane shouldn’t be anyone’s goal — unless you’re designing controls for an airplane!”
There was a 2004 study by the University of York which suggests that complex, cluttered airplane cockpit UIs led to dangerously high reaction times, and that airplane cockpits with better UIs could reduce accidents and make the skies even safer. Just sayin’.
As far as BRU is concerned, it seems to me like you’re trying to turn “good enough” into a virtue. Does it get the job done? Sure, as long as the job fits into a narrow set of requirements. But is this because the developer thought it through? No. It’s quite evident that this is a thrown-together UI. They stopped at “good enough.”
There may be valid reasons for a UI to slow you down, but being cluttered and unapproachable is rarely the right way to do it.
(UIs for word processors don’t strike me as straightforward either, but I’ll leave that for another day
Matt
Dec 3rd
@Dan: Great points all. I was fearing someone would bring up that airplane study
I’d definitely say that *any* interface can use as much work, refinement, and fresh thinking as possible. There’s no defense for giving up, just because it’s hard, and no excuse for throwing things together.
Considering airplane controls, more refinement and user centered design could definitely make things easier, and safer (bad system and interface design may have been responsible for the the 3 mile island incident). But still, flying an airplane is complex, and any UI will not be immediately understandable, at a glance, to a novice.
Still, my larger point is that design aesthetics (look, balance, visual organization, symmetry) aren’t always the top priority — how they dictate and affect use given the problem matters greatly. In the context of something complex (renaming, backup, etc), I don’t see it as a universal case of “bad design” if something is complex and takes a longer to understand. BLU isn’t something I’d defend as great design (I think it can be improved), but it’s not bad simply ‘because it’s ugly’ looking at it in a screenshot.
Consider iMovie 08 — it was a radical departure from previous video editing apps, and greatly reduced the complexity to make a simple movie. However, I find it still very hard to use and also damningly limited (adjusting the time of cuts and fades is incredibly annoying).
Making a video is just a hard problem (combing visuals, time, audio, storyline, pacing — it’s just tricky), and deserves a powerful, and likely more initially intimidating interface.
In the end, I just think that simplicity isn’t pinnacle design goal — it’s the tool giving you the ability to do the given task correctly.
Dan Hallock
Dec 3rd
“BRU isn’t something I’d defend as great design (I think it can be improved), but it’s not bad simply ‘because it’s ugly’ looking at it in a screenshot.”
Ugly doesn’t equal bad UI, but there’s a high degree of correlation. In this case I’d say it’s ugly and it’s bad for the same reason; because everything was jammed on screen without really dealing with consistency or clutter or approachability. And, of course, without thinking through the logical next step of an interface like this, which is “what happens if the user wants to do one type of operation twice?,” or “what if the user needs more than one of these operations but they need to reverse the order?” I think that’s what epitomizes the problem with this design for me: it allows a multi-step process, but then it defines the order and type of the steps. That’s no better or less limiting than using a “wizard” or the like, and compares terribly to the interface of its competitors.
I guess what I take issue with in your premise is this: “in rare cases, it’s actually better to pose a little bit of difficulty and confusion to the user.” … and this: “yes, it looks like hell at first glance, but it also looks powerful.”
Powerful is useful, and power tools don’t have to have great UIs to succeed. I think we’re in agreement to that point.
But I don’t think it’s ever better to make things difficult or confusing. When you’re trying to slow down the user because they’re going to do something dangerous, you want to minimize confusion and provide _perfect_ clarity on what’s about to happen. The only place I will agree that a confusing interface is a good thing is in a puzzle game.
Matt
Dec 3rd
@Dan:
I get what you’re saying, I do. I don’t like the cop out line that “bad is good” in regards to design and that’s not what I’m trying to argue. Design should always be about exploring everything possible, to come up with the best solution to meet all needs goals, etc.
But I do think that slowing users down, making them consider a choice thoughtfully, is an important design variable. You don’t have to slow them down by being ugly or badly considered, but it’s an interesting and very important dimension to interaction. That’s why I brought up Time Machine as a positive example — it slows you down on purpose, because it looks funky and the UI is highly animated (and therefore ‘slow’ itself). It’s not hard to use per-se, but it’s not immediately familiar, and this helps the user think more clearly about the task (file restore).
Great comments though, I like this discussion.
Matt Dawson
Dec 3rd
It seems like there are really two issues being discussed here:
The subjective clarity of a UI at specific nodes in the application and
the larger decisions about how an application will flow from one task to the next.
I don’t think anyone could argue that “clarity” is a lofty and worthwhile goal. Also, in my experience, it tends to be easier to reach consensus about when something is “clear” or “unclear” then it is to reach consensus about something being more or less usable.
On the issue of application flow, Josh Gruber actually started a very similar discussion a few months back, except that was focused on an iPhone app. The interface was similarly (and in my opinion, unfairly) maligned for much the same reasons as the interface you mention here.
http://www.37signals.com/svn/posts/1128-learning-from-bad-ui
Apple is in love with “stacked in time” navigation. A lot of the time, it works. But I find myself just as often infuriated by their decision to stick to the deep-and-narrow flow approach.
My larger point: I think this piece of UI design is more a matter of preference than a matter of finding the objective “best solution” to a given problem.