Sibling Rivalry

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.

If I Can Make It Here…

It appears that I’ve given up one ancient codebase for another.

No more am I writing a framework that supports System 7 and is built using Classic-only legacy tools.

Instead, as part of TADS Workbench for Macintosh, I am now employing someone else’s codebase, a port of the text-based TADS utilities, that supports 15 often elderly variants of Unix, and is built by the even more ancient makefile system.

Did I think I would no longer be involved with a 68K platform? Wrong!
This project supports such discontinued 68K platforms as Sun3 and the NeXT Cube.

Good grief, it even supports the otherwise forgotten IBM RT workstation.

How does it support all these platforms? Well, since they’re all Unix, they share most of their APIs.

But the differences, and how the project deals with them, are the interesting part. Interesting enough to fill more than one weblog post.

I’ll start by talking about the makefile.

There’s only one for the whole project, but this one file has different sections in it for all the platforms. Script-specific variables are defined, but commented out, in each of those sections.

The particular values you uncomment are then used to build your desired platform’s version of the tools.

Not unusual for this sort of thing, but in one of the explanatory files, the maintainer mentions that it could be done better, more automatically.

Investigating this a little further quickly led me to the book GNU Autoconf, Automake, and Libtool, which I will be looking into.

Before I go to do that, though, I’d like to mention one detail. It turns out that, for TADS Workbench, I’m both building the whole TADS tools via the makefile and also building just a few TADS source files into my GUI IDE application via Xcode.

Xcode doesn’t use makefiles, so I can’t reuse the settings from that makefile, and instead have to specify them a second time in my Xcode project.

Wouldn’t it be nice if all the build flags could be assembled in just one place where they could be used by both the makefile and by the Xcode project?

It appears that it is possible, by using the gcc flag -include in your makefile. You specify e.g. the defines.h file there, and then also use that same defines.h file in, for example, your Xcode target’s Language panel as the prefix file. I just tested it with a sample project and makefile, and it works.

This doesn’t seem to be the usual strategy. (Nor does it handle linker flags.) I’m curious whether autoconf and friends even accommodate it.

We’ll see.

Sound of Silence

I have enough feeds now, in NetNewsWire, that I didn’t notice when a couple of them went silent.

Some bloggers just stop posting…ahem, not like anybody here. So when I scanned the lists of feeds, day after day, a few quiet ones seemed normal to me.

But upon going through the feeds manually, I discovered that their Web sites still had lots of new posts, but I wasn’t getting them. In each case, this was due to the feed URL having been changed.

If I recall correctly, there are ways of specifying redirects to new feeds. I don’t know if any of these sites actually did that. Certainly the last posts that I did receive from them didn’t mention it, so maybe it was due to some adjustment in the blog service they were using that even the authors didn’t know about?

I do know NetNewsWire doesn’t seem to have UI to show me that sort of information, if it’s returned at the HTTP level. It has a “dinosaurs” page, but that just tracks the last time it thinks people posted, not if it got an error message from the server. Or, more accurately, I did see error messages from some servers in the Errors window, but that seemed to be for more usual kinds of errors – server isn’t currently responding, etc.

Hm, looks like one of the bloggers might have manually changed her feed due to problems. That would explain it.

The manual run-through works for now, since I have less than 100 feeds, but what if I get to 500? 1000? I would hate to lose posts from weblogs I find interesting, though I suppose if I get over 1000 feeds, I won’t have time to read them all, anyway.

You’re Soaking in It!: MarsEdit

Considering I’ve already paid for NetNewsWire, it didn’t make much sense that I hadn’t downloaded MarsEdit.

1) It’s free for NetNewsWire users, but only for “all 1.x versions.”

Being upfront about future charges, unlike the Bare Bones‘ switcheroo from BBEdit Lite (free) to TextWrangler (not free), is the right approach in my book.

2) It supports the weblog publishing system I’m using, though there does appear to be some missing functionality.

3) It has the conveniences that local applications usually have over Web applications, such as local saving of documents, easy maintenance of multiple windows, and dedicated UI.

This will be my first post written in MarsEdit, so let’s see if it works!

Update: There were some technically difficulties, as evidenced by the multiple posts, lack of category, and some formatting errors, but it seems to be going better now.

MarsEdit’s Help is exceptionally detailed for a beta application, though of course I didn’t turn to it at first!

There’s also an interesting combination of document-based and non-document based user interface. Each post is like a document, but there’s also a main window, for seeing all the post “documents” and managing your weblogs. I believe Brent Simmons refers to it as the “email model.” Still, I don’t yet equate multiple weblogs with multiple email accounts. Maybe it will after I use MarsEdit enough.

An Elementary Audigone: Watson

As noted in the comments of my first Audigone post, I forgot a very prominent Audigone, Karelia Software‘s Watson.

Watson is the real deal: sold for money, confronted with new features in Sherlock 3 (10.2 Jaguar) that did similar things for free, and now cancelled. See this 9/02 O’Reilly interview with chief architect Dan Wood for details.

The partial good news is that Dan Wood was able to get some money for the technology from Sun. The bad news is that Sun appears to be sitting on the technology, so a new cross-platform product based on it may not appear soon. The other good news is that Karelia is apparently working on something new.

Now, it’s interesting to note, Watson was cancelled because, to keep up with the outside service providers, Dan Wood would have had to spend ongoing effort updating Watson. Contrast that with other utilities I classify as almost-Audigone because they’re still technically supported, but “support” means at most doing a dot update for each new OS release.


The made-up word ‘Audigone,’ according to timestamps, was first used in this Forward Address: OS X post, as a way of describing the cancellation of Panic‘s commercial MP3-playing application Audion in the face of competition from Apple’s free iTunes.

The entertaining history of Audion makes me wonder how many other inspiration stories there are out there of…uh, Apple mercilessly crushing its independent developers.

So, despite the fact that it’s not my word, I am hereby defining ‘the Audigone’. In order to qualify as an Audigone, something must be:

1) sold for money.
2) confronted with a rival Apple product.
3) discontinued because of said product.

Added points for going out with a spirited fight. Subtracted points for bitching hypocritically about Apple during your concession speech.

While I believe there are many Audigones, the only true Audigone so far publicly revealed to me is Audion itself.

But because there’s nothing else to talk about, I’m also christening the ‘almost-Audigone,’ something that just misses being an Audigone by conforming to only 2 out of the 3 requirements.

Here is a list of almost-Audigones:

Internet Explorer
Competitor: Safari
Not a true Audigone on account of its freeware status, and minus points for whining about not having access to OS internals (!). But I suppose it stands to reason: isn’t giving up what Microsoft wishes its browser competitors, like Firefox, would do on the Windows platform?

Competitor: Safari
More of a real Audigone, since it’s sold for money. But not cancelled! After a disappointing demand from the CEO that Apple license Opera (!), they decided to fight on. I was very impressed by Opera as a stripped-down, fast browser on Windows in 1997, and I’ve paid for Mac Opera, but I must say it hasn’t impressed me enough to use over Safari. They’re fighting the good fight, but they’re also depending on other platforms for their revenue.

LiteSwitch X
Competitor: Heads-up Application Switcher in 10.3 Panther
Kudos for their spirited counter-attack: “Dear Apple: You forgot some important features,” and for continuing to sell the product, though that does disqualify them from being a full Audigone.
Boos for the unprofessional open memo asking for official recognition from Apple for “their idea.” The idea that the idea was solely theirs is demolished effectively by Daring Fireball. If they’d stuck to “features,” I might have paid out of solidarity, like I did for Netscape 4.

Competitor: Dashboard
As with LiteSwitch X, Konfabulator’s creator accuses Apple of copying their idea, and once again Daring Fireball assumes rebuttal duty. As with Opera, they will try to make their money on another platform. Should I include “concentrating on Windows” as an alternative to 3)?

Honorable mentions on the almost-Audigone list include Power Computing and all the Macintosh clones (cancelled due to license termination, not product competition) and UserLand Frontier (pretty much killed by AppleScript, though its technology lives on in Manila and other UserLand products and will be (has been?) open sourced).

I’m sure I’m missing a bunch of Audigones, both real and almost-. So remind me!

–And expect a real Audigone story from me in a few days.

Window of Opportunity

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


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.


I recently downloaded the Half-Life 2 Gameplay Video via The extended combat sequences with guns and various vehicles, and the way both your friends and your enemies act in them, impressed the hell out of me; I felt like I was watching a movie. But the narrator for the video makes the point that this realism comes at a price: vastly complicated beta-testing.

This ties in with my own experience writing the FPS’s lowly, humble cousin, the text adventure a.k.a. “interactive fiction” game. Even in an IF game, where the player can’t shoot at whatever square meter he wants to, but instead is relegated to a relatively small selection of verbs and nouns, there are far too many possible combinations of actions to try them all yourself. Even for a small game, you need beta-testers – as many as you can find.

This need exists with any development, but for some projects, it can be ameliorated by Test-Driven Development practices. You think up the relatively small number of outcomes you want, and you make sure that you always get them.

With games, the challenge isn’t consistently trying out the small number of desired outcomes, but testing – and even thinking of – the vast number of cases that derive from those outcomes, and making sure they all work, too. And “work” is tricky, for IF games. You can’t just test for the right numerical output. You’re trying to make sure the text not only make sense, but is well-written, consistent, and is pitched just right for the times it’s going to appear.

This is why you need not one group of beta-testers, but two and even three groups. The first group tests out your initial game, the stuff you came up with with no outside help. Those really cool ideas that drove you to start writing it in the first place. These beta-testers will give you the first dose of sanity, and point you in fruitful new directions.

But at some point, these testers will have become too familiar with your ideas. They won’t be able to react like your real players will: confused at the confusing places, intrigued at the mysterious places, surprised at the surprising places. You need a second group to get fresh impressions of how well your ideas are working. You can’t mechanize that.

And ideally, once they’re done making sure your game is going well, you need one last group to judge the final result and catch any remaining erroneous details. Many games have that one last prominent bug because nobody saw the final changes with fresh eyes.

How about a fourth, a fifth, a sixth, a hundredth group? Nah. Beta-tester after beta-tester, your game will still have bugs. Beta-testing is the antidote to perfectionism.

Heterogeneous Trees, Part II

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.