jg@hpldola.HP.COM (Joe Gilray) (08/17/89)
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
jg@hpldola.HP.COM (Joe Gilray) (08/19/89)
First, thanks to those of you who have responded to my base note so far.
I look forward to some more interesting discussion.
Second, more in the HIs (or do you say GUIs) saga:
I wanted to create an FTEXT object which could be used two different
ways. What I mean is that it could prompt the user for one field or
another. For example, it might say
Enter Category: ___
at one point or
Name: ___
at another.
Note that the number of underscores in both cases is the same,
although in general I don't think they should have to be.
I tried to accomplish this in two ways (both really the same in essence):
Method One: copy directly into the Object tree before displaying the tree
obspec = (TEDINFO *) (tree + THING)->ob_spec;
strcpy(obspec->te_ptext, "@@@");
strcpy(obspec->te_ptmplt, "Name: ___");
Method Two: (credit to Tim Oren and his PROGEM series) copy into a local
variable and then set Object to point to local variable
obspec = (TEDINFO *) (tree + THING)->ob_spec;
strcpy(localtext, "@@@");
obspec->te_ptext = localtext;
obspec->te_txtlen = strlen(localtext) + 1;
strcpy(localtmplt, "Name: ___");
obspec->te_ptmplt = localtmplt;
obspec->te_tmplen = strlen(localtmplt) + 1;
Note that the te_pvalid string is not touched in either case, it is
left as it is the original Object tree - pointing to "XXX".
Neither method works, in both cases it appears that the edit takes
place on the box where the original Object tree thinks it should.
If the original tree had "MMM: ___" as a template and I replace
it (using methods one or two above) with "Name: ___" the dialog
will only show "Name: __" and the cursor will go off the end of
the two shown underscores, also sometimes the system will crash.
If I replace "MMM: ___" with "Name:___" (note missing space)
everything is fine.
What am I doing wrong, or not doing.
Thanks for any help!
Yours,
Joe Gilraygreg@bilbo (Greg Wageman) (08/19/89)
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.
rosenkra@hall.cray.com (Bill Rosenkranz) (08/19/89)
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.comklute%trillian.irb@unido.uucp (Rainer Klute) (08/26/89)
In article <11830048@hpldola.HP.COM> jg@hpldola.HP.COM (Joe Gilray) writes: >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). The amount of information displayed in a dialog box is limited by the maximum size of the dialog box itself: the screen size. This should not be too much for the user to survey provided: a) a normal monitor is used (like the SM124, not those 19'' ones), b) the small font is not used (extensivly), c) the dialog box itself is well structured and clear, d) buttons etc. carry a good description of what they stand for, no acronyms. Nested dialogs have the disadvantage that you see only a part of the underlying dialog box(es) and so you do not have the full information at hand. Personally I try to avoid them as long as the dialog box fullfills the above mentioned conditions. However, in my new version of Arcgsh (coming in a few weeks on comp.binaries.atari.st) I had some problems with a dialog box which takes the parameters for Zoo. Well, Zoo parameters are that complex that they simply do not fit into a dialog box of (nearly) screen size. So I took the text edit fields for filename parameters out and "swapped" them to an extra dialog box which shows up when the user clicks a button named "Filenames..." in the main dialog box. Rainer Klute ---- klute@trillian.irb.informatik.uni-dortmund.de Univ. Dortmund, IRB |)|/ klute@unido.uucp, klute@unido.bitnet Postfach 500500 |\|\ ...uunet!mcvax!unido!klute D-4600 Dortmund 50 ---- Tel.: +49 231 7554663
jg@hpldola.HP.COM (Joe Gilray) (08/29/89)
Some seem to dislike the idea of nested dialogs, and I concur that they can complicate unnecessarily. The reason I am using them (besides the unsubstantiated 255 editable character limit that I mentioned earlier) is that for my application, the user will be creating a "header" with an unlimited number of "attachments". The header dialog box will allow the user to enter header information, then upon clicking a button the user will be offered a box (box 2) to enter a single attachment. Another click and the user can return to the header, exit, or add another attachment (in which case s/he will be offered another box 2). You see, this could not be achieved easily with a single box (I have thought of having a single box with an "attachment" section, which could be redrawn, but this is essentially the same as what I've described above, and uglier I think, (what do you think?)). <---- nested parentheses!!!! About the 255 editable (FTEXT or FBPOXTEXT) character limit per box that I mentioned earlier, I am using MWC (v3.0.6), the MW resource constructor, and original ROM TOS (v1.0?). Am I the only one who has noticed this? What might I be doing wrong? Any suggestions as to how I might test to be sure this is the problem? Thanks for any help -Joe Gilray
saj@chinet.chi.il.us (Stephen Jacobs) (08/30/89)
In article <11830050@hpldola.HP.COM>, jg@hpldola.HP.COM (Joe Gilray) writes: > > About the 255 editable (FTEXT or FBPOXTEXT) character limit per box that > I mentioned earlier, I am using MWC (v3.0.6), the MW resource constructor, > and original ROM TOS (v1.0?). Am I the only one who has noticed this? > What might I be doing wrong? Any suggestions as to how I might test to > be sure this is the problem? > I constructed a resource file with about 10 trees and a lot of editable fields within dialogs using resource.prg. It gave some funny behavior. When decompiled with the utility provided by Mark Williams Company, it had some obvious errors, and an attempt to compile the decompiled file crashed my ST. The people at Mark Williams Company have identified the problem (although they didn't seem anxious to tell me what it was: I suspect it involves the cavalier treatment of default text, validation strings and templates). They tell me it took some unusual bad luck to activate it, and that it will be fixed in the next release. Until then, whenever a resource constructed with the Mark Williams resource construction program behaves strangely, it's probably a good idea to look at what it decompiles to. Look particularly for trees with duplicate (and incorrect) names >in the decompilation<. Steve J.
krs@stag.UUCP (Kent Schumacher) (09/05/89)
[jg@hpldola.HP.COM (Joe Gilray) writes...] > Some seem to dislike the idea of nested dialogs, and I concur that they > can complicate unnecessarily. The reason I am using them (besides the > unsubstantiated 255 editable character limit that I mentioned earlier) is > that for my application, the user will be creating a "header" with an > unlimited number of "attachments". The header dialog box will allow the > user to enter header information, then upon clicking a button the user > will be offered a box (box 2) to enter a single attachment. Another click > and the user can return to the header, exit, or add another attachment > (in which case s/he will be offered another box 2). You see, this could > not be achieved easily with a single box (I have thought of having a single > box with an "attachment" section, which could be redrawn, but this > is essentially the same as what I've described above, and uglier I think, > (what do you think?)). <---- nested parentheses!!!! > > [...stuff deleted...] > > Thanks for any help > -Joe Gilray I recently finished up a contract writing program for a client of mine. The contract consisted of a header area (i.e. customer name, etc...), from 0-25 products, and a footer (i.e. totals, notes, etc...). I think this compares somewhat to your need. What I did, was to install the dialog in a window, and hide any unused products. Put another way, when a new contract is initiated, all that is seen is the header info in a sizeable (sizeable as in 'able to do sizing') window with sliders. If the user invokes an add product function (via menu, function key, alt key, or screen button), the program unhides one of the product sub-trees, shifts the y-coordinate of the footer down a little, and forces a redraw of the window area. Note that this is somewhat harder than simply calling form_do(), but not prohibitively so, and the code developed for handling dialogs in windows is very useful to have around (because it can be made to be as generic as form_do() is). In my application, the on screen version of the contract was very similiar to the printed out version. This was a big plus in my clients eyes. + + ^ o - Kent Schumacher /* "A member of STdNET- */ ardvar!krs@stag.UUCP /* The ST developers network */