dlarson@blake.u.washington.edu (Dale Larson) (10/11/90)
In an application I am currently developing, I have a window for entering data which includes radio buttons, string gadgets and integer gadgets. Some fields are optional. My question is: Since string gadgets only notify when "RETURN" is pressed, should the value entered be the state of the string when "RETURN" was last pressed, or should I copy the string to the record just before freeing the gadget and closing the window? I think that I should be doing the later, someone please correct me if I'm wrong. -- -Dale Larson (dlarson@blake.u.washington.edu)
ken@cbmvax.commodore.com (Ken Farinsky - CATS) (10/11/90)
In article <8973@milton.u.washington.edu> dlarson@blake.u.washington.edu (Dale Larson) writes: > >...My question is: Since string gadgets only >notify when "RETURN" is pressed, should the value entered be the state >of the string when "RETURN" was last pressed, or should I copy the string >to the record just before freeing the gadget and closing the window? The user can fill in a whole form of string gadgets without ever hitting RETURN (change fields with the mouse.) This does not make the data any less valid. Check the gadgets before freeing them to see if they contain any valid data. Also, give the user a way to cancel the operation. -- -- Ken Farinsky - CATS - (215) 431-9421 - Commodore Business Machines uucp: ken@cbmvax.commodore.com or ...{uunet,rutgers}!cbmvax!ken bix: kfarinsky
smithwik@pioneer.arc.nasa.gov (R. Michael Smithwick -- FSN) (10/12/90)
["It looks like your friend flew the coup, Coop"] In article <8973@milton.u.washington.edu> dlarson@blake.u.washington.edu (Dale Larson) writes: < <In an application I am currently developing, I have a window for entering <data which includes radio buttons, string gadgets and integer gadgets. <Some fields are optional. My question is: Since string gadgets only <notify when "RETURN" is pressed, should the value entered be the state <of the string when "RETURN" was last pressed, or should I copy the string <to the record just before freeing the gadget and closing the window? <I think that I should be doing the later, someone please correct me if <I'm wrong. <-- <-Dale Larson (dlarson@blake.u.washington.edu) The data used should be the last data seen by the user whether he/she hits return or not. Vista 1.0 requires CR to be hit, and we get endless complaints about that. The user types in data into a single stringgad and just assumes that that is what will be used. Wrongo. The program doesn't do what the data in the window sez it should be doing and they file a bug report. So make sure to read the gadgets buffer and never assume the user hit the CR. Yours for friendier software, mike >> mike smithwick << Any opinions are my own since nobody else would ever want them. "Colonize Cyberspace!"
lhotka@incstar.uucp (Glamdring) (10/18/90)
In article <1990Oct12.053232.22478@nas.nasa.gov>, smithwik@pioneer.arc.nasa.gov (R. Michael Smithwick -- FSN) writes: > > In article <8973@milton.u.washington.edu> dlarson@blake.u.washington.edu (Dale Larson) writes: > < > <In an application I am currently developing, I have a window for entering > <data which includes radio buttons, string gadgets and integer gadgets. > <Some fields are optional. My question is: Since string gadgets only > <notify when "RETURN" is pressed, should the value entered be the state > <of the string when "RETURN" was last pressed, or should I copy the string > <to the record just before freeing the gadget and closing the window? > <I think that I should be doing the later, someone please correct me if > <I'm wrong. > <-- > <-Dale Larson (dlarson@blake.u.washington.edu) > > The data used should be the last data seen by the user whether he/she > hits return or not. Vista 1.0 requires CR to be hit, and we get endless > complaints about that. The user types in data into a single stringgad and > just assumes that that is what will be used. Wrongo. The program doesn't do > what the data in the window sez it should be doing and they file a bug report. > > So make sure to read the gadgets buffer and never assume the user hit the CR. > > > mike > > > >> mike smithwick << The real question then, becomes how to process user input on a per field basis. For instance, the user enters a part number or some key field, and based on that data the program should fill in various other fields with existing or default information. Or better yet perhaps you wish to validate the user's entry before (s)he proceeds beyond that point... The user could enter the key data and then use the mouse to move, not pressing CR and thereby not triggering your program's field processing code... This is not a good thing. One might argue that all field validation should be done at the end of the screen (ala FOCUS or other 4GLs), but IMHO that is very impolite to the user, as they might have entered 20-30 fields before they find that some critical bit of data was invalid... My solution (this is the question part of this post...) is to always keep track of which field was most recently activated (GADGETDOWN) and to perform the field processing code on GADGETDOWN messages if the newly activated gadget doesn't match the last activated gadget. Is this the best way to do this? It appears to work, but I am leary of possible holes in my logic. Better yet, is there a better way to do this? Thanks for any input, but do direct any flames to me via mail. ______________________________________________________________________ / Rockford Lhotka INCSTAR Corp \ | Systems Administrator PO Box 285 | | incstar!lhotka@uunet.uu.net 1990 Industrial Blvd | \ 612/779-1701 Stillwater, MN 55082 / ----------------------------------------------------------------------
dlarson@blake.u.washington.edu (Dale Larson) (10/18/90)
In article <635@incstar.uucp> lhotka@incstar.uucp (Glamdring) writes: >In article <1990Oct12.053232.22478@nas.nasa.gov>, > smithwik@pioneer.arc.nasa.gov (R. Michael Smithwick -- FSN) writes: >> So make sure to read the gadgets buffer and never assume the user hit the >> CR. > >My solution (this is the question part of this post...) is to always keep track >of which field was most recently activated (GADGETDOWN) and to perform the >field processing code on GADGETDOWN messages if the newly activated gadget >doesn't match the last activated gadget. Is this the best way to do this? It That looks like somewhat of an unnecessary pain. If you have several string gadgets, hitting return in one of them should move you to the next. There should be no need to touch the mouse. Doing field processing code only on [RETURN] and before going on to the next record makes your life easier. Hitting return each time makes the user's life easier. So document that fact and encourage him or her by not doing field processing unless [RETURN] is hit or at the end of the record (and if you find an error in field processing at the end of the record, tell the user about [RETURN] again). Hopefully C/A will soon have a style manual giving us clear direction on "the correct" way to do many things like this in a very user-friendly way. If we're lucky, GadTools 2.1 (or whatever) will support a list of string gadgets which take care of activating each other since that would make things even simpler. -- -Dale Larson (dlarson@blake.u.washington.edu)
peterk@cbmger.UUCP (Peter Kittel GERMANY) (10/19/90)
In article <9480@milton.u.washington.edu> dlarson@blake.u.washington.edu (Dale Larson) writes: >In article <635@incstar.uucp> lhotka@incstar.uucp (Glamdring) writes: >>In article <1990Oct12.053232.22478@nas.nasa.gov>, >> smithwik@pioneer.arc.nasa.gov (R. Michael Smithwick -- FSN) writes: >>> So make sure to read the gadgets buffer and never assume the user hit the >>> CR. Yes, this is safer. >>My solution (this is the question part of this post...) is to always keep track >>of which field was most recently activated (GADGETDOWN) and to perform the >>field processing code on GADGETDOWN messages if the newly activated gadget >>doesn't match the last activated gadget. Is this the best way to do this? It Yeah, don't rely on the user doing anything that way you thought he should do it. >That looks like somewhat of an unnecessary pain. If you have several string >gadgets, hitting return in one of them should move you to the next. There Yes, ALSO. BUT you must not force the user to hit Return. Look e.g. into preferences. Nearly every editor has also boolean gadgets (just click) and string or numerical gadgets, too (type on the keyboard). So it can easily happen that the user changes from gadget to gadget simply by mouse clicking. This must not do harm to his inputs! Like in street traffic, drive (and program) defensively, be aware of ANY weird action the user might take. -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
dave@unislc.uucp (Dave Martin) (10/26/90)
From article <9480@milton.u.washington.edu>, by dlarson@blake.u.washington.edu (Dale Larson): > In article <635@incstar.uucp> lhotka@incstar.uucp (Glamdring) writes: >>In article <1990Oct12.053232.22478@nas.nasa.gov>, >> smithwik@pioneer.arc.nasa.gov (R. Michael Smithwick -- FSN) writes: >>> So make sure to read the gadgets buffer and never assume the user hit the >>> CR. >> >>My solution (this is the question part of this post...) is to always keep track >>of which field was most recently activated (GADGETDOWN) and to perform the >>field processing code on GADGETDOWN messages if the newly activated gadget >>doesn't match the last activated gadget. Is this the best way to do this? It > > That looks like somewhat of an unnecessary pain. If you have several string > gadgets, hitting return in one of them should move you to the next. There > should be no need to touch the mouse. Doing field processing code only on > [RETURN] and before going on to the next record makes your life easier. > Hitting return each time makes the user's life easier. So document that fact > and encourage him or her by not doing field processing unless [RETURN] is > hit or at the end of the record (and if you find an error in field processing > at the end of the record, tell the user about [RETURN] again). [...] > -Dale Larson (dlarson@blake.u.washington.edu) I come from the camp that software should be User Friendly, not User: You are required to do it this way, even though the O.S. Supports this way, and this way, and... I may be editing a form rather than entering one and may only want to change a few fields. It is easier for me to use the mouse to get to the next field that I want to change than to hit return 15 times and I may not remember to hit return on that last field. The programmer should go to extra effort (read "unnecessary" pain) to make his software easier to use. The world is already full of mediocre software because the programmer went 90% of the way then said "I'm done!". Now, will someone please tell me if my postings are making it past the building I work in? -- VAX Headroom Speaking for myself only... blah blah blahblah blah... Internet: DMARTIN@CC.WEBER.EDU dave@saltlcy-unisys.army.mil uucp: dave@unislc or use the From: line. Now was that civilized? No, clearly not. Fun, but in no sense civilized.
dlarson@blake.u.washington.edu (Dale Larson) (10/28/90)
In article <1990Oct25.212714.26909@unislc.uucp> dave@unislc.uucp (Dave Martin) writes: >From article <9480@milton.u.washington.edu>, by dlarson@blake.u.washington.edu (Dale Larson): >> That looks like somewhat of an unnecessary pain. If you have several string >> gadgets, hitting return in one of them should move you to the next. There >> should be no need to touch the mouse. Doing field processing code only on >> [RETURN] and before going on to the next record makes your life easier. >> Hitting return each time makes the user's life easier. So document that fact >> and encourage him or her by not doing field processing unless [RETURN] is >> hit or at the end of the record (and if you find an error in field processing >> at the end of the record, tell the user about [RETURN] again). >[...] >> -Dale Larson (dlarson@blake.u.washington.edu) > >I come from the camp that software should be User Friendly, not > User: You are required to do it this way, even though the O.S. > Supports this way, and this way, You are the second person to make a similar comment. Perhaps I didn't make myself clear enough. I do believe in being as user freindly as is reasonably possible, regardless of the pain. I just do not see how processing the contents of a string gadget every time the cursor is removed from it is necessary and desireable. In your example of updating a record you don't need to hit [RETURN] under my scheme -- all string gadgets should be checked at the end of that record (i.e. closewindow or a NEXT RECORD gadget or whatever). It's just that any sanity checking or whatever would not be applied until you hit [RETURN] or indicated that it was time to go on to the next record. While you can argue that you'd like immdiate sanity checking on updates, I will reply that: 1) Such immediate checking isn't very helpful since you're probably only changing one field before going to the next record anyway. 2) It is easier for the user to use [RETURN] to move to the next string gadget for most opperations, so the user should be encouraged to do so. and 3) [RETURN] should move the cursor to the next string gadget, but activating another gadget should not. The complexity introduced by several different ways of processing string gadgets does not at all seem called for by or supported by the operating systems and is getting close to, if not exceeding the threshold of what is reasonable to expect from programmers. Your point about what the operating system supports is very important. We seem to disagree about what the operating system "supports" (or perhaps about what the word "supports" means in this context). It is certainly the case that if we all adhered to a style guide indicating how to handle this, the user would know what to expect (assuming s/he read the manual and/or used the system much) and either solution would be acceptable. >Now, will someone please tell me if my postings are making it past the >building I work in? They made it. -- -Dale Larson (dlarson@blake.u.washington.edu)
peter@sugar.hackercorp.com (Peter da Silva) (10/29/90)
In article <10109@milton.u.washington.edu> dlarson@blake.u.washington.edu (Dale Larson) writes: > I just do not see how processing the contents of > a string gadget every time the cursor is removed from it is necessary and > desireable. Since nobody's suggesting you do that, what's your point. Set up your string gadgets and do you checking when they hit "done". If there's a problem leave the window open, display a message, and leave the cursor on that gadget. Programs that are too picky in realtime are annoying. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
dlarson@blake.u.washington.edu (Dale Larson) (10/30/90)
In article <6919@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >Since nobody's suggesting you do that, what's your point. Set up your string lhotka@incstar.uucp (Glamdring) suggested it very clearly (complete with programming details) in article <635@incstar.uucp>. The message to which my reply was directed also seemed to be suggesting that I check string gadgets whenever they are deactivated. (Sorry, but it is not practical for me to quote those earlier articles from this set-up). My point, then, is not only to debate the assertions of those articles but to engage in (hopefully) clarifying discussion regarding what can be a rather sticky point of style. >gadgets and do you checking when they hit "done". If there's a problem leave >the window open, display a message, and leave the cursor on that gadget. > >Programs that are too picky in realtime are annoying. Programs which aren't picky enough in realtime are annoying, too. If the validity of several fields can be checked with help from an earlier field, such checking should be done early to save entry of several bogus fields. Perhaps more importantly, [RETURN] in a string gadget should move the cursor to the next string gadget in that window in most (if not all) applications (though perhaps you didn't intend to preclude such minimal processing of string gadgets before the user hits "done"). -- -Dale Larson (dlarson@blake.u.washington.edu)
peter@sugar.hackercorp.com (Peter da Silva) (10/30/90)
In article <10177@milton.u.washington.edu> dlarson@blake.u.washington.edu (Dale Larson) writes: > Programs which aren't picky enough in realtime are annoying, too. If the > validity of several fields can be checked with help from an earlier field, > such checking should be done early to save entry of several bogus fields. Great, now what happens when you decide to go back to the previous fields to change it to make the next field valid? I don't know how many times I've been waiting in line behind someone and the operator on the point-of-sale terminal has screwed up. Often, even with the intervention of the store manager and once or twice myself (though I can usually help if they have a manual), it proves impossible to do anything but abort the transaction and start over because the UI wouldn't let them go back. > Perhaps more importantly, [RETURN] in a string gadget should move the cursor > to the next string gadget in that window in most (if not all) applications > (though perhaps you didn't intend to preclude such minimal processing of > string gadgets before the user hits "done"). No, of course not. That's a 2-liner in your event loop anyway. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
dlarson@blake.u.washington.edu (Dale Larson) (10/30/90)
In article <6927@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >Great, now what happens when you decide to go back to the previous fields >to change it to make the next field valid? I don't know how many times I've >been waiting in line behind someone and the operator on the point-of-sale >terminal has screwed up. Often, even with the intervention of the store >manager and once or twice myself (though I can usually help if they have a >manual), it proves impossible to do anything but abort the transaction and >start over because the UI wouldn't let them go back. You make a good point. Idiot proofing is very user-hostile! Not just in the sense that it can make uncommon events difficult or imposible to handle with the software, but it is also de-skilling in that it removes any need (or possibility) for significant human thought or action. I bring up a requester which basically says "This doesn't look right" and give the user the option to ignore the warning. Many proposed guidelines for making software user-friendly include something to the effect that feedback should be immediate. If you are entering a date and you find out right then that it isn't a valid date it is easy to change. But if you've gone on and done several other things, you have to mentally 'shift gears' and try to remember or figure out which date you really want. Further, user-friedliness includes providing reasonable default values when ever possible. Often, the only was a reasonable default for a later field can be determined is through knowledge of an earlier field. Though for this sort of thing, I suppose you want to check the current value of the string gadgets buffer, not what it's value was when return was entered. -- -Dale Larson (dlarson@blake.u.washington.edu)
hill@evax.arl.utexas.edu (Adam Hill) (10/31/90)
AMEN!!!! A friend and I were working on a D&D character generator for 2nd
Edition and came up on this big time.
Imagine: Dice Rolls -> Stats -> Race -> Class -> Money -> Equipment
Now with a "nice" screen on which you have these attributes displayed ---
WHAT DOES THE USER GET TO CHANGE ONCE HE HAS CHOSEN??? It gets worse, what
happens when the player says "Hey I want more money .. I wanna become a
Paladin!" The code has now become nasty to check for all of this.
We finally said "You will do this" un-Ghost some "Now do this" un-ghost
some more. And if he wanted to go back to X everything "after" X got cleared.
And I thought it was bad the mutual exclude didn't "quite" work ...... :-)
--
adam hill "I will tell you three things.."
hill@evax.arl.utexas.edu Make Up Your Own Mind.. AMIGA!
Amiga... Multimedia NOW!!
24 Bit Color(n.) Large waster of bandwidth. "Amiga walk with me ........"lhotka@incstar.uucp (Glamdring) (11/01/90)
> I just do not see how processing the contents of > a string gadget every time the cursor is removed from it is necessary and > desireable. In your example of updating a record you don't need to hit > [RETURN] under my scheme -- all string gadgets should be checked at the end > of that record (i.e. closewindow or a NEXT RECORD gadget or whatever). It's > just that any sanity checking or whatever would not be applied until you hit > [RETURN] or indicated that it was time to go on to the next record. While The package I am working on (hence my original question) is such that the various editor and transaction screens have a large number of fields (some upwords of 30...). Many (MANY) of these fields not only require various bits of sanity checking, but also access a database to get data to load in some of the other fields on the screen. It is very likely that the user will skip around the screen a lot, especially if changing an existing set of data, as all the fields will be filled in already. While you can argue that the user can fill in a field, press return and then use the mouse to select another field, this seems to be an unnecessary condition to place upon a user. After all, I am dealing with users who call terminals 'computers', monitors 'TVs', etc... It is vital that the screens be VERY userproof... > you can argue that you'd like immdiate sanity checking on updates, I will > reply that: > > 1) Such immediate checking isn't very helpful since you're probably > only changing one field before going to the next record anyway. You appear to be assuming simple record editing screens, where I am actually dealing with complex transaction screens... > 2) It is easier for the user to use [RETURN] to move to the next string > gadget for most opperations, so the user should be encouraged to do so. > and agreed - this is the case during data entry on a new or partially filled in screen. However, you mustn't overlook the possibility that a user is modifying a screen which was already filled in and there are a few scattered fields to change... > 3) [RETURN] should move the cursor to the next string gadget, but activating > another gadget should not. Obviously using the mouse to activate another gadget should only activate the chosen gadget. On the other hand, your program did not recieve a GADGETUP message so it may not have processed the field you just left. This is the crux of my problem. I *really* want to process that field the user just left, as it may affect the contents of the field just entered and I want to make sure that any defaulting, etc gets done before the user enters more information. I have written a nice one page routine which keeps track of the GadgetID of the last gadget and calls a ProcessGadget procedure if the most recently activated gadget is different (whether that activation be via a RETURN moving to the next string gadget or the mouse moving to some arbitrary field). This appears to be working pretty well but feels more like a workaround than an elegant solution... > The complexity introduced by several different > ways of processing string gadgets does not at all seem called for by or > supported by the operating systems and is getting close to, if not exceeding > the threshold of what is reasonable to expect from programmers. On this point I can only say that I firmly believe that if the user is inconvenienced by some lack of effort on the part of the programmer then the programmer did not do the job properly. I have seen the effect of trying to market software which worked as long as the user did everything perfectly - bad move... Users *always* screw things up if it is possible to do so. I most certainly do when I am being a user!! :-) ______________________________________________________________________ / Rockford Lhotka INCSTAR Corp \ | Systems Administrator PO Box 285 | | incstar!lhotka@uunet.uu.net 1990 Industrial Blvd | \ 612/779-1701 Stillwater, MN 55082 / ----------------------------------------------------------------------
lhotka@incstar.uucp (Glamdring) (11/01/90)
In article <6927@sugar.hackercorp.com>, peter@sugar.hackercorp.com (Peter da Silva) writes: > In article <10177@milton.u.washington.edu> dlarson@blake.u.washington.edu (Dale Larson) writes: >> Programs which aren't picky enough in realtime are annoying, too. If the >> validity of several fields can be checked with help from an earlier field, >> such checking should be done early to save entry of several bogus fields. > > Great, now what happens when you decide to go back to the previous fields > to change it to make the next field valid? I don't know how many times I've > [counter woes deleted...] > I didn't mean to imply in my earlier posting that you would be prevented from returning to earlier fields (via the mouse of course... yet another complaint that you can't trap the up arrow in a string gadget...) to change their values. On the other hand, that earlier field will have to be processed as soon as you enter the data into it, or the condition you are trying to fix won't be fixed... ______________________________________________________________________ / Rockford Lhotka INCSTAR Corp \ | Systems Administrator PO Box 285 | | incstar!lhotka@uunet.uu.net 1990 Industrial Blvd | \ 612/779-1701 Stillwater, MN 55082 / ----------------------------------------------------------------------