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