g r o t t o 1 1

Peeve Farm
Breeding peeves for show, not just to keep as pets
  Blog \Blôg\, n. [Jrg, fr. Jrg. "Web-log".
     See {Blogger, BlogSpot, LiveJournal}.]
     A stream-of-consciousness Web journal, containing
     links, commentary, and pointless drivel.


On My Blog Menu:

InstaPundit
USS Clueless
James Lileks
Little Green Footballs
As the Apple Turns
Entropicana
Cold Fury
Capitalist Lion
Red Letter Day
Eric S. Raymond
Tal G in Jerusalem
Secular Islam
Aziz Poonawalla
Corsair the Rational Pirate
.clue

« ? Blogging Brians # »





Book Plug:

Buy it and I get
money. I think.
BSD Mall




 10/6/2003 -  10/8/2003
 9/29/2003 -  10/5/2003
 9/22/2003 -  9/28/2003
 9/15/2003 -  9/21/2003
  9/8/2003 -  9/14/2003
  9/1/2003 -   9/7/2003
 8/25/2003 -  8/31/2003
 8/18/2003 -  8/24/2003
 8/11/2003 -  8/17/2003
  8/4/2003 -  8/10/2003
 7/28/2003 -   8/3/2003
 7/21/2003 -  7/27/2003
 7/14/2003 -  7/20/2003
  7/7/2003 -  7/13/2003
 6/30/2003 -   7/6/2003
 6/23/2003 -  6/29/2003
 6/16/2003 -  6/22/2003
  6/9/2003 -  6/15/2003
  6/2/2003 -   6/8/2003
 5/26/2003 -   6/1/2003
 5/19/2003 -  5/25/2003
 5/12/2003 -  5/18/2003
  5/5/2003 -  5/11/2003
 4/28/2003 -   5/4/2003
 4/21/2003 -  4/27/2003
 4/14/2003 -  4/20/2003
  4/7/2003 -  4/13/2003
 3/31/2003 -   4/6/2003
 3/24/2003 -  3/30/2003
 3/17/2003 -  3/23/2003
 3/10/2003 -  3/16/2003
  3/3/2003 -   3/9/2003
 2/24/2003 -   3/2/2003
 2/17/2003 -  2/23/2003
 2/10/2003 -  2/16/2003
  2/3/2003 -   2/9/2003
 1/27/2003 -   2/2/2003
 1/20/2003 -  1/26/2003
 1/13/2003 -  1/19/2003
  1/6/2003 -  1/12/2003
12/30/2002 -   1/5/2003
12/23/2002 - 12/29/2002
12/16/2002 - 12/22/2002
 12/9/2002 - 12/15/2002
 12/2/2002 -  12/8/2002
11/25/2002 -  12/1/2002
11/18/2002 - 11/24/2002
11/11/2002 - 11/17/2002
 11/4/2002 - 11/10/2002
10/28/2002 -  11/3/2002
10/21/2002 - 10/27/2002
10/14/2002 - 10/20/2002
 10/7/2002 - 10/13/2002
 9/30/2002 -  10/6/2002
 9/23/2002 -  9/29/2002
 9/16/2002 -  9/22/2002
  9/9/2002 -  9/15/2002
  9/2/2002 -   9/8/2002
 8/26/2002 -   9/1/2002
 8/19/2002 -  8/25/2002
 8/12/2002 -  8/18/2002
  8/5/2002 -  8/11/2002
 7/29/2002 -   8/4/2002
 7/22/2002 -  7/28/2002
 7/15/2002 -  7/21/2002
  7/8/2002 -  7/14/2002
  7/1/2002 -   7/7/2002
 6/24/2002 -  6/30/2002
 6/17/2002 -  6/23/2002
 6/10/2002 -  6/16/2002
  6/3/2002 -   6/9/2002
 5/27/2002 -   6/2/2002
 5/20/2002 -  5/26/2002
 5/13/2002 -  5/19/2002
  5/6/2002 -  5/12/2002
 4/29/2002 -   5/5/2002
 4/22/2002 -  4/28/2002
 4/15/2002 -  4/21/2002
  4/8/2002 -  4/14/2002
  4/1/2002 -   4/7/2002
 3/25/2002 -  3/31/2002
 3/18/2002 -  3/24/2002
 3/11/2002 -  3/17/2002
  3/4/2002 -  3/10/2002
 2/25/2002 -   3/3/2002
 2/18/2002 -  2/24/2002
 2/11/2002 -  2/17/2002
  2/4/2002 -  2/10/2002
 1/28/2002 -   2/3/2002
 1/21/2002 -  1/27/2002
 1/14/2002 -  1/20/2002
  1/7/2002 -  1/13/2002
12/31/2001 -   1/6/2002
12/24/2001 - 12/30/2001
12/17/2001 - 12/23/2001
Thursday, May 23, 2002
11:16 - "Ease of Use" is a Misnomer

(top) link
Comparative descriptions of the Mac versus the PC have always talked about "ease of use". Back to the earliest days, and up to the current day, the main selling point for Macs has been that they're easier to use; the PR copy for every new Apple product talks about the Mac's "legendary ease of use". This may well be true; certainly it's been what has sold most of the Macs that have been bought by new computer users daunted by technology.

But I think it's an unfortunate term, and counterproductive in the push to sell Macs to people who are computer-savvy. Most PC users (who are less than open-minded or curious enough to explore different platforms for themselves) think, "Ease of use? Who cares? I know how my computer works. I don't need it to be made more 'easy'." And so they tend to dismiss the Mac with the same prejudicial disdain that seasoned Internet users have for AOL, thinking that it's targeted for undemanding users and therefore inherently has only limited functionality. And therefore they never see what advantages the design of the Mac platform has.

What I think would be a better term to describe the Mac OS is elegance. It's a term that most of the savvy tech press already uses, fortunately, and even uses correctly: it describes what in engineers' lingo is something that is "done right". It's the kind of implementation of technology that you just look at and think, "Well, damn, there's no better way this could have been done. It all just makes sense." Engineers love elegance. We might shun ease-of-use that exists only for its own sake (e.g. AOL); but we praise and worship elegance above all other goals. It's the mathematicians in us, seeking the proof that can be completed in the fewest and cleanest steps, the most understandably and obviously to the reader. And that's what the design of the Mac is all about, which is why the hard-core geeks who use Macs do so.

For us, Mac advocacy is not about destroying Microsoft, or being rebels, or supporting a cool and charismatic leader (though those things are nice bonuses). What it's all about, for us, is making sure that the elegance of the Mac design does not go extinct. We look at Windows, with all of its glaring design flaws, many of which we still have to live with to this very day, and we see a system that looks like the refugee starbase in Titan A.E.-- a software shantytown, a monstrosity that's been cobbled together with so many successive hacks, so many incomplete spackle jobs and coats of paint, without ever stopping to rebuild the foundation, that while it may work, it causes a reaction of revulsion in the mind of any engineer who contemplates it. Everyday PC users have learned to ignore these flaws and to work around them, and to accept them as "just part of using a computer". But if the system had been designed properly in the first place-- had been "done right"-- they'd only be distant memories.

Let's look at a few of these little quirks that Mac users have never had to deal with, but that are par for the course in the PC world.
  • Drive letters. Back in the early days of DOS, it was simply common knowledge that your floppy drives were A: and B:, your hard drive was C:, and for those rich souls who had CD-ROM drives, it was D:. To do any DOS operations on files, you would switch from disk to disk by typing the drive letter at the prompt. That was Just the Way it Was. Boy, what a primitive time, eh? It sure is good that we don't have that anymore, right?

    Yeah, well, guess what: the drive letters are still there. Windows still shows them to you. If you have to do any DOS stuff, especially on remotely mounted volumes, you find yourself staring at prompts like O:\> and S:\>, and you'd better have your path set up properly, or else you won't be able to do a lot.

    Whereas with the Mac, whenever you insert a disk, it pops up on the desktop with an icon that reflects what kind of medium it is and whatever name or label you chose to put on it. It's not an alias for anything low-level; it's not inserted into an arbitrary priority ordering scheme like in DOS. It's just another volume. And its name is My Disk, or October PSD Files, not D:. It doesn't even matter what drive a disk is in; the icon leads to the disk, wherever it is.

    Granted, there are some benefits to having your drives addressed by letters that correspond to physical drives. If you have two optical drives, for instance. Hmm, which drive is "Giants: Citizen Kabuto Disc 1" in? I guess I have to check both. But then, because all drives have always had software eject mechanisms on the Mac, you never have to touch a physical button to get a disc out; you just eject it in the OS and out it comes. Wouldn't it be nice if PCs could do that?

  • Filename extensions. Remember this?


    Filenames were never meant to incorporate that stupid three-letter extension into the actual label of the file itself. Just look: the 8-letter basename and the three-letter extension were displayed in different columns. Even back in the early DOS days, the people who designed the 8.3 filename format considered the basename to be the filename, and the extension was merely file-typing meta-data. You can see that in the fact that you could run executable .EXE, .COM, and .BAT files by simply typing the basename without the extension. It was purely for convenience that the filenames were stored in such a way that you could address a file by referring to its name and its type in combination, e.g. MYFILE.TXT. Ideally, there would be content negotiation like with HTTP/1.1, where the same basename would be used for similar files in different formats; you could address a file by its basename, and the application would choose the proper variant.

    But that never caught on. And because of the limitations of the 8-letter basename, people started using the extensions as a legitimate and inextricable part of the filenames. So you got archiving systems like ARJ that created files with names like FILE.A00, FILE.A01, FILE.A02, and so on-- mocking the concept of registered extensions used deterministically for file-typing. Then, Windows came along, and filenames were now displayed in proportional screen fonts, with the extensions tacked on to the end of the filenames, no matter how descriptive, long, or natural-language the basenames were. And filename-extension mapping and display were spackled into law.

    And now we have this:


    Ah, progress.

  • Remember the 640K Barrier? Marcus just told a customer in his store, who was converting to the Mac from Windows and was frustrated that his PC would only accept 640MB of memory, that "Well, 640MB should be enough for anybody." They stared at each other, then broke into hysterical laughter. Then the guy bought a Mac.

    One of the most daunting terrors in the early DOS world was the 640K Barrier. Because of shoddy design work, DOS couldn't support memory sizes greater than that (well, actually 1MB-- though the upper part was mostly reserved for low-level drivers and stuff), and so users had to choose between the competing "expanded" and "extended" memory formats, both hacks that mostly worked-- but were incompatible with each other. Some programs would only run in the base 640K, and not in expanded or extended memory-- so users had to try to squeeze the most space possible out of the lower 640K, by loading device drivers into the "upper memory blocks" that existed in the attic above 640K. (Remember LOADHIGH? How about EMM386?) Lots of trial-and-error, lots of hoping-and-praying, and lots of wondering what kind of mental illness could have produced a design this hemorrhagingly bad.

    As with filename extensions, complementary artificial limitations led to compromises and crappiness for all involved. And it wasn't until Windows NT/2000 and finally XP that the home user was finally rid of all the vestiges of that memory model-- because now it was on an entirely different OS platform, and the old one had been jettisoned and retired rather than redesigned properly and elegantly.

    Now, granted, the classic Mac OS' memory model wasn't exactly ideal either. Because it wasn't designed for multi-user functionality or to have all the robustness inherent in server OSes like UNIX, the Mac's memory model was an unprotected one where the user had to manually set "preferred" and "minimum" memory sizes for their applications to run. Most applications came with appropriate values for these settings filled in already, and smart installers would tweak them according to system configuration. But it still wasn't exactly a picnic. Still, though, the interface for modifying these values was made as elegant and streamlined as possible under the circumstances, and was eliminated entirely in OS X. And oddly enough, OS X is what's attracting so many new geeks to the Mac who appreciate elegance in design-- and who may have been put off until now by the memory model.

  • No Unique File IDs. When you move a file from one place to another in the DOS/Windows filesystem, its path through the folders-- which is the only definitive way to locate or address the file-- is changed.

    See any problems with that?

    I sure do. What if you have shortcuts or aliases pointing to it? What if you have applications (such as MP3 organizers) that expect to find the files in a certain place? Those things become instantly useless if you move the target.

    On the Mac, files have unique identifiers-- so if you make an alias to a file or program, and then you move the target somewhere else in the sytem, the alias will still point to it. Wouldn't that be nice to have on Windows? And you know, that's the whole reason iTunes works so well: toss an MP3 file into it, no matter where in the filesystem it is, and from then on iTunes will always know where to find that file, no matter where you move it. It will keep track of it through its unique ID, and will only lose track if you delete the file.

    Same goes for applications. Ever find it annoying that you couldn't easily install anything anywhere other than "Program Files"-- or if you did, you couldn't then move it to somewhere else, because it had hard-coded the path to parts of the application into the Registry? Hard-coding is one of the ugliest, most godawful thing you can do in programming, and any coder who has any sense of elegance or design will recoil in horror when a program does this. But on the Mac, you can install a program anywhere you want, often by simply dragging a folder from a disk image into wherever you want to put it. Move it anywhere else in the system, it'll still run just fine. To delete an application, you throw it in the Trash. No "uninstallers", no Registry cleaning. Just delete it.

    See, this isn't just ease of use. This is proper design. This is why Mac people get warm fuzzies from using Macs.

  • The Registry. Microsoft wanted a way to emulate the Mac's ability to "know" where an application was (through its unique file IDs and the Desktop database), so apps could see if each other were installed and quickly access bits of data about the system and each other. But as any Windows user knows, a central database like the Registry that is definitive leads only to pain and suffering. How do you rebuild the Registry if it gets corrupted? You can't; you have to reinstall everything from scratch. It's not merely a cache, which the Desktop DB on the Mac is. On the Mac, each application registers its four-letter signature and the Type codes of the kinds of files that it will accept for opening, and the Finder and other apps can then know instantly, even pre-emptively, whether an app will be able to open a file that you've dragged over it. And if the Desktop DB should become corrupted, well-- you just run a "Rebuild Desktop" job, and the system takes that same information from the definitive repositories in the applications themselves. The Desktop DB is only there for speed. It's central, but it can be rebuilt. The Registry can't.

    I hardly need to say what else is wrong with the Registry. Again, anybody who has used Windows is aware of the pain it can cause-- how ad-ware and spy-ware can hide in it, and even non-malicious software can leave keys strewn all over it; how applications can collide, using the same keys and being unable to co-exist; how you can never completely un-install even some commercial programs; how manually editing the Registry is an ordeal we wouldn't wish upon our worst enemy. And Microsoft's tech support recommends that you reinstall Windows every six months anyway, preferably with a nuke-and-pave so as to clean out the Registry. This is why Windows servers seldom run more than one service at a time, incidentally-- not for performance reasons, but because nobody can predict what kinds of interactions might occur in the Registry. When it comes to ugly hacks that make engineers' skin crawl, the Registry is the prime poster child. And it's nowhere to be found on the Mac.

  • Limited Window Position Memory. Did you know that Windows does not keep track of the window positions and settings of all the folders in your system? Nooo. It only knows about the last sixteen windows that you've opened. It doesn't keep folder window settings in a cache along with each folder, like the Mac does; no. It keeps them in a separate buffer in the OS, a very small one at that.

    This may not be true in more modern iterations of Windows, but it certainly was in Win95/98. And if it's fixed in current versions, I'd wager it's because they've simply increased the buffer size, rather than re-architecting the system. This is the kind of thing I'm talking about-- if they'd "done it right", this kind of problem would be unthinkable.

  • No global drag-and-drop. On my Windows machine, I frequently find myself grabbing a URL from a browser window and trying to drag it into an application. In some special cases it works, but globally I'm out of luck-- I have to manually Copy the URL, then go to my destination and Paste it. Every time I have to do that I groan in exasperation. Because on the Mac, I can grab any text in the system-- any text, not just URLs-- and drag it to any other place in the system, and it will be copied and dropped (with as much of the formatting and style preserved as the destination will support). I can toss URLs from one browser to another or into an ICQ window with a flick of the mouse. Ever wonder how you could possibly get by with a single-button mouse? Well, how about by not having to use the right button for anything? That's proper design-- the kind of thing they didn't have to do, but they did, all because it was the right way to design something. It was hard, but they went the extra mile to make it something they could be proud of, not something that they simply expect people to tolerate.

  • Shortcuts. UNIX has links, either hard or symbolic; the Mac has aliases. Windows, however, was the last of these operating systems to develop such a concept-- and they did it in the worst conceivable way possible.

    UNIX hard links are simply duplicated identifiers for the same inode, and symbolic links are just pointers that refer to a file or directory. Any "pipe" operation on a link-- an operation that reads or writes data to the target-- is performed on the target item instead of the link itself. Other than that, it's just an invisible little placeholder in the filesystem. Symlinks don't keep track of their targets, though-- so if you move a link's target, the link will go dead.

    Mac aliases work the same way as symlinks, except that because of unique file IDs, the aliases will continue to point to their targets even if you move them. Furthermore, aliases have embedded data in them like "folder actions", modem scripts, AppleScript events, and other things that should be executed when the alias is opened-- for instance, if the target is on a remote server, the alias will know to open your network connection and mount the server to get to the alias' target. Aliases are thus "files" in the filesystem, with the data needed to get to the target-- but all applications display them properly as aliases.

    But Windows "shortcuts" are the worst of both worlds. They're ".lnk" files in the underlying filesystem, so applications can't access their targets-- they're just impenetrable files. But those files don't keep any useful information or any ability to extend the action executed by opening it. They're just special files that can only be executed by Windows-- an ugly hack, one that gives the user the requisite functionality, but in a way that makes both UNIX and Mac users cringe. And they can't keep track of their targets.

  • Only One Bootable System Folder. C:\WINDOWS is it, baby. (Or C:\WINNT, or whatever.) You can't rename it or move it. Of course not. Hell, you're not even supposed to upgrade a Windows system-- you're supposed to back up your data, nuke-and-pave the disk, and install the new OS from scratch.

    On the Mac, you can have as many System Folders as you want. You can have an OS9.1 one, an OS8.6 one, an OS7.5 one, and an OS X one-- and the OS lets you select in software which one you want to boot into next time. If they're on different disk partitions, you can hold down Option while you're booting, and you get a visual menu with all the bootable Systems that you can choose between. They all coexist happily, and they can be anywhere on the disk you want them to be.

    Similarly, you can hold down C to boot from the CD-ROM, F to boot from the first FireWire device, S for the first SCSI device, and so on. If there's a floppy drive, and the disk in it isn't bootable, the system doesn't collapse and lie on the ground bitching and whining like a PC does-- it ejects it and boots from the hard disk.

  • Booting in Text Mode. I mean, come on. This is 2002, for Christ's sake.

Whole websites have been devoted to the stupidities of design in DOS and Windows, and I don't need to replicate their efforts here. But I just wanted to give a good sampling of the kinds of things that engineers who appreciate elegant design find so repugnant about Windows, and that cause so many of us to gravitate toward Apple as a company that "gets it". Since they live and die by innovation and radical change, they can afford to do the foundational renovations that true steps forward and proper design require.

With Mac OS X, we're having to make some concessions to the ugliness of the Windows platform, purely for the sake of compatibility. Filename extensions are a front where we've surrendered and compromised. If networkable filesystems had been designed properly in the first place (e.g. if AppleTalk had become the standard instead of SMB/CIFS or TCP/IP protocols like FTP and HTTP), we would have complete filesystem meta-data available to all files to tell us their types and creators and version numbers and previews and all sorts of attendant information. But we've had to give up that dream so as to interoperate with a computing world that has standardized on much more limiting protocols. And so a great beauty is lost forever.

Most PC users don't think about this sort of stuff at all. During casual computing, all that matters is surfing the Web, working within Word or Photoshop, sending e-mail-- actions that take place within applications. That kind of user experience can be made infinitely elegant by application developers who know what they're doing, and interaction with the actual OS can be minimized so that it's hardly a bother at all. So the flaws are covered up and forgotten, and layered over with boards and plaster so that all anybody sees is the pretty surface, and doesn't have to think about the gruesome mess underneath. Elegant design becomes a lost esoteric art, and computers become a necessary evil, like government or the phone company-- and no engineers can imagine getting excited about working with it.

We Mac geeks don't want Apple to take over the world. We know full well that they'd become as bad as Microsoft, or worse (Microsoft is certainly better equipped to run as a despotic monopoly, and would please its shareholders better). We don't want all our Windows-using friends to switch platforms, and we don't want Mt. Rainier to erupt and drown Redmond in the collected effluent of seven thousand years of untreated sewage from Satan's public-works infrastructure.

No, all we want is to make sure the world remains aware that proper design is out there, and that having it die out and Windows to be the only OS in the world would be like leaving the unicorn off of Noah's Ark.

There's a reason why we call it the Joy of Tech.

Back to Top


© Brian Tiemann