Advocacy

  Myths
  Press

Dojo (HowTo)

  General
  Hack
  Hardware
  Interface
  Software

Reference

  Standards
  People
  Forensics

Markets

  Web

Museum

  CodeNames
  Easter Eggs
  History
  Innovation
  Sightings

News

  Opinion

Other

  Martial Arts
  ITIL
  Thought


Windows: Closing a Window
How not to do interface

By:David K. Every
©Copyright 1999


Ease of use is about simplicity. The more complex, the harder it is to use (by definition). That is just basic user interface. Remembering that, lets compare the following:

Macintosh

  1. On the Mac you press the close box
  2. You can use the File menu (close).
     
  3. Or you use the command key shortcut (Command-W) to close, which is the same for every Application.
     

    The Mac has an interface flaw in that the Command-Q (Quit) and Command-W (Close) are too close together. It is easy to accidentally quit. The flaw is minimalized by the fact that quit will ask you before it will quit, if you have changes that you haven't saved, and it is really more a flaw of Quit (rather than of Close), but I want to make a point that the Mac is certainly not flawless.

There are some complexities in dialogs, palettes, and so on, so there is more to close -- but I'm not going into those on either platform. But trust me, the Mac's ways of closing dialogs (with buttons) is far simpler and clearer than Windows, anyway.

 

MS-Windows

Special Window Menu

  1. On Windows you can use the special window menu in the upper left of every window. This menu has its own "close" window menu item.


     
    This is bad interface since:
    • The menu doesn't look like any other menu, or like anything at all. In fact a similar complaint was given for the Apple menu, the Application menu, and the older help ('?') menu on the Mac -- but at least they were in the Menubar, giving people a clue.
    • The control changes from Application to Application to always look like the applications icon. So that means:
      • it's not distinctive (as a menu)
      • it's not consistent (visually)
      • it's not obvious what it is for.
    • This menu is not always there. It is usually there but like everything in windows, you can not count on it.
       
  2. Of course, sometimes there are two of these menu's; one for parent window (the Application Window), one for the zoomed child window (the Document Window).
     


     
    This is bad interface since:
    • This is confusing since users often think, "why two" of the same thing?
    • This behavior adds errors because, if you move up too high while using the menus, the top menu drops down and obscures your bottom menus. This forces the user to release the mouse button, and try to hit their target again.
    • But that error only happens if you are using the menu's by holding the mouse down. If you just click on the menus and move back and forth, it won't automatically drop down the parents window menu, but it will drop down the child's (if the child window is zoomed). Which brings us back to inconsistent. Some menus behave different than others, sometimes.
    • That child window menu isn't always there -- it is only there if the child window is zoomed. That means, "inconsistent" again. Sometimes usually means "bad" in UI terms.
       
  3. You can double-click on either special menu's as a "shortcut" for close -- but the two window menus do different things (one exits the Application, the other closes the File).
     
    This is bad interface since:
    • The locality of position is bad (you don't want two things too close together), since a user could easily do the wrong action. Miss by a couple of pixels and "drat!".
    • Inconsistency: One control closes the document, the other exits the program. Different functions assigned to the same action -- not a good idea.
    • A control should not have both single-click and a double-click action (especially if one is a destructive action like close). This is because users sometimes stutter (double click by accident) or mice buttons sometimes electrically stutter (called bounce). A stutter while trying to bring down this menu (to move, or maximize a window) may just make the whole window or application go away.
       
  4. There is ALT-F4 to close the Application window (parent).
  5. There is CTRL-F4 to close the document window (child).
     
    This is bad interface since:
    • Notice the proximity of the CTRL and ALT keys to each other. So trying to shortcut one, is likely to result in the other. This will increase confusion and accidents.
    • Notice how hard it is to reach either of these commonly used shortcuts using only one hand? It is near impossible (on most keyboards), and to do it, you must remove your hand from resting on the home keys. You might as well just use the mouse.
       
  6. Using ALT-space key is another shortcut to pull up this special window menu for the application window only (parent window), then you can use ALT-C for close (since that is the underlined character).
  7. For the active child window you can use the intuitive ALT-'-' key, then you can use ALT-C for close (since that is the underlined character).

     
    This is bad interface since:
    • ALT-space is not labeled (because the design of using a small icon makes it impossible to label, and using the space key makes it impossible to show that as a shortcut since there is nothing to display). The same for the ALT-'-'.
    • Because this shortcut is not labeled it is inconsistent (with all other menus) and unclear (not obvious).
    • ALT-space is not documented well (not in help) -- most windows users don't know of its existence at all -- proving it is not obvious nor needed.
    • ALT '-' is also not documented well (if at all). Even fewer windows users know of its existence.
    • Of course the shortcut keys for the two types of windows are different (inconsistent ). The user has to know which type of window they are thinking of before they use the shortcut.
    • To make matters worse if ALT means parent and CTRL means child (as is the sequence used for ALT or CTRL-F4), then the shortcut key for the document window menu should be CTRL-space, which it is not. In fact, all the child window menus use CTRL, except for pulling the menu down. So it is inconsistent in that way as well.
    • In general, the use of a common key (like the spacebar), should be used for a common functions, or none at all, since it is too easily pressed. Putting a common key, for an uncommon function (like moving, closing or exiting) is not a good idea.
       
  8. Once you have pulled up the special window menu (by keyboard or mouse), you can often drop the "alt" for the second character in the sequence and just press 'c' to close. So "ALT-space, ALT-c" can also be "ALT-space, c". A tad inconsistent, but this kind of flexibility (or predicting errors) is not bad.
     
    This is bad interface since:
    • While the alternate ways to enter the sequence is not bad (and may be good), the double sequence itself is bad since it requires multiple steps to be what can be achieved in one.
    • CTRL is an annoying modifier key, since it is placed where you can't reach it easily. On the Mac the command key is easily reachable with either thumb (leaving your primary fingers on home). On Windows you must remove a hand from home, or do digital gymnastics with your little finger to reach CTRL. The Windows key is inconsistant (on some keyboards and not others), and I've seen the ALT key placed on either side of the Windows keys. Again, on Wintel boxes nothing is predictable.
  9. If you have pulled up this special window menu, you can also use the arrow keys to move the selection down until you get over the "close" in only 5 more steps, then press return (for 6 steps).
  10. If you have pulled up this special window menu, you can also use the arrow keys to move the selection up, which causes the selection to wrap to the bottom, this way you get over the "close" in only 2 or 3 steps total.

     
    This is bad interface since:
    • And you thought double key sequences were bad?! Way too many steps. They did this as a way to allow the user to manipulate the menu's from the keyboard -- but the problem is that some will use this bad method, and decrease their productivity. This trains the user on how to use the machine improperly! This would be like allowing the seats in your car to pivot so that it can face each other while driving -- making it easier to hold a face-to-face conversation. Not a good feature.
    • Going the other way works a little better, but is the opposite of intuitive. When people see a menu that is down, they don't think of moving up (and wrapping).
    • To complicate things, the parent and child windows have a different amount of menu items (there is a 'next window' menu item in the child windows), so you can never have a predictable amount of steps. So a user can't memorize a sequence because it changes.

File Menu

  1. There is a File Menu which also has it's own close (but that only works for the active child window).
  2. If you want to exit (and close the parent window) then there is a different menu item, named differently.
     
    This is bad interface since:
    • Since the file is a window, and the application is a window, it is confusing (inconsistent) that to close one you say close, and to close the other you say exit, sometimes, and close others. It gets weirder since the focus (the active window) is not only the Application window (parent) but also one of the document windows (child). This means the user must be real cautious about what they think the current focus is -- it is not just A window, sometimes it is a window in a window (or two windows).
       
  3. There is the File menu shortcut of CTRL-W to close the active document window (child). But it is often a different shortcut key. (I've seen all sorts or different keys used for close, and sometimes none).
  4. Of course there is usually not a direct shortcut key for exit, notice the, "usually."
     
    This is bad interface since:
    • Obviously it is bad because it is inconsistent key choices. Even Microsoft apps aren't always one or the other. You get to guess, and learn different shortcuts for each application.
    • Also notice that closing one window (child / document) has a shortcut, closing another (parent / application) does not have a shortcut. So it is inconsistent on whether it will have that method of shortcut.
       
  5. There is usually the ALT-F (for file menu) and ALT-C (for close) method, if you use that semi-standard convention. (Similar, but different than the ALT-space, ALT-C of before).
  6. And don't forget the ALT-F (for file menu) and ALT-X (for exit) method, if you want to exit (close the parent / application window).
     
    This is bad interface since:
    • Duplicate behavior. The more choices a user has, the more confused about those choices they are. It is always a balancing act in User Interface to offer enough choices and features to be useful, and not so many that it is bloated, confusing, or overwhelming. MS windows is way unbalanced.
    • Notice that ALT-C and ALT-X are very similar to CTRL-C and CTRL-X (copy and cut). There is something called muscle memory, where the reflexes try to repeat commonly done actions. So in interface you want to avoid using duplicates (like this) as much as possible. Otherwise it breaks peoples rhythm or causes accidents.
    • Notice the intuitive use of ALT-X for exit instead of ALT-E? I don't know why, they "standard" is supposed to be to use the first letter as the shortcut (if possible, and it was possible). I think this was a Microsoft attempt to avoid using a letter that would be used for anything else, except the 'X' is one of the most common keyboard shortcuts, the "cut".
       
  7. Once again, you can drop the 'alt' for the second character.
  8. Also, once again, you can use the arrow keys to move the selection down until you get over the close, and press return, in only 5 or 6 steps. Or more steps if you want to hit the "exit".
     
    This is bad interface since:
    • Again, redundant ways of doing the same thing, with most of the choices being bad training or behaviors. Imagine a new user watches 4 "power" users all use the system differently. Or try to train themselves and have all these bad choices. It is like wanted to get from point A to point B and always having to traverse a maze with lots of dead-ends, or winding paths that may eventually get you where you are going, if you hack at it long enough.

Close/Kill control

  1. On Windows there is a close/kill control at the upper right of every Window.


     
    This is bad interface since:
    • The close in the right menu works with a single-click of the mouse, the close/kill on the left side of the window requires a double-click, can you say "inconsistent?"
    • Notice how conveniently close the close/kill is to zoom control? This is so that when you go to zoom (and miss) the application window will go away and force you to reopen the application (a time consuming process).
    • Windows also use the corners and edges to resize the window. The close kill is very close to that, causing other accidents.
    • Because of all the potential for error, this forces users to move much slower when doing things to avoid surprises. Ask windows users about this, and they admit that they move slower and more carefully to avoid this problem. Think of the productivity wasted. Apple wisely places close and zoom on opposite sides of the window to avoid such errors.
    • Remember, unneeded redundancy is bad. There is a close on the left side of a window, why one on the right side as well?
       
  2. Of course sometimes there are two sets of "close/kill" buttons, one for the Application (parent) and one for the document (child).


     
    This is bad interface since:
    • Not only is the close of the child window close to zoom controls, but now it is also close to the application close (kill). So when you try to close the document, or unzoom it, you often kill the whole application. And likewise, when you go to unzoom the App Window, you often miss, and close the document, or only unzoom the child window instead. Think of all the possibilities for error. This is evil and incompetent placement, and is the FIRST thing you learn to avoid (in User Interface).
    • But note: this second close/kill is not always there, it is only sometimes there. This means that users are either surprised when it is there, or surprised when it isn't. (The brain expects patterns and consistency -- not lots of conditionals).

Other "shortcuts"

  1. Using the right mouse button you can click in the taskbar (for an application) and "close" the Application Window (Parent).
       
  2. The right mouse button, while clicking in the content of some windows, may bring up a menu that has a close menu, it may not. Usually if you do that on the title bar of Application window, it does bring up that close menu, which has all the options and ways for closing as before (arrows and return, 3 different other key sequences, and so on). I'm being generous by not counting them individually.
     
    This is bad interface since:
    • This behavior does not work for child-windows, only parent windows. Inconsistent!
    • Notice the strategic change from "exit" the parent (in the file menu), to "close" the parent (used almost everywhere else)? Terms are inconsistent. Imagine a new user asking, what is the difference between closing the application and exiting it.
    • Just for fun, holding the right mouse button down does not work a menu the same way it does when holding the left-mouse button down. To work the right mouse button menu's, you must release the button before the contextual menu will appear. Which is inconsistent with all other menus.
       
  3. To kill the application, you can use CTRL-ALT-DELETE. This will close the application, but of course it is called end task.
     
    This whole interface is bad since:
    • You must also remember that parent-child only exists sometimes. Then you have whole exceptions to the rules like Explorer (File Explorer, not Internet Explorer), which doesn't have a parent window or a Menubar like every other application. Exceptions on top of exceptions -- this is the opposite of consistency.
    • Like everything in Windows there are rules, and then the exceptions. Nothing seems to be a rule. This is bad interface.

These are only the ways of closing a Window that I know of. I'm sure that there are more. So the score is 3 (Mac) to more than 20 (Windows), with the lowest score usually being best.

Of course, the Mac can do various forms of quit (which will close its windows too) but the behavior is distinctive since it is not ever called close. Windows refers to "closing" an application (parent Window), so I treat it accordingly.

When talking to many windows users about closing windows (or other functionality) they will admit that they adapt by only using the easiest few ways to close windows (and that they don't know most of the ways to close windows. Meaning most ways are unneeded or bad). Or Windows users adapt by moving slower to avoid mistakes (like around the upper right close, zoom or shrink boxes). But that is still a way for them to adjust to a bad interface.

The problem is that most people accept the idiocy of interface, and loss of productivity, without blaming Microsoft. They adapt to what is bad! And humans are amazingly good at adaptation, which is why windows doesn't seem as bad an interface as it really is. But we need to stop adapting to it -- and start demanding that IT adapt to us (and that bad interface should be fixed).

Conclusion

Some people naively think more is better. You aren't forced to use those other ways. In interface this is almost never the case -- one good way is better than 12 bad ones. Remember that most ways to close windows are fairly complex, with multiple steps, so people don't use them. (They are less than worthless). If people do use those ways, then they reduce their productivity. (Still no value added). Many of these ways just increase the likelihood of errors -- meaning they reduce productivity for people that don't use them (intentionally). And throughout all these methods there is an increase in complexity and a lack of consistency (both in how they work, and whether they will be implemented by an individual application or not).

Imagine you are a new user, and you ask four different people to explain how to close a window. Do you mean a parent window, or a child window? What if there is no child window? Do I close an application or exit? What are the chances that any two users will give you the same answer? Not likely. Imagine you are unsure of yourself, all those choices are confusing and overwhelming. Bad interface.

 

Of course a bad "window close" interface is only one example (among many) of how Microsoft just does not have a clue about User Interface, or else they don't care. There are as many rules, exceptions, and special conditions for almost every function of all Microsoft's products.

For fun count how many ways there are to resize a window in MS-Windows, I gave up after the count went over 30. Most of these ways just increase the likelihood of errors (and loss of productivity).

If you care about interface, whenever you make a mistake, look to see if it is your fault, or if the control/action was poorly defined and it was really the designers failure. Microsoft users don't seem to understand that most basic concept; that the computer should adapt to THEM, and not make them adapt to it. But that is the whole point of a good user interface.

The point of this (and all articles in the Interface section) is not to imply that the Mac is perfect. It is not. There are many little consistency problems, or interface "bugs", and ways to improve behaviors on all machines (including Mac). But there are differences in degrees of usability as well. And for every one Macintosh flaw (or every 2 or 3 NeXT or BeOS or Acorn interface flaws), there are usually 50 Windows flaws. These problems with quality are what polarize the rest of the world against Microsoft and Windows.


Created: 04/21/97
Updated: 11/09/02


Top of page

Top of Section

Home