Jim.Spencer@p5.f22.n282.z1.FIDONET.ORG (Jim Spencer) (03/13/90)
>As I understand it, there are 4 kinds of dialogs: > >(a) an alert, >(b) a "real" modal dialog, i.e. a modal dialog that is too complex for > the _Alert trap, and is _really_ modal, >(c) a "movable" modal dialog, i.e. a dialog that is modal with respect > to the application, but modeless with respect to the rest of the > world, >(d) a modeless dialog. > >Only in case (b) one should use _ModalDialog (again, as I understand it). > >Now, my question is: Does case (b) ever occur in practice? When one >uses a dialog of type (b), is it not _always_ bad interface design? If >so, then what is the use of the _ModalDialog trap? > You use type (b) Modal dialogs all the time. For a couple of trivial examples, take a look at your page setup and print dialogs in any application. Moreover, Alert() simply calls ModalDialog() to actually handle the alert's events. -- Jim Spencer - via FidoNet node 1:282/33 UUCP: ...!uunet!imagery!22.5!Jim.Spencer ARPA: Jim.Spencer@p5.f22.n282.z1.FIDONET.ORG
ccc_ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) (03/16/90)
I never use the Alert traps. I invariably want to centre my alerts horizontally on the screen regardless of screen size, and I can't do that with Alert, whereas I can with modal dialogues. This also has the pleasant side effect that my alerts will never beep at you. Lawrence D'Oliveiro Computer Services Dept, University of Waikato, Hamilton, New Zealand Any opinions expressed by the author of this posting are sacred to Epimetheus, the Greek god of hindsight.
jackiw@cs.swarthmore.edu (Nick Jackiw) (03/17/90)
ccc_ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: > I never use the Alert traps. I invariably want to centre my alerts horizontally > on the screen regardless of screen size, and I can't do that with Alert, > whereas I can with modal dialogues. x:=GetResource('ALRT',res_ID); with AlterTHndl(x)^^.boundsRect do begin width:=right-left; left:=(Screenbits.bounds.right+ScreenBits.bounds.left-width) div 2; right:=left+width end; i:=Alert(res_ID); > This also has the pleasant side effect > that my alerts will never beep at you. Set the "soundN" parameters in the ALRT's stageList to 0. > Lawrence D'Oliveiro > Computer Services Dept, University of Waikato, Hamilton, New Zealand > Any opinions expressed by the author of this posting are sacred to > Epimetheus, the Greek god of hindsight. Understandable. :-) -- --- jackiw@cs.swarthmore.edu | Smoggo: Can you prevent the detonation of jackiw@swarthmr.bitnet | the thermonuclear device? Applelink: D3717 | Jimbo: No ... I cannot.
Jim.Spencer@p5.f22.n282.z1.FIDONET.ORG (Jim Spencer) (03/17/90)
>>You use type (b) Modal dialogs all the time. For a couple of trivial >>examples, take a look at your page setup and print dialogs in any >>application. > >BUT! I consider the current way that page setup and print dialogs are >handled BAD interface design. Why, fer gossake, should a page setup or >print dialog be modal? Give me ONE reason! Sorry, I must have misunderstood what you were saying (it was the end of a long day and I vaguely recall thinking you were asking for examples of where they were used rather than the more important question of when should you use modal dialogs. Generally I agree with you completely, particularly for dialogs like the page set up. I am less sure for the print dialog. It is not presented until you have asked for a print (a non-modal request). For the print to proceed, certain information is necessary. For the application to process the print request, it either must ask for this information modally or assume that values established previously are still valid. I'm having trouble picturing how a non-modal dialog presented when the "Print" menu cho ice is selected would work. Similarly, file dialogs which are only presented after you have asked the application to do something which requires this information. My point is that there are times when going modal makes sense. -- Jim Spencer - via FidoNet node 1:282/33 UUCP: ...!uunet!imagery!22.5!Jim.Spencer ARPA: Jim.Spencer@p5.f22.n282.z1.FIDONET.ORG
tim@hoptoad.uucp (Tim Maroney) (03/19/90)
In article <38.26037AF7@imagery.FIDONET.ORG> Jim.Spencer@p5.f22.n282.z1.FIDONET.ORG (Jim Spencer) writes: > >>You use type (b) Modal dialogs all the time. For a couple of trivial > >>examples, take a look at your page setup and print dialogs in any > >>application. > >BUT! I consider the current way that page setup and print dialogs are > >handled BAD interface design. Why, fer gossake, should a page setup or > >print dialog be modal? Give me ONE reason! >Generally I agree with you completely, particularly for dialogs like >the page set up. I am less sure for the print dialog. It is not >presented until you have asked for a print (a non-modal request). For >the print to proceed, certain information is necessary. For the >application to process the print request, it either must ask for this >information modally or assume that values established previously are >still valid. I'm having trouble picturing how a non-modal dialog >presented when the "Print" menu choice is selected would work. >Similarly, file dialogs which are only presented after you have asked >the application to do something which requires this information. My >point is that there are times when going modal makes sense. First, put carriage returns at the end of your lines. If your sysop doesn't provide a text editor that works with USENET groups in a friendly way, then USENET groups should not be available from your sysop's machine. As for modal dialogs, I don't understand your imaginative difficulties. A modeless dialog can configure a modal operation perfectly well. The dialog comes up, but the operation doesn't happen until you click the equivalent of the OK button. If you give the same command again (e.g., Print or Open) before clicking OK or getting rid of the window, then the window simply comes to the front. This would work perfectly well for both the Print dialogs and the Standard File dialogs, if the people who wrote those parts of the OS had taken Apple's guidelines about modelessness seriously. As it is, though, it almost can't be done. (It can, but it's a major pain and may not be future-compatible.) -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "Satanic is merely the name they give to the behavior of those who would disrupt the orderly way in which men want to live." -- Gabrielle, THE VAMPIRE LESTAT, Anne Rice
pratt@boulder.Colorado.EDU (Jonathan Pratt) (03/20/90)
In article <10853@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: > >A modeless dialog can configure a modal operation perfectly well. The >dialog comes up, but the operation doesn't happen until you click the >equivalent of the OK button. If you give the same command again (e.g., >Print or Open) before clicking OK or getting rid of the window, then >the window simply comes to the front. This would work perfectly well >for both the Print dialogs and the Standard File dialogs, if the people OK, explain this further. Suppose you bring the modeless print dialog in front of a window that that can't be printed. Do you dim the OK button? Does this kind of modelessness really help the user, or does it simply clutter the desktop? Would it be clear to most users that the modeless print window operates on the next window down? No flames please, just discussion. Jonathan /* Jonathan Pratt Internet: pratt@boulder.colorado.edu * * Campus Box 525 uucp: ..!{ncar|nbires}!boulder!pratt * * University of Colorado * * Boulder, CO 80309 Phone: (303) 492-4293 */
bowman@reed.UUCP (Eric Bowman) (03/20/90)
In article <18601@boulder.Colorado.EDU> pratt@boulder.Colorado.EDU (Jonathan Pratt) writes: >OK, explain this further. Suppose you bring the modeless print dialog >in front of a window that that can't be printed. Do you dim the OK >button? Does this kind of modelessness really help the user, or does >it simply clutter the desktop? Would it be clear to most users that >the modeless print window operates on the next window down? No flames >please, just discussion. One possible fix for this problem (?), and only one of many might be to put a list in the non-modal dialog box with the names of the open & printable windows/documents if there are multiple windows open. This wouldn't be needed most of the time, but if, say, in a word processor, several open documents, this would be a straight-forward way of telling the software what you want to print. BobO bowman@reed.{bitnet,UUCP,edu}
bc@modernlvr.sgi.com (Bill Coderre) (03/20/90)
Jim.Spencer@p5.f22.n282.z1.FIDONET.ORG (Jim Spencer) writes: |You use type (b) Modal dialogs all the time. For a couple of trivial |examples, take a look at your page setup and print dialogs in any |application. Tying this to an earlier thread begs an interesting question. We were told, ala "Don't Abuse the Managers," that the limit for ModalDialogs was about 20 items. We were then told that dialogs with more than 8 items were bad, and then that dialogs with too many items cause strange bugs (only hinted at). Well, I count 13 items (plus many more static text labels) in the Page Setup box, and about the same for Print. (Obviously, the static text items don't really count since they could be done with a PICT.) Page Setup also provides live icons and clever graphics (Mr Dogcow), all of which have been suggested as "Bad" to use For Compatibility Reasons. On another topic, let me point out how irksome it is to have to have four programming strategies to handle dialogs, and how repugnant I find it to have to do bizarre special casing in one's event loop to handle such simple concepts as modeless dialogs. Now that Apple HIG has come up with a swank Movable Modal, it too requires event loop chicanery, and different chicanery at that. bill coderre, fledgling consultant Please note that I am not employed by SGI. Or, for the conceptually impaired, "My girlfriend works for SGI and all I got was this stinkin' login."
isr@rodan.acs.syr.edu ( ISR group account) (03/21/90)
One important example for Print (or Save) for that matter to be modeless is when you want to examine the window one more time before printing/saving/whatever. How many times have you had a multi-page Draw-type document that you only wanted a few pages printed out of, and didn't remember to check which ones were which until the print dialog came up? it would be nice to be able to simply go up and check the "Drawing Size" display at that point. -- Mike Schechter, Computer Engineer,Institute Sensory Research, Syracuse Univ. InterNet: isr@rodan.acs.syr.edu Bitnet: SENSORY@SUNRISE
oster@well.sf.ca.us (David Phillip Oster) (03/21/90)
In article <10853@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >A modeless dialog can configure a modal operation perfectly well. The >dialog comes up, but the operation doesn't happen until you click the >equivalent of the OK button. If you give the same command again (e.g., >Print or Open) before clicking OK or getting rid of the window, then >the window simply comes to the front. This would work perfectly well >for both the Print dialogs and the Standard File dialogs, if the people The general problem for modeless dialogs are that if _anything_ changes, then you have to scan a list of potentially visible dialogs to see which ones _are_ visible, then change all relevant fields to be consistent with the new information. (You have to do this anyway, but in a world of modal dialogs, the set of things that are potentially visible is much smaller.) For example, suppose you have a database with three windows visible: a main window showing many records, a data entry showing one record, where the user can edit individual fields, and search window. If the user deletes a record from the main window, if that record was visible in the data entry you must clear it. If the user deleted _all_ the records, then you must dim the "(Search)" button, since there is nothing to search in (unless there is a partial record in the data window, and the data window is "above" the main window (although it may be on a different CRT even though it _is_ higher...)) Anybody have a good solution to this more general problem? I have particular trouble getting Undo to set _everything_ back the way it was before, since I like to give each window its own undo state. -- -- David Phillip Oster - Note new address. Old one has gone Bye Bye. -- oster@well.sf.ca.us = {backbone}!well!oster
tim@hoptoad.uucp (Tim Maroney) (03/22/90)
In article <10853@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >>A modeless dialog can configure a modal operation perfectly well. The >>dialog comes up, but the operation doesn't happen until you click the >>equivalent of the OK button. If you give the same command again (e.g., >>Print or Open) before clicking OK or getting rid of the window, then >>the window simply comes to the front. This would work perfectly well >>for both the Print dialogs and the Standard File dialogs, if the people In article <18601@boulder.Colorado.EDU> pratt@boulder.Colorado.EDU (Jonathan Pratt) writes: >OK, explain this further. Isn't there a word missing here? What your mother used to call "the magic word"? >Suppose you bring the modeless print dialog >in front of a window that that can't be printed. Do you dim the OK >button? Does this kind of modelessness really help the user, or does >it simply clutter the desktop? Would it be clear to most users that >the modeless print window operates on the next window down? It would be a big mistake to use this kind of functionality; the idea of printing the next window down would be anything but clear to the user. The best solution is to make the print dialog a multiply-instantiated floating sub-window locked to its particular window, which *would* be pretty clear, but the MacOS makes this quite difficult. The second best solution is that the print dialog contain the name of the window it is set up to print, prominently displayed in the print dialog window title. If you choose Print again, then the print dialog comes to the front again, but with the name of the window that was frontmost when you gave the new command. Or, simply disable the print command while the print dialog is visible (an inferior solution). Or, have a button in the print dialog that allows the window associated with it to be changed. >No flames please, just discussion. Does this inflammatory comment serve some purpose? -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com A good flame strengthens its points; it does not stand in lieu of them.
ech@cbnewsk.ATT.COM (ned.horvath) (03/22/90)
From article <16785@well.sf.ca.us>, by oster@well.sf.ca.us (David Phillip Oster): > The general problem for modeless dialogs are that if _anything_ changes, then > you have to scan a list of potentially visible dialogs to see which ones _are_ > visible, then change all relevant fields to be consistent with the new > information. (You have to do this anyway, but in a world of modal dialogs, > the set of things that are potentially visible is much smaller.) > > For example, suppose you have a database with three windows visible: > a main window showing many records, a data entry showing one record, where > the user can edit individual fields, and search window. [more examples] To put this into SmallTalk-y or object-oriented terms, what you are describing is a DATA object with multiple VIEWS. The recommended method is to store a list of dependent VIEW objects in the DATA object, then have the data object, when changed, send lots of CHANGED...BECAUSE messages to the dependents. Think about it... =Ned Horvath=
pratt@boulder.Colorado.EDU (Jonathan Pratt) (03/22/90)
In article <10879@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: > >In article <18601@boulder.Colorado.EDU> pratt@boulder.Colorado.EDU >I wrote: >>OK, explain this further. > >Isn't there a word missing here? No, but your elaboration is appreciated. > >The second best solution is that the print dialog contain the name of >the window it is set up to print, prominently displayed in the print >dialog window title. If you choose Print again, then the print dialog >comes to the front again, but with the name of the window that was >frontmost when you gave the new command. > This, IMHO, is marginally better than the movable-modal dialog. I assume the window should be dismissed when OK is chosen to avoid a loss off speed compared to current modal dialogs. It's also been suggested that a list or pop-up menu be used in the dialog to allow a quick change of the window/object to which the operation should apply. Has anyone tried these approaches and gotten some feedback from non-power users? In sum, I'm willing to expend the programming effort once I'm convinced my users will benefit. Perhaps Apple will too (with print and page setup, which is how this whole thread got started). Jonathan /* Jonathan Pratt Internet: pratt@boulder.colorado.edu * * Campus Box 525 uucp: ..!{ncar|nbires}!boulder!pratt * * University of Colorado * * Boulder, CO 80309 Phone: (303) 492-4293 */