waffle

And, perfectly timed, today’s Penny Arcade.

Three weeks ago, I set out to create a new ThisService icon.

I had some reasons for why I wanted to do this: First, the current one, though originally shaped, was really just something I threw together. Recall that the first ThisService product cycle, from idea to beta to icon to 1.0, took two days. It has held up, but in my opinion just barely.

Second reason: the icon used shamelessly copied AppleScript and command-line tool icons. I can get those only in the maximum resolution currently used in Mac OS X, which is 128×128, and when the maximum resolution for Leopard is 512×512 and the thumb rule is to always work, at a minimum, at twice the target resolution (1024×1024), that becomes a problem.

Third reason: I wanted to.

So I started out with a few experimental layouts based on service scripts being ‘bars’. This didn’t turn out half bad as far as looking good goes. However, it demonstrates perfectly the perils of working at 1024×1024. I had fit way too much stuff (not to mention legible text) into that icon. When you shrunk it down to 128×128 (which in the current version of Mac OS X, again, is the biggest icon), it was just a cluttered mess.

I didn’t know where to go with it, so I dropped it for a few weeks. Walking away from a project can be useful. You can approach the problem again with a fresh mind.

So yesterday, I took a new shot at the icon. I realized that even though I don’t think the original icon is a good icon, it works. So the first thing I did was to rebuild the icon again, although using some ideas from the bars. The bars ended up turned into iPhone-app-like blobs; one for shell scripts, represented by the magic #! insignia signifying the start of a UNIX script, and one for AppleScripts. I still didn’t know what to represent AppleScripts with, but after a while, I settled on “tell app”.

I showed this to a few people, and Peter Hosey gave me two bits of feedback: the AppleScript part should use a script icon and the arrows should go the other way. I argued that the arrows go the right way (from the Services menu to the executable and AppleScript icons) since the services generated actually does “call out” to the scripts. He argued that this was true, but that it was nevertheless baloney - what ThisService does is put services inside the services menu. So I created a version where the arrows go the other way, and contrary to the icon I had already created with the arrows in the other order before, it ended up looking better. Maybe because the arrows weren’t the size of Texas this time.

I still didn’t want to incorporate the script icon since I don’t have a sufficiently big version of it. Peter argued again that the largest icon I’d have to make now would be a 128×128 icon, and that by the time I’d need to put out a 512×512 icon, Leopard would be around, and I could use its script icon. I ended up taking his advice on that end, too.

After all that, I woke up today and realized that it’s still not good. There’s a lot of empty space. On a lark, I decided to remove the arrows, blow up the size of the menu item, blow up the individual blobs and place them in a different arrangement. This ends up looking quite nice:

There’s still at least one flaw in there: the center pixels are completely transparent, and thus non-clickable. If you click in the dead center of that icon, you click ‘through’ it. But the icon, on the whole, feels better to me. Services are such an abstract concept that they are hard to think up an icon for. I almost went with the cog wheel, which already means three distinct things in Mac OS X alone (cog wheel + arrow = action/context/right-click menu; steel blue cog wheel = advanced preferences; cog wheel on purple folder/playlist/album = “smart” folder/playlist/album). And to add insult to injury, there’s no name or icon for what I call standard scripts either (scripts commonly, but not necessarily, run on the command line).

Making an icon for ThisService - especially one that looks good, accurately depicts the concepts involved, feels simple, feels like a utility rather than a creative application, doesn’t look cluttered and is usable - is a challenge for me. But that’s what I love about programming, creating user interfaces, writing help books and designing icons: making it great on its own and better when the pieces all come together, and the art of adjusting the pieces and your vision for the entire thing when it looks like they won’t come together like you thought.

Perhaps the best argument against garbage collection is this:

But if I code garbage collected apps, my apps will be slower.

The prevailing opinion about GC is that apps using it will be slower, but there’s nothing that means it inherently is slower. Allocation in garbage collected apps are commonly as fast as stack allocation because the language doesn’t have to hunt for open spots.

But, okay, let’s say GC really does mean a performance hit - the net result in most cases today is usually that it does. My question in return is:

So?

Your app gets a little bit slower and you get a whole lot more productive. Moore’s law will help recuperate that time loss if not during lunch (in most cases, GC really isn’t that heavy) then easily within six months. If you continue to manage memory manually (even with the “semi-automated clutch” approach Cocoa and Objective-C takes), will you get more productive? No. Your apps will run a few milliseconds faster, maybe a few tens of milliseconds faster, and that’s it.

Unless these milliseconds really are critical to you in a documented way, why would you choose “runs slightly faster” above “makes you more productive by being able to focus on other stuff”?

I have written heavy, multi-threaded, efficient, interprocess-communicating, (”mission-critical” if you will) applications in garbage collected languages. What has been the ceiling blocking it from getting faster? Multi-threaded lock congestion. The memory limits of 32-bit Windows. In my experience, once you descend into such heavy use that the cost of GC is becoming unbearable, you’ll start to see the limits of other technologies as well, and dumping GC won’t mitigate the problem.

In two months, Leopard (Mac OS X 10.5) is coming. What’s your plan?

My plan is simple. Once it’s released, I won’t start any project that runs on 10.4 any longer. Once sufficiently many are using it, I’ll start dropping 10.4 support in my apps as I introduce features that need 10.5. If adopting happens as quickly as I think it will, I’m pegging that for spring 2008 (here, I’m referring to the Apple flavor of spring that apparently includes half of fucking June).

The aim isn’t to spit in people’s faces or herd them towards the nearest Apple Store. I appreciate that they use my software. I also recognize that that software won’t stop working just because a newer version is released. It’s entirely possible that people may need a hardware upgrade to enjoy (or even run) 10.5, but the rumored cutoff line is G3 Macs and despite early promises from Apple, most of these systems have been running Mac OS X under less-than-great conditions for a while now.

10.5 will bring great improvements - not only to the ease of which I can do whiz-bang features with animation, which I realize lots of people don’t see the value in, but mainly to the way I can write applications as a developer. I can way more easily debug my apps with improvements in Xcode and the new Xray app, and I can do away with an entire class of potential bugs (one being notorious for containing hard-to-debug crashers) with garbage collection handling much of memory management for me.

There might be a bigger resistance to this if 10.5 didn’t contain very many improvements for people. (This was clearly the case with how some people saw 10.4.) On the contrary, Apple has said that 10.5 is their biggest incremental OS change ever, and after having actually used it (yes, I have a seed key), I see no reason to dispute that fact. Especially not since many of the changes and most of the new features are really useful for everyone - like automatic backup or screen sharing with almost no setup. Some people may face trouble coming to terms with the theory that the honeymoon is over; there’s almost no low-hanging fruit left, and in the face of this, Apple has put together a remarkable update.

So that’s my plan. I really don’t want to cut people out, because I’ve sat there myself a bunch of times, but in the end, I want to do as good and as solid apps as possible, and 10.5 makes that dramatically easier and less time-consuming.