Subscribe to
Posts
Comments
NSLog(); Header Image

48 Hours

John Gruber says:

Recommended reading, even if you wind up disagreeing with more than 1.5 of his criticisms.

And so I shall: Matthew Thomas' list of faults found while "enduring" Mac OS X. As if the title alone didn't get you, the list surely will. Some are right, some are wrong. Let's have a look.

1. Pressing any key on the keyboard will wake the computer from sleep, but clicking the mouse button will not.

Works for me.

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.)

The presence of an ellipsis indicates that more information is required of the user. A quick scan of 20 of my applications (including all of my "always-on" apps) reveals that none have ellipsis after their "About" menu item (which does not prompt the user for more input). "Open Location…" in Safari does because it prompts you to type in a URL. "Downloads" in Safari just opens a window - no input required there, as does "Address Panel" in Mail. Finally, the "Help" menu item doesn't require further input, and when it does, it does so in a separate application (Help Viewer).

In other words, I find the use of ellipsis to be very clear. Ellipsis are used, or should be used, when the application requires further input from the user to complete the action. "Open Location…" asks you for more input or else it just sits there with a highlighted location bar, and "Downloads" opens your downloads window without any further action.

The HIGs state:

An ellipsis character (…) after a menu item or button label indicates to the user that additional information is required to complete a command.

Apple provides some more guidelines at the site above, none of which are broken by the list Matthew has provided. From memory, I can't recall an application menu item that doesn't follow these guidelines.

4. Some windows use a brushed metal appearance, while others do not. This distinction exists for no apparent reason.

Hey look, a bandwagon! Let's get on! This one bothers everyone and goes without saying, practically. Then again, any list that didn't have this one wouldn't be a very serious list.

8. Disclosure triangles always look unavailable.

Matthew has edited his article. A previous version noted that disclosure triangles looked different in other places (like dialogs asking for access to the keychain).

The disclosure triangle in a dialog box is a different style than one seen in other dialogs (or the Finder's list view). They're functionally different. Matthew continues this discussion in his 9th point even though it's the same argument. One I still feel is wrong. Triangles aren't all the same kind of triangle. You can re-use symbols so long as the functions are similar. In this case, the functions are "kinda similar" and the appearance is "kinda similar" (yet consistent within each variation). Seems OK to me.

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.

It's silly to think that dragging to the menu bar should cancel a drag. New users (i.e. those who aren't skilled with the mouse), trackpad users, and even power users who frequently re-arrange things would be annoyed to no end if this was implemented as Matthew suggests. If I'm dragging a window and want to position it at the top of my screen, I should not have to do so with pixel-level precision (for fear of having the drag cancelled).

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.

New users would hit the button and wonder where their sheet went. Would Matthew rather have modal dialogs everywhere? I hope not. Sheets, in my opinion, are great. Yes, they lack the ability to temporarily hide or roll up, but new users would be confused by this and advanced users tend to remember what they were typing (or realize that they can hit escape, have a look, and hit cmd-S again).

13. Until you start dragging, resize handles and scrollbar thumbs give no indication of whether you clicked on them successfully or whether you missed.

Thumbs should get darker to show that they're "selected" yes, I agree.

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.

Whatever he's smoking, I could use some.

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.

It makes sense to me.

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.

These are bad applications. The Dock, of course, can be temporarily hidden, so he's wrong in that regard. Cmd-opt-d to the rescue, eh?

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.

Yes, and this sucks. Agreed.

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.

I disagree. I think the labelling system we have now is better than the one we had in Mac OS 9 and, well, does Windows even have anything like labels? How easily could you discern a 16 x 16 icon's label in Mac OS 9 anyway? You couldn't, and oftentimes the tinting made the icon ugly as sin.

27. Disks cannot be given color labels, for no apparent reason.

Yes they can. I just labelled my two disks green and orange. So, bzzzzzzzt, wrong.

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.)

I disagree. I hated apps that would select the full URL. If I want to do that, I tab to the field, hit cmd-L, or click on the favicon. Having watched countless newbies use a computer as well, they too are surprised when IE selects the whole line. Oftentimes, they'll click at the end a second time and hold the delete key down. But me? I like - prefer - the way Safari handles this, and newbies do too only because they don't know any better.

29. Safari's View menu gives greatest prominence to those items that will be used least often.

Why does he mention this, yet fail to mention the existence of a disabled "Show" menu item in the View menu? Matthew loses a good deal of credibility for failing to mention this!

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.

Why should it? Why would I want to see "2004" on every previous day's history?

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.

38. The network activity window is called Activity Viewer in Safari, but just Activity in Mail. This distinction exists for no apparent reason.

I think Matthew got those backwards.

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.

Apparently not much is apparent to Matthew. Stopping, say, a 240 MB download which is still going on 5 minutes after you've left the Web site which had the download is far more damaging - and thus should be less likely to happen accidentally - than stopping an email check which you can quickly re-initiate. Furthermore, the Downloads window and the Activity monitor are very different things. Why mention this yet fail to mention that the activity monitor doesn't have a "Reload" button? Because it makes no sense. The windows serve different functions.

45. The Back, Forward, and Home buttons in the Help Viewer have a slightly different appearance from those in Safari, for no apparent reason.

One app is metal, the other is not. Again, apparently not much is apparent to Matthew.

In other words, I disagree with far more than 1.5 of his statements. Some of them are flat out wrong (and provably so - some aren't opinions).

14 Responses to "48 Hours"

  1. As for the "Labeling disk" point: I found that it worked here if I first selected the disk, then right-clicked, but not if I had another disk selected and directly right-clicked on the disk (the labels would just be greyed out).

    So it's simply a bug, not something which OS X lacks..

  2. Not that he doesn't have some good points, but I think a large number of these issues are simply personal taste.

    - Scott

  3. 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.

    Matthew is partially right on this one, but only in one case--logging out, when an app comes to the foreground to close and a document is open, you might very well not recall what was in the window. (I have this happen fairly frequently with TextEdit and Script Editor.) In those cases, escaping will allow you to close the dialog momentarily, but it will also cancel the logout. Transparency or resizability of the sheet would assist in these cases.

    Actually, as I sit here typing this in the form editor of OmniWeb Beta 2, I'm thinking that behavior like that of the form editor might be the best solution--a way to remove the dialog briefly and make it modal. Have this behavior triggered by a keystroke rather than a button in the dialog box, and you have a good solution for the power user that doesn't change the current behavior for a newbie.

  4. Isn't it funny how Windows people always pick apart every little detail of the Mac, yet the ignore all of the annoyances & inconsistencies in Windows.

    Actually the mix of aqua/brushed metal windows bothers me. I'd rather see all one kind.

  5. 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.

    Yeah, it's easy for them to be unclickable when they fall offscreen, too. I have a modest proposal: no windows should be allowed to overlap or move offscreen, ever! That'll solve this problem, and similar ones where any "on top" panel, pane, dialog or sheet overlaps a control.

    (sigh)

  6. I personally don't have a problem with the mix of metal and aqua apps. It doesn't even bother me that hiding the sidebar in Finder apps changes it back and forth. If it really bothered me there is a haxie available to take care of it. Personally I find a little variety to be nice. I've 'h4x0red' the nibs for Safari before to remove the brushed metal appearance, and though it might just be familiarity, I didn't like it as well. The darker (metal) window works better in some cases than a lighter (aqua) window for presentation purposes.

  7. What about the preferences menu item? That has an ellipsis and it is just displaying a window. Used to be under OS 9 that any menu item that caused a window to be shown had an ellipsis. Check out the about menu item (OS 9 remember) for an example.

  8. Bob: That rule has changed in Mac OS X. The new one is "use an ellipsis if the command needs more information to be executed", which is a question of interpretation on the preferences menu item.

    "Do it like Finder" might be a good idea, which has an ellipsis on preferences, but not on the about-item.

  9. doh, should have read the article 🙂

  10. Hey look, a bandwagon! Let's get on! This one bothers everyone and goes without saying, practically. Then again, any list that didn't have this one wouldn't be a very serious list.

    I find that this distinction makes quite good sense. First off, both aqua and brushed metal look pretty, though one looks better in some situations then the other. But due to the mix windows from different applications are easily recognized. It makes windows even more unique in appearance then by content and layout alone, which is nice.

    Some might argue that the value in adding an extra way to recognize windows from application more quickly is not necessary and that sticking to one design makes the desktop look less crowded and more consistent. But because (and especially with Panther) both the aqua and brushed metal designs look pretty and even together they look pretty good, I find that this extra distinction between programs is nice.

    Still using brushed metal at will is not a very good idea, some consistency would be nice, but I guess Apple has it just about right. Though different tastes means different opinions ...

  11. "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."

    I found this to be a problem when I had the Dock on the right side of the screen. I suppose it would also be a problem if it were at bottom, but I've never spent much time like that. It's easy to move a window over, then later go to scroll and end up dragging a Dock icon.

    I think you're less likely to have similar problems if the window hangs off the edge of the screen, because you can't see the inaccessible widgets. You *can* see the widgets through the Dock, more or less.

    The NeXT Dock could be toggled to a mode where it didn't float above all other windows. A single click on a Dock icon would bring the Dock to the top, but a window could be dragged over it when desired.

    I prefer that model. Having the Dock float above all windows eats screen space without really buying any functionality.

  12. Ah, the old single-click-selects-the-entire-URL "feature". That used to annoy me to no end. If I want to select the whole URL I'm not going to single-click, period.

    Also, I find OS X's scroll-bar thumb "ribbing" to be kind of ugly (regardless of how it moves, which I don't happen to understand). I wonder if it was originally unintentional; someone took a smoothly-shaded aqua blob and repeated the middle segment, which wasn't uniform, and the ribbing was born. It's pretty subtle.

  13. MPT has been a whiny little sod ever since he was effectively frozen out of the Mozilla UI community for being a ... well, whiny little sod.

  14. Er, right. Meanwhile, in the real world, I stopped devoting all my spare time to Mozilla when they stopped producing browsers for Mac OS 9, the only OS I was running at the time. It's amusing to think that the powers that be abandoned Mac OS 9 support because I was using Mac OS 9, but I don't think that's very likely.


Trackback URI | Comments RSS

Leave a Reply

Please abide by the comment policy. Valid HTML includes: <blockquote><p>, <em>, <strong>, <ul>, <ol>, and <a href>. Please use the "Quote Me" functionality to quote comments.