Buried options are irritating. Yesterday, I wanted to switch my external editor in iPhoto from Pixelmator to Photoshop, but had to hunt and hunt for the setting. Here’s the relevant options screen:

Totally obvious where to set it, right? Yeah, not so much. See, I don’t want to switch to editing every photo externally, so clearly “Edit photo:” isn’t what I want, given my mental model of my goal is “I need to change the external editor” versus “I need to change if photos are edited internally or externally.”

Too bad “Edit photo:” is only place the external editor is listed, as part of the drop-down:

Of course, by choosing Pixelmator, it sets the option to edit externally, but also pops up the standard Open dialog to locate the application’s binary. Ugh!

Here Apple has done what they (unfortunately) often do: go for simple over flexible, combining two discrete tasks into a single control. It fails both ways: if I want to just switch from internal to external edit, I get a dialog I don’t need and have to dismiss, and if I want to choose another program, but keep my default setting, I have to change that setting back after selecting the new editor. Would it really have killed them to add another line to the dialog with “External editor:,” a label for the current one, and a “Choose…” button? Nope. Sure, it would have added to the weight of the dialog, but it would have also saved me time in a) not having to remember the wacky, custom behavior of the control, which since seldom used is easy to forget, and saved me an extra step when I need to make a change.

I’ll admit I’ve designed stuff like this before, thinking “Hey, look how clever; I combined related tasks and eliminated a control. Yay!” But you know what happens every time I put something like this in front of users? They don’t get it, and rightly so. They’re not in on my cleverness, which came from , frankly, overthinking. They just want to get their task accomplished. We often forget that when a user sees a piece of UI for the first time, they’re not regarding it the same way we do in a design review, so even (to designers) too-long and too-dense dialogs can be successful, if they get the user from A to B as quickly as possible*. Start doing real user testing, Apple, and you’ll have fewer irritating fails like this one.

*=In fact, I just designed something like this last week. It’s atrociously cluttered, but it’s totally clear what the (complex) task is, and how to accomplish it. We’ll see if users agree!

Repeat after me: Mouse targets should be predictable. Labels should be readable. Seems obvious, right? Well, Safari disagrees on both counts. Today I decided to use Safari all day to see if they’ve made any improvements to the generelly-mediocre UX of the past several versions. Also, Firefox has been absurdly slow lately. After several hours, the most prominent issue is that of switching between tabs. I don’t have a ridiculous number of tabs open usually, but I’m still having a hell of a time navigating between them without pain. Why? Two reasons:

1. The Close button appears on mouseover, so in pointing to the tab, you have to remember that the left ~14 pixels are not where you want to click. Bad for two reasons: the user has to learn a pattern, with the penalty for not the frustration of closing exactly that tab you wanted and cutting into the already too-small tab label right when you really need that information.

2. The tabs resize dynamically. Therefore, there’s no way to predict exactly where that tab went, or what size the target for selecting it will be:

They’ve tried to solve this, but not effectively. Once you get past a certain number of tabs for the window size, you get a little ellipsis icon, and the remaining tabs end up in a menu. Not ideal, but not terrible either. However, with a modest number of tabs in a modestly-sized window, I get no such help:

Firefox (naturally) solves both these problems with little fuss, by keeping the tabs to a fixed size (easy to change with an extension) and showing arrows to horizontally scroll the tab list when there are too many to display comfortably.

“But, you can’t do that in Safari, since there’s no tab bar anymore!” I hear you say. Well, maybe it was a bad idea to get rid of the tab bar? I’ve read that Apple doesn’t do user testing before releasing things, and this is precisely why that’s shitty for their users. This is an obvious problem that would have been caught in the simplest working prototype, but instead we have to suffer with it in a released (albeit beta) product. Since it’s been released, though, it seems highly unlikely they’ll got back on the decision and change it for the final version. Which is really too bad. I love the speed of Safari, but the UX is just too much fail to use it every day.