An Objective Look at Safari 4 Beta - with Metrics

There have been many different reactions to the Safari 4 Beta, most based on a gut reaction or comparison to something comfortable. With that in mind, is there an objective way to evaluate Safari 4 calmly and rationally? A look at some fundamental browser notions proves to be fruitful.

Reactions to and opinions about browsers may make for interesting reading, but they don't really help a potential user make a decision about whether a new product is worthwhile. To that end, it seems reasonable to build some metrics for a browser that are quantitative.

There are two sub themes here. One, a good candidate for a standard in browser interface excellence is the Omni Group's OmniWeb for excellence in user interface. It's one of the few browsers that costs real money for real quality and value.

The second assumption, to simplify matters here, is that we all take for granted that a first class browser will attend to the issues of security, speed, and compliance with standards. Because these issues have nothing to do with the user interface tactics, they won't be discussed here.

Evaluation with Metrics

1. Intuitive clicking. This refers to a application layout that invites the user to click, intuitively, in all the right places. Controls should be logically grouped.

In that regard, moving the reload button out of the Toolbar just creates confusion for the user.

Next, because the tabs are placed on the top of the window, the user is now at a loss on where to drag the main window. Safari 4 fails.

2. Freedom from errors. An application should have its controls well spaced so that inadvertent clicking by just a few millimeters on the screen doesn't produce alarming, unintended, and unwelcome consequences.

By forcing the tabs to get smaller and smaller as the number increases, the likelihood that a tab will be closed when the user just wants to drag the window increases. Safari 4 fails.

3. Full disclosure. Information about the Web page should be fully revealed. The title of the page is designed by the Web page designer to provide useful information and should be respected.

By forcing the tabs to the top, the Web page title is now truncated into the tab, never to be seen again. Safari 4 fails.

4. Proper use of screen real estate and sense of time. A Web browser should assist with the preservation of the sense of time -- when did the user visit something?

Safari in general has a time-ordered history menu item. But when it comes to the Top Sites, the app seems ambivalent about whether this is a place for static favorites, defined by the user, or dynamic, changing over time. It's not intuitive how to create a set of favorites and keep them in place, but it can be done. As a result, the user can be confused about what Top Sites is for and how to control it as thumbnails dance around on the screen seemingly with a life of their own.

OmniWeb uses a set of thumbnails in a side-tab that are consistently added to, from top to bottom. While they can be arranged statically, the list grows top to bottom in an expected way. Safari fails, OmniWeb does not.

5. Graceful changes. A browser, as it morphs into the future, should respect that people develop a work flow and hand-eye-coordination habits. A new UI, if it has compelling advantages, can break that, but the user must see an immediate payoff, not capricious design.

Safari 4, in its compulsion to keep preferences minimalist, doesn't surface new interface options to the user. Instead, the user must locate mods by luck, and then implement them on the UNIX command line, not something everyone is comfortable with.

For example, to move the tab bar back where it was, restore the reload button, and recover the blue loading bar, one must issues these UNIX commands, then relaunch Safari. In that regard, Safari 4 fails the graceful change test.

> defaults write DebugSafari4TabBarIsOnTop -bool NO

> defaults write DebugSafari4IncludeToolbarRedesign -bool NO

> defaults write DebugSafari4LoadProgressStyle -bool NO

6. Limits on application arrogance. An application should not assume that it will be the preferred tool for an unrelated activity, one where users may have selected a better tool.

Safari 4 (as well as 3) force the user to launch Safari to change default browser preferences. Also, the RSS tab the preferences in both Safari 4 and 3, and forces the user to find this preference to change the default RSS reader. When the user's arm is twisted, in the name of obscured simplicity, that's arrogance. Safari in general fails this test.

7. Searchable history. Readers who use browsers often need to go back and find a key word or phrase. Simply looking at the history list doesn't always do the job.

Safari 4 introduces an elegant search function, combined with Cover Flow, that brings up pages that contain key search terms. Cover Flow can reveal the history of one's progression through Web pages. Safari passes.

8. User prompts for controls. A browser should have Mac OS X yellow box "callouts" that tell the user what each button does.

Both Safari and OmniWeb have these callouts. (Other browsers may have them as well.) Safari passes.

9. Reading aids. The browser should assist the user as much as possible with both scrolling and reading detailed text.

Safari 4 adds Multi-Touch gestures that afford faster zooming and scrolling. However, the pinch maneuver crashes Safari 4 beta on a MacBook Pro without fail. No doubt, that will be fixed as the product emerges from beta, but Safari 4 beta fails.


Apple says that Safari 4 introduces lots of new features. Under the hood, in terms of security, page rendering speed, and standard compliance, Safari is a superb browser. However, some of the UI changes that Apple has introduced in the beta of version 4 don't pass the acid test for thoughtfulness, respect, and user customization in user interface details. That may explain why there have been so many negative emotional reactions to the beta.