NOTE: This website is deprecated. All the same blogs + comments are now available at http://blog.quaddmg.com. You can go to the same article by going to http://blog.quaddmg.com/articles/YYYY/MM/DD/article-name

6/16/2006

I tried to look more carefully at someone using a mac today, seeing exactly what was slowing them down, and I think I've got it. See, macs have their menu bar at the top of the screen as opposed to on the window (this is not a bad thing, just different). However, modern applications come with more than just menu items. They generally have status bars, toolbars, tabs, etc. These appear on the window itself.

So now you have two potential places to click around on: the top of the window and the top of the screen. In order to get their applications nicely centered on the screen, mac users often have to click and drag to resize their application. A lot of the resizing happens due to the users trying to click on something at the top of the window, and looking at the status bar at the bottom.

Now the reveal:

First, move the status bar to the bottom of the screen, not the window. This way switching between applications changes the status bar, switching between windows keeps the status bar in the same viewable place. Do the same thing for toolbars, but at the top, as if it were a maximised window in Windows. The downside of this approach is that there's a lot of screen real estate used by default, but with clever auto-hiding and information "squeezing" there's no reason this can't take as little space as it currently does. The big advantage is that the toolbars are always there, where they're accessible. You can click on toolbar buttons for an application without being able to see the entire window / the top of the window / etc. A lot of the resizing that currently occurs should be minimised. If the mac panels are anything like gnome panels, you'll be able to place them anywhere around the screen (like the left or the right) for a flexible setup. The second advantage is that each window, where these controls are duplicated, get a lot more screen space to display everything.

Second, get rid of the scrollbar on document viewers. Scrollbars really don't take advantage of the fluid window management in the mac. They also limit the power of the scroll wheel. My proposal is that the window grows to the size of the document (at least, perceptually). If the webpage is 1000 pages long, the window grows to 1000 pages long. In order to "scroll" down the webpage, you have to move the entire window up or down. Now you can use the scroll-wheel to move actual windows around. Modern scroll wheels are two dimensional, so this makes manipulating windows very easy. Easier if you add IE-style auto-scrolling. The big downside is that now you can't completely control the size of certain windows, but I see more mac users size windows to what they would've been with the above implementation than to some other size.

Finally, get rid of the title-bar. The only real reason for the title bar in a mac is for shading and moving a window. Because window movement can now be done with the scroll wheel, the major purpose of the title bar is gone. It takes up room, and it makes the top of the window more important than the rest, which is clearly incompatible with the "windows move everywhere" philosophy above. Get a key combination + middle mouse button to shade. This way middle mouse button + scroll wheel + autoscroll can control all window motion. A window should shade to where your mouse is, and re-expand to where you left it. This allows users to shade docs out of the way when they're doing other things.

I'm thinking this is a good idea. What do the mac users think?
 Comments (5)
If those you see using OSX are slow, it's probably because they aren't making proper use of the tools available to them when it comes to manipulating and switching between windows. In addition to all the clicking in windows you mention, users are also able to use the dock, "alt-tabbing" with either keyboard or mouse, various other keyboard shortcuts or using expose.

With your first point, where you speak about moving the status bar, do you mean having it as a separate element much like the menubar? To me, this is rather wasteful, since (for me, anyway) most programs don't make use of a status bar anyway. It would be a waste of screen real-estate.

I don't quite understand what you mean with the second point. You'll probably have to tell me what you mean in person.

Title bars? Most apps (though not all, which is dumb - some are even Apple ones!) are capable of having the title bar collapse. Your point still stands, however, since most programs can be moved around using various other parts of the window in addition to the top.
 
Nathan: Note that I'm including you in this analysis. You spend insane amounts of time resizing your windows just so. Manipulating windows is something you do slowly. The theory I'm submitting is that the tools available are not attacking the right problems. All of the dock, the alt-tabbing, and your beloved expose all attack the problem of selecting which window you want. They should've just solved the problem once and moved on to something else instead of solving it 3 times slightly differently and none of them as good as the start bar.

Even you've mentioned the "cascading" pattern you keep in the windows themselves, just so you get quicker access to them, at the cost of screen space. If expose, alt-tabbing, and the dock are so great then why keep bits of your windows exposed?

You're not looking at my first point in it's complete light. The status bar is there at the bottom of your window, still wasting space. Worse, you've got to have it showing because the resize widget is below the status bar. If you look at my solution with auto-hide, this makes a lot of sense, since when your application needs to display status, the status bar will come up, and disappear a few seconds after. This takes no screen space, and gives all the advantages of the status bar.

The main idea in the first point, though, was the toolbar, not the status bar. It seemed really stupid that the menu bar in a web browser, you have to click "Go -> Back", but on the toolbar, which has a "back" shortcut, you have to sometimes manipulate the window to get access to the back button.
 
In what way is the start bar any better than the dock? Or, rather, in what way is it any different at all? Clicking an item in the dock and clicking an item in the start bar are exactly the same thing.
 
Blogger Tim
My Macintosh brings all the boys to the yard, and they're like, it's better than yours, damn right, it's better than yours.
 
1)Start bar has text
2)Start bar has more options

At least it seems that way. The next block (also by Jobs) was a better implementation, with the folders and things. These either don't exist on OSX or nobody uses them.
 

Add Comment


<< Home