The Macintosh Way

A few moons ago I noticed that my application (at work) had a certain behavior: if the focus was in a widget that supported cut-copy-paste, the cut-copy-paste menu items and tool bar buttons were enabled regardless of whether anything was selected or the clipboard contained anything.

I added to my to-do list an item for correcting the enabling and disabling of those menu items and buttons. To me, cut and copy should only be enabled if the selection is not empty and the widget with focus supports cutting or copying; paste should only be enabled if the clipboard is not empty and the widget supports pasting. A coworker favors leaving the items and buttons enabled but doing nothing in the absence of selection, clipboard contents, etc.

That coworker is a long-time Windows developer and I am a Mac zealot. I find these affiliations not entirely coincidental. On the Mac, cut, copy, and paste are only enabled when they will actually do something; under Windows, they are enabled whenever the developer feels like, sometimes when they won’t do anything at all. Those behaviors are representative of their respective communities’ approaches to the user interface: Mac applications do whatever is easiest for the user and Windows applications do whatever is easiest for the developer.

It takes a lot of complexity to make cut, copy, and paste work correctly. In my case I needed focus and selection notifications and strategies around when and which buttons to enable. (Luckily the Cocoa framework automates a lot of things.) It certainly would have been easier to leave the controls enabled and let the user figure out if they did anything.

The benefit of the increased usability outweighs the cost of the extra work and complexity. Whilst there are examples of Mac applications that do the wrong thing and Windows applications that do the right thing, on the whole the Mac development community makes more usable applications. It’s like the difference between a four-by-eight sheet of D-grade plywood and a sanded, polished piece of mahogany: both will hold up your coffee mug but one is a whole lot nicer to use.

Which is why I spent the day fixing the cut-copy-paste controls. I’ll do the work now so the users won’t get any splinters.

Advertisements

4 Responses

  1. I agree with you that the buttons should be disabled if you cannot use them and enabled only when you can, in a context-appropriate way.

    Some people go a little too far and hide buttons that you cannot use, arguing that if the button is present but disabled, you then must provide some obvious means for the user to learn why the button is disabled, whereas if it is not present at all there can be no confusion about whether you can use it. In my experience, and I think usability studies back this up, it is more confusing to have things appear and disappear than it is to have them enabled/disabled depending on the state of things. It is critical, though, that there be some clear indication of why the button is disabled and what the user would need to do in order to be able to use it (and tool tips are not the best way to do that).

  2. We also had the discussion about whether to hide disabled menus, menu items, tool bars, etc. What we decided (which I think works quite well) is that menus and menu items never get hidden, just disabled. (Well, except for the super-secret developer menu which is hidden until given the secret handshake.) Tool bars can get hidden and shown but that’s just until we add fine-grained support for the user picking which tool bars they want to see. All other controls are present but disabled if they can’t be used.

    Yes, tool tips are over-used as a mechanism for explaining to the user what’s happening. I love tool tips for some very specific cases but in other regards which apps (including my own) would use the damn things less. One of the things we really need to address better is showing the user the flow through the app to do certain tasks. It’s way beyond our widget toolkit but I wonder if some subtle luminosity tweaks might make it more apparent which controls are related to which.

  3. Is luminosity what you get when you hover over something and the lighting changes slightly? That’s a nice effect and it is handy for showing when you are over a clickable element.

    I think the only valid use for tooltips is when they are purely additional in nature, meaning they don’t covey anything that is critical to the use of the object over which they appear (which makes them just about useless). For example, general information about a control is something I would call purely additional, whereas specific details about the current state of the app is something I would call critical.

    One of the new features of Microsoft Office in Office 2007 is the “ribbon” concept, which I don’t like, for the same reason: the actions you can take change depending on the context you are in. I never liked the “personalized” menus, which were dropdowns that would show only your most-used commands, for the same reason. I would rather have the entire picture and customize my own menu environment than have the application hide choices from me unless I happen to find them some other way.

    By the way, I like the coarse vs. polished wood analogy you used. The storytelling method of using an example/analogy and then referring back to it at the end of the story really ties things together (comedians do that a lot, as do a lot of other bloggers). You gave it a cool, subtle twist by talking about splinters (and I also noticed (maybe it was intentional) that you referred to “fine-grained” support in your comment; nice reference there too).

  4. From Daring Fireball’s review of Leopard: the way that when you rename files in the Finder now, you get a default text selection of just the name part, without the file extension

    This is a good example of polishing. Now that Gruber mentioned it, it is annoying that the whole file name including the extension is selected in Tiger and previous. That’s the kind of simple but powerful usability improvement to which I aspire in my own UIs.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: