Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!gatech!ncar!tank!uwvax!umn-d-ub!umn-cs!hall!rosenkra
From: rosenkra@hall.cray.com (Bill Rosenkranz)
Newsgroups: comp.sys.atari.st
Subject: Re: Designing HIs under GEM
Message-ID: <4361@hall.cray.com>
Date: 19 Aug 89 03:59:45 GMT
References: <11830048@hpldola.HP.COM>
Reply-To: rosenkra@hall.UUCP (Bill Rosenkranz)
Organization: Cray Research, Inc., Mendota Heights, MN
Lines: 55

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.

this should be fun :^)


=1) Is there any standard "look and feel" for dialog boxes?  More than
=   just Title at the top, buttons across the bottom?  For example

what u describe is more like an alert box, which are trivial to use. they
are subsets of dialog boxes and good for yes/no type input. i generally
use them only to warn the user of some condition he should be aware of
(do you REALLY want to quit and loose all your data?).

=
=2) I also tend to use nested dialogs quite a bit.  I like to keep the
	
in a word: don't. design your program to have as much information as
possible in one spot, i.e. make it as modeless as possible. if you can
design your program so a user can get from one place to the desired
action in one move, it is far easier to use. in fact, if you can design
your program to have but one evnt_multi loop, it will be very easy
for the user to do what he wants to do, quickly. ST users really
appreciate that. i used to use zillions of alert boxes to tell users
what (i thought) they needed to know. i now opt for an asynchronous
message box in some static location on the screen, always there, which
gives the user info but does not require action (like click or key).

=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 have not heard this and doubt it is true. i can't see how it matters
since the resources are just strings. i have used dialogs with at least
200 objects which to me seemed like a lot, even in a code with over
50000 lines. half of them were FBOXTEXTs. if there is such a limit, it
would be in the form_do code. find tim oren's tutorial series. he has
a form_do source which you can hack if this is in fact the case.
the standard form_do is pretty lame anyway, especially if you do anything
serious (commercial). form_do is ok for run-of-the-mill stuff, but
you'd be better off in the long run rolling your own. besides, you'll
learn more about how things work. i hacked up form-do to do nested
menus (which were just dialogs, one on top of the others).

user interface is religion. just ask apple :^) expect this discussion
to get rather bloody...

=-Joe Gilray


-bill rosenkranz
rosenkra@boston.cray.com