Tag: User Interface

Others have commented on how the style of the iTunes 5.0 interface is different than any other Mac OS X 10.4 “Tiger” application. What’s more interesting to me is the contents of the new interface.

They finally added groups! I mean, folders. But they kept most of the wacky, colorful smart groups, I mean, sources, from 4.9:

Xcode iTunes	iTunes Xcode

All of this leads me to rule #1 (No, not that rule #1!):

Any sufficiently advanced Mac OS X application is indistinguishable from Xcode.

One problem I had tonight trying to set up an Xcode project for my previous post was in trying to set up the embedded framework.

The instructions on Apple’s Web site, Creating a Framework: Creating a Private Embedded Framework, are good as far as they go.

They say to add your embedded framework to two build phases in your application’s target. First, the Frameworks & Libraries phase, which makes sure the framework gets linked properly. And second, the Copy Files phase that copies the framework into the application bundle.

Now, the instructions emphasize that, for step one, you have to drag from the Products node, not the Target node. But they don’t emphasize the same thing for step two. I tried to accomplish step two by dragging the framework icon that was now in the Frameworks & Libraries phase into the Copy Files phase.

What I was expecting this to do was put a second representation of the framework in Copy Files. What it actually did was move the framework representation from Frameworks & Libraries to Copy Files. This gave me the impression you could only have one framework representation in your build phases – maybe putting it in the Copy Files phase was enough, it would automatically link it? (Nope.)

It turns out that if I’d dragged the framework from the Products node again, I would’ve gotten the framework representation duplicated in both phases. But what I also found, from playing around with it, is that starting the drag from Frameworks & Libraries, then holding down the Option key, turned the drag into a copy drag (cursor turns into a green plus sign), which has the same effect.

A copy-drag?? I complained here about using a single tree to represent a series of unlike objects. But this is even worse; unlike objects that look exactly the same. The same framework icon appears under the project sub-tree and the Targets sub-tree, but it represents two fundamentally different things – an actual file versus a build phase value. Which means different drag behavior. Even though they look exactly the same.

This is the second time (at least) I’ve learned a useful UI tip from a Helpful Tiger reader.

Thanks, everyone!

First was the the ability to disable the Preview column. Now, I should have seen that one, since it’s in the regular Finder UI. In my defense, it’s not entirely straightforward how to get to it. You have to be looking at a column view in order to change options about any column view. This is like being required to be looking at a Web page with JavaScript in order to change your browser’s JavaScript settings.

Second was the ability to open a folder from one window in a different new window. Now, Henry Maddocks suggested I use the “always new window” Finder mode, but while that works OK in OS 9, the Finder windows in OS X are just too heavyweight to make that the norm. Now, my case below is better supported by this feature, since as far as I can see it’s something that can only be found in the Help by an explicit search.

Finally, today, a coworker told me about Cmd-tilde. What does this do? It brings to the front the next window in the foremost application. But it’s not in the Window menu of any application.

What do all these features, especially the second and third, have in common? Obscurity. This isn’t something new to X; 9 had its share of techniques you needed to find out from friends or mailing lists.

But X is the new guy, the one getting the ongoing improvements. It has lots of really cool features. So it shouldn’t hide them!

I want every keystroke shortcut and mouseclick/keystroke combination to have a contextual menu item. I want to be able to find out how to do things by exploring the interface, not by reading the help, however thorough it is and well it’s written.

So let’s move on to my next UI pet peeve^H^H^H^H^H^H serious issue.

I open one window, say a column view window, and navigate the filesystem hierarchy to a particular location. I see that location’s contents in the window.

Let’s say at that point I want to see, side by side with the original window, the contents of a location next to the original location. Two locations, same parent folder.

In Mac OS 9, this was trivial:

1. Double-click the folder icon representing the sibling location, and it pops up in a new window.

In Mac OS X, to my knowledge, it is not trivial.

OS X thinks of Finder windows as separate working sessions, not as locations. Each session is distinct, and sessions don’t need to talk to each other.

Here’s the way I’ve figured out to do it:

1. Drag the folder icon representing the sibling location into Terminal.
2. Remove, by hand, escape characters preceding spaces anywhere in the location’s full path.
3. Select the path and copy it.
4. Open a new window.
5. Press Cmd-Shift-G to invoke the “Go to the folder:” sheet for that window.
6. Paste in the full path and hit the Return key.

Now, for locations that are easy to navigate to, this is overkill. Instead, just open a window to the same base location and navigate the same way as you did to get to the original place. But that’s a pain, and inelegant to boot.

Better solution? An “Open in New Window” folder contextual menu item would do the trick.

When you see a foremost window, and a window behind it, you’d think that Cmd-W would always close the foremost window, right?

Wrong.

Switch to the Finder, open a new window, then choose the menu “View” and submenu “Show View Options”. Then, press Cmd-W.

Instead of the foremost window, which is a utility window, closing, the regular window behind it closes.

Utility windows are distinguishable by their smaller window controls, and by their behavior: they float over other windows. They always have a close button, but the keystroke shortcut is never hooked up. You have to click that tiny tiny close button yourself.

Because of the control size, it isn’t hard to distinguish utility windows from regular windows. But during the kind of rapid-fire UI interactions that power users love, it’s easy to accidently treat the Find window of Acrobat Reader 5 (utility) like the Find window for Text Edit (regular). To treat the Palettes window of Interface Builder (utility) like the Catalog window of CodeWarrior’s Constructor (regular). After enough “D’oh” moments, I start to get frustrated, and I slow down.

My advice? Avoid using utility windows whenever they might be mistaken for normal windows, like when they overlap normal windows. Don’t use them when you might want to close them often.

But they can be done right. Have a look at Photoshop, where the utility windows are “docked” to the side.

Uli Kusterer has a response to my Heterogeneous Trees post.

His approach on modifying TADS Workbench for Macintosh – which is his app, after all, so he has some authority in the matter – is a compromise, and I can see his point.

There are some usability benefits to using trees. Trees nodes are easier for the user to minimize, and might be less cumbersome than, say, three separate list widgets stacked vertically in a window. If you make it so the list widgets get bigger as the window gets bigger, then even the spatial arguments I made before hold less water, since the coordinates of the beginning of the lower lists are not fixed, but depend on window size. If you don’t make the lists grow in that fashion, then you’re condemning the user to endless scrolling to navigate lengthy lists, no matter how big you make the window.

Split views are one solution, but I find them a bit cumbersome. You have to click just so on a split control to resize it, unlike the larger disclosure triangles of an outline view.

Well, so how about the Finder’s Info window? It uses disclosure triangles, but I’m dissatisfied here as well. Letting the user have so much control over minimizing pieces of a window’s UI feels sloppy: window-as-accordian.

My ideal solution to this is not to have multiple lists in a single window at the same time at all. Separate the lists onto different panels of a tab view, and make those single lists grow as the window grows. Will that cover all cases comfortably? Probably not, and I wouldn’t be rigid about it, but it’s where I’d start.

While I’m on the subject of UI annoyances…I’m not real happy with the Finder’s column view.

Here’s a test. Make a narrow Finder window, switch it to column view (Cmd-3), and then just…select one of the files in the leftmost column. What happens?

The column you just selected scrolls offscreen to the left to make way for the next column, which is either a list of contained files, if what you’ve selected is a folder, or the Preview column if it’s a file.

Does anybody find the Preview column useful for anything? If I want file details, I will explicitly ask for them, via Cmd-I. If I want to experience a media file, I will double-click it.

My usual workflow is this: select the file, curse that the file has scrolled out of view, and go down to the bottom horizontal scrollbar and scroll the column back into view so I can do whatever it is I originally wanted to do.

Lots of times, that action is dragging the file onto an app to open it; note you can’t drag a file unless you click on its icon or name, which are the first things to disappear when the column scrolls to the left.

Other times, I might want to rename a file. Same deal.

Yes, I could hit the back arrow to scroll back one column. Hm, I should try that more often. But it’s annoying to have to keep correcting for OS mis-actions. Since I find the Preview panel annoying, I think it should be the one to be partially visible if there’s contention for real estate in a Finder window.

On second thought, I think the selected item’s row should get precedence even if it’s a folder, and the column to the right is the contents of that folder. Sure, I understand it’s important to see those contents, but as a general rule, I don’t like that the mere act of selecting something can make it disappear.