Path: utzoo!utgpu!watmath!att!ucbvax!hplabs!hpfcdc!hpldola!jg
From: jg@hpldola.HP.COM (Joe Gilray)
Newsgroups: comp.sys.atari.st
Subject: Designing HIs under GEM
Message-ID: <11830048@hpldola.HP.COM>
Date: 16 Aug 89 19:10:07 GMT
Organization: HP Elec. Design Div. -ColoSpgs
Lines: 36


I would like to start a discussion about human interface design under GEM.

Lately I've been building some dialog boxes for a GEM application, and
I got to thinking about the following:

1) Is there any standard "look and feel" for dialog boxes?  More than
   just Title at the top, buttons across the bottom?  For example
   I would like a single dialog to handle several different cases, so
   I turn off inappropriate Object sub-trees with the ob_flag HIDETREE
   bit.  Now each Object sub-tree has its own location in the box so
   when I turn some off there are "holes" in the box.  I could place
   different Object sub-trees in the same location (as long as they
   will NEVER be both visible at the same time) but I don't want to
   do this as I feel that the user will find it easier to learn and
   use the box if it is possible to associate a location with a
   function.  What do you think?

2) I also tend to use nested dialogs quite a bit.  I like to keep the
   amount of information on a given dialog limited (this can also be
   helpful in making a dialog multipurpose, i.e. useable in many
   different parts of an application).  Do you think that nested
   dialogs are too hard to use?  I know that they can be harder to
   write as you often have to allow the user to move up and down
   through the levels of dialog hierarchy and may have to offer
   the same function in several different boxes (i.e. Abort,
   finished, etc).

3) One of the reasons I use nested dialogs is a limit I think I've
   found in GEM, it appears that there must be less than 256 editable
   (FTEXT, FBOXTEXT) characters per box in GEM.  Has anyone else
   noticed this (I am using original ROM TOS)?  Is this fixed in
   QuickSt or TurboSt?


-Joe Gilray