Skip to Content
Skip to Table of Contents

← Previous Article Next Article →

ATPM 7.10
October 2001



How To



Download ATPM 7.10

Choose a format:

The Personal Computing Paradigm

by Michael Tsai,

Mac OS X 10.1—First Impressions

Mac OS X 10.1 is the most anticipated software release from Apple in recent memory. Sure, everyone was excited about 10.0, but it was clear that it wasn’t the kind of release that you just install without thinking. Call it a second public beta or simply a one-point-oh, but most everyone agrees it was rough. Now the spotlight is on 10.1. This is the first release that Apple isn’t stealth-marketing, and they’ll probably make it the default OS on new machines soon. Let’s see how it stacks up.


For me, the most annoying part of 10.0.x was how slow it was. Classic applications were more responsive than native ones, the Finder list view was unusable, and I dreaded the appearance of the Spinning Pizza Of Death (as Bare Bones Software calls it). 10.1 is faster across the board, from launch times, to pulling down menus, to Classic. In some cases, the improvement is quite dramatic. On a newish Mac, OS X is now plenty fast for everyday use, although in most cases it’s still not as responsive as OS 9. The Finder, though vastly improved, still locks up much more than the OS 9 Finder, especially when dealing with iDisks (despite all the hype about how WebDAV would make them fast).

Feature Reinstatement

I never understood why Apple got so much flak when 10.0 couldn’t burn CDs or play DVDs out of the box. These are certainly important features, but in my opinion there were far more critical things to fix. In any case, 10.1 can burn CDs and DVDs from the Finder, and it can play DVDs. The new DVD Player application is a big improvement over its OS 9 counterpart because it can play in the background without skipping. Unfortunately, it doesn’t let me move the Viewer window onto my second monitor and it spontaneously quit the first time I launched it.

Mac OS 9 has a feature called the Notification Manager that, among other things, lets an application get your attention by flashing its icon in the application menu. This feature returns in 10.1 in the form of application icons that bounce in the dock. This makes sense visually, but unfortunately the bouncing is so extreme that I feel obligated to tend to the application immediately to make it stop. (Hiding the dock doesn’t hide the bouncing icon.)

The OS X version of Disk Copy can finally create disk images. Alas, Apple somehow left out the ability to make an image from a folder. In OS 9 you could drag a folder onto the Disk Copy window, pick a name, and be done. In 10.1 you have to first figure out how big the folder is, then ask Disk Copy to create an image of the proper size, then copy the files onto the image, then have Disk Copy convert the read/write image to a read-only compressed one. This is particularly bad because disk images are about the only way to archive files while preserving Mac metadata, resource forks, and long file names.

File Name Extensions

As I wrote in May, Mac OS X departs from the friendly and functional world of Mac OS type and creator codes, instead favoring Windows and Unix-style extensions at the end of filenames. Apple was widely criticized for this, because most Mac users find the classic Mac OS way superior. The best discussion I’ve found on this topic is John Siracusa’s ArsTechnica article on metadata. Further thoughtful discussion can be found in the archives of Apple’s Human Interface Developers mailing list.

Anyway, this criticism appeared to fall on deaf ears. Apple was working on an improved solution and didn’t want to discuss the issue until they had worked out the details of their new system, an alleged improvement over both the OS 9 and OS 10.0.4 schemes. This spiffy new system for keeping track of file types is part of 10.1. The details are explained in a long e-mail from Apple’s User Experience Technology Manager. To read them, go to this archives page, type in “archives” for both the username and password, and scroll down about halfway to where it says “File Name Extension Guidelines.”

The title of the document gives it all away: Apple’s usability breakthrough isn’t a revolutionary new way to keep track of file metadata. It’s not even a reinstatement of the popular Mac OS 9 system. Nope, the new system is that file extensions are now mandatory. It’s actually worse than that, if you can imagine. With 10.0.x, Apple recommended that applications add file extensions in addition to the type and creator codes. With 10.1, file extensions are required and developers can set the type and creator if they want. Of course, some won’t bother and others will interpret this new guideline as an implication to only set file extensions. This will further degrade the user experience and reduce compatibility with Mac OS 9. There are many examples of this, but one of the most striking is that a file without a type code cannot be opened by many Carbon and Classic applications because they intelligently filter their Open dialogs to display only the files that they know how to open. If a file lacks a type code, the applications won’t know that they can read it.

Apple’s own TextEdit still doesn’t set the type or creator code. This means two things. First, if your default text editor isn’t TextEdit, saving text document from TextEdit will create a file that opens in a different application when double-clicked. Second, if you remove the “.txt” or “.rtf” extension from a TextEdit document, Mac OS X forgets what kind of file it is.

Some of you who have already played with 10.1 or read the aforementioned File Name Extension Guidelines are probably wondering why I’ve so far not mentioned Apple’s solution for hiding file name extensions so that users don’t have to see them. The reason is that the issue of hiding extensions is separate from the issue of type and creator information. Apple presents hidden file extensions as its answer to complaints about missing type and creator codes, but it misses the point. It’s not that we don’t want to see file extensions, but rather that they don’t include enough information and shouldn’t be needed in the first place.

That said, Apple expended a lot of effort on the new system, so it’s worth discussing the system’s goals and how it stacks up. Apple feels that it needs to support file extensions so that Mac users can exchange files with users of other operating systems. In Mac OS 9, InternetConfig maps file extensions to outgoing files based on their types. InternetConfig works well; however it’s not perfect, and not all outgoing files pass through it. To ensure that every file that leaves your Mac has a valid extension, Apple decided that every file should be created with an extension and that the OS should prevent you from deleting it accidentally. This reasoning makes sense to me, though I think the behavior should be optional for those of us who don’t value easy Windows file exchange above all else.

Combine this questionable, but reasoned, decision with the feedback from users who don’t like to see file extensions, and Apple’s next move makes a lot of sense. Since file extensions are required but users don’t want to see them, they should be hidden. So, naturally, Apple created the best system in existence for hiding file extensions. Reading through the gory details, I was impressed with how much Apple thought everything through. The new system is almost as friendly has not having extensions in the first place, and it avoids almost all of the well-documented problems that extensions cause on Windows. (Most notably, Apple can’t get around the fact that, file extensions, unlike type codes, will always be ambiguous.)

Nevertheless, the system is really just a clever hack. Since periods are legal file name characters, Mac OS X can never be sure what’s an extension and what isn’t. Sometimes it will guess wrong, as it does with an application I have whose name ends with “.0a9" (part of a version number). Sometimes hiding extensions will make several files in a folder appear to have the same name. The elaborate system of rules and guidelines is just that—elaborate. Most of the time the system will work as people expect, but sometimes a subtlety in one of the rules won’t match the user’s mental model. When the computer does something unexpected, the user feels like he isn’t in control.

Even though the system can never handle hidden file extensions perfectly, I think there’s value in providing the hiding as an option. If people want to use extensions for increased compatibility, the new system is a good alternative. However, there should be a way to disable (not just hide) extensions for those who don’t want them, and all Mac OS X applications should set type and creator codes so that the traditional Mac OS experience is possible. With these simple changes we could truly have the best of both worlds.


The Finder is much improved from 10.0.x, especially with regard to its speed. The list view is now fast enough to use. Navigating the column view from the keyboard is easy and quick (though keyboard navigation of the very similar Open/Save panels is still broken). The columns can now be resized, which is nice, but the resizing behavior still doesn’t feel right to me. I typically want all but the rightmost two columns to be narrow. That way I can see many levels of folders, yet still see the full names of the files I’m focused on. Unfortunately, this behavior is not possible in 10.1 because column widths are associated with folders, not columns of the browser. It’s possible to set everything up the way I want for a given display, but if I then drill down another level I have to resize the columns again. The other problem with the new column view is that the leftmost column often gets partially cut off, so that I can only see the second half of the file names. This happens even if it is the active column, i.e. the active column doesn’t automatically scroll into full view.

As I mentioned, the list view is very responsive now, but it’s still not as polished as in Mac OS 9. First, the default width for the file name is too short and there’s no way to increase it. Second, it still doesn’t remember which folder triangles have been expanded.

The icon view is also improved from 10.0.x in that the grid size now adjusts in tandem with the icon size—no more swaths of white space between small icons. However, it’s not usable for me because arranging by name is still broken. In Mac OS 9, an icon view that’s arranged by name will keep the icons arranged in columns that fill the vertical extent of the window. Make the window shorter and the columns get shorter as the contents fill out more to the right. In Mac OS X, if you make the window shorter the icons don’t rearrange themselves and you’re stuck with a single column that’s many times the height of the window.

Finally, I now realize that I gave Apple too much benefit of the doubt regarding features from the Mac OS 9 Finder that were missing in action in 10.0.x. File and folder labels and the awesome Put Away command are still absent from 10.1.


Mac OS X 10.1 introduces copying and pasting of files. Unfortunately, it doesn’t behave like copy and paste in other applications; it’s possible to paste a newer version of a file that you copied, or to “save” a file on the clipboard only to find out that you can’t paste it.


Opinions are divided about the fonts that Mac OS X uses. Many find them to be beautiful and very readable. Others of us find it much easier to read sharp, unsmoothed text. (A separate issue is the size of fonts in Mac OS X. I’m continually frustrated that the Finder views font takes up so much space and yet is less readable than good old Geneva 9.) Anyway, 10.1 at last makes font smoothing somewhat configurable: as in Mac OS 9, it can be disabled below a certain point size.

Unfortunately, the font smoothing preference is indicative of many other “choices” in OS X. Apple lets you choose between icon, list, and column views in the Finder, but the former are so crippled that most users end up “choosing” column view (thus “proving” that the NeXT way is better). The same thing goes for icons on the desktop and multi-window versus in-place tunneling through folders. These are not choices between the OS 9 way and the OS X way, but choices between the OS X way and pale imitations of the OS 9 way.


Which do you prefer?

The pattern extends to font smoothing in the sense that you get to choose between blurry smoothed fonts and hard-to-read unsmoothed fonts. Why are unsmoothed fonts in 10.1 hard to read? There are two reasons. First, small fonts tend to be displayed on top of OS X’s standard striped background. Without the smoothing, the letters are skinnier and don’t stand out as much from the background. Second, the horizontal spacing of unsmoothed letters is off. As you can see in the screenshots, the same font (Geneva 9) looks worse in OS X than in Classic, with the letters running into each other.


I’ve spent most of this article critiquing Mac OS X 10.1, because most of the improvements are already well documented elsewhere—and, frankly, Apple still has a lot more polishing to do. Not surprisingly, 10.1 did not magically fix all the problems in the original release. Nevertheless, I’m really impressed with it. Apple has come a long way in only six months. The low-level plumbing and performance issues are being resolved, and Apple is clearly beginning to spend more of its energies on the user experience. I’m hopeful that the next major release will continue this trend and that continued user feedback will alert Apple to the areas that need attention.

Also in This Series

Reader Comments (9)

James Arnold · October 4, 2001 - 13:54 EST #1
OS 10.1 is good enough for me to make the switch away from 9.x. I am not a power user. I use this machine mostly for e-mail and web, and 10.1 is great for that. 10.0 was a toy and not really usable in my opinion, but this is great.
Michael Tsai (ATPM Staff) · October 4, 2001 - 17:56 EST #2
There is now a Web page for the file name extension guidelines.
Ron Alcasid · October 8, 2001 - 12:48 EST #3
Actually, if you rename a TextEdit file in the Finder such that it doesn't have a file extension, the Finder adds it for you but makes it hidden.
David Chilstrom · October 8, 2001 - 14:19 EST #4
Regarding file extensions being mandatory, this from Apple's File Name Extension Guidelines:
"Applications should support ease of interoperation with other operating systems and Internet services by saving files with file name extensions."
OS X has, from the get-go, provided full support for type and creator codes and applications can choose not to use extensions if that is desired. Apple is recommending, however, that extensions be used. OS X is a much better net citizen than the classic Mac OS in that the conventions of the rest of the computing world are respected by the Mac operating system. As for the compressed Geneva font, while unattractive, it does allow more characters to appear in a file name, which given OS X's 256 character capacity would be most advantageous. From my standpoint, OS X's font handling is far superior and more powerful than the legacy font handling system in OS 9. While the OS X Finder lacks a few of the niceties of the OS 9 Finder, it adds far more than it takes away. Connecting to file servers is now where it has always belonged, in the Finder. Chaotic Desktop types like me can now view the Desktop in list view. Multi-column view puts those despicable flippy trianges to shame for burrowing deep file systems and the customizable Finder bar is very slick for quick access. Overall, the positives far outweigh the few remaining negatives. This is not to say that there aren't remaining issues to resolve in OS X. The main issue is the availability of applications. If a user's core applications are native and their complement of hardware can support it, I would unreservably reccomend that a user crossover NOW. Esoteric quibbles about file typing and font spacing (Jeez, I hope you don't use Geneva for anything but the Finder) pale in comparison to vastly greater stability and multi-tasking that really works.
Michael Tsai (ATPM Staff) · October 8, 2001 - 17:52 EST #5
Ron: The behavior you describe is the default. However, if you have enabled the "Always show file extensions" preference, then renaming the file without the extension will really delete it. Then the Finder will forget the file's type. David: As I said, supporting file extensions is good so long as we can turn them off if we don't want them. The main problem is that Apple has made type and creator codes optional. Not setting the creator code degrades the user experience. Not setting the type code has the effect of making file extensions mandatory, as in the TextEdit case. The font issues don't really apply to file names since the Finder's font isn't configurable. In any case, I'd hardly call the compression a feature (since it can't be turned off). I use Geneva for everything from writing to Web browsing, and I recognize that that's unusual. However, Geneva is also common in the user interfaces of popular Carbon apps like BBEdit and Internet Explorer, and the metric problems seem to apply to other fonts as well. Whether the changes to the Finder add up to a plus or a minus is certainly a matter of preference. However, I can find no good reason for Apple not to preserve the niceties of the icon and list views. The columns view is very nice for some uses, but it can't show as many icons as icon view or the contents of multiple folders at the same level, like list view. There certainly are lots of reasons to switch to OS X, and I've done that even though one of my main applications (Mailsmith) isn't native. The usability issues with 10.1 aren't show-stoppers like they were with 10.0, but they are real and should not be ignored.
David Chilstrom · October 9, 2001 - 14:07 EST #6
Regarding Michael's comments to me here: File extensions are more relevant in OS X than OS 9 because of X's support of UFS as an alternate file system to the traditional HFS. Because a user may be using UFS (which doesn't know squat about resource forks) extensions are required to identify a file. Yes type and creator codes are good and extensions are bad, but supporting multiple file systems is also good and we have to accept the limitations of such systems. I am hoping that Apple has a long term plan for a more robust system of file typing than the classical type and creator code system. BeOS, for instance, can manage a user customizable swath of info about a file, who created it, the project the file belongs to, etc. For now, though, Apple needs a system which works with the file systems supported by OS X. Oh yeah, Geneva isn't even used in Finder views anymore. So much for that lame theory. Your assumption is likely correct that Quartz font spacing is optimized for anti-aliased fonts and treats aliased fonts as second class citizens. Can Quartz be smartened up to adjust? Maybe, but I doubt that was a priority for this release. Regarding the Finder, Apple has addressed the major gripes users had with 10.0x, and the issues you describe, while agravating for some, are not the kind of deal breakers present in the 10.4 Finder. Though I miss labels, which I use occasionally, there is so much more about the X Finder that I like that I can forgive a few omissions. I especially like the choice to toggle between single window mode and window spawning mode. Finder window clutter is a constant aggravation for me in OS 9, and OS X nicely eliminates that. Overall, OS X is so much more capable than OS 9 that I'm more tolerant than some people of the remaining rough edges. X has support for multiple file systems, connectivity with Windows networks (though inelegantly implemented at present), ability to run most UNIX programs with minimal tweaking, powerful server capability (web and ftp) on a consumer OS, glitzy features like automatic digital camera capture and DVD data burning on the desktop. Most of all I like the smooth feel of OS X. OS 9 feels herky jerky, with breaks for daily restarts, waits while programs are launching, the wake from sleep pause, coffee breaks while a program is doing some massive computation and you dare not switch it to the background lest it grind to a crawl and so forth. Yes, the spinning pizza of pausitude appears in OS X programs, in which case I just switch to something else, confident that the program will have adequate resources to finish its work expeditiously while I move on to something else for the moment.
Michael Tsai (ATPM Staff) · October 9, 2001 - 14:43 EST #7
I agree with you about BeOS, the extra capabilities of OS X, and the benefits of good multitasking. I just want to point out that file extensions are not needed to run Mac OS X on top of UFS. Although resource forks, type and creator, and other HFS metadata are not directly supported by UFS, the Finder (and other apps that access files through Carbon) preserves them using hidden files. This is described in the Finder and File Operations section of the Mac OS X System Overview.
Michael Tsai (ATPM Staff) · October 17, 2001 - 22:31 EST #8
John Siracusa has completed his thorough overview of Mac OS X 10.1 for ArsTechnica. This is the best 10.1 article I have read, and the sections on the Finder and file name extensions are must-reads for anyone who cares about the quality of the Macintosh user experience.
Taken individually, the bugs and problems listed above may not seem that bad (although some are pretty troubling on their own). But they combine to thwart any attempt to recreate the interface that has defined the Mac user experience since 1984: the spatial Finder.

The metadata policy in Mac OS X 10.1 is complex in its implementation (sometimes to the point of being mysterious), misguided in its apparent motivations, and does not live up to the quality of the traditional Mac user experience that it intends to replace. Furthermore, it will make future improvements more difficult as files created with "partial metadata" by Mac OS X applications that adhere to this policy proliferate.
I couldn't agree more.
Kerry Alexander · August 27, 2002 - 18:26 EST #9
You should make it so you can download the cool features for the old computers. Not Mac OS X but the classic Mac OS.

Add A Comment

 E-mail me new comments on this article