• Explore the magic and the mystery!



  • Complicated User Interfaces #2: What About Consistency?

    March 5th, 2005

    It’s bad enough that a computer or consumer electronics product is hard to use. But at least make it consistent! So if you have to go through a convoluted process to perform one task, one hopes that the next task will involve a similar process. If nothing else, it means you might actually learn how to use the thing with a reasonable degree of flexibility.

    Being consistent is also about following the crowd. Take a knob that turns the power on or off on a car radio. For some models, you do it the old fashioned way, by turning the knob clockwise to power up the unit and adjust the volume. On others, you push the knob to toggle it on or off. The latter is a better solution, of course, since you can leave the volume level in just one position, if that’s what you prefer. But, unless you can decipher the tiny label, if there is one, you don’t immediately know which type of knob is being used.

    The hallmark of the Mac OS has been the ability to learn the basics on how things function, and transfer that knowledge to virtually every application you use. That reduces the learning curve big time, once you get past those basics, of course. In order to help ensure a consistent user experience, Apple has developed a set of User Interface Guidelines. There’s no secret about it; you don’t have to sign a nondisclosure agreement or pledge your first-born to Steve Jobs to get a copy. You can just click that link and read the document for yourself, and developers are urged to follow those guidelines as much as possible.

    Now Apple isn’t going to send the brain police to the home or office of a developer and demand they follow those guidelines to the letter. In fact, Apple has been known to ignore them itself from time to time. But you have to agree with the basic goals, one of which is that “Users will learn your application faster if the interface looks and behaves like applications they’re already familiar with.”

    And I can’t ignore this one: “Media reviews of your product will be more positive; reviewers easily target software that doesn’t look or behave the way ‘true’ Macintosh applications do.” Ah, yes, we call it “Mac-like,” and when an application doesn’t have the proper spit and polish, we all gang upon on its publisher. Do you recall the infamous Word 6, for example, with its Windows look and feel? It took years for Microsoft to live one that down.

    In any case, I started thinking about this issue when I read a short article on the subject at author Hadley Stern’s Apple Matters site. Hadley complains that “we have some Apple applications with a metallic look and some without. Why does iPhoto get the metallic look and Mail doesn’t?”

    I think Hadley misses the point, however. It’s not the color of the window that might cause confusion, but on how it works. Consider this description on moving windows in Mac OS X: “The user moves a window by dragging its title bar or, for brushed metal windows, anywhere on the border. As a user drags, the full window and its contents move.”

    In a broad sense, saying you can drag a window by its title bar or borders seems logical. But it means there are two types of windows, and their behavior depends on the presence of borders or lack thereof. In the Classic Mac OS, borders were part and parcel of the design of all movable windows, so you didn’t have to stop and take a look before clicking and dragging. Mac OS X, by giving developers two options, forces you to stop and think for a moment before proceeding, and that’s not a good thing. I suppose the borderless window looks neat from a designer’s standpoint, but it’s not as practical as the brushed metal variety.

    But the problem here is that you either have to stick with the title bars or learn two different window movement behaviors. Why complicate something that’s supposed to be simple? This is a more important issue than which window design a developer selects.

    As you go through Mac OS X’s components, you’ll find more evidence of inconsistent behavior. You normally quit an application by choosing Quit from the File menu or with a Command-Q. Just closing an application window isn’t sufficient. But with System Preferences, Calculator and others, closing the window also exits the application. Yes, I can understand the logic that you do not create documents with these applications, so the additional step may, in theory, not be necessary.

    However this leads to a common beginner’s mistake, where some people believe that all they need to do to shut down a program is to close its window, so they leave applications open without being aware of it, unless they look at the Dock, of course. This was a really big problem in the Classic Mac OS, where running too many apps meant running out of memory, and you didn’t have any visual feedback of what was open without clicking on the Finder’s application menu, a frequently forgotten step.

    And, of course, the process of closing all open windows in an application does indeed exit that application in Microsoft Windows.

    Then again, why should we demand consistency in personal computers when life itself isn’t consistent? Oh well.



    Share
    | Print This Post Print This Post

    Leave Your Comment