Mac OS X GUI versus Windows XP GUI

[Nostromo]

On the "why people still use Windows" thread, I asked what's so great about Mac OS X's GUI, and what's wrong about it. I also asked the same about Windows XP's GUI. I never got an answer, so I googled it. Here are Bruce Tognazzini's thoughts about these issues. Even though he's an ex Apple employee, he makes good points IMO.

http://www.asktog.com/columns/022DesignedToGiveFitts.html

A Quiz Designed to Give You Fitts

So you think you are an interaction designer? Not if you cannot answer all the following questions quickly and with authority.

If you're not an interaction designer, but you know one—or you are thinking of hiring one—slip them just the questions, and see how well they do. I've used variations of this quiz for years during the interview process to good effect.

These questions and answers assume that you have total control over all screen real estate, the OS, etc. Just pretend you are chief designer for Microsoft and Apple (after the big takeover).

The Quiz

1. Microsoft Toolbars offer the user the option of displaying a label below each tool. Name at least one reason why labeled tools can be accessed faster. (Assume, for this, that the user knows the tool and does not need the label just simply to identify the tool.)

2. You have a palette of tools in a graphics application that consists of a matrix of 16x16-pixel icons laid out as a 2x8 array that lies along the left-hand edge of the screen. Without moving the array from the left-hand side of the screen or changing the size of the icons, what steps can you take to decrease the time necessary to access the average tool?

3. A right-handed user is known to be within 10 pixels of the exact center of a large, 1600 X 1200 screen. You will place a single-pixel target on the screen that the user must point to exactly. List the five pixel locations on the screen that the user can access fastest. For extra credit, list them in order from fastest to slowest access.

4. Microsoft offers a Taskbar which can be oriented along the top, side or bottom of the screen, enabling users to get to hidden windows and applications. This Taskbar may either be hidden or constantly displayed. Describe at least two reasons why the method of triggering an auto-hidden Microsoft Taskbar is grossly inefficient.

5. Explain why a Macintosh pull-down menu can be accessed at least five times faster than a typical Windows pull-down menu. For extra credit, suggest at least two reasons why Microsoft made such an apparently stupid decision.

6. What is the bottleneck in hierarchical menus and what technique used on the Macintosh, but not on Windows, makes that bottleneck less of a problem? Can you think of other techniques that could be applied?

7. Name at least one advantage circular popup menus have over standard, linear popup menus.

8. What can you do to linear popup menus to better balance access time for all items?

9. The industrial designers let loose on the iMac not only screwed up the mouse by making it round, they screwed up the keyboard by cutting the command keys in half so the total depth of the keyboard was reduced by half a key. Why was this incredibly stupid?

10. What do the primary solutions to all these questions have in common?

If you can’t answer the last question, you are going to have all kinds of trouble with the rest. You aren’t alone, of course, as evidence abounds that no one at Microsoft and fewer and fewer people at Apple could answer these questions.

Microsoft sort of has an excuse. They claimed from the beginning that a visual interface with the mouse and all that junk is inferior to a keyboard interface. They might have looked foolish if they had ever really tried to build a real GUI. By consistently sabotaging the visual interface, they have avoided such embarrassment.

What has happened at Apple is a little more mysterious. The industrial-design blunders are expected. Apple’s outside industrial designers have always hovered between cluelessness and hostility when it came to human factors. However, lately, Apple has been doing some pretty stupid stuff in-house, too. Like turning the rapid-access Labels menu into a hierarchical, slowing it down by five or ten times.

The Answers

Let's start out with a preview of the answer to question 10, Fitts's law, since all the others revolve around it. From First Principles of Design:

* Fitts's Law: The time to acquire a target is a function of the distance to and size of the target.

This little bit of obviousness is so often ignored, I sometimes wonder if it is on purpose. Usually, though, it is merely a leading indicator of overall ignorance, amplified by superstition and unsullied by facts or study.

Fortunately, readers of AskTog, being as tenacious as they are perspicacious, either know exactly what Fitts's Law is or damned well will by early tomorrow morning.

Fitts's Law (properly pronounced "fitzez law") is simple, absolute, and immutable. Let's see how it pertains to the questions:

Question 1

Microsoft Toolbars offer the user the option of displaying a label below each tool. Name at least one reason why labeled tools can be accessed faster. (Assume, for this, that the user knows the tool and does not need the label just simply to identify the tool.)

Here are two answers. You may have more.

1. The label becomes part of the target. The target is therefore bigger. Bigger targets, all else being equal, can always be acccessed faster. Fitt's Law.
2. When labels are not used, the tool icons crowd together.

At first glance, it might appear advantageous to crowd the icons together, since it results in less distance among targets. However, the task here is not to hop from target to target. Instead, the point of origin when a user decides to access the toolbar will usually be somewhere in the content region, away from all the tagets.

When the icons are spread apart, users have a "buffer zone" between icons, where an incorrect acquisition will result in no action. When the targets are crowded together, however, the user has more chance to initiate an unwanted action. To avoid this possibility, non-label users learn to slow way down. (Don't bother to ask them whether they've slowed down. They'll tell you it sped them up. Only the stopwatch knows for sure.)

Another way to make the targets bigger, of course, is to always choose large icons, rather than small. Pity the "power-user" with the 4x4-pixel icons who thinks he's going faster.

Question 2

You have a palette of tools in a graphics application that consists of a matrix of 16x16-pixel icons laid out as a 2x8 array that lies along the left-hand edge of the screen. Without moving the array from the left-hand side of the screen or changing the size of the icons, what steps can you take to decrease the time necessary to access the average tool?

Two separate steps may be necessary to maximize average tool access time. Both are important.

1. Change the array to 1X16, so all the tools lie along the edge of the screen.

2. Ensure that the user can click on the very first row of pixels along the edge of the screen to select a tool. There should be no buffer zone.

This second step is vital, and is so often ignored.

Remember that Fitts's Law states that access time is a function of distance and target size. If the target size is larger, then the time is reduced. It is reduced for a simple reason: the user need not slow down when approaching the target for fear of overshooting.

Now consider the screen edge. How deep is the target? If it were really only the one pixel it appears, it would be very hard to hit. However, the screen edge is, for all practical purposes, infinitely deep. It doesn't matter how fast that mouse is going when it hits the screen edge, that pointer absolutely will not overshoot. Having to hit a pixel two pixels in from the screen edge takes much longer than hitting the edge itself. Use that edge. It is your friend.

Question 3

A right-handed user is known to be within 10 pixels of the exact center of a large, 1600 X 1200 screen. You will place a single-pixel target on the screen that the user must stop upon and point to exactly. List the five pixel locations on the screen that the user can access fastest. For extra credit, list them in order from fastest to slowest access.

No, this is not a trick question. And the first part should be immediately answerable by any interaction designer. The extra credit question is not quite as simple. But first, the locations of the five "magic pixels":

The prime pixel is located at the current location of the mouse pointer. Popup menus make use of this pixel, showing up relative to the mouse pointer, no matter where the user may have moved it. This pixel requires zero travel and is, in effect, an infinitely large target—you just can't miss it.

The other four pixels are located, on average, as far away from the mouse pointer as you can get. Their distance, however, is more than made up for by their target size, which is infinite in two dimensions. These magic pixels are the four corners of the screen. Throw the mouse in any direction you desire and the odds are overwhelming that if you threw it with enough velocity, it will end up in one of those four corners. This presupposes a properly designed acceleration function for the mouse.

The key to the extra credit question is in the user's right-handedness. A right-handed user can access, in order of increasing difficulty, and starting with the point already mentioned:

1. The pixel immediately at the current cursor location: Click the mouse and you're done.

2. The bottom-right corner.
3. The top-left corner.
4. The top-right corner.
5. The bottom-left corner.

If you hold the mouse in your right hand and move the mouse, using just your wrist and hand, in the four different directions, you will see how the mechanics of your arm leads to this. The answers for a left handed person are, of course, reversed.

These differences are relatively small compared to the power of the "magic pixels." All four corners should be used and used well.

Question 4:

Microsoft offers a Taskbar which can be oriented along the top, side or bottom of the screen, enabling users to get to hidden windows and applications. This Taskbar may either be hidden or constantly displayed. Describe at least two reasons why the method of triggering an auto-hidden Microsoft Taskbar is grossly inefficient.

Now these should have started getting easier.

1. Screen edges are prime real estate. You don't waste an entire edge that could be housing a couple of dozen different fast-access icons just for one object, the Taskbar.
2. The auto-hidden Taskbar is entirely too easy to display by accident. Users are constantly triggering it when trying to access something that is close to, but not at, the edge.
3. The Taskbar would not have any of these problems, yet be even quicker to get to if it were located at any one of four corners of the display. Throw the mouse up and to the left, for example, and you'll have a taskbar displayed. Fast access without the false triggering.

Question 5

Explain why a Macintosh pull-down menu can be accessed at least five times faster than a typical Windows pull-down menu. For extra credit, suggest at least two reasons why Microsoft made such an apparently stupid decision.

Microsoft, Sun, and others have made the decision to mount the menu bar on the window, rather than at the top of the display, as Apple did. They made this decision for at least two reasons:

1. Apple claimed copyright and patent rights on the Apple menu bar
2. Everyone else assumed that moving the menu bar closer to the user, by putting it at the top of the window, would speed things up.

Phalanxes of lawyers have discussed point 1. Let's deal with point two. The Apple menu bar is a lot faster than menu bars in windows. Why? Because, since the menu bar lies on a screen edge, it has an infinite height. As a result, Mac users can just throw their mice toward the top of the screen with the assurance that it will never penetrate and disappear.

Unless, of course, I'm testing them at the time. I did a test at Apple where I mounted one monitor on top of another, with the menu bar at the top of the lower display. The only way the user could get to the top monitor way by passing through the menu bar enroute.

I then gave users the task of repeatedly accessing menu bar items. When they first started out, they penetrated into the upper screen by around nine inches on average, just because their mouse velocity was so high. Then they learned they had to slow down and really aim for the menu. By the time they adjusted, their menu-access times became so ponderously slow, they took around the same time as the average Windows user.

The other "advantage" usually ascribed to a menu bar at the top of each window is that they user always knows where to look for the items pertaining to the task they are carrying out. This is silly. Users may do various tasks within a given window, and the menu items may change. Not only that, but a great many perverse applications exist, particularly in the Sun world, where the menu bar you need to access is not even in the window in which you are working! That is truly bizarre and mind-bending.

Microsoft applications are beginning to offer the possibility, in full-screen mode, of a menu bar at the top of the display. Try this out in Word or Excel. It is much faster. Microsofts general cluelessness has never been so amply displayed, however, as it is in Microsoft Visual Studio, which has a menu bar at the top of the screen with a one-pixel barrier between the screentop and the menu. Talk about snatching defeat from the jaws of victory.

Question 6

What is the bottleneck in hierarchical menus and what technique used on the Macintosh, but not on Windows, makes that bottleneck less of a problem? Can you think of other techniques that could be applied?

The bottleneck is the passage between the first-level menu and the second-level menu. Using Windows, users have to slide across just right, least they slip down to the next menu at the last moment.

When I specified the Mac hierarchical menu algorthm, I called for a V-shaped buffer zone, so that users could make an increasingly-greater error as they neared the hierarchical without fear of jumping to an unwanted menu. As long as they are moving a few pixels over for every one down, on average, the menu stays open. Apple hierarchicals are still far less efficient than single level menus, but at least they are less challenging than the average video game.

The Windows folks instead leave the hierarchical open for around a half-second before jumping down. Thus, as in so many of the other areas of their OS, they mimic the Mac without getting it right. They have decoupled cause and effect by 1/2 second, a long, long time in human-computer interaction. If you happen to get to the hierarchical within that half-second, the Windows behavior is indistinguishable from the Mac. If you don't, the behavior is just weird and few users can figure the rule out.

Question 7

Name at least one advantage circular popup menus have over standard, linear popup menus.

With the options displayed around you in a circle, you need only move a pixel or two to enter the "slice of pie" you want. Less travel, good target size. Good design.

They have a second advantage of feeding not only distance, but direction information into your motor memory. As long as the options are few enough, you will soon learn to move your mouse up and to the left to print, down and to the right to fax, etc. In fact, once these simple gestures are learned, you needn't even display the menu anymore, unless the user hesitates long enough to indicate they may be unsure. (This was borne out during the course of the Fabrik project at Apple in the late 1980s.)

Question 8

What can you do to linear popup menus to better balance access time for all items?

You can "Fittize" them by making those items farther away from the mouse pointer larger. They need not literally be larger, since the user is not having any trouble seeing the farther items. Instead, the mapping of mouse-to-screen could be such that, as the user pulls further down the menu, more movement of the mouse is necessary to get a corresponding movement of the pointer. In effect, you are decoupling the behavioral map of the screen from the visual map.

Other decoupling tricks include setting up local gravity, so that once a mouse pointer gets near the target, it is drawn to the target. Barriers can be erected, so that once the mouse enters an object, it is difficult for it to pass through to the other side. This can be frustrating. Having a pressure-sensitive mouse that could "push through" if pushed down upon would enable the user either to be caught by the object or to flee to the territory beyond.

[...]

Question 9

The industrial designers let loose on the iMac not only screwed up the mouse by making it round, they screwed up the keyboard by cutting the command keys in half so the total depth of the keyboard was reduced by half a key. Why was this incredibly stupid?

The farther away the target is, the larger it must be to retain access speed. Not only did the industrial designers reduce the total size of the target, they reduced it in the very dimension that was most critical. Stupid, stupid, stupid. What they should have done was to curve the keyboard sharply upward, so that merely lifting the finger a few degrees would access the numeric and function keys, aiding both precision and speed.

Question 10


What do the primary solutions to all these questions have in common?

You now know that it's Fitts's law. And you can use it in everyday design, whether you are building a new OS or laying out a new web page. When that default OK button, with only two characters, ends up really small, consider packing a few spaces in on either side to fill it out. If you have real control over your environment and are laying out a palette, make sure the user can access the tools by pinning against the screen edge. If you have menu bars at the top of the screen, use them! They are far more compact than a bunch of icons or buttons and, if you user-test, you will see they are faster. And if you work at Microsoft or Apple, consider listening to the people that have a clue when it comes to interaction design. They do exist. I've talked with them before. You might try talking with them, too.

[Nostromo]

He's also critical about Mac OS X. He thinks that the Dock, in particular, sucks. Despite that, he doesn't think Apple should get rid of the Dock:

Contrary to my previously-held position, I no longer believe Apple should get rid of the Dock. It's just too pretty there in the store, and it does help set Mac apart from the more utilitarian appearance of Windows (although Windows grows more attractive with every release). You want that in sales. You want a visibly-apparent manifestation of the personality of the underlying technology. That's why automakers spend milliions making the outside of the car project an image of what's underneath the skin.

http://www.asktog.com/columns/044top10docksucks.html

Some reasons why it sucks, according to him:

The Dock is big and clumsy

The Dock by default sucks up around 70 pixels square minimum, more than four times as much vertical space as either the Windows task bar or the Macintosh menu bar. (Yes, you can set it much smaller, but then you make it progressively more difficult to identify an icon without "scrubbing" the screen with your mouse to reveal its label.) Couple that with Apple's move to 16:9 wide screens (read: short screens), and you have a real problem. For good measure, add in the Dock's habit of floating on top of working windows, and you have little choice but to hide it.

Dock objects have no labels

That works fine in the demo, since every object shown is completely unlike every other object. However, put in three or four folders next to each other and the user becomes clueless.

Yes, the user can "scrub" the length of the Dock, forcing one label at a time to appear as they root around for the right folder. However, that takes time and, when dragging a document, ensures a high rate of serious error.

Again, the best solution is to provide something other than the Dock specifically designed to show such objects.

The Trash Can belongs in the corner

This decision was so wrong that several replacement desktop trash cans have appeared to address it. Dock diehards point out that they always use Command-Delete anyway. Of course they do! That's because having a hidden, constantly-shifting trash can sucks!

The Dock's locations are unpredictable

Apple's solution to the early fire storm of protest over the Dock was to allow the user to hide it. That way, it doesn't float over all your applications. Slide below the screen with your mouse and the Dock appears.

This Windows copy job, unfortunately, suffers from the same defect as the Windows Task Bar: You can't predict where a given object is until you reach the bottom of the screen and cause the Dock to appear. Worse than with Windows, your job is not over. Now, you begin the task of scrubbing the length of the Dock, trying to force the labels to appear, hoping you won't go far enough out of range in the process to cause the bar to disappear on you. (The Dock is linear; the human hand was designed to move in an arc. We don't do well with scrubbing.)

The Dock is a sprawler

The corners and edges of the screen are proven by Fitts’s Law to be the most easily reached targets. The low-information-density Apple Dock takes up a variable, but large measure of one entire side of the screen, leaving little or no room for high-density docks, such as those of DragThing. It's target region sprawls even beyond, covering one entire side of the screen.

This excessively-large target also ensures many mistakes, where people are simply sweeping the mouse too far while engaged in their application, suddenly triggering the hidden Dock.

The Dock needs to have a visible target. Hit the target and the Dock opens. Miss the target and the Dock won't open. Then supply a very slight delay, measured perhaps one twentieth or one tenth of a second to prevent accidental triggering. (The Dock, at the time of 10.3's release, has an excessively long delay, probably in response to the invisible, unpredictable sprawl problem herein discussed.)

This tab could be dynamic, one or two pixels deep and running the full length of the Dock, with the Dock acting much as it does now except in a more predictable manner. Or the user could elect to set a labelled tab of user-defined width, freeing up a lot of precious edge space. Still another option might have the Dock triggered by throwing the mouse in a corner. This could relieve much of the frustration of the variable-location trash can. Throw the mouse in the lower right-hand corner to grow the Dock up the display from that point, leaving the trash can in a consistent, predictable location.

(This by the way, is the way the Windows XP task bar should be triggered, instead of having any touch of the bottom of the screen display it.)

To improve the Mac experience, he suggests some add-ons:

http://www.asktog.com/columns/060MonsterMac.html

[Urban Ranger]

Fitts's "Law" is hardly a law in the scientific sense.

[Kuciwalker]

[Asher]

Originally posted by Urban Ranger
Fitts's "Law" is hardly a law in the scientific sense.

You're completely right, it's a law in the mathematical sense.

[Asher]

The AskTog articles are generally nonsense, as you'd expect from the guy who actually patented the single-menu bar, he's defending it.

The Apple menu bar is a lot faster than menu bars in windows. Why? Because, since the menu bar lies on a screen edge, it has an infinite height. As a result, Mac users can just throw their mice toward the top of the screen with the assurance that it will never penetrate and disappear.

He's overestimating the importance of one case -- a maximized window where you can just throw the mouse up to the top to access a menu.

There are many problems with the "single menu" approach, the most important of which is multitasking. If you have, say, 3 windows open in non-maximized state in this contrived example: one is an interface to a digital camera, one is a file manager, one is a photo editor.

In Windows (and most *nix window managers), each menu is logically attached to the window it controls. This intuitively makes more sense, in addition to being much more efficient: you can see the menus for all 3 applications at once, rather than having to waste time selecting the other windows, then once again dragging the mouse up to the top of the screen to actually use the menu.

Using Fitts' law again, we can see that this requires dragging the mouse about 3x as much to access the same set of menus. Further, the windows likely aren't at the edge of a screen so you're not taking advantage of an infinite plane anyway.

The only case where a single-menu bar is theoretically faster is when you're using a single window, maximized. And that's because the controls are close to the window, and can still use the infinite plane when throwing the mouse up to that menu. This advantage is overstated -- the Windows menus are so damn close to the top of the screen in a maximized window that you can still "throw" it up to the top and then make an extremely minor correction anyway. Of course, after a while you don't need to throw it up to the top anyway, and you become more precise...

There's a reason no one else is implementing the single-menu mode, and it has nothing to do with patents.

[Kuciwalker]

He's overestimating the importance of one case -- a maximized window where you can just throw the mouse up to the top to access a menu.

He's correct in that even then, the menu bar isn't at the top of the screen.

EDIT: I see you mentioned that

[Asher]

Originally posted by Kuciwalker
He's correct in that even then, the menu bar isn't at the top of the screen.

This advantage is overstated -- the Windows menus are so damn close to the top of the screen in a maximized window that you can still "throw" it up to the top and then make an extremely minor correction anyway. Of course, after a while you don't need to throw it up to the top anyway, and you become more precise...

[Kuciwalker]

unintentional DanS

[Asher]

I'm not even going to discuss how awful the Finder is. Even most Mac users hate that thing, and Apple miraculously makes it worse in each MacOS X version. That's well-documented. File management is an extremely basic and necessary feature, so that's very frustrating to me.

The Dock is a disaster.

Simply:
1) By default, the icons move around and change in size. Absolutely stupid from a usability perspective, and it shows in a clear example how Apple values style and appearance over functionality.
2) The dock mixes up running and inactive programs, with only a stupid little triangle thing telling them apart. In my experiences on the Mac, this has been a huge pain in the ass. It's hard to tell instantly which windows are open and running, like it is on Windows.
3) Most applications aren't on the dock, and if all applications are, it's horrendously ugly and hard to use. I had to search for "Xcode" on our machines here because it wasn't on the dock, and I had to navigate the machine using Finder to find it. I wanted to cry...
4) There are no textual labels on the finder objects, only a stupid icon.
...

[Asher]

http://mpt.net.nz/archive/2004/02/16/os-x

My first 48 hours enduring Mac OS X
General (Mac OS X 10.3.2)

1. Pressing any key on the keyboard will wake the computer from sleep, but clicking the mouse button will not.
2. In Windows and in Mac OS pre-X, an ellipsis following the label for a button or menu item means further information is required to carry out the command implied by the label. In Mac OS X, however, an ellipsis means nothing in particular, and so does the lack of an ellipsis. (For anything you think it might mean, at least one of these is a counterexample: Open Location… in Safari; About in any application, Address Panel in Mail, and Downloads in Safari; the main Help menu item in any application.)
3. The Application menu (which appears to be a dumping ground for menu items that should not exist) has a different width in every application. This means the File, Edit, and View menus are in a different position on the menu bar in every application, making them slower to get at.
4. Some windows use a brushed metal appearance, while others do not. This distinction exists for no apparent reason.
5. In the Finder, Safari, Mail, and the Help Viewer, instructions for using a search field are placed inside the field, disappearing when the field is focused. This slows you down by making you check whether the text needs deleting every time you use the field, and it also hides the instructions just when you need them most.
6. Date and time entry fields in OS X are several hundred percent slower to use than the equivalent controls in Windows or Mac OS pre-X.
* The ? and ? keys cannot be used to increment and decrement values.
* The ? and ? keys cannot be used to navigate between components of a date or time. Tab and Shift+Tab are used for this purpose, inconsistent with their use in all other controls in the OS.
* Mistyped values cannot be retyped without selecting or deleting the previous value first.
7. Some listboxes (such as the Song list in iTunes, and the Buddy List in iChat) alternate blue and white highlighting to distinguish consecutive items, while others (such as the Source list in iTunes, and the List view in the Finder) do not. This variation exists for no apparent reason. To make things worse, Mail uses the same shade of blue by default to highlight message threads.
8. Disclosure triangles always look unavailable. (Indeed, they are almost indistinguishable from the icon of an unavailable Forward button in Safari or the Finder.)
9. Exceptions to the previous problem are the disclosure triangles used in Open and Save dialogs and in the Authenticate alert. These disclosure triangles have a different appearance from those in the rest of the OS, for no apparent reason.
10. Pressing the Escape key would be a reliable method of cancelling any drag, except that it doesn’t work when dragging an icon out of the Dock.
11. Dragging to the menu bar would be a reliable method of cancelling any drag, except that it doesn’t work when moving a window.
12. Sheets move together with their parent window, which is good, but they cannot be moved independently of their parent window, which is bad. When asked if I wanted to save changes [sic] to a newly-created TextEdit document, I could not remember whether what I had started typing was important, and I could not move the sheet out of the way to look.
13. Until you start dragging, resize handles and scrollbar thumbs give no indication of whether you clicked on them successfully or whether you missed.
14. Any scrollbar, when scrolled as far as possible to the top or left, looks as if it could be scrolled three or four pixels further upward or leftward.
15. The subtle ribbing within a scrollbar thumb stays in the same place (relative to the scrollbar as a whole) while the thumb is being dragged. This is subtly distracting because it does not make sense: the ribbing is not visible in the rest of the scrollbar trough, and therefore must be part of the thumb.
16. It is easy for important controls — such as a window’s scrollbar buttons and resize handle — to become unclickable because they are stuck under the Dock. The Dock cannot be hidden temporarily, but even if it could, that would only be a workaround, not a solution. 2004-02-28: It has been pointed out to me that Command+Option+D will put the Dock into auto-hide mode, which is somewhat similar to hiding it temporarily. I hadn’t found this myself because it isn’t mentioned in the help topic Shortcuts for the Dock, or in the help topic Shortcuts for the system, or in the help topic Using the Dock, or in the help topic The Dock is in my way, and because the Dock submenu of the Apple menu had been removed by FruitMenu which I was using to fix the jumping-menus problem. Incidentally, I’d expect the need for a The Dock is in my way help topic to result in the Dock itself being fixed by the third annual update to the OS, but it hasn’t.
17. In many applications (including iChat, Help Viewer, Mail, Preview, and Safari, but not iTunes), scrollbars in a background window will scroll in response to the same click used to bring the window frontwards (in Apple parlance, they allow click-through). This makes focusing a window without scrolling it frustratingly difficult, since the scrollbar trough is often a large fraction of the only visible edge of the window.

Finder (10.3)

18. Adding unpredictability to the previous problem, a Finder window’s scrollbar correctly ignores click-through when it takes focus from another Finder window, but incorrectly allows click-through when it takes focus from a non-Finder window.
19. The Finder presents a non-spatial interface by default. Those people most likely to need the simplicity and realism of a spatial interface are those least likely to realize it exists or how to achieve it.
20. Even when the spatial mode is achieved, it fractures by allowing the same item to be visible in two places at once. This problem can be experienced by opening the Desktop folder, or by expanding the disclosure triangle in a list view for a folder that is already open in its own window.
21. Normally, an alias to an item has the same icon as the original item. Unfortunately, there are some exceptions. These include (unless their icons have already been customized) the Applications folder, the Library folder, the System and System Folder folders, the Users folder, anyone’s home folder, their Desktop folder, their Documents folder, their Library folder, their Movies folder, their Music folder, their Pictures folder, and their Public folder. In other words, for all folders that have non-generic default icons, aliases to those folders fail to inherit the same icons.
22. Unlike the Trash in Mac OS pre-X, and even the Recycle Bin in Windows, the Trash in Mac OS X has no idea where any of the items inside it came from. Only the most recently trashed item can be restored to its previous location (unless you remember the location and drag it there yourself), and even that can only be done (using the Undo command) if trashing that item was the most recent action performed in the Finder.
23. Trying to open a file in the Trash from the Finder will, correctly, produce an error message (to prevent people from relying on the existence of a file that will disappear when the Trash is emptied). Dragging a document from the Trash to an application should result in the same error message, but it does not; the application will happily edit and save the document back to the Trash.
24. All folder windows zoom out from their icon when opened, and zoom back into their icon when closed. All, that is, except for the Trash.
25. An item’s color label highlights its text but not its icon. This allows a blue-labelled icon to look selected when it is not. It also causes unnecessary difficulty in finding a labelled item quickly, particularly when it is selected or when it is in Icon view.
26. It is impossible to view, let alone modify, an item’s color label from its Info window.
27. Disks cannot be given color labels, for no apparent reason.

Safari (1.2)

28. Clicking once in the address field does not do what people want 99 percent of the time, which is selecting the address so it can be replaced by typing a new one. (This can be done without interfering with those who want to select only part of the address, as demonstrated by Firefox and by Internet Explorer for Mac.)
29. Safari’s View menu gives greatest prominence to those items that will be used least often.
30. The dates in Safari’s History menu do not follow the format you choose in the Formats tab of the International panel in System Preferences.
31. Dragging a bookmark from Safari’s Bookmarks page to the Trash trashes the bookmark, as it should. Dragging a bookmark from Safari’s Bookmarks Bar to the Trash highlights the Trash, as if the bookmark will be trashed, but the trashing never happens.
32. It is unnecessarily difficult to tell whether you successfully clicked on a link (or dragged a link to a window), or whether — as often happens with unsteady hands or dirty cybercafe mice — you just missed. The cursor does not change at all; nor is there an indeterminate progress indicator, as might be expected from software that has no idea when or whether a remote server will respond. The only feedback is a partial, non-animated filling in of the address field, looking almost indistinguishable from selected text in the field.
33. The Show in Finder buttons in the Downloads window always look unavailable.
34. When a link’s href attribute contains a stray space character (for example, accessibility in web-based applications), Safari will go to the intended page, but it will never mark the link as visited.
35. Multi-line text fields use a proportional font rather than a fixed-width font.
36. Safari does not support HTML 4’s label element, but allows it to be styled. Many misguided Web authors style label in various ways to indicate its clickability, making its unclickability confusing.
37. When the currently selected option in a select element is too wide to fit in the option menu, it is truncated. The truncation should be indicated with an ellipsis, but it is not.

Mail (1.3.3)

38. The network activity window is called Activity Viewer in Safari, but just Activity in Mail. This distinction exists for no apparent reason.
39. The Stop buttons in Mail’s Activity Viewer are over-large and garish, and have a different appearance from those in Safari’s Downloads window for no apparent reason.
40. The default set of toolbar buttons in Mail’s Customize Toolbar dialog is not actually the default set. The true default set also includes the Junk button, at the opposite end of the toolbar from the Delete button. But in the junk filter’s Training mode Delete and Junk are used in tandem (first mark a message as junk, then delete it), while in Automatic mode they are close substitutes (Delete to delete a message, or Junk to delete it and future messages like it). Therefore they should be immediately next to each other by default.
41. Mail does not allow plain text attachments to be saved, assuming instead that they are part of the message text.

iChat (2.0)

42. iChat’s Buddy List window uses a mini-sized scrollbar, despite the rest of the controls in the window (and the scrollbar in instant message windows) being normal size.
43. If an instant message window is as tall as possible, every time you type a space the text field scrolls back to the first line, hiding what you just typed.
44. The Page Up, Page Down, Home, and End keys can be used to scroll through a Web page in Safari even when the address field is focused. The same should work in an iChat instant message window when the text field is focused, but they do not.

Help Viewer (2.0.4)

45. The Back, Forward, and Home buttons in the Help Viewer have a slightly different appearance from those in Safari, for no apparent reason.
46. The search field is the only usefully focusable control when the Help Viewer opens. (Focusing the content area is not useful when the Help Viewer opens, since the contents page for an application’s help should be — and usually is — too short to need scrolling.) Therefore the search field should be focused by default, but it is not.
47. The Help Viewer often takes a second or more to perform an action. During this time, it never provides feedback that anything is happening.
48. Unsuccessful search terms are not displayed in the Help Viewer’s No matching topics were found page. This, combined with the lack of in-progress feedback, makes it impossible to tell whether a second search has also been unsuccessful or whether it is merely taking a very long time.

[Imran Siddiqui]

He's overestimating the importance of one case -- a maximized window where you can just throw the mouse up to the top to access a menu.

Exactly (though I think rather it doesn't have to be a maximized window, but just ONE window being open case). I found that interesting as well... How difficult is it to go to a menu bar near the top of the screen, but not at the very edge? And with multiple windows, having one menu bar makes things more complicated.

[Asher]

Exactly (though I think rather it doesn't have to be a maximized window, but just ONE window being open case).

That's possible, but it's debatable if it's really saving any time if you're working on a smaller window in the middle of the screen and need to throw the mouse all the way to the top of the screen to access the menu. The "best case" for Apple's design is a maximized, single window.

[Verto]

I don't see the big deal made over the Dock. I find it extremely easy to use, regardless of whether or not it is costing me an extra .0000005 seconds to use. I have its size reduced so that it takes up about 5 inches, with a fairly large magnification - 3/4 the way to the max. I do not agree with his claim WRT having trouble trying to pick the right icon since the dock magnifies and "jumps around". I have no difficulty using it.

It is not as easy to access the more extensive list of programs installed that the Windows toolbar offered, but at the same time I haven't found myself missing that much. Really the only time I used the toolbar instead of desktop shortcuts was for stuff like the calculator.

[Verto]

Re: Mac OS X GUI versus Windows XP GUI

Originally posted by nostromo
On the "why people still use Windows" thread, I asked what's so great about Mac OS X's GUI, and what's wrong about it. I also asked the same about Windows XP's GUI. I never got an answer, so I googled it.

Well, my impression has been that graphically, compared to OS X, Windows XP looks extremely shoddy. Ignoring any technogeek arguments about the most inane problems made in some of the posts here, Windows XP looks like ****. Windows Vista seems to be more of the same, with very slight improvement. Now, the Linux-ite, ultra heavy-weight power users here who can change the Earth's axis with their keyboard shortcuts can say what they will about how graphics are just eye candy and are insignificant next to the power of the Force a solid command terminal or whatever, but when a normal, somewhat unbiased computer user looks at an OS X desktop and a Windows XP desktop, I am confident that they will agree the OS X design looks much cleaner, much nicer.