[Usability] Closing instant-apply settings windows

[Gregory Merchan <merchan phys lsu edu>]

There is a certain kind of interface which we want to provide for our users.
This interface is presented by a window containing controls which, when
activated, alter some part of the system outside of the window. No further
interaction, such as pressing an OK button, is required to make the changes.
(What follows is a description of how this has been done, excluding GNOME
and KDE.)

There are at least three ways in which such an interface has been presented.
Mac has had one since at least version 7. OS/2 had one in versions 2 and 3,
and another one in version 4.

 ( Windows, at least Windows98, only has the "Ok, Cancel, Apply"-type of
   settings interface; though some buttons do not require OK or Apply, they
   present other windows such as confirmation alerts. )

The following descriptions are of only the instantly applied settings windows.
Both platforms have windows with OK and Cancel, or nearly the same,
which do not apply changes without further interaction.

The Mac guidelines group the settings interface with others, such as a
Search and Replace window, as "Modeless Dialog Boxes".
 http://developer.apple.com/techpubs/mac/HIGuidelines/HIGuidelines-125.html
(et sequitur)

The guidelines dictate that the window frame close button is the only
button that should dismiss the window.

Generally, the only outstanding button provided for a settings window it a
help button. This is presented as a raised square with an image of a circled 
question mark. Afaik, help was always available from the menubar.

A button to undo changes is not provided because the Undo command is
accessible from the ever-present menubar.

I could find no case of a way to restore "out of the box"-settings.

The CUA guidelines are the basis of the OS/2 interface, and indirectly
and incompletely the Windows and CDE interfaces; these show many vestiges
of an earlier version of CUA which was designed during the transition
from fullscreen console applications to windowed environments.

The CUA may be seen here:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F29AL000/CCONTENTS

In the CUA model, most everything is an object and objects have four listed
views: Contents, Composed, Settings, and Help. Another view is mentioned
else where which is the Icon view. As all of these view just views of one
object, changing the object in one view instantly changes the object in
all other views, assuming the change can be seen in that view.

The Settings View is the one of interest here.

OS/2 versions 2, 3, and 4 provided "settings notebooks" as the standard
settings view. The layout of the notebook version 4 is different from that
in versions 2 and 3.

In 2 and 3, the settings notebook presented tabs on the right-hand side
and some buttons from a standard set on every page. The tab labels were
not rotated as is sometimes seen elsewhere.

In version 4, the tabs of the notebook were across the top side and
uniquely colored. (I find this tacky, but I've heard from those who used
version 4 that they liked it.) The buttons from a standard set were placed
outside of the page which introduced a known notebook usability problem.
It is not apparent in such an interface whether the buttons apply to all pages
or just the one immediately visible; they applied only to the immediately
visible page, unlike in Ok/Cancel dialogs where the buttons apply to all
pages.

Another, less relevant, feature of the notebooks is that they provided
page turning devices in addition to the tabs. In versions 2 and 3 these
were arrow buttons in the bottom right corner of each page and in version
4 it is a square that looks like a turning page with plus and minus signs
placed in the top right corner. Some tabs had pages only accessible by
this extra control which served to hide more advanced options.

OS/2 did not have the ever-present menubar of the Mac, so it was necessary to
present Undo and Help within the settings view. A button to restore default
settings was also provided.

Versions 2 and 3 present the buttons per page on the bottom left side,
but displaced upwards a number of pixels by the page turning arrow
buttons. The order when all three were presented was (from the left) Undo,
Defaults, Help.  (No space was left in the absence of any particular button,
they all shifted over.)

Version 4 presented the same buttons outside of the page graphic centered
at the bottom of the window. The order was the same. (I suspect that
an inapplicable button would be greyed-out rather than hidden, but I
have not confirmed this.)

Because in the CUA model a the settings window is a kind of view, and because
no view contains within it a closing command, the only way to close a settings
window is to use the Close command provided on the window frame.

( I will now assume that the Windows, CDE, Macintosh and OS/2 are the only
widely used platforms. I know there are other comparable platforms, but I
assume because of my unfamiliarity with them and given that I have not
long been a computer afficionado or programmer that they are of sufficiently
little use to be exluded from the what follows. )

Of the widely used platforms only two have provided instant-apply settings
windows. On both of these platforms the only control which would close the
settings window is provided by the window frame.  If we are to take
common practice as a guide, then we should not present a closing button within
an instant-apply window. If we are to follow the principle of usability that 
there should only be one obvious way to perform an action, then we should not
present a closing button within an instant-apply window. If we are to just
look upon the result of doing so and see that the immediate presence of two
controls to perform the exact same action would confuse users at least enough
to cause unnecessary hesitation, then we should not present a closing button 
within an instant-apply window.

Sincerely,
Greg Merchan