Just Not Quite There Yet
So I’ve spent a lot of time with the latest version of Firefox. I’ve used it as my primary browser, my secondary browser, and tried running with both it and Safari at once to highlight differences. I’ve reeeeeeeeeeally wanted to like Firefox 3, but in the end, I just keep going back to Safari.
Why? Well it’s a variety of things. My biggest gripe is its lack of integration with the Mac OS X Keychain. For the uninitiated, the Keychain is a secure service provided by Mac OS X that can store passwords and the like and make them accessible to applications that bother to integrate with it. Because it’s systemwide, I can be sure that any password I ask Safari to remember will be available to OmniWeb or the Finder, or the Disk Image mounter if they ask and I give permission. In practical terms, it means I can switch browsers and be sure that all my saved passwords will be remembered as long as the new browser is Keychain-savvy. It’s a terribly useful system, and I have pretty much all my passwords in it.
Sadly, Firefox doesn’t use it.
Another thing is the standard Mac OS X text view; developers will know it as an “NSTextView.” What’s so nice about NSTextViews? Well, for one, Appple keeps piling features into it! NSTextViews can check spelling and support a whole range of keyboard shortcuts for text selection and editing. In Tiger, NSTextViews started supporting instant definition and thesaurus lookups via an unbelievably-convenient floating dictionary panel that I use all the frikkin’ time:
In Leopard, NSTextViews can automatically detect links, change straight quotes to smart (”curly”) quotes, and check grammar. In the upcoming version of Mac OS X named Snow Leopard, who knows what they’ll add? The point is, any developer who uses NSTextViews in an application will get free features whenever Apple decided to update the NSTextView class. Thus, over the years, old applications have gotten more useful with the regular infusion of new functionality simply by using the Apple-supplied user interface widgets, and I’ve come to rely on a variety of features offered by NSTextView, in particular the systemwide spelling and dictionary integration and the text editing shortcuts. As with the Keychain, I’ve come to rely on the standardization afforded by NSTextviews.
Sadly, Firefox doesn’t use it.
And then there are all the niggling user interface quirks. Like how Firefox doesn’t respect Mac OS X’s systemwide “smooth scrolling” setting, instead, re-implementing it in what I feel is an overly slow manner. When I leave it on and use the arrow keys or the scroll wheel, it feels like it takes forever to get anywhere, but when I disable it out of annoyance, I have difficulty finding my place whenever I jump by a page-length at a time by hitting page down or the space bar. Sigh. Just use OS X’s built-in setting!
Another annoyance of mine is the perennial ignorance of the difference between a pop-up menu button and a drop-down menu button. The issue arises from the fact that in Windows, there’s one user interface element for both things. But there’s a subtle difference in OS X. A pop-up menu is used to select state; it lets you choose from a list of items to determine which one you want to be looking at or interacting with. When you make a selection, the widget itself changes its title to show you which item you’ve selected, since you may need to refer to which item you’re looking at.
A drop-down menu, on the other hand, is used to issue commands. Drop-down menus have fixed titles because they’re closely related to the menus at the top of the screen (or on the top of the window in XP or Vista). That is, the menu’s title lets you know what kinds of commands you can issue, and clicking on it brings down a list of these commands.
I’m always getting confused in Windows because both of these user-interface concepts are jammed into one widget. Whenever I click on a drop-down menu in Windows, I don’t know if I’m about to tell the program to do something or just change my selection. Usually the only cues it provides are the wording of the menu items: strong action verbs usually denote commands, but this has the unfortunate side effect of causing homographs to complicate things. Will the item labeled “Tag Field” select a thing called a Tag Field, or will it somehow tag or highlight all the fields?
Sadly, Firefox opts to adopt the confusing, inferior, Windows-like hybrid drop-down/pop-up menu universally, even on the Mac version. Sigh.
Now, don’t get me wrong; Firefox is a great browser. It’s fast, loaded with features, and feels great on Windows. My problem is that it still isn’t a first-class Mac citizen. I, like most Mac users, chose my platform because of the perceived superiority of the software bundled with and capable of running on Macs. This perceived superiority arises from useful, tightly-integrated systemwide services like the Keychain and Time Machine, and the clean, intuitive user-interfaces favored by Mac developers. In other words, we want to see our choice vindicated by using software that takes advantage of the features that set our platform apart from the alternatives. Firefox still doesn’t do this. And so I’ll stick with Safari.
August 28th, 2008 at 2:11 pm
The AwesomeBar is one of the hugest features of FF3, it really beats anything Safari can offer.
August 29th, 2008 at 12:40 pm
It is pretty cool, and I wish Safari would implement something similar. But that’s all it is: pretty cool — it’s nothing terribly important. If you want to talk about some things that Safari *really* needs to steal from Firefox, how about the ability to undo recently closed tabs and automatically re-open the last browser window on relaunch?
November 10th, 2008 at 1:42 am
So you’ve convinced me–even though people think I’m nuts for still using not-cutting-edge Safari, until something better comes along, I guess I’ll still keep using it!