Tales of a BeOS Refugee seems to have touched a nerve. In the two weeks since it was published at OSNews, I have received more than 500 email responses from users of Mac OS, BeOS, Linux, and Windows.
Unsurprisingly, I got a few things wrong in the original piece. Fortunately, almost none of the messages were flames (okay, there were a few). Most of the responses were point-by-point rejoinders to facts and observations in the original piece, some of them incredibly detailed. Because it was impossible to respond to everyone individually, and because I thought many people would appreciate being able to read these comments and my reactions to them, I've assembled this addendum. Many thanks to everyone who took the time to write.
Many readers asked for a mirror of the article. I'll keep a permanent copy here:
http://www.birdhouse.org/macos/beos_osx/
That location also includes the PDF version of the original article, which OSNews removed to reduce bandwidth crunch.
By a huge margin, I received the most mail commenting on my comparisons of BFS and HFS+, and on Be's database-like filesystem. With only one exception, every single message expressed frustration with Apple for de-emphasizing meta-data and for encouraging filename extensions.
For an interesting read on Mac OS and metadata, see these excellent pieces by John Siracusa:
Metadata, the Mac, and You
Mac OS X Metadata Proposal
For all the agreement I got on meta-data, I got just as much from people who couldn't understand my argument with the Creator code or, more specifically, with the application binding policy stemming from the Creator code. Many readers seemed to think I was asking them to give up some of the functionality they had in OS 9, which made me realize I had done a bad job of explaining myself. So I'm going to tackle this topic first, a bit more carefully this time.
Many readers are bringing up the following case:
Imagine a folder full of HTML files - some saved from Netscape, some from Explorer, some from BBEdit, some from Word. Here we have multiple files of the same type, but the user wants them all to open in different apps - either to view them or to edit them. And they may want to edit them in different apps, depending. Double-clicking any of these files should result in different behavior for each file.
Not coincidentally, I raised almost the exact same scenario in the filetyping section of the BeOS Bible.
What I didn't fully describe in the BeOS Bible, and what none of the people writing to me are describing, is the fact that there are two ways this scenario can manifest:
Clearly it is important to satisfy the desire of users in scenario #1 and to prevent the frustration of users in scenario #2.
What I somehow failed to communicate is that the BeOS method satisfies both of these goals equally well, whereas the Mac OS method serves only scenario #1, while failing miserably with scenario #2. I've been bitten too many times by this problem in the short time I've been using OS X, and apparently, so have many of you, judging by the email responses. Scenario #2 is too common an occurrence for Apple to just leave it hanging. It's a genuine usability problem, and one that's not overly difficult to solve.
Again, a summary of the BeOS method, whereby both goals are satisfied simultaneously:
Through this system, all of the flexibility the power user demands is there, while the newbie gets reasonable defaults and a "best possible" scenario for files without a preferred app. Undesirable behavior never happens (files never launch in an unexpected app), but users can easily set specific / local files to launch in other apps if desired. And of course, users can drag files into other apps easily enough in any operating system, if they prefer to work that way.
All of this is accomplished in BeOS through a combination of system and local preferences, and intuitive, easily accessible preferences panels (both global and local). The Creator code is never stored in BeOS, and yet the user experience is superior both for the newbie and superior for the experienced user.
Still, many old-school Mac users feel that Creator serves as a reasonable default because, well, because it just seems to make sense for there to be a connection between the creating app and the default viewing app. This connection does make sense as a baseline assumption, but only given the premise that the user does not prefer to have different apps for creating and viewing documents (as is often the case). If that premise fails, then the conclusion (that the creating app is the best launching app) falls apart as well.
The truth is, we all have different styles of working, and do different amounts of editing vs. viewing. Some creating applications most definitely are the best viewing applications -- for example, most of us would want to both create and view Word docs in Word. For most of us, media files are viewed far more often than they're created. Images, audio, and video files are generally only created by a small percentage of the computing population, but viewed by many.
Even though I sometimes like to edit video, I don't want Final Cut Pro to be launched if you send me a QuickTime movie, and I don't want Photoshop to launch if I double-click a .psd file on our shared Mac volume. And I never, ever again want to see the Classic environment start up when I double-click a .jpg file in an email attachment. HTML files are a total toss-up. Most people want them associated with a browser, while web developers often want them associated with an editor of some kind. And as described above, web developers might want some of their HTML files associated with a browser, others with an editor.
All of which is a long way of saying that there is no consistent way to deliver the experience desired and expected by the user when the Creator code is involved in the application-binding policy. If Apple is going to overcome this inconsistency, it must acknowledge that only a policy based on filetypes combined with a "preferred app" flag (for local overrides) is going to get the job done.
That said, I know how dearly Mac users hold the Creator type. I always lobby for maximum flexibility and user choice. So, again, I advocate a system that allows users to specify the application-binding policy in use by the system. I feel strongly that Creator-based application binding is more of a nuisance than it is a good thing, but I don't want Apple to take away things that people use and appreciate. People have different ways of working. Apple should let the user decide by which mechanism they want files bound to applications. I believe that once users try both ways for a while, they'll opt to ditch Creator-based binding.
It was interesting to see that Mac users who had used BeOS and BeOS users who had used MacOS agreed with me about de-emphasizing the Creator code, while Mac users who had never used BeOS still defended the Creator code.
Many readers pointed out that they just used drag and drop - drag the files in question from the Finder and onto the application icon or alias. Fine, but I have to point out two things here:
1) These users are basically saying that they've found a workaround to a deficiency in the system. Experience has taught them that if they double-click, unexpected things can happen (files might launch in the wrong apps). Rather than eliminate undesirable behavior, they've found a way to skirt it.
2) The target application or alias must be visible before you can drag anything onto it. Sometimes that's no problem. Other times the target icon is buried deep and this process becomes far slower than it would otherwise be. For common filetypes, this works fine - I've always got a BBEdit or Explorer icon visible somewhere. But I don't necessarily want to have a Preview icon visible all the time just to serve as a drag target for image files someone might send me from another department.
Q: When does the preferred app get set in BeOS? By the application at save-time?
A: By default, files do not have a preferred app. This is the key to providing reasonable defaults. If a file does not have a pref_app attribute, the system binding for that file's type is used. If the user wants to use other than the system binding for that file, s/he sets a preferred app for that file or files. That's really the core of the argument. The default system binding for filetypes is easily changeable, and so is the override.
Q: Isn't the Mac OS Creator code the same as the BeOS pref_app attribute?
A: The similarity is that both BeOS and MacOS have metadata and application binding policies. But Creator and Preferred App are not the same, and the functional difference is that the Mac sets the Creator (and hence the binding policy) when the file is created. This is where the problem arises.
Q: If somebody sends a BeOS user a file by e-mail, and the preferred app attribute is set, will it get removed on BeOS? Because if not, the situation is the same as on MacOS: An application that you don't want to open will get launched. The only difference seems to be that on MacOS, most files have the creator type set, while on BeOS, most files *don't* have the preferred app set.
A: That's accurate -- it could happen. In order for it to happen though, two things must be true:
1) The file must have a pref_app set, and in the vast majority of cases people do not set it for indidividual files. The flexibility is there, but most people are happy with the system defaults most of the time.
2) Both sender and receiver must be using mail clients capable of sending attributes along with attachments.
Between the two of these, I remember only one instance under BeOS where a file launched in an unexpected app. But you are technically correct. Good point.
Q: In BeOS, is it up to the creating app to set the pref_app attribute?
A: No! The app always sets the filetype. Files never have a pref_app unless the user sets it manually. This is the key to avoiding unexpected behavior. Some apps (such as Pe) have a preferences panel that lets you edit the list of filetypes the application can output. For example, when saving from Pe, you can save as text/plain or text/html or to a custom filetype such as text/x-shacker. But Pe will never set a preferred app for these files - Pe does not make the assumption that you are going to want to view/edit the file again later in Pe. And neither does any BeOS application. That would be arrogant of the application.
Q: All of these things can be done on a Mac too, so I think what you want is not really different meta data, but better ways to change and work with the meta data we already have.
A: Mostly correct. My real argument is with the application binding policy and the (lack of) a clear interface to change file types and preferred applications both globally and locally. It's worth noting that Mac OS *does* have preferred app metadata in addition to Creator and filetype. All the pieces are already there. But the way this metadata is used to establish behavior is, IMO, totally whack, and barely customizable by the user.
This one I got plain wrong. I said that HFS+ was a 32-bit filesystem and couldn't handle very large files without stitching them together behind the scenes. Someone I believe to be completely "in the know" set me straight:
HFS has a 32 bit limit (actually 31 with an effective limit of 2 gigabytes per file).
HFS+ (the default file system for Mac OS X) has a full 63 bit file size.
However, for the release of Mac OS 8.1 HFS+ was supported as a volume format, but the new 64 bit API's were not released to the general public. Therefore any _EXISTING_ software using the legacy Mac OS file system API's are limited to 32 bit file offsets. Mac OS 9.0 and Mac OS X both have 64 bit file system API's for HFS+. But few if any applications have migrated from the "old" file system API's to the new HFS+ API's.
Summary:
- Mac OS Software using the legacy file system API's are limited to 2 gigs.
- Mac OS Software using the _NEW_ file system API's can go much larger than 2 gigs.
- HFS+ supports 64 bit file sizes - but not all applications have come around to this (witness iMovie's import files are artificially broken up into 9:29 sec chunks - this is the 2 gig limit, therefore iMovie is using the old file system API's that work on both HFS & HFS+ volume formats).
The following link will cover the specifics of HFS vs HFS+:
- Anonymous
http://developer.apple.com/technotes/tn/tn1150.html
I was also incorrect in stating that Mac OS X does not have a plugable architecture for supporting alien filesystems. It does -- we just haven't seen it in action much for some reason.
Several people wrote to share my pain about how Apple's Samba implementation litters remote shared volumes with dotfiles, which annoys co-workers on other platforms. The purpose of these files, of course, is to store meta-data about files in the current directory. These users didn't seem to see a good solution to this problem. To me, the solution seems simple: Don't expect the presence of meta-data when working on cross-platform or non-HFS+ shared volumes. If the files are being shared with Windows or Linux users, that meta-data is useless to them anyway.
You know I think meta-data is a huge advantage, but we also have to realize that shared environments are lowest-common-denominator environments. We shouldn't be trying to impose meta-data on filesystems that don't support it just for the sake of Mac users in that environment. Obviously, Windows and Linux users get along just fine without meta-data, and we can too.
You can do what you want in your own house, but you have to obey certain customs and laws when you're out in public. The dotfile problem goes away when we acknowledge that we're working in a "public" and shared space. Apple needs to give us the option to turn off meta-data storage for selected volumes. When in Rome, do as the Romans do.
So. How does BeOS handle meta-data on non-BFS volumes? It doesn't and it shouldn't. Meta-data should never be considered essential. An application that can't even open and work with a file that doesn't have meta-data would be considered a very poorly designed application.
In the section on batch-resizing images directly from the Finder, I provided a broken link to Apple's toolbar scripts (search/replace error, sorry). The page I meant to link to is here. Many of these are well worth the download.
I complained that Sherlock won't let me search on specific filetypes, which caused some confusion. Sherlock's "Custom" search does let you search on gross document kinds (e.g. "sounds" or "documents") and it does let you search on specific filetypes, which is technically I wanted to do. However, in order to search on a specific filetype in OS X, you must know and enter the exact Type code, and this information is not provided anywhere in the Sherlock interace.
The BeOS Find panel, in contrast, provides a picklist containing every filetype on the system (both "official" filetypes and those added by applications or users). This picklist is right up front, not buried in a fairly hidden Custom search panel. Every filetype in BeOS is identified by both a MIME type and a friendly name. The BeOS Find panel's filetype picklist shows the friendly names of all filetypes on the system. Therefore, limiting a search to just MPEG videos or RealAudio files or HTML files etc. is far easier in BeOS than it is in OS X.
One point I didn't raise in the original article but should have: The BeOS Find panel lets you group your search terms in and/or clauses, while Sherlock does not. This means it's possible to search a BeOS system for (e.g.) all MPEG videos that are larger than 10MBs AND smaller than 100MBs AND that were created in July OR August.
Of course, complex boolean logic is difficult to represent in a GUI. In case you need to create a really complex boolean search, BeOS provides an optional "Formula mode" search, which lets advanced users create queries in text mode. For example the following query would find all files of type audio/mpeg OR audio/aiff AND that have the string "burnside" in the filename.
(((BEOS:TYPE=="audio/mpeg")||(BEOS:TYPE=="audio/aiff"))&&(name=="*burnside*"))
It looks complex, but you can have most of your Formula query written for you -- just start the query in Attribute mode, then switch to Formula mode. The query formula will be filled in. Then just dial it in / customize it and hit Enter. This query syntax works from the BeOS Terminal as well as from the GUI Find panel. Sherlock offers nothing similar.
I incorrectly stated that Sherlock doesn't let you save queries. I was wrong about that -- it does. I didn't notice this because I was looking for an icon in the Find panel similar to one in the BeOS Find panel -- drag that to the desktop or Tracker and your search terms are always a click away. But the really significant thing about saved BeOS queries is that you can right-click navigate them. Because search results in BeOS are instantaneous, you can therefore navigate directly to a real-time query result without launching the Find app itself. It's a wonderful thing.
I complained that Sherlock took four hours to index one of my volumes. It turns out that Sherlock's indexing process merely creates summary indexes of file contents, which is what enables it to search through files for text strings quickly. I'd agree that's a good thing, but if that's the case, it will have to get a bit more intelligent about what kinds of files it should be searching through. Since that volume contained nothing but MP3 files, it didn't need to be examining the files' contents for searchable strings at all.
I lamented that it wasn't as easy to crop selections out of images in OS X as it is in BeOS (in BeOS you just drag a selection out of an image and onto the desktop -- instant cropped clipping). Many people wrote to inform me that GraphicConverter and other Mac graphics apps include this functionality. In other words, my complaint there should not have been about the lack of an important OS-level service, but about the fact that Preview doesn't take advantage of a service that's apparently already there. Sorry for the confusion.
This raises the related question of how much functionality should be included in the OS-provided software versus how much should be provided by third-party vendors. This is always a sticky question. With the exception of some of the more "dangerous" power tools, the challenge of the OS developer is to provide a user experience that is at once simple enough to be intuitive and not overwhelm the newbie, while simultaneously giving the power user the latitude to do whatever s/he pleases with the computer. In a perfect world, this also means providing an interface that helps the new user to empower him/herself.
Of course, it's never easy for an OS vendor to decide how much functionality to include in the OS vs. how much to leave up to the development community. Microsoft has had no qualms about completely destroying the third-party browser and email client markets (to name but a couple) by including full-featured implementations in the OS. Apple has made it difficult for MP3 encoding/playback vendors to succeed on the platform by making iTunes so good. It's a tough call, but the bottom line is that people have far higher expectations for the functionality of bundled OS services than they did five or ten years ago.
No, I don't want Preview to do everything that GraphicConverter does (and of course Preview is really a PDF viewer more than a dedicated image viewer). But its functionality in the image handling department is far too limited, in my opinion. It's hard to understand, for example, why Apple would put so much energy into making iTunes such a good handler of audio data, and QuickTime such a good handler of video data, but Preview such a terrible handler of still image data.
Side note: Be's MediaPlayer application lets you drag from any playing or paused movie directly to the desktop, instantly creating a still image file (a frame grab). I found this incredibly useful, and wish QuickTime Player would grow the same capability.
I incorrectly reported the version of Internet Explorer for OS X. The latest version is 5.1.3. I complained that MSIE for OSX doesn't handle PNG images properly, and got a ton of mail on this. In fact, MSIE for OS X provides the best PNG support available anywhere. But for some strange reason, in-line viewing of PNG images is disabled by default - you have to enable it manually:
One reader wrote:
Internet Explorer 5.5 does support PNG, and far better than its Windows counterpart (it supports alpha transparency).
From http://www.libpng.org/pub/png/pngapbr.html#msie-mac:
"* Internet Explorer [Microsoft] (Mac PPC) - version 5.0 and later; read-only; full alpha support (screenshots); full gamma support; full sRGB and ICC profile support; progressive display of interlaced images (replicating method); uses libpng and zlib; freeware."
Apparently there's a good reason why I'm only seeing visualization plug-ins for iTunes, but no functional plug-ins (e.g. to enable users to turn their MP3 collections into real-time Internet radio stations) : Apple's plug-in API currently only supports visualizers. Im looking forward to seeing that situation improve. A quick walk through the plug-ins section of winamp.com will give you an idea of how much functionality could become available to us once this is done.
I marveled at the way none of my iTunes playlists broke when I batch-renamed thousands of MP3 files. This capability is there not due to intelligent (non-breaking) aliases, as I reported, but because the iTunes database actually points to each file's inode - its unchanging "ID" at the disk layout level.
Also, many readers pointed out that Apple released a great starter collection of AppleScripts for iTunes just after my article was published. Run, don't walk to download this collection.
I complained that neither iTunes nor Audion provide the ability to give MP3 files custom filenames while encoding, e.g. to generate:
03) The Lounge Lizards - Live in Tokyo - Do the Wrong Thing.mp3
An employee from Panic (who makes Audion) wrote to let me know they're working on this, as well as an MP3 broadcasting plug-in for the future. Looking forward!
I mentioned that some apps don't preserve window size and position on exit, and I noted Terminal as an example of this. Many readers wrote to say that it's easy to save all of your Terminal settings, including window size and position. Yes, this is true (the BeOS Terminal can do this as well). My point was really that this should be the default behavior for all applications and windows -- users shouldn't have to be pro-active about it, and developers shouldn't have to think about it. Terminal is sort of a special case, since power users often want lots of Terminal windows open in different colors, sizes, fonts, etc. But I do feel that this should be default behavior for most apps. Developers and/or users should be able to turn it off if they don't want it, not enable it if they do.
In the course of making a point about Apple's approach to case sensitivity, I used the following example:
Open a Terminal and type:touch foo touch FooThe shell returns no errors, so you conclude that OS X is properly case sensitive. But get a directory listing, and you'll find that you've got a "foo," but no "Foo."
That was a terrible example, because one wouldn't expect any errors from those two commands, whether the filesystem is case-sensitive or not. In a case-sensitive system, two files would be created in the directory. In a non-case-sensitive system, the first command would create the file and the second would simply "touch" it again. Duh. I knew that -- just testing you ;) Sorry for the confusion this generated.
I received a ton of email in defense of Apple's approach to case-sensitivity (HFS+ is case-respecting but case insensitive). And you know what? I'm convinced. I've changed my tune. Apple's way makes sense. I think my initial reaction was simply one of surprise. It felt strange to use a Unix shell but not to have full case sensitivity. It felt like something was unfinished. But after reading the many (lengthy) diatribes I received on this issue, I've come around. Here's the letter that expressed Apple's position most cogently -- the one that changed my mind:
As for the "rightness" of using a case-preserving, case-insensitive filesystem, though... well, I come from a UNIX-geek background myself, and it was many galling years before I understood why it was designed that way in the first place.
Case-sensitivity seems like a great idea to UNIX-heads. These are people who want every possible command and workflow to have a distinct, deterministic result -- the kind of thinking you expect from an academic/research environment. Synonymous workflows that arrive at the same result are anathema to science. Students filling up directories with lab data like for there to be a difference between "a.dat" and "A.dat" and sorts them according to ASCII value rather than orthography. It's a sure-footed, obedient scheme, one where the computer does exactly what the user wants it to do -- because the user is one who has the expertise to issue instructions that are very clear and precise and speak the same internal language that the computer does.
But that's not who desktop OSes are written for. In a desktop OS, there is no conceivable reason why you would want to have two files in the same folder that are, for all intents and purposes, named the same thing. "Picture1.jpg" is the same thing as "picture1.jpg". No, really -- it is. It's the metaphor by which you organize the people in your address book. Would you consider "john thomas" to be a different person from "John Thomas"? Would you be unconfused by a set of introductions at a party with both these fellows in attendance?
Mac and Windows users have to have filenames read to them over the phone by support techs. They have to be able to write little sticky notes to their mothers about how to open up the mail program, without worrying about how the filenames are capitalized. Haven't you ever fumed over a URL with initial-caps in the folder names in the path, having to fiddle with capitalization until you get a response that's anything but a 404? Haven't you ever been secretly pleased that e-mail addresses aren't case-sensitive?
(Side note: Apache's mod_speling module corrects capitalization errors, but does it the "right" way-- issuing a redirect so the browser re-requests the file with the correct capitalization, thus closing the loop as a "case-preserving" scheme. Windows servers just happily serve up the file with the wrong capitalization, leading the client to save a file capitalized differently from the copy on the server.)
Bear in mind that it's MUCH more work for a filesystem to be case-insensitive than -sensitive. A filesystem is case-sensitive by default, in the simplest case; it can only be made case-INsensitive through a lot of extra engineering. In UNIX, all the system has to do is sort on the ASCII values of the first letters of the filenames. In the Mac OS and Windows, the filesystem has to be smart enough to create synonyms of various letters -- A for a, and so on -- and sort accordingly. That takes a LOT of code. It's a testament to the completeness of the original Mac OS that in 1984 this was all handled properly, before Windows even brought lower-case letters to the PC side.
It goes well beyond that, too. Look at how the Mac handles foreign, extended characters. Rather than the Windows way, in which you have to pick accented characters from a bizarre grid of upper-ASCII values, the Mac builds such things into the keyboard input routines in a way that's workflow-consistent. Press Option+U, and you get an umlaut. Then enter a vowel, and the umlaut combines with the vowel. Option+U,U -- and there's your ü.
And what about sorting? The Mac sorts ü right along with the other U variants. iTunes recognizes Bjork and Björk as the same artist. There's a completeness to the thinking here that Windows still only approximates. Windows sorts all of your folders first in a folder listing, before any files. Why is that? And it still has that infuriating and inexplicable stupidity of not allowing you to create a file with a name that's an all-caps acronym, without helpfully converting it to an initial-caps string for you.
It's taken me a long time to come to terms with the appropriateness of a case-preserving, case-insensitive filesystem, but I've done it. It's clear to me now that while it's nice in an academic sense to have deterministic control over filenames to the point where two files that differ only in capitalization can exist in the same folder, it's simply nothing but confusing to a casual user for there to be a distinction. It's an area in which Mac OS X inherits some of the very hard and complete work of the classic Mac OS development in the form of the HFS+ filesystem, but in which some of the recent UI decisions are causing ease-of-use to suffer (for instance, hidden filename extensions, which lead to the never-before-seen problem of multiple files with the same APPARENT filename in the same folder -- we can only hope we don't end up like Windows, with six files in a folder all called "setup"). And this is one case where I hope Apple develops with the home user in mind, rather than the academic UNIX geek.
It's telling that over the past several years, in attempts to reassure myself of the usefulness of case-sensitivity, I've asked UNIX geek after UNIX geek to name a single truly compelling reason for it to exist. And to a man, not one of them could think of anything more concrete than "Well... y'know... it's just better."
No, the Mac way of handling lexicography is by far the most intensive and complete out there. Certainly by comparison to UNIX and Windows. And I've come to appreciate it as a true Mac advantage.
-- Brian Tiemann
I also got a ton of mail in defense of AppleScript. I noted that I thought AppleScript was a fine language, but that Be's method was better because it lets you write scripts in any language. Oops. My mistake there was in not distinguishing clearly between AppleScript and AppleEvents. Reader Michael Hanson described the situation clearly:
Re: the AppleScript issue... scripting is implemented using something called the Open Scripting Architecture. Apps don't actually expose AppleScript hooks directly; they expose "Apple Event" hooks, which are basically interprocess events. The Open Scripting Architecture sits on top of the Apple Event system, and AppleScript is implemented in OSA. So, theoretically, you could have any number of other languages sitting on top of the OSA that could still use all of the scriptable apps.
In practice, there's really only ever been one other scripting language for the Mac, which is Frontier, from UserLand. But there's no technical reason why you couldn't have perl, python, or whatever calling into OS X apps. I think.
Here's a quick reference.
Many readers also brought up the case of MacPerl, which lets users script GUI apps. So AppleScript's near-hegemony is not due to any architectural limitation in Mac OS.
I received dozens of emails on the keyboardability issue, ranging over the entire spectrum from love to hate. All the way from people who said they would love to switch to Mac OS X but couldn't because the keyboardability was so abysmal to those defending every aspect of it from a human-interface design perspective. It takes all kinds, which is an important point in and of itself - an effective operating system must accomodate all kinds of people with all kinds of needs and predilections. Whether you like or dislike the current keyboardability of OS X, it's impossible to deny that a lot of users hate it, and that fact alone should be enough to warrant serious work in this department.
I have one criteria for keyboardability, and one criteria only: It should be the fastest possible way for me to operate my computer. That's why things like the Full Keyboard Access tab in System Prefs seem like a joke to me - yes, it lets me pull down menus without a mouse, but the methodology it provides is far slower than simply reaching for the mouse to begin with. If Apple is going to re-evaluate keyboardability, they need to remember this in every nook and cranny of the OS, from menus to dialog boxes and everything in between.
This one definitely turned into a hot-button. I received a lot of cogent email on this, but unlike the case sensitivity issue, I didn't hear a single convincing argument in support of Cmd-O or Cmd-DownArrow instead of Enter for file launching in the Finder.
Several people claimed that Apple is trying to de-emphasize "destructive" moves. In other words, some people seem to think that launching a file is less "destructive" than going into rename mode on it. That makes no sense to me at all. The reverse seems true (renaming a file is more "destructive" than launching it).
Others said that "Enter" is associated with entering words into a text editor, and is therefore associated with editing the file's name. I beg to differ. "Enter" is the universal "Go do it" key throughout the computing universe. Enter activates the selected button, takes me to a URL I've just typed in my browser, and tells the Terminal to execute the command I've just typed. The Enter key should launch files.
Another reader noted that Cmd-O is used to open files from within apps. At first glance, this seemed like the best argument I had heard - it appears to make sense from a consistency perspective. On closer inspection, though, this falls apart, because Cmd-O from within an app says "Show me a file panel," not "Act upon the selected item." Big difference.
A final thought: Double-click and Enter are generally functionally equivalent. Since a double-click launches a file in Finder, shouldn't Enter do so as well?
I posted a screenshot of a BBEdit dialog box which (I thought) wouldn't let me Replace All without reaching for the mouse. Turns out I was wrong! Hold down Cmd for a second and trigger keys appear on all the buttons in that dialog. Well, I'm glad to know this is possible, but there are two problems:
This is the kind of thing that Windows does far better than OS X. It's 100% consistent throughout the OS, and its usage is more apparent.
One other note: It's still not possible, as far as I can tell, to tab between buttons -- only between text fields.
Again, got the full range of responses on this one, ranging all the way from:
"In your article, you mentioned many of the things about MacOS that simply drive me insane. The home/end keys thing is a huge issue for me. I use those keys and the CTRL + arrow keys all the time when I am editing code or web pages and I simply can't give that up."
all the way to:
"I'm a tech writer too and I jump to the top and bottom of the doc all the time, but rarely ever to the start and end of the line."
I can only take that person's word for it. It's hard for me to imagine why someone would want to go to the top or bottom of the doc except to initiate a search. But while editing text, start and end of line is something I use constantly to get quickly closer to the word or phrase I need to edit.
The point is that people work in very different ways, and OS vendors need to provide the flexibility for people to work however they feel most comfortable.
Interestingly, throughout Office X for OS X, Home/End work as they do in Windows, Linux, and BeOS (start/end of current line) - MS has apparently decided it's more important to make editing easy than to blindly revere this Mac tradition.
Yes, there's a lot to be said for the power of muscle memory. But on the other hand, I've been trying to retrain my fingers for several months now, and it's not working out. It's not that I'm still reaching for the Home/End keys, just that it takes more time to find Cmd-LeftArrow / Cmd-RightArrow. The arrow keys are just as far a reach as the Home/End keys, but now the left hand has to re-orient itself as well. This operation which I perform dozens (if not hundreds) of times per day is a two-handed operation in OS X, whereas it was a one-handed operation in Windows, BeOS, and Linux.
One reader pointed out that Cocoa apps support emacs keybindings. For example, Mail.app, TextEdit, and the URL bar of OmniWeb.
Open up TextEdit, type a few words into a document and then Ctrl-A, Ctrl-F, Ctrl-B, Ctrl-D, Ctrl-E, etc. and you'll get what I'm on about. It works just about everywhere you're editing text, such as in Mail, or even in the URL bar of Omniweb, but not Internet Explorer for some mysterious reason... In BBEdit, it's a Preference setting. -- Rob Telford
Interesting - Be's built-in Mail app supports these as well.
I incorrectly stated that Tinker Tool lets you change the font in the Finder. Tinker Tool does have a panel that lets you change the System and Application fonts, but these settings do not affect the Finder.
I incorrectly said:
"Office X includes Entourage, which is the Mac version of Outlook/Express. "
Not quite. In fact, MS makes three similar products for the Mac:
I incorrectly stated that OS X's display engine is PostScript-based. This is incorrect. OS X is PDF-based. Apple developed their own PDF rendering engine to avoid paying licensing fees to Adobe for PostScript, and because it offers efficiency advantages over PostScript. From Apple's tech docs:
"The internal model that Core Graphics Rendering uses for vector graphics representation is Portable Document Format (PDF). As a superset of Adobe PostScript, PDF brings several improvements, including better color management, internal compression, font independence, and interactivity. However, PDF is not a full-fledged language as is PostScript; it is declaratively, not programmatically, specified. Consequently a sophisticated and expensive language runtime is not necessary, as it is for PostScript."
Something I forgot to mention in the original piece but often find myself wanting: Hide This App is almost always mapped to Cmd-H. Why does Apple not provide a hotkey for Hide Others, which I use just as frequently? Mysterious. And for that matter, I'd really like a menubar button I could click to Hide All (Reveal Desktop), a la Windows. Anyone have any theories why these don't ship with the OS by default? Any good 3rd-party solutions for these?
Update: I've learned that if you Cmd-Opt-click a Dock item, it will hide all but that app. Very nice. Still odd that there's no trigger key for this.Several readers asked whether I could write a regular OS X column for Byte similar to the BeOS column I wrote for them. I'd love to, and actually pitched the idea to them, but unfortunately my column at Byte was dropped due to funding cutbacks as much as due to Be's demise. Content-driven web sites are expensive to run, and layoffs are the M.O. these days, not new columns.
I was also asked whether I was interested in writing an OS X Bible similar to the BeOS Bible I wrote for Peachpit. This sounds like a great project, but there are already a number of OS X books on the market, and I don't have the long history with Mac OS that I have with BeOS.