Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!sjsca4!news From: greg@bilbo (Greg Wageman) Newsgroups: comp.sys.atari.st Subject: Re: Designing HIs under GEM Message-ID: <1989Aug18.183951.14376@sj.ate.slb.com> Date: 18 Aug 89 18:39:51 GMT References: <11830048@hpldola.HP.COM> Reply-To: greg@sj.ate.slb.com (Greg Wageman) Organization: Schlumberger ATE, San Jose, CA Lines: 72 In article <11830048@hpldola.HP.COM> jg@hpldola.HP.COM (Joe Gilray) writes: > >I would like to start a discussion about human interface design under GEM. > >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? The "look and feel" (ghod, how I hate that phrase. Sounds like something one does with a prostitute) of a GEM dialogue is pretty much determined by GEM itself. The various GEM objects (radio buttons, TEDINFOs, BOXCHARs, etc.) each have a distinctive appearance and behaviour. I've yet to see a real GEM dialogue where the objects and their operations weren't intuitively obvious. As for hiding object trees and overloading dialogue boxes, I don't personally find this a good idea. More important even than object location is familiarity with a particular dialogue as a whole. I know that I myself get to recognize certain dialogues when they appear, and don't have to stop to thing about what I'm being asked and what I need to do when one appears. Changing a dialogue on-the-fly would lead to a longer learning curve and slower operation for the user, and doesn't make your own code any shorter. Besides, GEM provides the ability to "grey-out" objects and make them unselectable. This is the appropriate way to indicate an invalid selection in a dialogue. This preserves the appearance of the dialogue while disallowing inappropriate selections. >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). I see nothing wrong with nesting dialogues as long as the nesting isn't gratuitous. In other words, don't split a dialogue just to make it appear more "flashy". >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? I can't recall reading about any such restriction, but that doesn't mean one doesn't exist. However, you say nothing about what programming environment you are using. 255 is exactly the largest unsigned integer that can be represented in a byte. You aren't using a language that encodes string length in a leading byte, are you? (No K&R standard C language does this; C strings are arbitrarily long and null-terminated. Perhaps BASIC or Pascal?) Greg Wageman DOMAIN: greg@sj.ate.slb.com Schlumberger Technologies UUCP: {uunet,decwrl,amdahl}!sjsca4!greg 1601 Technology Drive BIX: gwage San Jose, CA 95110-1397 CIS: 74016,352 (408) 437-5198 GEnie: G.WAGEMAN ------------------ Opinions expressed herein are solely the responsibility of the author.