Safari 4 Beta's new tab arrangement has me bothered. It seems to be largely lifted from Chrome's user interface that puts the tabs at the very top of the window. Not only is this a departure from Apple's typical UI choices, it presents problems for users with special needs.

On your average Apple user interface, every object -- a title bar, menu, button, or handle -- has a single function. It can resize the window, move it, close it, or scroll it. Safari 4's tabs, however, have a dual purpose: They not only can be selected to move the entire Safari 4 window, but can be clicked individually to display their contents. In Safari 3, this was handled by two different objects -- the title bar to move the window, and tabs in the tab bar.

Google chose to put tabs at the top of the window because it was an important part of the user metaphor for their web browser, Chrome. In Chrome, tabs are independent processes brought together in a kind of stack. This is all very well and good, but it poses the same problem of having the area at the top of the window do two things at once: move the window as a whole, and control each item in the stack.

In the video at the top of the article, you can see the problem I have. I use a graphics tablet. Those who have graphics tablets know that when you're moving fast, clicking can sometimes result in dragging objects a short distance. With Safari 4, this results in a frustrating little dance until I can very precisely tap on the tab without dragging it across the screen. Furthermore, mistakenly clicking the close button or the resize handle for each tab creates additional complexity -- each with their own set of unexpected consequences. Dan Frakes and John Gruber have played with the title bar, too, and found their own litany of irks.

Tablet users can compensate for this by changing the configuration of their stylus. But people with motor control issues -- like those with slow reflexes, palsy, ALS and other motor neuron diseases -- will find this frustrating to use. Great care must be used to click on a tab without dragging, lest the window moves.

Mouse keys (found in the Universal Access preference pane, under the Mouse tab) may be one option to overcome this, and many individuals already have developed techniques that work for them. It is, however, another hoop to jump through just to use a web browser.

With Firefox and Safari 3, the tab bar was gracious enough to let you drag the tab a short ways and still appropriately switch to it when you let go of the mouse button. Safari could sidestep this problem by switching to the tab you click, even if you do drag the window by accident. But this creates a converse problem: if all I wanted to do was move the window, why did it suddenly switch tabs on me? Thus the need for a fundamental theory of UI: Every object needs only a single purpose.

My recommendation? Make the title bar tabs optional, and allow users the option of a more Safari 3-like tab experience. Mat linked yesterday to some undocumented preferences, but I think users would be well-served to have these available without using the Terminal.

This article was originally published on Tuaw.
Apple shareholders will re-elect board