tim@hoptoad.uucp (Tim Maroney) (12/07/88)
tim@hoptoad.uucp (Tim Maroney) wrote (talking about dimmed menu items): > There are a few different ways to deal with the selection issue. The > best way is probably never to allow a disabled cell to be selected. Actually, I was talking about disabled list items, not menu items, but it's still a valid topic for discussion. In article <6001@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) has written: >I find this one of the worst aspects of the Mac user interface. >In most cases when I want to deal with a dimmed item, I want to select >it to get something done (e.g. read in a new file) but there is >something I have to do first before it will let me do it (e.g. write >out the one I already have). In a command based interface I would >command it to read in the new file and would get an error message, e.g. >"Can't read a new file until you save or dispose of the old one". In a >dimmed-menu interface where you can't select the dimmed items, there is >no way to find out what it wants me to do before it will "let me" >command it to take the action I want done. Yep, it can be frustrating to be told you can't do something, with no reason why; I agree completely. The latest revision of the Menu Manager lets the software check to see whether a disabled item was chosen and which one. That way, error reporting information can be passed back to the user. Unfortunately, it's not clear from IM V whether the MenuChoice routine that does this also works after using a keyboard equivalent. The motivation for disabling menu items is error prevention. One of the points of Mac philosophy is supposed to be that error correction is nice, but it's better to keep someone from having the opportunity to make an error. I think you've made a good case that this principle has been overapplied with respect to menus. Let's hope that application designers start taking advantage of the new "disable notification" feature. >The solution is simple; you let dimmed items be selected, and if one >is selected, you print an error message (display an alert, whatever the >Mac calls it) that says what the problem is. Write these messages >from the point of view that you are a human who desperately wants >to make the computer do the thing that they selected, e.g. they >picked this menu item for a reason! Tell them what they need to know >about how to do it; don't tell them "you selected a dimmed menu item idiot", >tell them "you can't load a file because first you need to quit out of >the one you are in -- use the Quit or Save or Save As menu item". To be fair, a lot of command based systems give error messages in such a case that are not much more useful to the average user than "Wake up, you moron!" Control-G is a common method of error reporting. But the solution you outlined is feasible on the Mac -- it's just that at present no one bothers. Which seems to disrespect the most basic Mac interface principle, that of not making too many assumptions about the intelligence or computer literacy or Mac experience or manual-reading of the user.... By the way, the case you cited, where "Open" is disabled, is a sloppiness of another, far worse kind in my view. Writing a single window application for the Mac should lead to at least defenstration, with evisceration the preferred penalty. It was immensely dumb that all three of Apple's lead-off applications for the Mac were single-window (MacPaint, MacWrite, MacTerminal). Any single window program is isomorphic to one where the globals have been moved into per-window data structures! We're supposed to be *improving* on ttys. -- Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim "Do what you wanna, do what you will; Just don't mess up your neighbor's thrill. And when you pay the bill, kindly leave a little tip To help the next poor sucker on his one-way trip." - Frank Zappa, "You Are What You Is"
mikem@uhccux.uhcc.hawaii.edu (Mike Morton) (12/08/88)
Tim Maroney recently wrote: > The latest revision of the Menu Manager lets the software check to see > whether a disabled item was chosen and which one. Some colleagues and I tried to incorporate this into a product in mid-'87. We found that the trap for "MenuChoice" was not implemented, even on the Mac II, although the global "MenuDisable" was being set correctly. When we complained to Apple, they told us it was not going to be supported, and not to use it. Both the trap and the global are documented in the published IM volume V, dated January '88, though. I think there were some problems with using the global, but I'm afraid I don't remember, since Apple was so insistent and we decided not to bother with it. Incidentally, MenuDisable can return the root item for a hierarchical menu (the "submenu title"). We were tempted to use this for an odd syntax, but a preview of this concept at the Boston Computer Society's MacTechGroup convinced us that this was a Bad Thing To Do. -- Mike Morton // P.O. Box 11378, Honolulu, HI 96828, (808) 676-6966 HST Internet: msm@ceta.ics.hawaii.edu (anagrams): Mr. Machine Tool; Ethical Mormon; Chosen Immortal; etc.
earleh@eleazar.dartmouth.edu (Earle R. Horton) (12/08/88)
In article <6004@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: ... >By the way, the case you cited, where "Open" is disabled, is a >sloppiness of another, far worse kind in my view. Writing a single >window application for the Mac should lead to at least defenstration, >with evisceration the preferred penalty. It was immensely dumb that >all three of Apple's lead-off applications for the Mac were >single-window (MacPaint, MacWrite, MacTerminal). Any single window >program is isomorphic to one where the globals have been moved into >per-window data structures! We're supposed to be *improving* on ttys. This statement has a lot of merit, but I don't think the presence or absence of multiple windows is really the correct way to judge how flexible an application writer has been, or how much of an advance he has made over glass ttys. For instance, HyperCard has ONE window, but it clearly demonstrates progress in some direction or other from the first Macintosh programs. Imagine HyperCard as a multi-window application, with a separate window for each card, and you should quickly see that multiple overlapping windows are not always appropriate. Also, multiple windows are slower than a single window. You have to handle activate, deactivate, and update events properly, and if many windows exist then the user can run into problems managing them all. An example of where a single window is appropriate for an operation is the split-window option in Word. Cutting and pasting between two sections of the same document is much much faster using a split window than it would be using two windows. Any time I do extensive cut-and-paste between two separate documents I wish there were some way to get both docs into a split window like this! A careful application writer will weigh the inconveniences of multiple windows against the conveniences, and then judge on an application by application basis how many windows and types of window are needed to get the job done. If we're talking about a word processor or a paint program and its documents, Tim is exactly right here. An application which exists to create and modify documents should support operations on multiple documents, and multiple windows is a good way to accomplish this. It is not, however, the only way. Earle R. Horton. 23 Fletcher Circle, Hanover, NH 03755 (603) 643-4109 Graduate student.
kent@lloyd.camex.uucp (Kent Borg) (12/09/88)
[discussion about wanting to make choices from _disabled_ menu items] <begin flame about not blindly tampering with the user interface> You mean you want the machine that tries to elimate modes to have 2 modes for every single disablable menu item?? Does that mean that the disabled item should blink 3 times too?, or do you just leave it to the user to be confused enough without the confirming blinks? Applications should be well enough designed that the user is not confused with disabled menu items. If the user _is_ confused, then it is the fault of the application's user interface design. Don't ask to fix bad programs by breaking the larger interface. There is room for improvement in the Macintosh user interface, but that doesn't mean that every gripe should get the first kludge you can think of applied to it. <nearing end of flame: sorry about this, but I don't think the Mac was arrived at lightly, nor do I think it should be tampered with lightly> Kent Borg kent@lloyd.uucp or hscfvax!lloyd!uucp
kehr@felix.UUCP (Shirley Kehr) (12/12/88)
In article <11407@dartvax.Dartmouth.EDU> earleh@eleazar.dartmouth.edu (Earle R. Horton) writes: <An example of where a single window is appropriate for an operation is <the split-window option in Word. Cutting and pasting between two <sections of the same document is much much faster using a split window <than it would be using two windows. Any time I do extensive <cut-and-paste between two separate documents I wish there were some <way to get both docs into a split window like this! >Earle R. Horton. 23 Fletcher Circle, Hanover, NH 03755 This is exactly how you get sucked into buying more and more equipment. I was very happy with the SE at my former employers. After seeing the original big screens at FileNet (MegaScreen), I went back and told my boss they were harder to read than the SE screen and I didn't want one. Still, my friends at FileNet said that it was really hard to go back to the small screen when they took their SEs home for the weekend. Now that I'm at FileNet, I "had to" accept a big screen. (:-) The first day I used it, I finally understood what they meant when I pulled those two documents up on the screen side by side in MultiFinder and happily clicked away transferring text from one side of the screen (one document) to the other side (other document). On a Mac II it was just as fast as transferring text from one part of a split window to the other - at least I was not aware of waiting. The moral of the story is: don't try addictive hardware until you're ready to buy it. Shirley kehr