Have you ever noticed how faulty the brain’s mechanism for detecting “freshness” can be? If you’re anything like me, you find yourself foolishly clinging to the belief that something is new, long past its certain staleness. For instance, I still think of The Cure’s Friday I’m In Love as “their new song,” almost fifteen years after its release.

The same mental bug appears at more depressing moments. We might spend a decade feeling essentially the same about our health and vitality, until we look into the mirror one groggy morning and see a particularly aged face staring back at us. Before we know it, we’re yesterday’s news. So it goes with pop music, our bodies, and with the computers we use every day. Having fun yet?

While I was working at Apple, I had the privilege of contributing to the transition from Mac OS 9 to Mac OS X, as a member of the Core Services group. At that time, there was no doubt in anybody’s mind that Mac OS X was new. It was so new in fact, that for a long time nobody took it seriously. As pre-10.0 developer previews rolled off the line, Mac OS 9 loyalists insisted that it would never supplant their favorite operating system. Mac OS X was just some newfangled thingamajig that the crazy kids were playing with.

Then lots of years passed and, lo and behold, almost nobody uses Mac OS 9 anymore. I was using Spotlight to try to track down a copy of Resorcerer, when I stumbled upon this old folder full of aliases, in an old backup directory from a home computer when I was still on Mac OS 9:

What is this list of sundry items? Well it’s the folder of aliases I put in my Mac OS 9 “Apple Menu items” folder. The quick-access list of items that I could easily access at any time. Now, I’m not sure how accurate this list is as a reflection of my everyday application usage. At this time I was probably using Nitin Ganatra’s excellent Malph utility for most of the same purposes. I’m also not sure how much different my work machine’s list would have been. This was my personal machine at home, which I obviously used to some extent for work development. What strikes me today, looking back, is that almost every one of those applications has been supplanted by something else. They were all very appropriate to my computer life only 5 or 6 years ago, but now many of them are ancient relics.

Let’s go through each of them and figure out what used them for then, and what I use now to achieve the same goals.

BBEdit. To be honest I’ve never used BBEdit as my 100% full-time editor, but it’s almost always “been around” in one form or another for something important. At this time, I probably was using MPW for most of my text-editing needs, but would occasionally open up BBEdit to do some particularly advanced search & replace, or to sort by columns or something. I still use BBEdit largely in this capacity, though one of the major ways I use it these days is as a file comparison tool (I find it more reliably with strange line endings than Apple’s FileMerge application).

CyberStudio. I can’t remember whether this application was called “GoLive” at the time, but I’m pretty sure it was. Adobe had come to Apple for one of our irregular (at the time) beer bashes and offered us free copies of the app. I used it to design my personal web page for some time. Eventually I switched to Macromedia Dreamweaver, which I used for a few more years, before finally relying mostly on manual CSS editing.

Fetch. For a long time, if you wanted to use FTP from a Mac, there were really only two choices: Fetch or Anarchie (now Interarchy). I dabbled in both but mostly found myself using Fetch for the rare occasion on which I needed to push files. These days, I tend to use Fugu for uploading to my SSH enabled servers. It’s got a lot of rough edges, but it’s free and basically functional. If I needed to do more file transferring, I’d probably use Transmit, like everybody else.

Internet Explorer. I remember sitting in the lab at Apple, as a QA Engineer in 1996 or so. Everybody was still using Netscape Navigator, but this new Internet Explorer was grabbing our attention. My, it was a nice upgrade at the time. IE came with us to Mac OS X in the early days, but of course Safari eventually came along and proved an easily superior alternative to the aging IE.

Microsoft Word. Like everybody else in the world, I had to keep a copy of this app around just to be able to reply to the emails from marketing or whatnot, which were inevitably in Word format. These days the popularity of PDF has gone a long way towards eliminating the need to use Word as a generic document format. I do think Word can be a pretty nice word processor, but when I wrote the thesis for my BA in Music in 2005, I used Apple’s Pages with a good deal of satisfaction. It’s what I would use again if I had to do any substantial amount of non-blog writing at this point.

MPW Shell. At this time, most of the Mac development world was using CodeWarrior for day-to-day development purposes, but in my group at Apple everything was still tightly bound to MPW. It made up my editor and source control management (projector – yuck!), with MacsBug serving as the debugger. These days of course, it’s all Xcode and GDB. I miss some things about MPW, especially the highly (and easily, compared with Xcode) customizable menus. And I miss some things about MacsBug. But on the whole, Mac OS X in 2006 provides a much better environment for development than MPW on Mac OS 9 did.

NiftyTelnet. When I first worked at Apple in 1994, I was bit of a freak to my coworkers. In those pre-OSX days it was rather uncommon for anybody at Apple outside of the A/UX group to be interested in telnetting to a UNIX machine. But I had just come from UC Santa Cruz, and was tied up in a certain amount of command line computing lifestyle there. For instance, I wanted to be able to check my email. I’m not sure what I used in those earliest days. Possibly ZTerm? All I know is as life went on I still had the occasional need to connect back to my school’s alumni server, and eventually it became NiftyTelnet with its SSH support that best served the purpose. Of course on Mac OS X I still do quite a bit of ssh connections, but it’s almost always through the standard command-line tool that ships with the operating system.

ObiWan. Oh, ObiWan, how I adored you! This utility was like my third arm during those years. It served as a comprehensive, instantaneous reference for the Mac OS API. The touch of a hotkey would present a floating window. Type the name of the API to see the prototype instantly. Another hotkey pasted the prototype directly into your code. Of course, we get more or less comparable behavior for free nowadays in Xcode, but I’m amused to see that ObiWan was in fact ported to OS X, renamed WanObi, and is available for download through the Stairways FTP Server.

Outlook Express. I don’t really remember using Outlook Express, but this snapshot must have caught me at least dabbling with it. I was interviewed by Tim Gaden about my mail habits, and neglected to mention this in my history. All I know is that I use Mail now and have consistently for the past 6 years or so. It’s not perfect but it gets closer than anything else I’ve tried.

Pro Tools Free. Digidesign made the incredibly cool marketing move of giving away a free version of their venerable recording software. I used it for my hobby of songwriting and (very!) amateur recording. The marketing worked: I was hooked on Pro Tools and convinced that I would hate using anything else. Unfortunately by the time I wanted to upgrade to something more sophisticated, Pro Tools had not finished their OS X support, but MOTU had. I bought a MOTU 828 and switched to their free version of Digital Performer, called AudioDesk. These days I’m just as likely to pop open GarageBand if I feel like playing around with some recording.

Radar. Radar is a private Apple application for interacting with the internal bug database. You know, I really had a love-hate relationship with that application, but I would love to be able to use it again, instead of the frustratingly limited web-based version that we’re forced to use as company outsiders. It was a lot better than many of the open source and commercial options I have been subjected to by the various projects I’ve worked on over the past few years. For my personal projects I don’t use anything more formal than a series of conventionally named text files, but I keep meaning to remedy that.

ResEdit and Resorcerer. These were the two options for editing resource files, which was an essential part of any Mac development effort. These days I still use Resorcerer from time to time because I’m unlucky enough to have legacy projects which require resource fine-tuning from time to time. But for the most part, their use has been replaced by Interface Builder on OS X, which lets you lay out interfaces in a much more intuitive way. The feature I miss most from the resource-editing days is the ability to store arbitrary hex data, while allowing for extensible editing via template definitions. Interface Builder is pretty frustrating when it comes to storing anything non-standard.

SoundJam. Those of you who have been around a while remember that SoundJam was one of the early MP3 Playback offerings on the Mac. It was the one I ended up using, and I still use it today, it having been purchased, rebranded, and massively expanded on by Apple as the iTunes we know, love, and hate today.

I’m sure there were lots of other applications that played a role in my day-to-day work at the time, but these just happened to be the ones that were in my Apple menu. They must have been important to me then, and I’m impressed to see that very few of them are very important to me today. I wonder how the application landscape of my computer will change over the next 5 years.

A FlexTime customer recently asked me if there was any way to set up a routine such that each activity in the routine would take a random period of time. His interest was in having FlexTime remind him at irregular intervals to stay focused on the task at hand. Unfortunately, the short answer is “no.” FlexTime currently relies on having a specific time set for each of the activities in a routine. But as is so often the case, the long answer is “yes, sort of. kind of.”

This is another instance where the presence of a robust AppleScript implementation allows me to offer at least a passable solution to the customer. By writing a script that configures a new document with a random arrangement of activities, and then runs it, it approximates the desired experience of being able to have a single document that runs differently each time it is run.

FlexRandomTimes is a standalone applet that can simply be double-clicked to start playing a routine with random timings. You can place it in your dock or Finder sidebar for easy access. It can also be opened and edited with Script Editor to suit your particular needs. All of the “easy to change” settings are near the top of the script. For instance, if you want more than 20 randomized activities, just change the setting of “kMyNumberOfRandomActivities” to suit your needs. Likewise for the randomness range and for the sound that should be played on each activity.

A particularly advanced move would be to merge this script with some of the logic from FlexTime Random Sounds to get an especially randomized experience.

Anybody who’s ever taken a public speaking class, in high school or college, remembers the strict time considerations that were placed on speech assignments. I remember mine, at City College of San Francisco, where the instructor would sit in the back corner of the room with a stopwatch around his neck. At the beginning of every speech he would start the timer, and any deviation from the assigned time of the speech would cost you serious points. I believe in my class it was a full grade reduction if you under or overshot the target by something like 30 seconds or a minute.

After I finished developing FlexTime, it occurred to me that it would have been the perfect tool to practice my public speaking assignments. By building a FlexTime routine comprised of different “activities” for each of the note cards comprising a speech, you could fine-tune the timing of a speech down to each specific topic and point. FlexTime text cues would make perfect reminders that it’s time to move on to the next topic. Each time you practiced the speech, immediate feedback from FlexTime would let you know whether you were getting more or less on target for the ideal timing.

It’s been years since I’ve given a formal speech in any context, so I haven’t had a chance to put this particular use case to the test. Geoff Pado is a young Mac software developer who also happens to be taking his high school speech class this year. Faced with a speech that needed to be at least 5:50 but no longer than 6:10, he decided to put FlexTime to the test. The results were glorious, as he describes being able to hit the target with very little practice. That’s a very tight window of time, and I’m sure most of his classmates weren’t nearly as successful at meeting the requirement.

Another weird success story for FlexTime!

Resolution independence is the notion that all graphics on a computer display should be zoomable to an arbitrary multiplier without losing quality. If you know even the slightest thing about computer graphics, you’ll understand that in a resolution independent world, bitmaps are out and vector graphics are in. Vector graphics can scale gracefully to an arbitrary resolution, while bitmap graphics inevitably lose quality.

Bitmaps specify a graphical image as a grid of colored dots that, when combined at high enough resolution, may create the illusion of a photorealistic image, or a smoothly curved contour. For the time being, we’re stuck with grids of pixels, because that’s how our monitors and (most) printers work. Over the course of computer history, bitmap graphics have gotten larger to accommodate increasing display resolutions. For instance, icons “looked fine” in Mac System 7 at 32 by 32 pixels, because most monitors were not more than 640 by 480. As monitor sizes grow, the standard sizes for icons and other graphics grow along with them. Suddenly the System 7 icon looks like crap when forced to participate in this modern world:

So, MarsEdit pretty, Resorcerer ugly, right? For now, anyway. Time marches on, and one day we’re sure to find ourselves struggling to appreciate the relatively low resolution of the MarsEdit icon, too. Look what happens if we quadruple the resolution (caveat, this is from the screen capture, not necessarily from the highest quality available in the MarsEdit bundle):

Suddenly the cracks are beginning to show. So what’s the big deal? Can’t we just continue to improve image quality as resolutions increase? We could, except that the limits of resolution are about to be completely blown away. Resolution independence will debut as a user-level feature in Mac OS X (and Windows Vista, as I understand it) giving users the ability to choose the resolution at which they wish to view any graphics on their screen. Apple has a few documents on this that are worth reviewing

• Resolution Independent UI Release Notes
• Carbon Resolution Independence Notes

What this means for developers is that every piece of bitmap graphics in your application is now liable to be zoomed to such a degree that it looks like ass. How much like ass? You can get a sneak peek at how well your graphics survive resolution independence by using a little-known feature of the Quartz Debug application (part of developer tools). Select “Show User Interface Resolution” from the Tools menu to see the following window:

You’ll have to quit and relaunch your application to see it at the zoomed level. Now that you know how bad the problem is, what’s the solution? In order to prevent our graphics looking like ass, they themselves need to be resolution independent. This means they either need to be drawn on the fly, or created and saved in a vector-based format. Ugh! Lots of work. The good news is that lots of designers have been using vector-based art for their work for some time, and can probably accommodate the changes pretty easily. But if you’re a cheap hack like me, you’ve probably got lots of bitmaps around that will need to be revised.

Peter Hosey noticed one such cheap bitmap in FlexTime 1.1: the new pie-chart table header cell. It looks fine at 12×12 pixels, but let’s see what happens when resolution independence takes its toll:

Yikes! Peter was nice enough to send along a solution, which was a small EPS source file that, when compiled into PDF, made a fast and resolution-independent graphic resource for my product. The only problem was I had some minor qualms with the exact size of the pie-wedge, and wasn’t comfortable enough in PostScript to easily make (or maintain) the changes. What the heck, I thought, why not do this programatically from Cocoa? I can use NSBezierPath to draw vector scaleable graphics on-the-fly at any resolution. I discovered, with Paul Kim’s help, that NSCustomImageRep would allow me to both do all the drawing on the fly, and take advantage of the conveniences of NSImage, such as being able to “setImage” on a table header cell. Let’s see how my pie icon survives zooming now:

Wow! That’s pretty cool. I thought this technique for “resolution independent generated images” would be useful for others, so I thought I’d share some code. But surely you’d have no use for a quarter-filled pie. Let’s see, what would be truly useful. A piece of reusable code that will last through the decades, and never turn stale. I know! A little yellow guy!

LittleYellowGuy contains an example application and Xcode project, demonstrating the creation of an NSImage that draws itself at full resolution for whatever size it’s set to. This code is available to you under the MIT license.

Now that my pies and little yellow guys are in order, I can turn my attention to the other vulnerabilities in my interface. Those brand-spanking-new toolbar icons I just designed using PhotoShop? Even they are not ready for 2006.

But at least my pie looks good.

Update (Nov 19): This article has inspired a great deal of discussion not only in the comments below but among other blogs. It seems people haev a lot to say about this subject! Many reactions point out that a single vector-based graphic is not likely to look great at all resolutions. Fine-tuning at the pixel level will remain a requirement. I hadn’t really considered this, but it makes a lot of sense. Ample payback for the time I spent writing this article!

Some of the most substantial reactions are linked to here:

Sven-S. Porst
Jasper Hauser
Craig Hockenberry
Christopher Lloyd
Stephen Deken
Marc Edwards