Decades before Liquid Glass appeared on the scene to blur Apple’s user experience, translucency snuck into the Macintosh user interface thanks to subterfuge and a culture of mutual support among engineers.
In December of 1993, the first Power Macintosh computers were a few months away from being announced publicly. With my colleague Ron Avitzur, I had spent six months sneaking into and squatting at desks in Apple’s Infinite Loop campus. As our badges from earlier projects had expired, friends at the company would hold locked building doors open for us, bring us rare hardware prototypes to work with, and offer programming advice and debugging help.
We were developing Ron’s interactive Graphing Calculator application into a showpiece for the leap forward in speed and user experience made possible by the new PowerPC processors. Our software project was an exciting, beautiful, and unsanctioned team effort.
As an initial release of the calculator felt increasingly coherent and stable, our desire to add useful and slick features was surpassed by our fear of introducing bugs. The goal, and perhaps the main compensation, for the months of day-and-night efforts was going to be the satisfaction of seeing it in the hands of a million students and math aficionados.
Ron had made a long and ultimately successful effort to persuade Apple management to include our software on the hard drives of the first PowerPC Macintoshes. The program’s rock-solid stability and impressive interface and graphics had won them over. If a single serious bug slipped in with any late code changes, Apple could reverse its decision.
Ron and I reminded each other daily that our unofficial project should be considered to be in a virtual code freeze. We had built and refined the software. We knew that our own misguided self-confidence in making unneeded changes was the biggest threat to its release. So, aside from addressing major bug reports, as developers we sat on our hands.
Our lives were mostly lived in the office buildings where we did not officially work, and I needed a new project. One idea that had been lurking in my mind for a year seemed worth trying: taking advantage of the Drag Manager hooks.
On the Mac, the Drag Manager had just recently been introduced. This set of APIs provided a way for any developer to let their users drag items within and between applications. The operating system would handle the mouse interactions during the drag, as well as draw the dotted outline that represented the objects being moved.
Dotted outlines, drawn primitively by flipping pixels in the screen’s memory, were all there was in the operating system for interactivity as the mouse dragged objects. The original 1984 Macintosh only had a black-and-white screen, with no colors and no grayscale pixels. The processor was slow, and memory was tight. While colors had been added to Mac screens over the following decade, color support was not universal. On some Macs, color was just provided with an 8-bit display, offering too few shades of color to make realistic or subtle compositions on screen.
As color screens became more common and pretty Finder icons became the norm, the dotted drag outlines felt primitive. The cutting-edge NeXT Computer supported dragging using full images on screen, so that seemed an obvious and overdue evolution for the Mac as well.
Coincidentally, I shared an apartment that year with one of the engineers that created the Drag Manager, Dave Evans. Each time I ragged him about the primitive appearance, he would remind me that there were documented methods in the API to let other code get hooked in for controlling the drawing. Those hooks let any software tell the Drag Manager hey, call me to draw the feedback on the screen. Dave probably knew better than I did what minefields lay in drawing on the Mac screen of that era.
One evening at the office, to keep myself away from the Graphing Calculator code, I started banging away on enabling translucent dragging of icons and other objects on the Mac. Quickly, the challenges became apparent.
The reasonable way to draw complex interfaces on computers is to create separate memory buffers for laying down and combining the images that will eventually appear on screen. But in the early 1990s, memory was not yet abundant and cheap enough to support many screen-size buffers. The Mac saved memory by drawing its controls, windows, and images directly to the screen’s memory.
Dragging objects translucently would require using buffers. The dragging code had to copy the screen’s pixels from near the mouse location, mix the object images so that they would appear to be hovering over the pixels from the screen, and copy the mixed image to the screen. Then, each time the user moved the mouse even a pixel, the code would immediately restore all the original screen pixels and start over at the new location. All of this had to happen continually in small fractions of a second to maintain the illusion of the moving objects being translucent.
The problem was that all of this was only barely possible on the Macs of the day. There might not be enough memory available for buffers to draw in. Even worse, if we approached the computer’s hardware limits, the Mac might try to swap some of the memory to the hard drive.
Swapping memory would create a huge delay, killing the user’s feeling of interactivity. Everything involving drawing on the Mac screen in those days was synchronous; it blocked whatever the user was doing with the mouse or keyboard. Spinning up the hard drive would cause the user’s drag to be a jerky annoyance.
The challenges went beyond memory. A 1990s Mac might have a black-and-white screen, or an 8-bit color screen with a palette of color choices that would not allow a convincing color mix to create a translucent image. Or it might have a great 16-bit color screen sitting right beside a black-and-white or 8-bit screen that the user could be dragging the objects to or from. There could be any number of screens that objects were being dragged over, each screen a unique challenge.
I stayed up late every night for a week working on translucent dragging. First, I wrote the drawing code to create the illusion of translucency, at a speed that maintained the Mac’s interactive facade. Then came the endless refinements, from determining when memory was too scarce or slow to attempt the drawing, to analyzing the window color palettes to decide if there was enough subtlety to draw translucency convincingly.
The 1990s were long before the Macintosh had robust protection against memory corruption. Writing incorrectly to video memory could easily crash the operating system. Bugs during development would mean I had to reboot; any bugs that lingered after development would mean users would have to reboot. For stable software, I had to understand all the impacts and side effects of the code and every byte of memory it could touch.
Another difficulty was that I was not an Apple employee. I was not an engineer on the Drag Manager team, nor on any part of the operating system. I could not see the source code for either the Drag Manager or the operating system. I had to write the translucency additions using only the hooks publicly offered by the Drag Manager, along with intuition about how dragging should work. Still, it seemed like it should be doable.
By the end of a week, it worked. Objects looked beautifully and naturally translucent as I dragged them on the screen. 8-bit screens worked when they could. Smooth interactivity was preserved. The code fell back to dotted-outline drags when screen depth or memory limitations cropped up. Now I just had to figure out what to do with my code.
I could have released the software independently as a third-party hack; Apple had not asked for or paid for its development, though I had written it in their offices and on their hardware.
My real hope, though, was for translucency to become part of the operating system, visible to everyone for dragging icons in the Finder and available to any program that wanted to use it. I created a simple one-line API so any developer could provide the image to be dragged translucently. Then I went to show my work to the director of the user interface group at Apple, Mitch Stein.
Mitch was an advocate for flashy features. He loved it. With little discussion beyond a demo, Mitch said he’d buy it. I asked for $25,000 and he quickly agreed, since he had money unspent in his year’s budget. That was a fine payday for one week’s work—and more than I’d end up making for the six months I had spent sneaking in and working with Ron on the Graphing Calculator.
Feeling like I ought to do more to justify the pay, I spent several more nights adding 25 pages of comments documenting the 25 pages of code I was delivering to Apple, aiming to deliver it all before the end of the year. Each limitation and constraint was explained in hopes that future engineers who had to maintain or update it could know not just how it animated the dragging, but why on some machines at some times it was unable to do so.
Mitch was so enthusiastic about translucency that he showed me other concepts he felt were promising, such as fully translucent windows. Among the more exotic ideas he was considering were windows that would appear to fall down backwards in a 3-D space as a way to minimize their presence. He asked if I could implement those. I lied and said “no.”
It was true that neither the hardware nor the operating system support was available at the time to make those ideas fully practical, as they would become a decade later. But I also didn’t want to implement even small scale or limited versions of them because making text blurry and harder to read was anathema to the usability that underpinned the Macintosh. Brief image blending during drags felt excusable; permanently obliterating contrast and clarity was not.
After delivering the dragging code at the end of 1993, I waited for someone at Apple to integrate the code into the operating system. And waited some more. The new PowerPC Macs were released in March 1994 with System 7.1.2 and with the Graphing Calculator. In September, Apple released a horde of new features in System 7.5, but without translucent dragging. And then updates were released for 7.5, but still without my code.
My slight frustration at the delay became more pronounced when a friend showed me a prerelease version of Microsoft’s Windows 95, then still called Chicago. Among its trove of improvements over Windows 3 was a kind of translucent dragging of icons in the Windows Explorer. At the time, it felt unimpressive, with dithered icons looking like 8-bit pieces of Swiss cheese being moved on the screen, but it reinforced my frustration that no effort at Apple was being made to ship the Mac’s translucent dragging code. I feared that by the time translucent dragging came out on the Mac, it would look like a response to Windows 95 rather than a predecessor.
By late in 1994, my friendships with Apple engineers led to a paying job as a contractor, tracking down bugs in the latest Mac system releases. I started visiting colleagues on engineering teams who could do what Apple management had lost interest in: ship the translucency.
Getting the drawing code into the Drag Manager itself was easy. My friend Dave continued to maintain that part of the operating system and could adopt my code. Then a bigger challenge cropped up that at first seemed insurmountable.
The Finder, which Mac users relied on to interact with file and program icons, predated the Drag Manager. To draw dragged items, the Finder still made older calls into the operating system, bypassing the Drag Manager. As the centerpiece software on the Mac, the Finder team had a carefully planned and managed schedule. That schedule did not include rearchitecting their dragging code.
With the advice of a Finder team engineer, I conceived a way to do it. It would be an unconventional and ugly approach, but it seemed possible, and the result would be seamless for users.
The Finder was a huge application written in C++. I created tiny snippets of assembly language code to patch out and override the Finder’s old dragging calls in the operating system, redirecting the Finder so it was unwittingly relying on the newer Drag Manager—and on the translucent drawing code.
My patches were implemented as a string of hexadecimal numbers directly inside the Finder’s C++ source code, literally the machine code bytes to be used to redirect the Finder as it made the older calls. It was a gross hack, leaving in code the fingerprints of my desperate effort to find a way to get the feature included, but it worked. No other effort was required by the Finder engineering team.
One important step I had neglected, though I should have learned it from Ron’s efforts to ship the Graphing Calculator: finding some way to get official buy-in. A string of successful skunkworks efforts, including the Graphing Calculator and the secret about box of the iguana flag, had earned me the trust and goodwill of developers at Apple. Still, getting onto official release schedules requires the cooperation of the engineering and product managers, not just programmers.
All the pieces of translucent dragging were in place for the next update, System 7.5.3. Unfortunately, when the translucent dragging code and associated Finder hacks first came onto the radar of the manager responsible for the system updates, it wasn’t because of his team’s planning of the list of approved fixes and changes.
Rather, he learned about translucent dragging after the update was first being built, from user feedback for a private test release. A system update intended to have no visible changes suddenly had a huge user interface improvement, one that test users really liked.
The manager was understandably upset by the surprise. Thankfully, he decided against removing the feature. I was not present for the discussions, but my engineering friends and co-conspirators were supportive.
The hack stayed in the Finder, my code stayed in the updated Drag Manager, and they shipped out to everyone’s Macs in 1996. Translucency became a standard attribute, and for many years a blissfully subtle one, of the Macintosh user experience.
A year later, Steve Jobs would return to Apple, bringing with him top-down control and discipline. The company was in need of that focus, but it came at the expense of the engineering esprit de corps that had brought unsanctioned innovation, and a few unofficial developers, to the company in the preceding decade.
