The Source of Technote #2034
Former Apple Evangelist Tim Holmes started a huge Twitter reply chain referring to this podcast episode:
I admit responsibility for Technote 2034. An act of civil disobedience.
It’s Avie’s 10 commandments. I felt devs should know. Some engineers felt they were losing Mac OS.
As a non-coder, I was less personally offended than some, but paths sure did feel like the beginning of the end.
I had an agenda… impart a reality check. It was ’01… no way devs could comply.
Still have 2001 emails as to why & from outraged devs asking if I’d seen it & if I could help fix it
Fragility is the real issue. Remove a few letters and it breaks w/no easy fix.
Back in 2002, Apple published a technote, Technote 2034, which was one of the most pro-Next, anti-classic-Apple things that was seen in a long while. It was met with immediate, violent reaction, and Apple withdrew it.
Of course, I wrote a reply which I emailed to Apple and filed as a bug in Radar (closed as duplicate). But that didn’t seem to be enough, so for WWDC 2002, I made up a batch of No To TN2034 buttons that I handed out.
John Gruber (2003):
Tevanian’s legacy is marred, however, by Mac OS X’s usability flaws, most of which are attributable to Tevanian’s nearly unyielding obsession with promoting old Next technology over old Apple technology. His technical acumen may be undisputed, but neither is his tin ear for usability.
Epitomizing this flaw was the infamous Technical Note #2034, entitled “Mac OS X Programming Guidelines”, which as reported by MDJ was written by Tevanian personally. Technote #2034 was so inflammatory, and in places so ludicrous, that Apple withdrew it afters howls of derision from professional Mac developers.
6 Comments RSS · Twitter
What was all the fuss about? Most of those suggestions seem entirely reasonable to me, especially from the perspective of today.
@Kevin Did you read the links above? They explain some of it. The file extension and HFS+ metadata issues have been extensively discussed here and elsewhere (e.g. by Siracusa). You also have to consider the world at the time it was written. For example, now Mach-O is standard; then, the toolchain for it was very rough. Now, the frameworks support file reference URLs; then, using paths or URLs led to a degraded user experience (and a couple high-profile data loss bugs). Now, Cocoa is clearly the best way to develop Mac apps; then, it was missing lots of features and the widgets were not very Mac-like. The bottom line is that certain people within Apple were dictating changes seemingly without understanding any of the benefits of the current approach.
@Michael: I did read them; I wasn't a Mac developer then so I guess I lack context to understand some of the complaints.
From a usability POV, apart from the brittle file name extensions that replaced the more solid type/creator codes, the main issue people had were the "Investigate using path-based file-system APIs" section. Previously, Mac applications did not care about where a document was located. You could open a document in an application, start editing it, move it in the Finder, and just continue editing it. After the switch, some applications could no longer find a file file that was moved while it was open, and would fail in interesting and unusual ways.
@LKM Right. The other filename extension issue is that Apple never offered a replacement for creator codes. Some people liked having files open in the app that created them rather than in the default app for that file type, i.e. some image files open in Photoshop and some in a viewer; or some text files in BBEdit, some in a browser, and some in an IDE.
