Column Before the Storm

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.

Just One More Thing…

So if you haven’t been reading the comments, there’s already something similar to what I want out of a file-specifying widget in the standard Open and Save dialog boxes, if you just hit Cmd-Shift-G to bring up a separate little utility dialog.

But I don’t want a separate, after-the-fact solution, sprung on the unsuspecting user like a last Columbo question. I want something integrated.

Speaking of after-the-fact, one thing about Panther that really bugs me is is the FileVault prompt to save space in your encrypted file. There’s no preference in the UI for “always do this,” nor is it part of the “Are you sure you want to log out” dialog box. Nope, it’s just thrown in there after everything else. Instead of making the hard choices of what other UI to change to incorporate this new workflow aspect, they went the easy route: easy for the developer, a pita for the user. I’m both a (picky) user and a developer who tries to do the right thing, so this sort of thing makes my head explode.

Forest for the Heterogeneous Trees

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!

Here’s iTunes:

iTunes left panel, including Library, playlist, shared music tree, and more

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:

Xcode left pane, including source files, targets, Find Results, and more

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:

CodeWarrior window

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:

Workbench for Macintosh window

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.

A Colossal Tease

You’ve heard of text adventure games, also known as IF for “interactive fiction,” right? On my IF page, I mention the (award-winning, natch) games I’ve written, Small World and Rematch. I also mention Colossus, a larger game that was supposed to be the successor, though otherwise unrelated, to Small World.

Most game writers dream of the Big Game, their Magnum Opus: years to write, months to play, a work that advances the form in some significant fashion. An in-depth experience akin to reading a novel, full of fiendish puzzles, compelling character development, and satisfying plot twists. Colossus was going to be that game for me.

I had several ideas about it. It was going to be the IF equivalent of a sci fi blockbuster. I even wrote a “teaser” for it, a mini-game at the start of Dan Shiovitz’s (also sci fi-themed) Bad Machine, released (gulp) going on 6 years ago now. As MacTADS took longer and longer, I thought I would write it in MacTADS once it was finished, using the newer version 3 of the TADS language.

I’m no longer sure that Colossus is what I want to spend the next year or two of my free time on, but hey, who knows?

In the meantime, the teaser’s pretty fun. I may polish it a bit and release it as a tiny standalone game, but the joker is that I’d need to use my old, Classic-only, unfinished MacTADS tools to do it, since TADS Workbench for Macintosh only supports TADS 3 currently. Such is life!

And, please, don’t laugh at the “Fall 1999” release date, OK?

Blinded by the Spotlight

Pretty much a year ago, I wrote this post, and then this post, about downloading Apple’s mailing lists in order to be able to search them better.

What I didn’t do was go the rest of the way and make up a Search Kit-based application to allow for robust queries into all that downloaded data.

Well, there’s good news, and there’s bad news.

The bad news is that I’m never going to get around to it. Hey kids, welching on your promises can be fun!

The good news is that Apple is going to do my work for me in the upcoming Mac OS X 10.4 a.k.a. “Tiger”. Spotlight even uses Search Kit, just the way I would have. The small, individual text files that make up the mailing list download will be ideal for Spotlight.

So now you have something to look forward to. In the meantime, did you notice the new mailing list search UI at It seems to be faster, more flexible, and return better information. As a Web app, it still may not do the thorough indexing that Spotlight would do locally, but it’s available today.

That should keep you out of trouble while you’re waiting for Tiger.

File Imprecations

There’s no dedicated widget in Cocoa for specifying and displaying a file.

Both Cocoa and Carbon apps tend to cobble together custom UI for the task. A “Save” or “Open” button that triggers a Navigation Services dialog, plus a path text field, and sometimes an icon. Apps tend to be internally consistent – CodeWarrior uses the same aggregate widget everywhere, for instance – but none of them quite match each other.

Cocoa apps often do let you edit the path by hand. It seems to me that this reflects the greater NeXT reliance on the command line, and I can see the utility of it sometimes. But I dislike the potential to erase a path by hitting the delete key by mistake. It also seems to me that this sort of thing is better suited to developer apps, where the user can more safely be assumed to have command line expertise.

Carbon apps, with the old Toolbox deprecation of file paths, generally never allow users to type in the path of the file they want: you must use the Open or Save dialogs to specify the file, though the application might then show you the path afterward.

I can actually see something in-between: maybe in the Save/Open dialog, there is a text field, which reflects the full path of the file/folder you’ve currently chosen. You can type in it, and once a name matches, the Navigation Services portion of the dialog moves to that location specified by your typing. Maybe that’s overkill, but it is the kind of marriage of command-line and UI that I’d really like to see. Toss in tab-completion, and you’re all set!

I’m thinking about this because I’m thinking about how I would modify the UI of TADS Workbench for Macintosh if (more like when) I decide to take over its maintenance. I had my own widget in my Isthmus framework to specify and show a file – I even had a specialization of that widget to deal with special file paths, like the “{Compiler}” and “{Project}” paths in CodeWarrior. I will either have to redo that work for TADS Workbench, discard the concept completely, or – most likely – figure out a more scaled-down version. After all, it was trying to make things perfect that doomed Isthmus.