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.

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.

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.

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.

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