When you’re holding a hammer, everything tends to look like a nail.
Similarly, it seems, when you’re writing an app for Mac OS X, complex UI problems tend to look solvable via an outline view. Don’t do it!
Most people think of the left pane of the main iTunes window as a simple list, not a tree. But as you can see, with the addition of shared music, now it at least includes a two-level tree.
Inverting the capitalization pattern, here’s Xcode, a rather longer example:
Now, what problems do I have with these examples?
The first problem is the “which one of these is not like the other?” riddle. Many of these aren’t like the others, but they should be. My belief is that a single outline should consist of homogeneous hierarchies, like the file system objects in Finder windows or the songs in a playlist. This simplifies the user experience and leads to a cleaner, less cluttered UI.
The second problem derives from the first. In Xcode, for instance, to get to the Targets, you need to get below the project’s groups & files hierarchy. But that hierarchy is a variable number of rows long: every time you open or close another group, you change where you have to click to get to Targets. Same with Find Result: any group you open or close above it shifts its position, making it more cumbersome to get to.
iTunes, with shared music, is even worse. Where you have to click to get to your playlists depends on what other users are currently on the local network!
CodeWarrior, which has to deal with a similarly large amount of complex information as Xcode, does this in what I consider to be the right way, by separating the different trees:
Each tree is homogeneous, so the user doesn’t have to manually navigate around unrelated UI to get to what he or she wants. For example, Targets as always easily accessible. Muscle memory can do its thing.
Now, is there no value to doing it the other way? I wouldn’t say that. Some people probably like not having to switch panes to get to all that information, and certainly the whole muscle memory/spatial Finder concept isn’t in the ascendancy right now.
But if you agree with my reasoning, then hear my plea: just because
NSOutlineView is easy doesn’t mean, for your own apps, you shouldn’t take the extra time to put together appropriate UI to show complex data to the user. Look at CodeWarrior for what I consider to be some good examples of this. Just remember: keep unrelated lists and trees separate, don’t lump them together as nodes of a larger tree.
One last example. Here’s TADS Workbench for Macintosh:
This is the app I’m going to be taking over maintenance and updates for, probably in December. Yup, it’s got the same heterogeneous tree behavior as the other apps I’ve mentioned. In my book, what should be separate lists of, respectively, source code files, folders, TADS 3 library files, and language constants, are lumped together in a big ol’ tree.
I won’t be able to change Xcode, and I certainly won’t be able to change iTunes, but I can still strike my own little blow against heterogeneous trees.
One thought on “Forest for the Heterogeneous Trees”
While I don’t agree with all of Xcode’s UI design, they way it displays targets allows you to compare multiple targets fairly easily. It’s been a long time since I’ve used CodeWarrior, so I don’t remember how it deals with this… I’ve just been spending too much time looking at Xcode target settings lately 🙂
Comments are closed.