Modelessness (Was porting UNIX applications to the mac)

[Robert Reed]

Bill Idsardi writes in article 1897 at utecfa.UUCP
> 
> I don't really know whether modelessness is a myth or not, (though I suspect
> it is a myth).
> 
> For example, the dialog boxes and file selection boxes and pull-down menus
> and click-drag mouse functions are ALL modes.
> 
> The idea is, however, to keep the modes simple and small, so that a user's
> options and how to get at them are obvious.
> 
> So, MacWrite has lots of little modes, and vi has two big modes.

Proving the myth of modelessness by picking at nits seems to be a waste of
time.  Larry Tesler gave a reasonable definition of the "modes" of which
people speak when they talk about modeless programming:

    A useful definition of mode is a state of a user interface that affects
    the interpretation of subsequent inputs without obvious indication.

The operant words here are "WITHOUT OBVIOUS INDICATION."  We can argue all
month about whether holding down the shift key or pushing the mouse button
while looking at a pull-down menu constitutes a mode in the strictest
definition, but all of this would be beside the point.  The idea behind
modeless programming is to eliminate surprises.

If I click-drag an object or pull down a menu, or hold down the shift key,
it is a conscious act for which I am getting direct feedback from the
system.  As a novice user of vi, I was constantly surprised by trying to
enter text, only to find that I was in command mode (with no obvious
indication).  That is the point.

One additional attribute of systems which are objectionably modal is their
way of navigating through the modes.  If holding the shift key is considered
a mode, it is not very objectionable because I can get out of it by just
letting go.  The same goes for pulldown menus.  If I don't like the choices,
I can intuitively avoid them by moving the cursor away before letting go.
Getting out of insert mode in vi, is not quite as easy, but can be easily
acquired through the learned behavior of hitting the ESC key.

The lesson here is NOT that systems should have no global states (i.e.,
modes) but that:

    o  Users should be able to know, without having to query, those states
	of the system that will affect what they are about to do.

    o  If in a state that the user no longer desires, they should be able to
	correctly guess how to get out of it (e.g., letting go of the shift
	key).

Robert Reed, Tektronix CAE Systems Division, bobr at zeus.TEK