apple style guide vs. vi: the modelessness wars



Gleef wrote:
> 
> On Thu, 6 Aug 1998, Bowie Poag wrote:
> 
> >
> >  o The UISG proposes that all applications be non-modal in order to fit
> >    the definition of "GNOME Compliant"
> >
> >    (By "modal", we're referring to apps which have like a "user mode",
> >     or an "edit mode", etc.. Thi smethod of application design has been
> >    generally disliked by users & serious app developers for some time.)
> >
> > Agree or disagree?
> 
> Firstly, using the term modal here, while technically correct, is
> potentially confusing.  thanks to Microsoft (at least i've been told this
> confusion is their fault), modal also has the meaning of taking over the
> focus and all user input.  I would certainly agree that applications
> should be non-modal in this sense, but the incompatable definitions might
> cause unnecessary confusion.

for some clarificatin here, i offer the apple style guide's section on
modelessness:

For the most part, try to create modeless features that allow people to
do
whatever they want when they want to in your application. Avoid using
modes in your application because a mode typically restricts the
operations
that the user can perform while it is in effect. It locks the user into
one
operation and doesn't allow the user to work on anything else until that
operation is completed. In contrast, modelessness allows the user to
perform
more than one operation at a time and thus gives the user more control
over
what he or she can do on the computer and in an application. As much as
possible, you want to preserve the user's ability to be in control of
the task
and the order of operations.

This is not to say that you should never use modes in applications.
Sometimes
using a mode is the best way out of a particular problem. Most
acceptable
modes fall into one of the following categories:

* Long-term modes, such as doing word processing as opposed to graphics
editing. In this sense, each application is a mode.

* Short-term "spring-loaded" modes, in which the user must constantly do
something to maintain the mode. Examples are holding down the mouse
button to scroll text or holding down the Shift key to extend a text
selection.

* Alert modes, in which the user must rectify an unusual situation
before
proceeding. Keep these modes to a minimum.

Other modes are acceptable if they do one of the following:

* They emulate a familiar real-life situation that is itself modal. For
example,
choosing different tools in a graphics application resembles the
real-life
choice of physical drawing tools.

* They change only the attributes of something, not its behavior. The
boldface and underline modes of text entry are examples.

* They block most other normal operation of the system to emphasize
the modality, as in error conditions incurable through the software
(for example, a dialog box that disables all menu items except Close).

If an application uses modes, there must be a clear visual indicator of
the
current mode, and the indicator should be near the object most affected
by the
mode. A good example is the changing pointer in many Macintosh graphics
applications; depending on the function ("mode") the user has selected,
the
pointer looks like a pencil, a paintbrush, a spray can, or an eraser. It
should
also be very easy for users to get into or out of the mode (such as by
clicking a
different palette symbol).

end quotation.

> Secondly, if you require this, it will be impossible to make such things
> as a GNOME-Compliant vi clone.  I would say that this is a bad thing.

i would say that since vi is a very non-intuitive interface, it would be
bad to make exceptions to the style guide to allow for it just on the
basis of nostalgia. let a vi-clone author imitate gnome-compliant
features, but let's not forget that we're not mandating that _all_
applications _must_ be gnome-compliant. obviously special cases like
this need not feel obliged to conform to a set of rules laid down to
prevent user interfaces like vi's from ever happening again. :)
--
"They that can give up essential liberty to obtain a little temporary
safety
deserve neither liberty nor safety." --Benjamin Franklin



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]