I’ve been involved in a number of patents over the years, but I’ve not written about them before, mostly because the US patent system seems to be more about stifling innovation than encouraging it. And more about funnelling money to lawyers than entrepreneurs. And that’s me trying to be positive about things. In this publication over the years, I’ve also chosen to focus on the grunt work I’ve done and not tout my patent portfolio as an accomplishment in itself.

But the patent process was still quite interesting to be involved with so directly.

Patent filings are among the most inscrutable documents you will ever come across. Often consisting of vague text and odd diagrams, they appear randomly (or so it seems) in various patent databases like Google Patents. All this creates an air of mystery and intrigue.

The patents with interesting diagrams often get posted as news stories, claiming they surely reveal future roadmaps. There is even one site exclusively devoted to unpacking patent news about Apple.

But no one really follows up on these stories. If they did, the truth is that most of the time, nothing ever comes of them. Even if you have a law degree and time on your hands, you’d be hard-pressed to find examples of patents that definitively revealed future products years in advance, which is what Patently Apple sometimes implies.

An example patent

Here’s a patent I’ll use to illustrate some of my later points: US8745535B2 Multi-dimensional desktop. I was involved only as an inventor and don’t have any special insight into the patent process or strategy. Anyone with access to a web browser and unlimited time can honestly deduce anything I mention here.

At the time this was filed, this may have seemed to many people as perhaps a window into a future product, but like many patents, that’s quite far from the truth.

What to make of a patent filing

Patents with diagrams definitely add some excitement, but try not to get too excited. Most often, the reasons for patent getting filed are pretty mundane.

Something shipped over a year ago and it needed to be protected

Check out the dates listed in the example patent. It was made public (“published”) on 2008-12-11. It was filed on 2007-06-08, which is eighteen months prior. This is pretty standard. What’s special about 2007-06-08? This was a few days before Apple’s Worldwide Developer Conference, which is generally the coming-out party for new versions of the various operating systems. That year, it was Mac OS X Leopard.

By filing it right as it’s released, the invention gets protected without revealing it ahead of time. If you go back to Google Patents and search for patents filed around the time of major announcements, you’ll find the same thing. For example, here are all the patents filed the month the original iPhone was announced.

Something small and specific in a broader patent actually shipped

Patents are intentionally broad and vague. When filing a patent, there’s a balance between filing too specific a patent and too vague. Too specific, and someone may rip it off by coming up with something that is substantially the same but slightly different enough that it’s considered not to infringe the patent. A patent that is too vague risks not getting granted.

Back to the multi-dimensional desktop patent. It’s fairly broad and ambitious, which led people to miss something important. A small-ish feature known as Dock stacks is buried in this patent, and it did indeed ship. You can see how a patent that seems to be stuff that has never before been seen would cause people to get overly excited. But this patent has something in it that shipped, and it needed protection.

Patents are very often an obituary notice for ideas

If a patent was filed and there’s truly nothing in it that ever shipped, then it’s very likely that nothing in it will ever ship. I don’t have any definitive proof of this, but from observing tech patents over the year, a fair number of them fall into this category.

So, why file a patent? Well, many companies file patents defensively, so that when patent trolls come after them, they have more potential ammunition to fight them off.

So, the notion of an idea graveyard may seem rather depressing, but they provide incredible insight into the thought process of inventors and the companies they work for. And sometimes the world changes and an idea that didn’t work out at the time gets resurrected. For example, the stacks/piles concept in this patent dates back more than a decade before this patent and still lives on today in some form or another.

If they are revealing the future, some deeper analysis will be needed

If you follow patents more closely, you can probably deduce some things and maybe come up with some unique insights into the thought process of a company, especially if you put it in the context of products that have actually shipped. So, what I’m saying is that considering one patent in isolation is probably not going to be a window into the future, but considering a company’s patent portfolio as documentation of a long-term thought process, you may be able to speculate on where a company might be going (or not going) next.

Back to my example patent

Fifteen years after this particular patent was filed, the desktop experience of the Mac has not become three-dimensional, for better or for worse. In fact, it’s even more two-dimensional than it was back then, when there was a lot of effort put into reflections and depth that are now gone.

Looking back, there were some interesting ideas that might have evolved into a rethinking of the desktop experience, but nothing really seemed like a slam dunk. I would have liked to see a few of the ideas live on, but the overall concept seemed like replacing clutter with different clutter.

None of this ever got past the discussion and mockup stage, except for Dock stacks. Here are a few screenshots from a Director file that I kept as mementoes.

Summary

To me, patents are the past and the present, and may sometimes be the future, but more often they tell a story of the past. For those who really want to dig into the thought process of a company and don’t mind reading boring documents, they can be a historical gold mine.

Having worked at Apple in an era where people didn’t care about the company or, if they did, thought they were most certainly going to be bankrupt within a year, it was heartening to see how passionate people could get over mundane things like patent filings. But I think by not following up on patents, or treating each one as a single news story, people may be prone to jumping to conclusions rather than gaining interesting insight into a company.

I recently created some Shortcuts that approximate this functionality on iOS. They are easiest to create on macOS, but they sync automatically and work on both platforms.

To try things out, I started with a hard-coded list of signatures. Here’s an example with three signatures picks one and displays the result. You can either manually create a dictionary or use JSON.

You can then upload a JSON file of your signatures and reference them via URL so that they can be shared between multiple macOS and iOS devices.

I created two scripts and then used Siri to run them on iOS. I can say “New Message”, which will create a new message in Mail with a random sig attached. If I say “New Signature”, it’ll simply copy it to the clipboard, which is convenient for replies since you cannot automatically append text.

If you already have sigs in Mail, I wrote a gross Applescript that will attempt to turn them into a JSON file that you can use with the scripts.

I’ve bundled everything together to download here. It’s not rocket science or anything, but it demonstrates that Shortcuts can sometimes fill some gaps.

I’ll never use it, but Twitter is going to be a huge hit.

Me in December 2006, to @iTod.

Here was my contribution over the years: 15 tweets in 17 years, and I earned a coveted 16 hearts.

Based on some digging around, Twitter supposedly had about 50,000 users when I joined. Since then, it grew. A bit.

The unexpected part was that three years later, I had amassed hundreds of followers. What? I didn’t recognise anyone on the list. But, I did notice that most of my followers had Indian-sounding names and it clicked. So, I tweeted about it.

A year later, I thought I’d freak my followers out a bit by making shit up.

But no one reacted to it, and I kept gaining followers. I just don’t really get Twitter. As of today, I have more than 35,000 followers.

I also didn’t predict that random people would email me every few months, wanting to buy my username. My highest offer so far has been $10,000. But I’ve come to enjoy not using my account at all.

So that’s the story of how I predicted the rise of Twitter, barely used it, and amassed a hundred thousand followers.

Note: I joined the Mail team in June 2000, three months before the Public Beta. We shipped the first “real” version of Mac OS X (10.0) nine months later.

On March 24, 2001, Apple released Mac OS X 10.0 (internally codenamed Cheetah). The initial version was slow, incomplete, and had very few applications available at launch, mostly from independent developers. While many critics suggested that the operating system was not ready for mainstream adoption, they recognized the importance of its initial launch as a base on which to improve. Simply releasing Mac OS X was received by the Macintosh community as a great accomplishment, for attempts to overhaul the Mac OS had been underway since 1996, and delayed by countless setbacks.

macOS (previously Mac OS X)—Wikipedia

An accurate and fair description! I previously wrote about the first day we first printed something in Mac OS X a month before the ship date! Everyone knew the operating system had large areas of missing functionality, and Mail was no exception.

One of the big holes we wanted to fill in Mail was the ability to import messages from other email clients. Everyone was keen on using Mail because it sported the fancy new Aqua look and feel (pinstripes! drawers!). Without an importer, you were left running your existing client, probably in Classic, and having your email split between clients. At that time, IMAP wasn’t yet a big thing, so you couldn’t just configure your account and have your messages magically appear.

We felt we couldn’t ship without an importer, yet there was a long list of things we felt we couldn’t ship without. Since everyone was busy with even more important stuff, this became a great summer intern project. Well, unless you’re the intern!

Mail’s first importer

Even though there was a loosely defined file format for mailboxes called mbox, it wasn’t a standard. Simply put, an mbox file is the raw source of every message in a mailbox, strung together into one large file. There is an RFC—essentially a proposal for a standard—which stated:

The mbox database format is not documented in an authoritative specification, but instead exists as a well-known output format that is anecdotally documented, or which is only authoritatively documented for a specific platform or tool.

It turns out that Eudora and Netscape were the only major clients that used mbox format, BUT they had their own variations:

Eudora used an mboxo variation where a sender’s email address is replaced by the constant string “???@???”. Most mbox clients store incoming messages as received. Eudora separates out attachments embedded in the message, storing the attachments as separate individual files in one folder.

The Mozilla family of email clients (Mozilla, Netscape, Thunderbird, et al.) use an mboxrd variation with more complex From line quoting rules.

Mbox—Modifier mbox—Wikipedia

So, Netscape required some ugly trickery, and bringing in attachments for Eudora wasn’t going to happen. It didn’t help that mbox is already a pretty difficult format for parsing. It’s not like XML, where data is labelled and structured. It’s just a stream of text. The end goal was to massage the mbox files from these two clients into the mbox format that Mail used (which followed the “standard”).

Then there were many confounding factors. Sometimes the mailboxes in the file system didn’t map to how they were organized in email clients. There was sometimes a separate database that would track this sort of information. Did we have time for even more error-prone reverse engineering?

And speaking of reverse engineering, there were two very popular clients that didn’t use the mbox file format at all: Microsoft Outlook and Claris Emailer. Even though we had the source code for Claris Emailer, it was still quite a daunting task, with only a few weeks to complete it.

The end result was an importer that was rather disappointing, to be honest. And I think the intern would probably agree with me. Too much gnarly stuff and too little time. For two clients, there was no attachment import. For Outlook, everything was imported into one mailbox because we didn’t crack the code in time. In some cases, mailbox names and the organization of them was lost. There were issues with encoding. The whole project was a minefield of edge cases.

Icky workaround

Back then, Mail would store local mailboxes in ~/Library/Mail/Mailboxes and would look there on launch to load existing mailboxes. If Mail encountered a corrupt mailbox or message, you could rule it out by moving some mailboxes aside and relaunching.

So, there was an opening here to trick Mail into importing your mailboxes. Provided you organized mailboxes and formatted them the way Mail was expecting, it would “import” them. For example, if you had a mailbox you created in Mail called “Apple”, this is how it would look in the filesystem.

Then, if you had an mbox file from another email client, then formatted in a way that Mail understood, you could create a folder in the filesystem (e.g. Pear.mbox), drop in a file named “mbox” and then relaunch Mail. Cross your fingers.

Mail’s second importer

Applescript can sometimes be an effective glue when no good solution exists. My thought was that if Mail were scriptable, we could simply grab messages from one client and stuff them into Mail, all with a script. But Mail was effectively not scriptable at that time. I pushed for getting some basic support for 10.0, but there were too many other things on the agenda and adding scriptability to Cocoa applications was very much a work in progress.

My hope was we could pursue this after 10.0 shipped, and then we wouldn’t have to rely on reverse engineering file formats. We could support attachments, mailbox hierarchies, and perhaps avoid some of the problems the first importer had.

BUT!

After work on 10.0 was closed down, I had an epiphany. Like many epiphanies, they are obvious in retrospect. Given we had this icky workaround to “import” mailboxes, perhaps I could use Applescript to grab data from other email clients, manually construct mailboxes Mail could understand, then quit and launch Mail. Voila!

When I proposed the idea, it was assigned to me. Surprise! So I spent an intense month on scripts for five major email clients: Entourage, Claris Emailer, Outlook Express, Netscape, and Eudora. The last two either had no Applescript support or it was so poor as to be usable. So, I had to replicate the reverse engineering that the built-in importer did for them, but I had some time to improve on it quite a bit. So it was worth the effort.

While it fixed many problems with the built-in importer, it still didn’t support getting attachments. There was no progress indication, and the import was all-or-nothing. So if you had 10 years of email in Eudora, plan on waiting… and praying… indefinitely.

I initially wanted to create one script, but Applescripts had a 32k limit back then, so it would’ve been too large! So, I ended up with 5 scripts. It was possible to put common code into a shared library, but this was not working for me very well at the time. This was a huge pain because the same code had to be copy-and-pasted between scripts and the same bugs had to be fixed in multiple places.

As an aside, debugging is pretty terrible for those who don’t know Applescript, even if you used one of the third-party script editors. You put in some logging, run it, and look at a big pile of output and try to guess what went wrong.

AppleCare agreed to host the scripts, and they shipped the same day that Mac OS X shipped. They let me ship them uncompiled so people could see the code and adapt it to situations or clients I hadn’t had time to get to. There were even versions for Mac OS 9, so you could run them on that side of the fence, and then move the output to the right location when you booted back into Mac OS X.

Here’s the page from archive.org a few months after they shipped: Mail Import Scripts.

Here are the original scripts in all their terrible splendour:

• Import Entourage 1.0.5

• Import Emailer 1.0.5

• Import Outlook Express 1.0.5

• Import Eudora 1.0.5

• Import Netscape 1.0.5

Future updates to the importer

The importer went through many changes after the initial version posted on the AppleCare website and in the next four versions of Mail I worked on.

Updated scripts

Three months later, AppleCare posted new versions of the scripts that addressed some of the biggest shortcomings. Attachments were now imported! The code for Emailer and Eudora was particularly gnarly.

• Import Entourage 1.1

• Import Emailer 1.1

• Import Outlook Express 1.1

• Import Eudora 1.1

• Import Netscape 1.1 (This one got corrupted somehow!)

I added super cheezy progress indication by opening a blank TextEdit window and then appending text to it. It was a live-updating log file. It was one part clunky, one part sweet. Applescript has never been known for progress indication. This was before Applescript Studio (ASS) existed… and then got killed.

And for Emailer, the script would copy the attachments folder over into Mail, then manually construct messages that contained links to the attachments. That script is some of the gnarliest Applescript I’ve ever written. It was a mess, but it worked and was better than nothing!

I added support to select individual mailboxes to import, so it was no longer an all-or-nothing proposition.

Puma (10.1)

An improved importer was on the feature list for 10.1, codenamed Puma. Since it was only a few months after the updated scripts, the main change was that the scripts were integrated into the Mail interface. The old importer was gone, and the new one merely launched the scripts and guided the whole process.

Jaguar (10.2)

I wrote a new generic mbox importer for clients other than the five main ones for this release. It would sniff around in a folder hierarchy and determine if anything could be imported. One common use case was people wanting to import messages from Outlook for Windows.

Additionally, this was the first release that enabled importing mailboxes in Mail’s own format! A small thing, but better than making people shuffle things around in the file system and hope they did it correctly.

Panther (10.3)

This release featured a native Cocoa importer that used Apple Event APIs to extract data with other email clients. The biggest benefit was an immense speed boost. The biggest benefit to me was that it was now fully debuggable. It was my first multi-threaded code and my first significant Cocoa project.

This release included Applescript support that was finally ready for prime time. The grand irony was that, now that we had good Applescript support, we never used it for the importer. Since I had now written this native importer, it was faster and better to use Mail’s APIs to create mailboxes and stuff them with messages.

We would’ve had to add a lot more Applescript support to do an end-to-end importer entirely in Applescript as I had originally envisioned. You would need to be able to create mailboxes, create received messages (with attachments), and append them to mailboxes. No email client I’m aware of allows you to do that, even to this day. I feel like the Panther importer was the best solution all along, and if anyone had thought of this back then, it could have been a 10.0 feature.

Also, in this release, we included a host of sample Applescripts. It included the famous Crazy Message Text script written by Sal Sogohian. I’m pretty certain I wrote the rest. They were great tests of the Applescript support in Mail and great examples for scripters. You could now create scripts and attach them to rule actions, put scripts in the Scripts menu, and even attach keyboard shortcuts to them. Even the preferences were scriptable. We had gone from being terrible to being in the top tier for scriptability.

It was too depressing to try the scripts I wrote as I expect changes in Applescript and Mail in almost 20 years have certainly broken them. I did try Crazy Message Text, and it was indeed broken! But I fixed it up. When you run it, it creates a new Message and pops in whatever text you want in various crazy colours, sizes, and fonts.

If you’re bored, I zipped them up here.

The account preferences needed to be rewritten to support the scriptability of preferences. Of course, bringing that up meant I was once again volunteering for something. So that became my first project that every Mail user would use. Scary! The worst that could happen with the importer is it would fail, and your email couldn’t be imported.

Leopard (10.4)

I left Mail before Leopard shipped. However, the importer lived on as is for quite some time. Eventually, the client-specific importers were removed, and all that remains are the mbox and Mail importers. Here is a sequence of screenshots from versions after I left, up until the present.

2025 update

It’s been three years since I wrote this article and since then, the importers have all been removed! Now you can only import mailboxes in mbox format and from previous archives exported from Mail. I guess it’s been a long time since any of these apps have been used, but it does seem that they could have kept the importers, but buried them deeper. It’s not implausible that someone would find an archive of old email and want to import it.

Conclusion

From the outside, it can sometimes feel like Apple is a chaotic mess. How could they have two importers that overlap each other? And the built-in one they are telling you not to use. Go download these Applescripts instead. It’s laughable to look back on that now.

The truth is that most of the time, things in software don’t go as planned, and you decide to ship something ugly and confusing because it’s better than not shipping it.

As I recall, we didn’t get any major criticism for it, and the scripts were widely appreciated. There was intense scrutiny of Apple after so many failed attempts to bring out a new operating system. At the same time, there were a lot of understanding users out there that enjoyed Mac OS X so much that they looked beyond its many faults. After a few releases, I looked back at the other email clients and was happy to discover that our importer was among the best out there!

Sometimes it’s better to focus on improving your software and not obsessing too much about what your competitors are doing. It can cause you to focus on doing what they do, only better. This can blind you to going down paths they never considered.

Think Different and stuff.

Download all the scripts

Here’s a link to an archive of all the scripts. Note that most of them likely won’t work and definitely won’t compile unless you still have an ancient version of some of these email clients lying around.

Summer 1979

After finishing third grade, I took a summer school course in computer programming at the Junior High. It was the first one the school district had ever offered. I took a magic course the same summer, but the computer class was all I really remember. The class shared a single terminal that was wired into a mainframe somewhere. It was my first exposure to any kind of computer like we think of them today.

I’ve tried to figure out what computer system we may have used. I found a picture of an HP terminal that dates from that era that seems vaguely familiar to me. Argonne National Laboratory was nearby and they had deep relationships with local schools. It’s possible we were doing some time-sharing on one of their systems.

I definitely recall that it used the BASIC programming language.

I remember thinking that computers must have all the answers, right? I wanted to write a program that would allow me to ask arbitrary questions, and then the computer would give me the answer.

The instructor told me I had to program the questions ahead of time. This seemed like allowing the computer to cheat. And then I had to program in the answers too. I was quite disillusioned. My first program was one where I’d ask for the size of a baseball field, and the computer would tell me. It was always right because I told it the answer beforehand!

Even though I didn’t completely understand computers yet, I wanted one. Since I was obviously the star pupil, the instructor gave me a copy of Creative Computing magazine, which I still have today. The word “BASIC” appeared in the issue 261 times. It was a big deal back then.

This magazine turned my interest into an obsession.

Fall 1979

The summer school instructor was right. That fall, when I started fourth grade, our school got their first ever personal computers. Although they were from Bell & Howell, they were actually just re-branded Apple II Plus computers. They came only in a sexy black color. It’s an interesting story. They were the first computers to make a significant appearance in schools, and back then, you were very lucky if your school had one.

The computers were put on carts and shuttled around to various classrooms. They were stored in the janitor’s closet when they weren’t in use! Three years later, there was a whole computer lab in my Junior High, but back then, it was two sinister black carts with black computers on them.

At first, they were making an appearance maybe once a day in classes. I wanted to spend more time with them, especially on my own. I was told to ask the librarian and I could “check out” one of the computers just like a library book.

After the last class, I’d corner the librarian, and she’d walk me to the janitor’s closet to unlock it. I’d wheel one of the black beauties to the library and goof around with it until the school closed down for the night. One of my most vivid memories is a game from Apple called Lemonade Stand.

It was effectively a lesson in small business economics masquerading as a game. You can even play it in a web browser today.

Aside from some games, I remember reading the manuals that came with the computer cover to cover. I’m one of those weird people that read manuals. The library had some computer magazines, including Creative Computing, and that’s where I continued to learn BASIC. I started by transcribing programs from the magazine and running them. Then, I’d modify them and eventually write my own.

I was the only one that ever used the computers after school for quite a long time. The librarian eventually grew weary of hiking to the janitor’s closet twice a day, so she gave me a spare key.

One day I was wheeling one of the quite expensive computers out of the closet. Including display and floppy drives, I estimate a cost of $10,000 for each system (in today’s dollars). A teacher I didn’t know confronted me as I zoomed down the hallway. She was not pleased! She dragged me to the principal’s office.

Mr Michalek, the principal, was a great guy who knew all the students, not just those in trouble. So, the teacher dragged me in front of him. When Mr Michalek saw me, he laughed and said “whatever he did, it’s fine, don’t worry about it”.

Just over 20 years later, I started at Apple.

Easter eggs that are used to credit people have especially been disliked at Apple. The company feels that everyone in the company contributes to a product, so it’s unfair to give credit to only a tiny subset of them. If you’ve ever watched the credits of a Pixar movie, you’ll see what it looks like when everyone is credited!

User pictures

Viewing a message in Mail will show a user picture if you have one configured for that person (or business) in Contacts. This feature has been there from the beginning of time. Later on, support was added for getting images from iCloud users and from social media accounts.

Since CARROT undoubtedly has my picture in their Contacts, this is what they will see in emails from me.

But there were two cases where user pictures would appear, even if they were not in Contacts. Both were only available for Apple employees.

Apple network

Mail would look in a specific (NetInfo) network directory for user pictures. It would display if it found a correctly sized and named TIFF there. For example, there was a file named “cricket@apple.com.tiff” which looked like this:

Images were not sent with the emails. When you viewed a message, it would grab the image from the network. No image would appear if you weren’t connected to the Apple network when you read the message.

Emails sent outside Apple

When I worked on Mail, a couple of us were active on public mailing lists, answering questions and helping people out. When the general public saw messages coming from Mail team members, they’d see our user pictures.

The magic file

So, if this image wasn’t coming from Contacts or sent with the email, where did it come from? Although the trick was eventually discovered, it took quite a few years! This was due to a combination of being hidden in plain sight coupled with a bit of deception.

Since it was an email client, people expected the image was being downloaded from the internet. It took a while for people to discover the pictures were part of the application itself. If you opened the Mail bundle and looked in Contents/Resources, you’ll find a jumble of files, including icons, images, sounds, and other assets. For example, in the current Mail bundle, there’s a standard icon file called ApplicationIcon.icns. If you open it in Preview, this is what you’ll see.

However, if you show the thumbnails and make the window larger, you’ll see that it’s multiple images at different sizes.

This is nicely bundled into a “multi-page TIFF” file, where each image is at a different resolution. This is how icons and other image assets are typically stored.

There used to be a file in this same directory called senders.tiff. The name was intentionally innocuous and boring. If you decided to open it anyway, you’d see this.

Even if you’re a software engineer, you might not know what a multi-page TIFF is, so you might not think to show thumbnails and expand the window.

So, there is the source of the user pictures that people on the mailing list outside Apple saw. The image for me was the cricket icon, obviously. When the email address for someone on the Mail team was encountered, it would look up the associated image in this multi-page TIFF. Since the source code for Mail was already littered with the email addresses of everyone on the team, it was easy to hide this in plain sight.

I recall that it was discovered a few years after Mac OS X shipped. Here’s a reference to the easter egg from January 2003. Until then, whenever we posted to a mailing list outside Apple, we’d inevitably get at least one email asking how this user picture was showing up! I think we all knew the fun would end eventually, but we enjoyed it while we could. We usually would just say it was magic or that we were special (which was true). We’d insist they were imagining it if we were in an evil mood.

Staying power

Eventually, someone at Apple decided the fun would be over, and the file and associated code had to be removed. Still, it’s always amazed me how it persisted for many years after first appearing in all the online Mac easter egg directories.

This easter egg wasn’t technically a list of people who worked on Mail, but a badge showing up for people you already knew worked on Mail. I suspect this is one reason it wasn’t considered very objectionable. It had been there even before Mac OS X first shipped to the public, so the risk of problems was low. Also, the Mac OS X engineering team was predominantly engineers from the acquisition of NeXT, which had a quite different culture from Apple.

Mixed feelings

I always have mixed feelings about easter eggs. I think they can add personality to an app and show people that human beings write the software they use. But on the other hand, the risk is huge and could tarnish the company’s image. People may not take kindly to a bug caused by inserting a video of an alligator playing the accordion, especially if the software has other serious bugs (which all software does).

One thing we could’ve done differently was to present a special image (e.g. Apple logo) as a user picture on every email from an apple.com address. This would acknowledge that everyone at Apple contributed to Mail and would get a special perk as a reward.

But I have to admit that I liked knowing that my cool cricket icon would appear on all the emails I sent.

Before Coldplay’s four-song performance started, Chris Martin (lead singer) remarked, “We played this song for Steve 10 years ago, and he said it was sh–. He said we’d never make it”. It’s not hard to imagine hearing him say that.

In my mind, the opening bars of “Fix You” seemed instantly appropriate. Amidst a sea of people and giant iconic banners of Steve, the lyrics gave me goosebumps. I’m sure I wasn’t the only one.

When you try your best, but you don’t succeed
When you get what you want, but not what you need
When you feel so tired, but you can’t sleep
Stuck in reverse

And the tears come streaming down your face
When you lose something you can’t replace
When you love someone, but it goes to waste
Could it be worse?

I started imaging a music video of this song as it unfolded. I imagined footage from the early 1990s, long after Steve was kicked out of his own company, then desperately trying (and let’s be honest, failing) to will his new company (NeXT) to success.

Synchronicity

Many have experienced the phenomenon of hearing a song in a certain context and feeling like the lyrics just seem to fit perfectly. I’ve tried many times to find a word to describe this, and the best I could find was synchronicity: circumstances that appear meaningfully related yet lack a causal connection. The interesting part is the desire to want there to be a connection even if there can’t possibly be one. I wanted the lyrics to fit so Steve could have the most fitting tribute possible.

By the seventh line, it was starting to become a stretch. Who was the person he loved, but it went to waste? Lisa, his estranged daughter? Supposedly his adoption held him back in life. Maybe the lyrics refer to him loving Lisa but not being able to reconcile with her yet. You could probably bend the lyrics to fit any occasion.

Then:

Lights will guide you home
And ignite your bones
I will try to fix you

Ok, is Steve seeing the white light and going to heaven? Or is he going home to Apple in 1996? And who is trying to fix him?

This is where things got even weirder. If you watch the video, the camera switches to Laurene Powell Jobs (his wife) right as Chris Martin sings, “I will try to fix you”.

If I were into conspiracy theories, I’d spread a story that Coldplay played the song for Steve, after he called it shit, they re-wrote it together to follow the narrative of his life. Then, Steve staged his death from cancer so that this could be played at his memorial. Then, he’s in his secret lair somewhere, hatching amazing new products. Maybe I should have my own AM radio show.

In the interest of beating this to death, here are the remaining two verses:

High up above or down below
When you’re too in love to let it go
But if you never try you’ll never know
Just what you’re worth

Tears stream down your face
When you lose something you cannot replace
Tears stream down your face and I
Tears stream down your face
I promise you I will learn from my mistakes
Tears stream down your face and I

Is it just me, or does it sound like Steve is suffering and then learning from getting pushed out of Apple?

Admit it; now you’re starting to see it too.

Having worked on at least 15 software development cycles, here is what often happens:

1. QA identifies several very serious defects or usability problems

2. Engineering or management thinks QA is exaggerating the issues

3. The software ships

4. Bugs in the release get negative press, and users are frustrated by usability problems

5. A rapid software update is prepared to address the issues

My experience has shown that serious issues are almost always known issues at the time of shipping. They just aren’t prioritised high enough to warrant getting addressed. But it’s also true that QA does tend to overreact.

Let’s add some steps

In between steps 4 and 5 above, I’d add the following:

1. See if the problematic issues were reported by QA before the software shipped

2. Find the responsible QA engineers

3. Tell them:

You… were… right!

Even though the release shipped with issues that QA diligently discovered and reported, not acknowledging their contribution just adds insult to injury. It makes them feel that users and journalists are taken more seriously when reporting issues than your QA department. Even though their bug reports weren’t addressed, it’s good for QA morale to acknowledge this mistake.

For bonus points…

Sometimes a financial reward doesn’t hurt either. Give them a bonus for issues they found that were serious enough to warrant a rapid software update after the fact. Or at least make everyone aware of how the outcome could have been different.

QA is often treated like the enemy of engineering or the enemy of shipping a software release on time. But you slow progress on your next planned release anytime you are forced to do a software update. Fostering a good relationship between QA and engineering is another big win for improving morale.

While Apple was busy transitioning to Intel, I was working on the software team responsible for Dock, Exposé (later Mission Control), and Dashboard (now deceased). We did a lot of experimenting with new interface concepts; one was a radical new way to manage apps and windows. It effectively made the existing Exposé irrelevant as well as the Dock as a way of managing running apps and windows.

It never became an approved project, but I continued to live on it for many months until it just stopped working with newer versions of hardware and software. By then, our team had moved on to other things.

Fast-forward 15 years

At WWDC 2022, I was very excited to see Apple announce a new feature for macOS and iPad called Stage Manager. It’s a radical new way to manage windows and likely makes much of Exposé and the Dock functionality irrelevant. Sound familiar? Well, it turns out it looks familiar too!

Now, it’s not unusual for a feature to get killed, only to re-surface in a future release. But this has to be some sort of record! In addition to being a macOS feature, it’s also a much more elegant way to do multitasking on the iPad.

Apple has put up nice pages showing the new features of macOS Ventura and iPadOS 16. They include screenshots and movies showing how Stage Manager works on the Mac and on iPad.

How do they compare?

Given how long it’s been since I used the 2007 version, I don’t remember all of the interaction details. But there were key differences between it and Stage Manager.

Both took over the positioning and size of all windows. Back then, we saw this as a huge win for novice to intermediate users who struggle with window management.

Both features showed background applications as groups of windows along the left side of the screen. But, it also showed windows that weren’t frontmost in a column on the right side of the screen. So, in addition to being able to focus on one app at a time, there was the ability to focus on one window at a time if you wanted.

Both let you view multiple applications at the same time.

Although they look visually similar, the Stage Manager interface is definitely much more refined and compact. Part of that is because it pre-dated retina displays, so there was only so much shrinking you could do before it just looked awful (or more awful). Without the green-light, it never got sufficient attention from the Human Interface team. Visually, Stage Manager looks really nice!

Stage Manager appears to be positioned as a power-user feature which I think is a shame. I’d much prefer to see it as something you pick in Setup Assistant or choose in Settings rather than hidden in a menu somewhere. I think this is something that would be especially appealing to a new Mac user. On the iPad, I don’t see any reason to use the existing multi-tasking UI anymore.

Conclusion

Never say never! I’m thrilled to see this feature and looking forward to trying it out and providing feedback. I’ve not filed any bugs since I left Apple in 2019, but this may get me back into the saddle.

In February, my coworkers and I gathered in a conference room at Apple to watch the keynote address for Macworld Tokyo. People were in an anxious mood and were hoping for something compelling to be unveiled.

Steve Jobs walked out on stage, looking paunchy and visibly sweating at times. He looked clearly uncomfortable in a suit and was sporting a wrinkled tie.

Our hearts sank as this sweaty man unveiled some of the oddest-looking products Apple has ever made.

But these weren’t the only designs that were created. The team came up with more than a dozen designs to present to Steve. None of the others have ever seen the light of day, probably because the product was widely considered a failure. It was shelved 5 months later.

Over the years, designers had learned if they only presented their absolute favorite designs to Steve, there was the risk that everything would get rejected. Rather than risking a huge setback, the designers would mix in some designs they didn’t like as much. They hoped that presenting a wider menu of options that something would resonate with Steve.

And then there were the curveballs. These were designs they were sure that Steve would reject. They felt that after some rejections, he would be look upon the other designs more favorably.

This time around the two curveballs were named Flower Power and Blue Dalmatian.

And he loved them.

As I mentioned in my article on the “iMail” concept, I was getting increasingly frustrated with the complexity of Mail around this time.

The week before the WWDC 2004 keynote, my manager told me that Steve threw a fit during the rehearsal of the Mail demo. He was frustrated and paced around saying [paraphrased]:

Why does Mail have to be so fucking complicated? You read email, you compose new messages, you send them. That’s it!

Steve Jobs, trying to use Mail.

I was thrilled to hear this anecdote. I didn’t feel like I had many allies in the management chain that shared my desire for a much simpler Mail. And now I had the ultimate ally. I took advantage of this and sent Steve an email the same day.

I barely had time to get back to work when I got a reply.

A few weeks later, I was in a brainstorming session with the Human Interface team and Scott Forstall was present. I was often quiet during these types of meetings because everyone would be frantically talking over one another such that I really couldn’t follow it. I was more the pondering, contemplative type.

This time around, though, Scott kept interrupting the flow, looking at me and smiling:

Why don’t we ask cricket what he thinks? cricket? You seem to know a lot about designing things, why haven’t we heard from you?

Scott Forstall, possibly passive-aggressively

That’s when it hit me. Steve had forwarded my email to him.

Months later, fate brought me to the Aperture team, so the story sadly ended there.

I was always trying to push Mail in the direction of simplicity and higher usability, but there were always these major roadblocks:

• Email clients had worked fundamentally the same way for a very long time, so there was a LOT of resistance to change.

• Innovations that required email servers to add new functionality were dead on arrival.

So I experimented with ideas for a new email client that I dubbed “iMail“. Think of it as the email version of an app like iMovie or iPhoto. Since Apple had recently started running their own email servers as part of .Mac (now called iCloud), here was a chance for client and server to innovate together.

This never became an official project although certainly some ideas were eventually implemented in Mail.

I documented the results of the brainstorming and compiled the very rough content you’ll see below. I’ll leave it unedited and add [some present day comments in braces]. I thought it would be interesting to look back at the concept.

Start of iMail proposal (unedited)

[Note that there are 8 times as many internet users when this article was written as there were back then].

Why iMail?

Does the world need another email client? Doesn’t it have enough already?

At MWSF 2003, many people wondered why Apple released Safari into an already crowded browser market. Two years earlier, many wondered the same thing about iTunes, released into a an already crowded market. In both cases, the reasons were simple:

• None of the existing products were remarkably easy to use

• Innovation had dried up and stagnated years before (some people call this ‘product maturity’)

• The functionality these applications provide are critically important to computer users

The same has been true in the market for email clients. No major new email clients have been released in the last 5 years. Innovation has completely dried up and this has incorrectly been hailed as a sign that the market for email clients has ‘matured’. What’s really happened is email client vendors have run out of ideas and have instead spent the last five years in features arms races with each other, while failing to recognize these critically important facts:

• People universally feel unable to manage their ‘flood’ of email

• Email is inherently simple. You send, receive, file, and find email. It isn’t more complicated than that for the vast majority of people

• Most users are intimidated with their email clients and have no idea how to solve problems when they occur

Why can’t an email client be as easy as iTunes?

Good question! The typical iTunes user needs the following functionality:

• Get songs into iTunes so they can be played

• Play songs

• Find songs immediately

• Organize songs using dynamic categorization

Here’s what a typical email user needs:

• Send and receive email, with or without files attached

• Read email

• Find stored email immediately

• Organize email using dynamic categorization

There is not much difference there. The typical iTunes user doesn’t need to leave the single window to get all the functionality they need. It’s highly likely that the typical user never even needs to use any menus or set any preferences. This is the kind of design that is perfect for the kind of user that just wants to use the system and have it do what they want it to do, without needing to read a manual or grasp concepts such as IMAP vs POP or local versus server-side storage

What has every other email client done to help address these problems?

Over the years, other email vendors have layered new features on top of old ones in a vain attempt to make you feel like it’s easier to manage you email.

Example:

Rules were invented to help manage a flood of email to the inbox, allowing you to route messages or mark them in a limited number of ways. These have gotten so complicated that you need a separate manual to figure them out, which is why few people (except power users) actually use them. Then, new features are layered on top of rules because with all your messages scattered in a growing number of mailboxes, you need an additional feature if you want to see your messages in a coherent list again. What this demonstrates is that people want to see their email in different ways, sometimes seeing them by date, sometimes sorted by mailboxes, sometimes based on arbitrary connections that exist only in their brain (and rules can’t replicate this), and some based on ideas and relationships that haven’t been thought of yet.

Many of these so-called solutions are just duct tape on top of bad initial design that fails to recognize that email users have simple needs and they don’t want to be confused by endless options, cryptic errors, or things that they must visit Preferences or the menus to have a chance of figuring things out.

What about power users?

The notion of a power user of email is silly. It is only because email clients have gotten so overwrought and complex that there is even the need for power users to arise in the first place. As long as you can send email to people whenever you want, send and receive any files you want, instantly find any message you want, and never miss an important message, that’s all anyone could ever expect or want from an email client. Spending time configuring a program and reading 500 page manuals is time better spent actually reading and writing email.

What could a good email client offer?

These is just a short list of what a simple, well-designed email client could do:

• Provide immediate status without using the mouse and keyboard

• Allow you to read, file, associate, and find email in the way your brain works, instead of in ‘mailboxes’ or ‘categories’

• Configure itself and never need you to visit Preferences again

• Provide unlimited stepping stones to hop to other messages, no matter what context you are in, much like hyperlinks do on a webpage

• Be fun to use!

• Allow unlimited relationships between email messages

Stakes in the ground

A list of absolute musts:

• The experience must be optimized for the user in the lower 50% of the experience spectrum, a sweet spot that has yet to be targeted by an email client

• Anything that is a user preference must be absolutely necessary to using the program (for example, setting a font size is absolutely necessary for someone with bad vision). See [[direct manipulation UI]] for an explanation of why setting a font size should be done directly in the view where the font is being displayed!

• Users must not have to know what POP, IMAP, or SMTP to use this program

• Users should not have to visit a menu to use the program

• For the first time ever, this email client must be fun to use!

Target audience

The target audience for an iMail product would start with the bottom 50% of email users, ranked by the user’s experience level. Once the functionality goals are met for the 50% group, it could gradually target more users, as long as the bottom 50% were never compromised in any design decisions.

Possible users:

• Any home users

• Casual computer users

• K-12 students

• Educators

• Less technical corporate users (administrative, for example)

• Anyone that spends less than an hour a day reading and responding to email

[Note that there are eight times as many internet users today as there were when this was written. That’s a lot of potentially novice users!]

Competitive analysis

A quick look at the complexity of currently popular email clients:

Microsoft Entourage

• 6 navigation buttons

• 12 toolbar items with 56 menu items attached to them

• 9 default header columns in the list of emails

• 264 menu items

• 28 preference panels

• 9 separate entry points to set mutually exclusive preferences

• 384 total items

Eudora

• 13 toolbar items

• 10 default header columns in the list of emails

• 194 menu items

• 40 preference panels

• 6 separate entry points into preferences, all except one is mutually exclusive (Settings and Preferences both end up in the same place)

• 263 total items

Netscape

• 10 toolbar items

• 6 default header columns in the list of emails
  *174 menu items

• 12 preference panels

• 2 entry points into preferences, which overlap in functionality somewhat

• 204 total items

Mail

• 9 toolbar items

• 4 default header columns in the list of emails

• 159 menu items

• 12 preference panels

• 1 entry point into preferences

• 185 total items

Possible feature set

Database-driven

Having a database to store email metadata is the single most important feature we could possibly put in an email client, allowing us a tremendous amount of flexibility that a flat, mailbox-based model cannot do efficiently.

Advantages

• Download and save incoming messages once, then only toggle metadata in the database after that. In a flat-file system, there is an atrocious amount of reading and writing of large chunks of data that is simple unnecessary

• Allows unlimited amounts of categorization and cross-categorization of emails. Most email clients right now let you put email into mailboxes, maybe color them, and maybe assign a single category to them.

• Adding new metadata wouldn’t cause backward compatibility problems. New metadata would simply be ignored by older versions

• Usage patterns could easily be recorded and leveraged for future enhancement to the user’s experience. In a database model, every time a record is accessed, the email client knows it, making it trivial to provide useful functionality like the history of emails that have been read, how often they’ve been read and in what order, how often they’ve been searched for and found, etc

What this enables

With a database-driven model, this would free the email client from having to anticipate how users may want to store, tag, and reference their email. With an unlimited set of meta-data, users could do any of the following:

• Jot down arbitrary notes on any email, then search by these notes later on

• Create arbitrary links between emails (for example, two emails that address the same issue, but sent by different people in an unrelated thread)

• Apply an unlimited set of user defined categories to emails

• Find related and specific emails instantly — text-based string and substring searching is incredibly primitive

Attachment view

An attachment is another piece of meta information that is associated with a message and can leverage a database-driven email client. The word attachment is unfortunate, implying some sort of permanent bond between a message and a file. It should instead be a loose association.

When users want to find an attachment in one of their existing emails, they usually remember fragments, like the name or part of the name of a file, maybe who sent it, maybe the type of file it was. Given the filing in mailboxes metaphor, this doesn’t lend itself very well to managing attachments.

A concept of an attachment view could present the user with a Finder-style window that lets them see all of the attachments that they have received. Just like with any email message, they could attach meta information to any of these files (for example, marking a bunch of attachments as associated with a given project they are working on). In the same way that iTunes and iPhoto provide a meta-database to organize music and photos, an email client could provide a meta-database for files that have been received. A file browser could list all attachments and allow you to sort by when you received them, who sent them, the type of the file, the size of the file, etc.

Dragging a file into a new outgoing email message could copy this file from its original location and store it in a location specific to the email client, much like iTunes and iPhoto does. Then, you could also browse and access files you have sent in an efficient and easy manner such as this.

Speech

No email client has anything but rudimentary support for Apple’s amazing speech technology. We can do better:

• UI navigation by speech

• Command and control via speech (leveraging Applescript)

• Background speech notifications (rather than dialogs and Dock bouncing, which conveys little useful information. When you’re not using your email client, you shouldn’t have to switch contexts to keep abreast of what’s going on).

• Add email addresses to outgoing messages via speech (also leveraging Applescript)

• Possibly work with 3rd party to enable voice dictation to work seamlessly

Applescript

Stakes in the ground:

• A feature or functionality should not be added unless it has Applescript support, even if only for testing purposes

• No email clients have Applescript recordability. We should be the first.

• An effort should be made to make scripting as accessible to novice Applescripters as possible, through the careful definition of terminology

Visual stationery

It’s about damn time that email started to get interesting. Right now, in order to send anyone any sort of interesting content, you need to toss in some attachments. We should strive to provide functionality that goes well beyond the current model.

Some ideas:

• Provide beautifuly stationery (like Keynote does for presentations) that users can compose email on top of. With HTML composition, this is within the realm of possibility. Imagine getting beautiful parchment emails that utilize an elegant, script font!

• Sending HTML forms to people that they can fill out and send the results to you

• Ability to easily send tabular data in a presentable format

• Eliminate the need to use an external application to create the communication you want to create

Direct manipulation UI

Stakes in the ground:

• Users should never have to hunt to find out how to do something. It should be right in front of them!

• Anything resembling a preference should be directly accessible in the UI (not in a prefs panel or in the menus)

Zero configuration

One of the reasons the Junk Mail feature in Jaguar Mail was so successful is that it required almost zero user configuration. It shipped in one mode, then offered to switch to another mode based on some internal logic. I’d like to go one step further with an email client and require zero user configuration. We should pick one way to do every action that is optimized for the novice user and make it work!

Rendezvous could also possibly be an interesting option here. If ISPs installed Rendezvous on their email servers, could we do auto discovery and configuration when the user connects to their ISP?

Zero AppleCare costs

Users should not have to call Apple to help them use their email client. Apple is not an ISP. We should strive in designing an email client that generates no calls to Apple’s call centers.

How do we do this?

• Review historical call data from Apple’s support of current email clients

• By providing immediate status, this should keep users fully apprised of what’s going on in their email client

• By defining a strict set of functionality that concentrates on optimizing one way to perform any given task, there is less room for user confusion

• Provide inline help in every context, so that a user who asks the question ‘Why is this happening?’ always has something to click on

• Work with as many major ISPs as possible to get autoconfiguration working

Column view threading

This one became a specific proposal for Mail after it was conceived for this iMail idea. I wrote up a separate article about it.

Hybrid mailboxes

[Hitting IMAP quotas is not such an issue anymore and POP usage has declined a lot, but I think there still are a few interesting ideas in here].

Goals:

• Make the difference between POP and IMAP transparent

• Get rid of crappy old POP hacks for managing multiple accesses to the same account

• Make quota management significantly easier

• Negate the need for making mirrors of IMAP mailboxes on your local system so that you can preserve your organizational system while at the same time dealing with your IMAP quota

• Same goes for special mailboxes — having your sent messages on a server is nice, but when you need to free up space, you need two sent messages mailboxes, one on the server and one local

Possible solution:

• Hybrid mailboxes, where current content is kept on the server and then aged locally, based on global quota logic.

So, how would this work for an IMAP account? You would configure an IMAP account and the email client could query the server and find out the account quota. If this is not supported on the server, the user could manually enter their IMAP quota. They would then be free to create mailboxes in their IMAP account. The email client would manage the quota in such a way that older messages would be removed from the server and kept locally.

The benefit here is that the user doesn’t ever have to worry about archiving messages. It will be done for them automatically (or based on user-defined criteria). All their messages would still show up in the mailbox (on their local system) after the messages have been aged.

For the mac.com [iCloud] customer who doesn’t access their account from multiple machines, this will make their experience of using Mail significantly better.

Potential pitfalls:

• How to handle users that access their IMAP account from multiple locations. What I mean here is that it’s potentially problematic that a message that has been aged automatically by one copy of their email client will not be visible in another copy of their email client on another system (or another IMAP client).

• How to indicate what is a server message and what is a local message (if this is needed)

Conclusion:

This would go a long way towards simplifying the email experience for users, while at the same time reducing the number of configuration options, and potentially removing the need for users to care about whether they have a POP or an IMAP account. They would simply create accounts and create mailboxes and the email client would deal with the rest.

Leverage .Mac

Because Mail was designed to be an email client for any ISP, it’s stuck when trying to innovate. Working with .Mac specifically, or even with a set of the most popular ISPs, we could work to provide enhanced email experience for users of this email client. This client could be tailored, for example, to only work with .Mac, Earthlink, MSN, and other large ISPs. For their part, ISPs could get significantly reduced support costs since users of this client would have to consult them far less often since it’s not just a generic email client.

Admittedly, this is an odd proposition for an email client to be limited to specific ISPs, so this is presented only as fodder for thought! [The key thing is to have client and server work together on moving things forward]. There are some interesting ideas we could push if we had the support from specific ISPs. We could submit new RFCs to enhance functionality, then push this set of ISPs to support them.

Some ideas:

• Better quota management

• Support for hybrid mailboxes

• Security integration (PGP, etc) [Hard to believe we’re still not there]

• Handling of large attachments through an intermediary website hosted by the ISP [iCloud now supports this]

• Server-side spam filtering

• Server-side message routing [iCloud supports this]

• Server-side preference storage

Smart mailboxes

[This has since been implemented in Mail]

Out with old mailboxes, in with smart mailboxes. Some email clients call them ‘views’ and relegate them to the bottom of a long list of traditional mailboxes. Smart mailboxes would always be on and would completely replace traditional mailboxes. Like iTunes, there could be a concept of a Library, listing all of your messages, and smart mailboxes, which would be like smart playlists (or even ordinary playlists).

Plain/Rich transparency

[Not much of an issue anymore as most email clients have since switched to HTML composition]

We need to figure out an elegant way to provide rich/plain text transparency. There are still known problems with Japanese and other Asian languages, but we should strive to find a way to remove the need for the distinction between plain text and rich text. Users that are new to the email game have no clue what plain text means and they shouldn’t have to. They should pick a font and start typing and have an expectation that a reasonably facsimile of what they typed will show up on the receiving end.

User feedback/bug reporting

[The Feedback Assistant handles this now].

Like Safari and some of the iApps, we should provide users a way to provide feedback and report bugs. The bug reporter could grab a snapshot and the raw source of a problem mesage, much like Safari does. We could design a database backend to gather this feedback and categorize it, allowing us a way to better determine who our users are and what they want from an email client.

Usage statistics

[This is supported at the operating system level now, but applications have to decide what statistics to gather].

Despite all our internal efforts to simulate real-world use of Mail, information gathered from the ‘field’ would be priceless in determining usage patterns of Mail, including determining areas where users frequently stumble.

Some products, like Eudora, collect rudimentary statistics on e-mail usage. For example, with Eudora, you can get statistics on received e-mail over daily, monthly, or yearly time frames. While this information is great, I think we could dig even deeper.

As long as the system was completely voluntary, fully open for inspection by the user, and non-intrusive to the regular usage of the program, I think we would find many customers more than willing to submit this data to us to be used to improve the user experience of the program.

Some of the things we might be interested in:

• Volume of incoming and outgoing e-mail

• Memory usage over time

• Average running time of the application (do people keep it running or launch and quit it frequently)

• Download speed for incoming messages

• Type of internet connection (56K, T1, DSL, etc) [Welcome to 2003]

• Crash Catcher reports (?)

• Usage of toolbar buttons, menu items, and keyboard shortcuts

• Changes in Preferences (what is changed most often, least often)

• Attachment types sent and received

This is just a random list off the top of my head, mostly just to illustrate that it could be very interesting and useful information to get from our customers. On top of all my other arguments, I think it would be an interesting change in how we gather feedback currently, usually in a small seeding group.

As far as how this could be implemented, there are many paths we could take. As long as it was clearly presented and voluntary, I think it would be a win-win situation.

Browser-style navigation

Users have a pretty good grasp of web browser navigation and use the back/forward buttons and the history features to find previous pages they have visited. The same tools would be invaluable in an email client. Rather than always having to resort to searching, some users remember emails based on when they read them or how often they’ve read them. With browser-style navigation, users could go back to previous messages they’ve viewed, see a history of messages they’ve viewed. See the database-driven section for some ideas on how a database could be leveraged to store this information for easy retrieval.

[This could be useful for that maddening situation of “I know I saw this email!” and then never being able to find it manually or via a search].

Single search field

[This is now part of Mail and other applications].

So, the idea is that we would just have a single search box like iTunes does and you would enter search terms. Behind the scenes, we would be doing a full index search of headers and body. The results would be presented in the message list, separated by what field the search matched on. So you would see

• ‘From’ matches

• ‘To’ matches

• … and so on.

Given a database-driven set of metadata, it should theoretically be fast enough to search all messages, so the need for per-‘mailbox’ searching would be reduced.

Example-driven help system

We need a great help system, but what would be even better would be example-driven help, much like Apple Guide used to provide in Mac OS 7-8. Instead of just providing pictures and text, you could provide step-by-step examples that would drive the application itself. We could enable UI scripting such that we could pull off the same task.

[As I recall here, the biggest problem was essentially localizing movies in many languages. Perhaps someone could come up with a clever idea to automate the creation of this content].

Spatial UI hints

This is somewhat of an abstract idea, but one thing that I think a lot of applications could benefit from is something I call spatial UI hints. A couple of example of this might be the best way to illustrate:

1. When you sent a message, an animation would carry the message and visually drop it in your sent messages mailbox. This would easily communicate to the user where this message went after they hit send, should they want to view it again

2. When a user dismisses a dialog, a similar animation could drop it on top of a UI widget, that, when clicked, would reveal a log of all recent error messages.

POP/IMAP transparency

The goal of this feature would be to remove protocol-dependent settings and preferences and make everything based on how the user wants to manage their email. This removes the need to understand the subtle and not-so-subtle differences between POP and IMAP and also removes functional differences between the two account types. This prevents situations where users expect a feature that works in one account type to work in another. If we can’t provide the feature and have it work for both account types, we don’t do it.

Single-window interface

It should be a design goal to make the client a single-window application for all the most commonly used operations (if not all). Some interesting ideas here could be to put configuration right into the Mail window itself. When you click on an existing account in the account list, you would reveal configuration options for that account. When you click the + button to create a new account, the Mail window becomes a preferences window. No need for separate windows for everything.

[This is very much in opposition to the “cleaner interface” concept Apple has today where hiding UI elements is used to give the illusion of simplicity].

iLife integration

An email client should be an integral part of the iLife suite, providing easy integration with these other apps.

Some of the functionality you could provide:

• Browsing the digital libraries of the iLife apps so that they can be easily attached to new messages and sent

• Incorporate incoming attachments directly into your iLife libraries. For example, incoming images could go right to iPhoto’s library

[Anyone remember iLife?]

Immediate status

One problem that appears to be common with users of current email clients is that they frequently don’t know the current status of the application and don’t know where to go to get this information. The concept of ‘immediate status’ is that the UI design of an email application should lend itself to having a clear and easy way for users to find out the status of the application.

What types of status do users want to know?

• Are there pressing emails I need to attend to?

• Am I connected to the internet currently? [Wait, you can disconnect?]

• Am I experiencing any problems fetching email from any of my accounts? If so, what problems?

• Are there new emails on threads that I’m interested in?

• Have I gotten that email from my boss yet?

• If I’m currently sending a large message, how much of it has been sent so far? When will it finish?

Some ideas:

• Use speech when Mail is in the background

• Use the screensaver to provide email status when the system is idle, so you can know where you stand even before you move the mouse

• Establish a UI indicator that can reveal more detailed status and use it pervasively

[I never could figure out how to flesh this one out better].

End of iMail proposal

Conclusion

Email, while used by over 4 billion people(!) regularly, has been declining in importance as messaging and social media and collaboration tools forge ahead. However, people generally still want the same things out of their interactions with others so no idea is truly ever gone forever.

I have no visual design skills and I’m not very good at pitching things, but I gave it a good try. I presented the idea at a meeting with our representative from the Human Interface Group and Scott Forstall (I don’t recall what his position was at the time). I was disappointed he shot it down, but not particularly surprised.

Here are the ideas I jotted down sometime in 2003 (I think). I left it in original form and [I’ll put any commentary in brackets].

Column-view email threading proposal (unedited)

Why this is really important

• Many email clients have threading support and threading UIs, but none of them are very good

• Threading is an incredibly useful idea that every Mail user could benefit from

• I think this is an opportunity to catapult ourselves over other clients in terms of usability

How other clients do it

Every other client that supports threading uses a nested list view (like the Finder) to present an ever increasing hierarchy of messages. Just like with Finder’s List View, it’s a repetitive exercise in flipping and unflipping disclosure triangles, that is only made (somewhat) easier with an endless set of keyboard/menu commands (Next Message, Next in Thread, Next Thread, Previous Thread, Previous in Thread, Previous Message, etc). It’s also presented as a mode that you must enter and exit, making it less appealing to even advanced users that can understand how it works.

[I really hate list views].

Proposal: a column-view interface for threading

Essentially, an iPod-style interface, with one ‘column’ showing at a time. The message list would look exactly the same as it does today, with the addition of arrow icons in the message list to indicate which messages are part of a thread.

Here’s an example of how the message list would look when first opening a mailbox. [Note that the idea was that the mailbox would look no different than it did before threading existing. Messages did not get coalesced based on being part of a thread. The idea was that threading would be “always on” and those that chose not to use it wouldn’t notice anything different other than the arrows indicating there’s more than one message in the thread.]

“Standard” View:

Messages that are part of threads would indicate this with a right arrow icon at the right edge of the message list, similar to how both column view in the Finder and the iPod indicate this. Hitting the right arrow key when the message shown above is selected would swap the message list (using a column view style animation) with this message list:

“Threaded” View:

Note that the same message is selected as before, the same sort order is preserved, but now we see all messages that are part of this thread displayed. Left arrow would bring you back to the original message list.

Sent messages integrated in the list of messages for a thread

A really important (and cool feature here) would be the integration of your sent messages with the messages in a thread, allowing you to see an entire back-and-forth correspondence with one person or a group. In the screenshot above, note that messages I’ve sent are integrated into this ‘thread’.

[Believe it or not, the original design for the list-view-based thread interface was to NOT include sent messages. I argued that this was the main reason for having threaded view at all. The mindset was helping people manage high-volume mailing lists in a work environment rather than the more typical back-and-forth correspondence a home user might experience. Threaded views were typically an advanced user feature and I saw it as something that everyone would find benefit from. The shipping version of Mail threading included sent messages.]

Simple arrow key navigation

Using only left and right arrow keys, it would be possible to jump in and out of threads, without needing a dozen keyboard shortcuts that other clients have had to devise to deal with thread navigation. The arrow icons in the UI would serve as a great mnemonic and would likely be highly discoverable.

Always on

Using this threading UI, we could ship it in an ‘always on’ configuration, so that all users could derive benefits that threading provides, not just power users that have grown up on newsreaders. [Ouch!] The default configuration would allow Mail to run as it currently does, while providing an easy way to jump into threads without changing modes.

Flat threading hierarchy

In the screenshot from Netscape (see first screenshot in this message), note how the same thread has split into subthreads, leading to a nested hierarchy that could theoretically go on forever.

A one-to-one correspondence, when viewed in a List View threaded mode would look like this:

Message 5 (Your reply to Message 4)
    Message 4 (My reply to Message 3)
        Message 3 (Your reply to Message 2)
            Message 2 (My reply to Message 1)
                Message 1 (The original message sent by you)

A column view style display would allow you, for example, select Message 3 in the Inbox, hit the right arrow key, and see this:

Message 5
Message 4
Message 3 (highlighted/selected)
Message 2
Message 1

This would show you precisely where the selected message fits in with the rest of the messages of the thread, allow you to jump back to the first message, or read messages that have come in later than Message 3.

[Note that a flat hierachy is the norm today in social media like Facebook and Twitter. Not that this necessarily validates my design!]

A summary of the advantages of this threading UI:

• Power of threading available to all users, not just power users

• Uses column view style browsing that is used by the iPod and popular with users of the Finder

• Essentially modeless operation (threading could always be ‘on’, since current behavior of the message list would be preserved).

• Simple keyboard navigation (only uses left and right arrow keys)

• Easier to select and act on messages in a thread (i.e. what does a ‘select all’ do when a message is selected in part of a thread showing in List View?)

• Better use of horizontal space (since there is no indenting)

• Threads could become virtual mailboxes in Mail (much like we’ve talked about virtual search mailboxes)

• Issue with sort order are less problematic to solve (i.e. When you sort by date, does that mean sort the top-level threads by date or sort items within a thread by date?)

• Sent messages are integrated (a top requested feature from customers)

Why it’s better even for power users:

• Multiple entry points to a single thread

• Easy to jump in and out of threaded mode for those that like to switch contexts often

• Highly favors easy keyboard navigation, most often used by power users

Why List View threading is a terrible interface for threading

Summary

• Keyboard navigation is excruciating

• Lots of flipping and unflipping triangles

• Lots of scrolling to arbitrary locations in a list of messages

• Lots of switching in and out of threaded mode to see messages sorted by date

• Completely unusable in the INBOX

• Difficult and cumbersome to act on entire threads at a time

• Requires lots of new keyboard shortcuts and menu item commands

[Not that I felt strongly about it or anything.]

For the sake of example, I listed a number of common operations that threading potentially offers users, and how List View compares to Column View threading:

Selecting all messages in a Thread

• List View

  • Scroll to arbitrary location, click mouse, scroll to arbitrary location, shift click mouse

  • Use ‘Select All Messages in Thread’ menu command, if available, or the command shortcut, if available

• Column View

  • Right arrow (if needed), Select All

Moving to the beginning/end of a thread

• List View

  • Scroll to arbitrary location

• Column View

  • Scroll to beginning or end of message list, or use Home or End keys

Note: Don’t underestimate the drudgery of scrolling to arbitrary locations! It’s far easier to drag a scroller to the beginning or end of a list or to use Home and End than to attempt to nail the beginning or end of a thread in a long list of threads/messages

Deleting/transferring all messages in a thread

• List View

  • Scroll to arbitrary location, click mouse, scroll to arbitrary location, shift click mouse, Select All, delete or transfer

  • Use ‘Select All Messages in Thread’ menu command, if available, or the command shortcut, if available, then Select All, then delete or transfer

  • Use ‘Delete All Messages in Thread’ menu command, if available, or the command shortcut, if available

• Column View

  • Right arrow (if needed), Select All, delete or transfer

Note: In List View, there is a serious problem when transferring/deleting the parent message in a thread. Most threaded email clients just act on the parent message and don’t bring the entire thread along for the ride. If we want to act on the whole thread, how do we distinguish that from a normal drag of the parent message? With Column View threading, this is far less ambiguous.

Opening/closing a thread

• List View

  • Scroll to arbitrary location, click on flippy triangle in arbitrary location

• Column View

  • Right arrow to open, left arrow to close

Navigating messages in an unthreaded view

• List View

  • Exit threaded mode via menu command, keyboard shortcut, or window widget

• Column View

  • Left arrow key

Seeing sent messages as part of thread (a top user request)

• List View

  • Not supported

• Column View

  • Integrated into the thread

[What about compared to the leading brand! Note that this was not supported at the time I wrote this.]

Finding unread messages in a thread

• List View

  • Scroll to arbitrary location, possibly offscreen, check to see if any unread messages exist

  • Devise another level of hierarchy on top of the existing List View hierarchy to separate unread messages from read messages

  • Invent another new widget to hide/reveal read/unread messages

• Column View

  • If thread is shorter than the number of messages that the message list can display, you just see your unread messages (Note that even short threads could end up with offscreen unread messages in List View)

  • If thread is longer, scroll to the beginning or end of the message list (depending on your sort direction)

  • Status Link could indicate unread message count in the thread, so you could know ahead of time if there are unread messages (In List View, this could only be accomplished by overloading the status line or putting individual unread counts at the top of each thread in the message list).

Sorting a thread’s children differently than thread parents

• List View

  • Either impossible or incredibly messy, possibly involving introducing a second tier of sort columns inside of each thread

• Column View

  • Threaded and unthreaded are separate views, so this is not a problem

Alternative interface ideas

[I toyed with the idea of the message list becoming a split-view when you selected a message that was part of a thread. In the screenshot below, after selecting the message from Nitin, the left column would start showing the thread subjects and the right column would show individual messages in the thread.]

[There was also an idea of including a 4-way control, which I stole from DVD Player (I think?) for this screenshot, to navigate in and out of threads as well as within a thread].

End of column-view email threading proposal

Present day

It’s obvious I felt pretty passionate about this when I go through these old notes! I took some solace in the fact that the list-view style threading was eventually removed from Mail in favor of the new “conversations” view. This includes some of the ideas I was proposing and I think it’s definitely a big step forward.

Part of the deal for participating in this scary experiment was that if people encountered problems, I would immediately show up in their office and provide technical support to them. Not only did I meet virtually everyone on the Mac OS X team, but I also got to meet many of the directors, VPs, and executives.

Secrets

As an amusing consequence of this, I would sometimes accidentally find out about future projects I was not supposed to know about. Email was king back then, so it’s difficult to provide support while looking away from the user’s screen so you don’t see anything. If someone not disclosed on what you’re working on, you’d typically lock your screen so they wouldn’t see anything. But my job was specifically to look at their screens and troubleshoot.

One of the most common things that happened would be someone having a problem with a specific email. The best way to troubleshoot was the get the raw source of the email. However, the raw source contains everything in the email, including attachments. I inadvertently learned about several designs from the Human Interface group before I should have, for example.

But my favorite story in this vein was when I was contacted by Jon Rubinstein, then the Senior VP of Hardware Engineering. I went up to his office to check out his problem. His office was arranged like many people working on sensitive projects. His desk was facing his door so that no one could see his display and no one could peek in without him knowing.

He got out of his chair and motioned for me to sit down at his desk to debug the problem. I rested my hand on the mouse. I moved it a bit. It felt heavier than I expected. I looked down at it and although it was the right shape, it was milky white. Puzzled, I picked it up and noticed it had no cord attached. The shipping Apple Mouse at the time (2002) had a tail on it.

As it slowly dawned on me, I looked up at him. He slowly brought his index finger in front of his mouth. So, Apple might be working on a wireless mouse? I never told.

In-person feedback

In my earlier days at Apple, feedback was almost always provided (in person) in a post-interview feedback session in a conference room. Typically, we’d take turns talking about the candidate, mentioning the topics we covered and how they did.

Benefits:

This provided a nice back-and-forth between interviewers as we tried to build a complete picture of the candidate. Everyone would know what happened in every interview session. This would trigger further questions and answers between the interviewers. This was also an opportunity to try to reconcile differing opinions about various qualities of the candidate. One of the biggest benefits of these sessions was the hiring decision was made right there. Everyone whose opinion was considered was in the room.

It was a great consensus-building activity. We required unanimous support for a hiring decision. If there was some dissent, we would consider bringing the candidate back for a second day, bring in some new interviewers, and hammer them on what was found lacking.

I remember one particular interview where everyone raved about the candidate, but I thought he was arrogant and he rubbed me the wrong way. He described himself as an “expert” in both Objective-C and C++, so we brought in two experts in those areas. They gave him more advanced questions and also played devil’s advocate on some of the accomplishments on his resume. He came unglued and we didn’t hire him.

Drawbacks:

The biggest problem with group feedback sessions is that your opinion may be colored by what others say before you speak. If five people in a row speak badly of a candidate, you may revise your glowing review downwards. It’s human nature.

There are other downsides like the time a feedback session can take out of the schedule of a large group of people as well as the difficulty in finding a time everyone is available. Some of the feedback sessions could exceed an hour.

Solution?

One practice we used to counter the main drawback was something we called the “Thumb-o-meter”. It originated at NeXT and was carried into the Mac OS X group where most of those engineers landed.

The concept was simple. Before the feedback session began, we would count to three and then hold up our thumb rating, channeling rock-scissors-paper. Anything from full thumbs up to full thumbs down was acceptable. Here are what five reference thumb positions stood for, based on a clock:

• Noon: Hire immediately

• 10:30: Hire if no one has objections

• 9:00: Indifferent

• 8:30: Concerns about hiring

• 6:00: Don’t hire

After people held up their thumbs, someone would jot down what everyone voted, usually in 30 minute increments at most. This had one critical benefit. If everyone was thumbs up or down, then there was no need to take any more time from the interviewers. Meeting over! In some cases, if only one or two people weren’t on board, the feedback could start with them. If they are not swayed up or down, then we could proceed with the full feedback session.

But the biggest benefit was that this was a check against people changing their verbal feedback. It was also kind of hokey and fun. Someone would jot down the ratings quickly before anyone could sneakily drift their thumb in either direction. It was self-policing.

Email

Over the last 10 years I was at Apple, feedback migrated much more towards providing it via email to the manager and/or recruiter.

Benefits:

Due to teams being larger, not all in the same physical location, and the difficulty of finding conference room space and compatible times, email was often the ideal way to handle feedback. Even a video conference would cause schedule and time disruptions.

Even if someone was trying to take notes at an in-person feedback, having a written record of feedback can be essential if there is debate about a candidate.

Provided the manager or recruiter don’t read the feedback until they have finished theirs, this can be a way to capture more honest feedback that is not influenced by peer pressure.

Drawbacks:

With email, everything is many-to-one, so there is no dialog between interviewers. Sure, you can try to get clarification from different interviewers, but it’s more ad hoc and uneven.

One of the biggest impacts is that the interviewers feel more disconnected from the hiring process. You don’t see what others have said before a decision is made. It’s a bit like voting and then watching the results on election night.

Subjectively, I feel like the new hires that come from the email feedback process have generally not been as strong. I think when you are writing feedback, you are more careful and collected and might be tempted to be more positive about a candidate so you’re not the odd person out. My theory.

Also, with email feedback you’re spending far less time considering a candidate as you are not listening to the feedback of others and thinking mostly about your own. I think this type of feedback leads to less thoughtful hiring decisions.

Solution?

There are a couple of technical solutions that could improve some of the drawbacks of email feedback. You could set up a website to submit feedback. Once all feedback is submitted, then the site unlocks and every interviewer can see everyone else’s notes. Perhaps it could be like a message board where you could have a dialog with each item of feedback.

You could also set up a room in Slack (or equivalent) specifically for feedback about a particular candidate. People could be free to pop in and out of the room, asking and answering questions, as their schedule and time allows. Basically a somewhat time-disjointed group feedback session.

Conclusion

There’s no one way to handle interview feedback, so I’m just providing an overview of two ways that Apple chose to handle this over the years. If you can find a conference room and everyone is available and can devote a block of time, I think an in-person meeting (or video conference) is well worth the time invested. Hiring the wrong person can be a drain on the team and the organization.

However, we have to recognize that all getting together at once is increasingly less possible, so perhaps employing some new technical strategies could be the best option of all.

I had a number of interview topics I liked to deploy. One of the most important to me was learning what software projects the candidate had accomplished that were not part of a class at school or a job. It was a big red flag if a candidate has no side projects, and learning about any side projects could reveal a tremendous amount about them.

In 2001, when I was on the Mail team, I interviewed a candidate, who I will call Felix, for a QA position on Address Book (now Contacts). In addition to testing experience, we wanted someone with excellent scripting ability.

We found people that were strong scripters, but lacked testing experience. Felix was the opposite: rather weak on scripting, but solid everywhere else.

The candidate put a link to his website on the résumé. Before the interview I poked around and found a page of scripts that he had written. They were mostly simple work-related geeky scripts.

One script caught my eye: cactus_watering.pl. It would connect to a weather server and get the daily rain forecast for Tuscon, AZ. If rain was expected, it would email anyone on the happy-cactus mailing list to tell them to water their cactus.

It’s always a positive sign for me when people post code they’ve written, no matter how impressive or unimpressive it is.

I loved it for so many reasons.

1. I appreciate when people are not shy about publishing code they’ve written, even if they are not exactly revolutionary. They are allowing criticism as well as helping others learn things.

2. Choosing a portable language like perl or python rather than a shell scripting language shows good programming choices.

3. The script was nicely written and documented. It’s one thing to write a quick-and-dirty script; it’s another thing to write something for public consumption.

4. I like when people see a need and try to find a software way to solve it. Felix could have easily just done a Google search and called it a day.

5. Even though it was a fairly simple script, it did involve networking, text parsing, sending email to a mailing list, and daily scheduling for running the script.

6. It showed a genuine sense of humor and an enjoyment for writing code.

7. One of the best way to enhance your testing skills is to write code that you and others will use. This gives you insight into those that are writing the code you are testing.

8. I felt like it gave an insight into his personality and helped determine whether he’d fit in well with the team.

Oh, and we ended up hiring Felix. He stayed for more than 15 years.

• I’d ask them first if they had any questions. They always expect that at the end.

• I’d pick something on their resume I didn’t understand and had them explain it to me

• I’d belittle something on their resume to see if they were arrogant or had easily hurt feelings

• If they used the word “expert” on their resume, I would study up on the subject ahead of time and see how much of an expert they really were

• I’d ask them how they would either implement or test a project that synced bits of data with a server and multiple clients

• I’d ask them to name their favorite and least favorite Apple product and why

• I’d ask them why they wanted to work at Apple and press the hell out of them. Apple must be someone’s first choice

• I’d ask them if they could fix one bug in an Apple product, what would it be

• I’d ask them about the biggest asshole they ever worked for and how they handled it

• I’d give them a list of made-up bug title and have them prioritize them from 1 to 10

• I’d ask them to describe one of the pet projects they’ve written on the side

Several of these are showstoppers, but the last one is the biggest.

If an engineer has NEVER written a side project in their life, they don’t deserve to be hired. Everyone has to have a passion, an itch to scratch, something that gets them excited. Everyone should see a hole out there that no one has ever filled or filled poorly.

• Apple makes some really great products (and bad ones too)

• People are cynical about big companies and believe that if someone is telling them how great something is, they are lying

• Steve Jobs was a very, very persuasive person

Having said that, I did witness one event that was definitely a reality distortion field. No one wrote about it or criticized him for him. It’s like a hypnotic spell overtook everyone who saw or read about it.

Mac OS X ship dates

Like any major software undertaking, Mac OS X was perpetually late. Apple promised Mac OS X would finally ship in the fall of 2000.

Like anything associated with this story, there is no YouTube video, no transcript, nothing. You only have my word on it.

Steve Jobs got up on stage at MacWorld New York in the summer of 2000 to tell everyone the progress of Mac OS X. A round of applause followed him saying that everything was on schedule.

But…

He said they were going to change the name of the releases. The fall 2000 release would now be Public Beta and the final release would be in the spring of 2001.

Rename?

Hardly. That’s what you call a final release that is 6 months away.

But he got away with it.

Why?

Partly I think it’s because people wanted SOMETHING to ship and couldn’t care less whether it was 1.0 or a beta. So, no one cared.

But maybe it was an actual instance of the reality distortion field.

Not so at Apple. We can guess the ship date based on when our planned completion date is. But this is software. It’s perennially late, so you just never know.

One high profile case of this was with the first release of Mac OS X.

Nearly the entire Mac OS X engineering team was in the audience on January 9th, 2001 at MacWorld Expo. This was the public unveiling of Mac OS X and the Aqua user interface.

Us engineers were nervous for many reasons. First, what would the reaction be to the new Aqua user interface. A lot rode of the acceptance and love of it.

Second, here Steve was demoing something that we know was far from being shipping quality. I worked on Mail at the time. Steve deviated from the script and Mail crashed, only to return by switching to a backup machine. Talk about nerves.

Surprise!

Then the surprise happened. Steve announced Mac OS X was shipping on March 24th. Of the same year! We were doing the mental date math in our heads and were horrified.

Several of us mimed getting up to get back to our desks to get back to work.

But Steve knew what he was doing. It had dragged on long enough. We had to ship it. Apple was in serious trouble and the new OS was the one thing that could save it. Well, and the iPod, which was merely an idea at the time. And without a viable Mac, there would be no iPod.

So that’s the story about how the entire Mac OS X engineering team found out when their product was going to ship.

At the same time everyone else in the world did.

The animation first appeared in Developer Preview 4 and many thought it was a placeholder for something more polished. However, after awhile, many people seem to take a liking to it.

The legendary poof animation came out of a discussion of the Human Interface team that wanted this action to have an animation to go with the very liquid Aqua interface.

One of the most talented engineers on the team took out a piece of paper. I wish I could say it was a napkin to make the story better.

On the piece of paper, he drew a series of five frames. The intention of the designer was that these drawings would stoke further discussion. That it would get cleaned up and refined later.

But that never happened. It shipped as is. And the rest is history.