Frozen Fish 2: PC/frozenfish_august_1995.bin/bbs/d09xx/d0911.lha/GadLayout/Style_Guide

Text File | 1993-10-03 | 19KB | 366 lines

                       Judging a Book by its Cover:
                            A Synopsis of the
                    "Amiga User Interface Style Guide"

                          Copyright (c) 1993 by
                             Timothy J. Aston
                           All Rights Reserved

                           Editor: Mark Rickan


* Introduction:

If you've ever used such graphic operating systems as the Macintosh,
Windows on a PC-clone, or a NeXT, you've likely come to appreciate the
consistency in the way their applications both appear and operate. Through
the enforcement of strict interface guidelines and the increasing
competition among vendors, developers have become particularly concerned
with how their software conveys a sense of professionalism and attention
to detail. The important factor here is "consistency" in the look and
functionality of different applications running under the same operating
system.  Apple, Microsoft, NeXT and others created a set of guidelines to
ensure that developers would provide applications that would look and act
alike on their particular systems. Functions common to most applications,
such as selecting a file, would then be performed in an identical fashion
in all applications.

In the formative years of the Amiga, many applications could be described
as in a state of chaos when it came to user interface design.  With no
real established standards and a limited set of resources for product
development, many programmers inevitably developed software on the basis
of their own impressions of how a software package should look and feel.
Anyone that has either owned or used an Amiga since the days of Release
1.3 of the operating system won't need to be reminded that Release 2 was a
major revolution to the Amiga as a whole.  This revision of the operating
system and its graphic user interface (+) -- or GUI, pronounced "gooey" --
forever changed the way users would interact with the the Amiga.  With an
impressive new 3-dimensional look, 2.0 heralded the beginning of a new
era.

Today, programmers have can access a variety of functions in the operating
system to create attractive and powerful user interfaces for their
software.  In addition, Commodore has provided a set of guidelines for
software development which are embodied in the "Amiga User Interface Style
Guide".  This book brought to the Amiga an element which had traditionally
been absent: user interface standards. The text covers a broad spectrum of
user interface issues such as pull-down menu layout, requester design,
ARexx command interfaces and keyboard equivalents.  Developers now have
official guidelines they need to ensure  that their applications will be
consistent, powerful and easy to use.

(+) Although the term coined by MicroSoft is in fact "graphical user
    interface", I have used the word "graphic" instead, as there is no
    such word in the English language as "graphical".


 * The Problem:

Sadly, this major advancement for the Amiga has turned into somewhat of
a disappointment.  What could have led to a major step forward in
the overall quality of Amiga software has not yet been realized to its
full potential.  Though the Style Guide has been available for almost two
years now, there have been almost no commercial, and only a few shareware
or public domain software packages that follow its guidelines.

Why is this so?  If the comments in the introduction are indeed true, why
haven't the guidelines laid out in the Style Guide been heartily embraced
by developers?  The reason appears to be two-fold:

1) Lack of knowledge:

A large number of people, particularly users, are not aware of the
Style Guide, nor have they come to appreciate how important standards are.

2) Insistence on creative freedom:

Among many developers, there is a tendency to create software which looks
and acts according to personal preferences. This is also coupled with
concerns to continue supporting the now obsolete Release 1.3 revision
of the Amiga's OS. Because the Style Guide assumes Release 2, it is
difficult to write Style Guide compliant software that still runs on
older versions of the OS.

One of the goals of this document is to help address the first reason.
By learning that standards exist, it is hoped that users will increasingly
appreciate the need for programs that follow these standards.  In the
following section, a brief overview of some of these standards will be
provided to give users some idea of what constitutes a standard interface.


 * The Guidelines:

Some people seem to be of the opinion that as long as their programmes
conform to the 3-D look of Release 2, that their software may be
considered as having a "standard user interface".  This could not be
farther from the truth.  The Style Guide contains a very extensive list of
guidelines, all of which should be followed as closely as possible in
order to earn the distinction of being style-guide compliant.

I will now take some time to provide a brief synopsis of some of these
guidelines.  This overview will give users a basic understanding of how an
Amiga application should act.  It may also be helpful as an introduction
for developers.  Please keep in mind however, that it is essential to
obtain a copy of the Style Guide before you release any software in order
to make certain that you are fully compliant.

  - The Basename:

    Every program should have a basename.  This is a simple string that
    identifies the program.  For the most part, this can simply be the
    name of your programmes binary.  If the program has a fairly long
    name, it should be abbreviated to something more manageable.  But be
    careful, if you abbreviate too much, your basename will become
    ambiguous and fail to properly identify your program.

  - Pull-Down Menus:

    Most applications share a set of basic functions.  For example, just
    about every program has to allow the user to load and save a file.
    Most programmes also need to let users change program options.
    Other common functions include items such as support for the clipboard
    and macros and other features. These functions should be laid out in the
    pull-down menus in a very specific manner, using specific names.
    Additionally, pull-down menus should use the same font as the screen
    they are on, and should be drawn in the pen colours given to you by the
    OS. (This is accomplished by using functions in the GadTools library).

    Briefly, here is how the Style Guide states the menus should appear.
    Of course, not all programmes will implement all of these items, since
    they are not appropriate for all applications.

   Project            Edit        Macros              Settings
     New         N      Cut   X     Start Learning    / Option
     Open...     O      Copy  C     Stop Learning     / Option
   <bar>                Paste V     Assign Macro...   / Create Icons?
     Save        S    <bar>         Load...           <bar>
     Save As...  A      Erase Z     Save..              Option...
   <bar>              <bar>                             Option           >>
     Print              Undo                          <bar>
     Print As..         Redo                            Load Settings...
   <bar>                                                Save Settings
     Hide                                               Save Settings As...
     Reveal...
     Close
   <bar>
     About...
   <bar>
     Exit Level
   <bar>
     Quit Program... Q

    A few notes on the above: First, the capital letters following some
    items denote Amiga key equivalents, the "/" refers to an item that may
    be "checked", ">>" means that the item brings up a submenu, and <bar>
    represents the standard bar separator item.

    Stylistic points you should note include the use of the elliptics
    ("...") for items that will bring up some kind of requester in response
    to their selection.  In the "Settings", note how toggle items come first,
    followed by items that bring up a requester, followed by items that
    bring up sub-menus. Note also the placement of the bars.  This menu should
    be the last menu unless you have implemented the "User" menu described
    following.

    A menu called "User" may be provided for user defined macros.  This
    menu will be variable length and could hold anything the user wishes
    to configure for it.  This should be the last menu, pushing the
    "Settings" to the second to last position.

  - Preferences Files:

    As mentioned above, any program that allows users to adjust its
    settings in any way should have a "Settings" menu from which users can
    do this.  For the most part, you will also want to be able to load and
    save these settings.  If a program has only a very small amount of
    things that it has to save as a part of the settings (eg. half a dozen
    or less variables), then a convenient way is to save them as "tool
    types" in the program's icon file (the .info file).  In most cases,
    you'll have a fair number of settings options, thus you'll need to keep
    them in a seperate file.  The way you decide which file to use is by
    following these steps according to sequence:

      1. Check  for a user supplied settings filename, via either the
         SETTINGS workbench tool type or command line keyword.
      2. Look in the current directory for a file called <basename>.prefs.
      3. Look in the directory in which the program resides in
         (programmers: use the special AmigaDOS assignment PROGDIR: to
         facilitate this) for <basename>.prefs.
      4: Look in ENV:<basename>/<basename>.prefs.

    The Style Guide suggests using the IFF format for your settings files.

  - Keyboard controls:

    It is important for software to have facilities for effective keyboard
    and mouse control.  Try to make it so that you can do as much as
    possible with both the keyboard and the mouse, but don't go to extremes
    simply for the purpose of providing complete keyboard control.

    For example, if you try to give every gadget in a requester a keyboard
    equivalent, you'll probably end up having keys that have little
    relation the gadget text.

    Keyboard equivalents in menus are simple to implement, as the OS does
    just about all the work for you.  Just remember to follow the equivalents
    suggested by the Style Guide.  Gadgets require a little more work in order
    to give them keyboard equivalents.  The operating system will handle the
    placement of an underscore under the character that will serve as an
    equivalent to gadget selection. But remember, you have to check for the
    keypresses yourself.  These keypresses should be accepted unqualified,
    accept in the case of cycle and listview gadgets, where the unqualified
    key should give you the next item in the gadget and a shifted entry
    selects the previous item.

    The cursor keys should be used to move around within your project.
    Unqualified, they should move you up, down, left or right one "unit"
    (eg. a character in a word processor).  <shift> plus a cursor key
    should move you to the appropriate extreme within the current view of
    the window, and if already there, move you along the size of the view.
    <control> plus a cursor should move you to the appropriate extreme of
    the project.  <alt> along with a cursor is not defined, its usage is
    left up to the application.

  - ARexx:

    As with menus, we see a lot of programs that have ARexx commands on
    different applications that are similar in function, but have different
    names.  The Style Guide attempts to remedy this somewhat by providing
    a set of standard commands.  Naturally, the scope of commands an
    application might support will go far beyond what can be detailed in
    any document, but a program should support as many of the Style Guide
    commands as possible.

    The ARexx port name of an application has a naming convention:
    <basename>.<instance> where <instance> is the execution instance of
    the program in case it has been run multiple times at once by the
    user. It can also be a project number in the event that the program lets
    you work on several projects at once.

    Even simple program should try to support as many ARexx commands
    as possible, even if this amounts to as few as half a dozen commands.


 * The Style Guide in Practice:

Naturally, it is going to be difficult for programmers to have their
applications follow the Style Guide word for word.  Some things will have
to be left out if not supported by the application, and when it comes to
adding things not discussed in the Style Guide, you're on your own.
There are also going to be cases where the Style Guide specifications
simply will not make provisions for enough power, and functions will have
to be implemented differently.

All you have to do is be a little mindful when implementing the Style
Guide.  Try to follow it as closely as you can.  When it comes to adding
things that are beyond what is in the Style Guide, look at what else is
out there to see if there are some common practises.  A fine example of
this is the folder gadget for bringing up a file requester to select a
directory.  This was something we originally saw in Commodore's Fountain,
and has since appeared in other software such as ToolManager and Term
It is not something that is talked about in the Style Guide, but it
is a common practise, and from the point of view of the user, that's
almost the same thing as a standard.

There are also a few cases where your opinion may differ from the official
guidelines.  One example is with cursor movements.  The Style Guide says
that <control> + <up cursor> or <down cursor> should move you to the upper
or lower extreme respectively.  What we see most commonly however is <alt>
being used instead of <control>.  I find the best idea is to use both,
since the function for <alt> can be program specific.

There also appears to be at least one case where you can make a very
substantial argument against a Style Guide suggestion.  This one case
that I am familiar with is with the SELECT ARexx command.  This seems to be
a poor choice in name, since SELECT is a built-in ARexx command, and to
actually send this command to an application via ARexx requires extra care.
My suggestion is to implement this command, but to also add a command called
REVEAL as a synonym.

I would also like to point out that the Style Guide really only sets up
guidelines for a MINIMAL user interface.  You should comply with its
guidelines, but to have an interface that goes beyond merely adequate,
you'll have to do more.  The few Style Guide compliant GUIs I have seen
have been quite dull indeed.

Don't be afraid to use images in your gadgets or anywhere in your
program (but please note, if your program runs on the Workbench screen
or any place that the user can adjust the pens for, you'll have to be
prepared to remap your images to match the user's pen selection).  With
gadgets you have far more than GadTools to work with; you also have
BOOPSI, which is a tremendously powerful addition to Intuition and an
integral part of Release 2.

On the other hand, don't go overboard.  It's okay to be creative with your
GUI, just keep good taste and the standards in mind while you do so.
You may think you have an idea for a GUI that would be really attractive,
but before you go ahead and implement it, ask yourself if its really
consistent with other Amiga GUIs that you could consider to be exemplary.


  * Pet Peeves:

These are some things I have noticed in a lot of Amiga software that I
personally find really annoying, and would love to see an end to all of
them:

 - Programs that save their data files in the S: directory.  "S" stands
   for "script", this directory is mainly used for AmigaDOS script files,
   leave it alone.  The Style Guide defines very clearly where data files
   should be placed.  At the very least, please use PROGDIR:.
 - Programs that ASSUME you are using an 8x8 font.  Properly written
   software should adjust to the user's screen font setting (which may
   not be proportional). If you're not prepared to do this, the least
   you can do is make certain that you have an 8x8 font, and ask for it
   if you don't.
 - It's very annoying when you can't choose the screen mode an
   application runs in.  By default, programmes should open in the same
   mode as the Workbench screen, while allowing you to change into any of
   the Amiga's allowed screen modes (check the display database for this).
 - Please try to get as many defaults as you can from a user's preferences
   settings.  The screen mode example above is just one.  Instead of
   defaulting to Topaz 8, default to the user's screen font selection.
   The system preferences are there for you to make use of, so do so.
 - Don't make use of non-standard requesters such as those provided by
   the ReqTools library.  User's can patch their system to use these if
   they want to, but your application should always be coded to use the
   standard system requesters.
 - Stay away from forcing users to make special "assigns".  With Release 2
   there is little need for this since it is a trivial matter to find out
   what directory your program resides in (use the special DOS
   assignment PROGDIR:).


 * About the Author:

I am student studying computing and information science at the University
of Guelph in Ontario Canada.  I have owned an Amiga since 1988.  My first
major programming project on the Amiga was TransAmiga BBS, which I continue
to develop.  More recently, I have written a system for programmers called
GadLayout that greatly simplifies the task of making gadgets adjust
dynamically to user font and language preferences (VERY important in being
Style Guide compliant).  My main focus over the last 6 months has been in
writing a text editor which I hope will serve as an example of what a
style-guide compliant user interface should look like.

As you will have probably already gathered, user interface issues are my
main interest in computing.  I am available for any consulting or design
work if you need help with the GUI in software you are developing.

If you wish to get in touch with me, any of the following are methods
are at your disposable, and are listed in order of preference:

  InterNet E-Mail: [e-mail]
  FidoNet Netmail: 1:247/192.0
              IRC: Timmer @ #amiga
              FAX: [phone]
     Regular Mail: 128 Riverview Blvd.
                   St. Catharines, Ont.
                   L2T 3M2
                   CANADA

If you want suggestions, critisisms or insults about a GUI, feel free to
contact me.  I'm eager to help if it means that we'll get better looking,
more functional and more standard GUIs out there in the Amiga community.