Speed

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.

Finder

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.

Fonts

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.

Verdict

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.