Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!husc6!necntc!ames!ptsfa!ihnp4!inuxc!pur-ee!j.cc.purdue.edu!mit-prep!tmb
From: tmb@mit-prep.UUCP
Newsgroups: comp.sys.amiga
Subject: problems with the amiga user interface...
Message-ID: <50@mit-prep.ARPA>
Date: Mon, 9-Mar-87 07:36:16 EST
Article-I.D.: mit-prep.50
Posted: Mon Mar  9 07:36:16 1987
Date-Received: Wed, 11-Mar-87 20:41:31 EST
Organization: The MIT AI Lab, Cambridge, MA
Lines: 118

Below, you will find a sundry collection of things that bother me about
the Amiga user interface, the windowing system, &c., from a user's
point of view. I hope that if people on the net make sufficiently
loud complaints, Commodore may fix some of these problems in later
releases of the operating system. Many of these problems could be
solved by compatible (application transparent) changes. I also hope
that developers will start to think more about these user interface
issues. While lots of entertaining and graphically interesting things
can be done on the Amiga, a clear and clean interface for an application
is still much more important than an interface with lots of (graphical)
bells and whistles. 

Some of the problems with the Amiga user interface seem to me to be the
result of trying to avoid being too similar to the MacIntosh.  However,
much of the Mac's user interface was around before, in the Xerox Star,
and in particular the Smalltalk-80 system (e.g. the concept of
selection followed by an operation) and can therefore hardly be
considered proprietary or copyright by Apple. Others seem to be a
result of lack of standardisation. Commodore should, in my opinion,
push their developers harder in this area. Some of the deficiencies may
be due to time constraints during the development phase. Finally, some
of the points above may not even be considered shortcomings by
everybody. Your comments are invited. I believe, though, that the
graphical Amiga user interface has to improve considerably if the Amiga
wants to survive in the marketplace.

--------------------

-- window activation and window re-arranging are not coupled in a useful
   way: usually, when I activate a window, I want to use it, and it should
   come to the front. Usually, if I send a window to the back, I don't
   want to use it, and it should not become active. The same is true
   for the selection of new screens using either the mouse or the keyboard
   (the keyboard equivalents for selecting a new screen are particularly
   useless since you always have to use the mouse anyway to activate
   a window in the new screen). Therefore:
   -- clicking the back (or front) gadget should not activate a window
   -- clicking a window and activating it should move it to the front
   -- an expand/shrink gadget would be nice
   -- selecting a new screen should activate the front window in that
      screen (this is esp. true for the keyboard equivalents)

-- the keyboard equivalents for selecting screens should go through a
   circular list rather than just bringing the last screen to the front

-- there should be keyboard equivalents for cycling through the windows
   of a screen

-- there should be standard keyboard equivalents for 'accept' and
   'cancel' gadgets in requesters

-- intuition (and the workbench) is unbelievably slow. A machine with a
   blitter should be able to do better than this. 
   The fundamental problem may be the way Intuition has 
   to compute internally which part of a window require
   refreshing, but this is just my guess. The representation of icons
   and file names is probably another reason. What about an alternative
   scheme in which each directory contains an info file that holds all the
   icons and file names for this directory (comparing dates on this file
   and the directory would show when it needs updating).

-- string gadgets in requesters should become activated automatically,
   and a standard keyboard equivalent should be provided to cycle through
   them

-- the paradigm of selecting a tool and then performing an action with
   it (e.g. selecting scissors and then cutting) is very impractical.
   The Smalltalk-80 and MacIntosh approach of making a selection
   followed by an operation on the selection is much more efficient.

-- the standard font should be small enough to allow for 80 characters in
   a workbench window. Alternatively, the standard screen should be a
   little bit wider. 80 characters is unfortunately a magic number that
   everybody assumes when writing text, and having fewer than 80 characters
   on a line means that TYPE'ing a file, running a terminal emulator, &c.
   in a workbench window will often result in lines that wrap around for
   just one or two characters.

-- the collection of fonts provided with the system is poor. At least one
   of each a no-frills sans-serif and serif font should be provided in
   a large range of point sizes (8-36).

-- the printer drivers often do not support high-resolution graphics printing
   even if it is available. The Imagewriter II, for example, can print
   at twice the resolution provided by the driver to give near letter
   quality printing even in graphics mode.

-- it is nice for programs to use colour to enhance the user interface.
   Unfortunately, many applications sacrifice quality and usability for
   it. Using more bitplanes for graphics costs lots of memory. And, for
   some reason, applications that rely heavily on colour for on-screen
   presentation seem to generate extremely poor b&w printouts, like DMCS.
   (This is not a technical, but a design problem).

-- trying to control the aspect ration in a low-density dot-matrix printout
   is a loosing proposition.  The resulting pictures plainly look bad.
   If one could print at higher resolution, this problem might go away.
   So far, I would suggest that every application should at least give
   the option:  1 screen pixel <=> 1 printer dot. People tend to learn
   rather quickly to ignore distortions on the screen, but asymmetries,
   discontinuities, and non-uniformities resulting from re-sampling a
   bitmap make printouts look extremely crummy.

-- the console driver still does not deal correctly with backspacing
   and line cancelling if the line contains control characters

-- starting two jobs under the CLI, like 'run foo<cr>run bar<cr>'
   results in massive disk thrashing. I can imaging why this might
   be difficult to fix cleanly, but some hack would definitely be
   appreciated.

-- pop-up menus (perhaps optional, selectable via preferences) would
   be nice, in particular for larger screen sizes. Otherwise, why bother
   with a two-buttoned mouse anyhow?

-- resource tracking should be added to the operating system so that
   processes can be killed. Jobs that don't need would not have to use
   it, but it ought be be available.