tim@hoptoad.uucp (Tim Maroney) (03/08/90)
In article <1831@esquire.UUCP> baumgart@esquire.dpw.com (Steve Baumgarten) writes: >Specifically, people tend to want to cut and paste in dialog boxes and >are continually surprised and annoyed when they can't. Even if it's >the kludgy Hypercard script editor solution of supporting the keys and >not the Edit menu, anything would be better than forcing people to >type things when they shouldn't have to. I regard this as a bug. If people are going to use ModalDialog with editable text items, they *must* use a filterProc that allows the standard edit menu commands; if they don't, their software is broken. This is one of the most common bugs on the Mac, unfortunately, and it even crops up in Apple programs like HyperCard. (Try pasting the name field of a card, background, button, or field sometime in HyperCard 1.2.2. It's amazing to me that this hadn't been fixed in a version that came out some two years after the initial release of HyperCard!) >Nisus solves this problem very, well, nicely. It *always* keeps the >Edit menu enabled, so that you can cut and paste anywhere, even in >modal and StdFile boxes. I find myself reaching selecting parts of >names in other programs' StdFile boxes and trying to use CMD-X and >CMD-V, and I'm always frustrated when I can't perform this most basic >of Macintosh functions. Best of all, since Nisus allows you to choose >cut and paste from the Edit menu, this feature is available to novices >as well as experts. I don't really think so. I've never observed a novice even *try* to pull down a menu when a modal dialog is up. It seems obvious to them that it wouldn't work. So, the only people who would benefit from the feature are people who are at least semi-experts, people who read that part of the manual. But these are people who probably always use the edit menu shortcuts anyway. Maybe if all other menus were disabled when a modal dialog came up, that would be eye-catching enough to some neophytes to suggest pulling down the menu. But I still doubt that many people would either notice it or figure it out. >So if there's any way to add support for Edit menu items in modal (and >non-modal) dialog boxes, I urge the Human Interface group to consider >it. It's easy to forget that new users don't know what we veterans >have known for a while -- that some things "aren't allowed", but for >no justifiable reason (apart from programming, which is never a valid >reason when you're trying to explain to your mother why the skills she >just used in her MacWrite document suddenly cause the computer to >beep). Technically, it's not at all hard to intercept and handle clicks in the menu bar from a modal dialog filter proc. The question is whether the effort involved is worth it. >By the way, Nisus also handles the issue of command-key equivalents in >dialog boxes with equal aplomb. Instead of forcing you to wade >through a manual as Word does, Nisus displays the "cloverleaf-letter" >combinations right next to the buttons as soon as you press the >command key. So a novice can use the dialog boxes in the traditional >point-and-click way, a more experienced user is given reinforcement to >aid his memory, or is just allowed to consider the possibility of >using command keys without having to haul out the manual, and an >expert is not slowed down in the least. Ooh, I hate those. Talk about some ugly buttons. Yeah, the reminder is nice from a psychological perspective, but the appearance of the shortcuts themselves is nasty from an aesthetic perspective, at least to me. If pressed to justify this judgment, I'd say that the graphic simplicity and symmetry of a text label is being spoiled by the addition of an extraneous and assymetrical element. Suitcase does the same kind of reminder, and I wince every time I look at it. The right-column/left-column arrangement of a menu is inherently more capable of supporting this kind of thing than oval buttons are. As graphic elements, ovals demand bilateral symmetry, while rectangles can cope with a division into unequal columns. This approach to shortcuts would perhaps look better with rectangular buttons, but they'd have to be very close together vertically, and the shortcuts would have to be in a clear and distinct column. Shortcuts are for power users, and power users are likely to look in the on-line documentation for a shortcuts section, while non-power-users are likely to ignore even the most obvious shortcuts. This being the case, it's all right to have a single clear hidden rule for all shortcuts rather than a constant reminder of a diverse set of variously-chosen shortcuts. My favorite way to do button shortcuts is still what I did in TOPS Terminal. Outlined buttons take return or enter. Cancel buttons take Cmd-Period or Escape. All other buttons are unique in their first letter and take Cmd-Shift-first-letter. People did in fact use these shortcuts and find them convenient, and it's very little effort for the programmer to make sure that the buttons have unique first letters. >All in all, Paragon software has done some serious thinking about >their program's user interface and about the low-level Macintosh >interface, and I think they've made the right decisions. If the Human >Interface group isn't familiar with Nisus, they should definitely >check it out. I don't know. What you've said sounds like programmer-think rather than user-think or artist-think. There's a vast gap between these kinds of thinking, and learning to think like a non-programmer is the most basic skill of friendly user interface design. (Though I haven't examined Nisus, I have also heard that the interface has one of the main problems with all Mac word processors I've used [MacWrite, Word, FullWrite] -- meaningless graphics littering the screen, each of which has some secret meaning which, once you've read the manual, you can figure out and perhaps remember a few hours later, but which is not at all suggested by the graphic itself. Better just to use text than to use an arbitrary graphic.) -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "Skip, witches! Hop, toads! Take your pleasure!" -- Aleister Crowley, THE BOOK OF LIES
d88-jwa@nada.kth.se (Jon Watte) (03/08/90)
In article <10672@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >In article <1831@esquire.UUCP> baumgart@esquire.dpw.com (Steve Baumgarten) >writes: >>Specifically, people tend to want to cut and paste in dialog boxes and >>are continually surprised and annoyed when they can't. Even if it's >I regard this as a bug. If people are going to use ModalDialog with >This is one of the most common bugs on the Mac, unfortunately, and it >even crops up in Apple programs like HyperCard. (Try pasting the name So how about EXTENDING THE SELECTION WITH THE ARROW KEYS & SHIFT !? Apple programs don't do this, Word & THINK do it, and I tend to prefer the latter. I get really annoyed when trying to do it in HyperCard (which is my main base of work) and it doesn't. And guess why I use THINK C instead of MPW... h+ -- --- Stay alert ! - Trust no one ! - Keep your laser handy ! --- h+@nada.kth.se == h+@proxxi.se == Jon Watte longer .sig available on request
baumgart@esquire.dpw.com (Steve Baumgarten) (03/08/90)
In article <10672@hoptoad.uucp>, tim@hoptoad (Tim Maroney) writes: >In article <1831@esquire.UUCP> baumgart@esquire.dpw.com (Steve Baumgarten) >writes: >>Specifically, people tend to want to cut and paste in dialog boxes and >>are continually surprised and annoyed when they can't. Even if it's >>the kludgy Hypercard script editor solution of supporting the keys and >>not the Edit menu, anything would be better than forcing people to >>type things when they shouldn't have to. > >I regard this as a bug. If people are going to use ModalDialog with >editable text items, they *must* use a filterProc that allows the >standard edit menu commands; if they don't, their software is broken. Sure, but I think programmers just regard this as one of Apple's friendly tips, like never having commands that can only be accessed from the keyboard. Certainly Microsoft has never taken many of Apple's human interface suggestions, and I can only think of two or three other applications that I own that properly support cut and paste in modal dialogs. Just out of curiosity, does MacApp provide support for this? >>Nisus solves this problem very, well, nicely. It *always* keeps the >>Edit menu enabled, so that you can cut and paste anywhere, even in >>modal and StdFile boxes. I find myself reaching selecting parts of >>names in other programs' StdFile boxes and trying to use CMD-X and >>CMD-V, and I'm always frustrated when I can't perform this most basic >>of Macintosh functions. Best of all, since Nisus allows you to choose >>cut and paste from the Edit menu, this feature is available to novices >>as well as experts. > >I don't really think so. I've never observed a novice even *try* to >pull down a menu when a modal dialog is up. It seems obvious to them >that it wouldn't work. Of course, since the Edit item is always dimmed. But in Nisus the Edit item is enabled, so you're encouraged to take a peek and see what's there. You could say something similar about many communication programs -- most don't allow you to use desk accessories under Finder while downloading. In most cases you're presented with a (possibly) movable, but modal dialog and all menu items are dimmed. But Versaterm keeps the Apple item enabled, so even if you didn't know you *could* use desk accessories, you're given a strong reason to think that the computer won't beep at you if you try. > So, the only people who would benefit from the >feature are people who are at least semi-experts, people who read that >part of the manual. But these are people who probably always use the >edit menu shortcuts anyway. Again, something similar could be said about the trick that Multifinder pulls when you double-click on a file the application for which is already running. My roommate (a computer novice) knows all about the File menu and the "Open" choice to work on a different file, but he never considered using it after he found that he could double-click on a file in the Finder layer. I neither showed him that nor suggested it could be done. The funny thing was, he wasn't surprised when it worked. To him it seemed a perfectly natural extension of his standard Finder skills. But I remember the first time I did this using THINK C -- I was surprised that it worked! I'm so used to using "Open" that my brain lagged behind my fingers. So I think cutting and pasting in dialogs is much the same thing. People who don't know better try it (at least once), and if they're not beeped at will continue trying it. But since most Mac applications don't support Edit items in dialogs, novices are immediately discouraged from further experimentation in other programs. >>So if there's any way to add support for Edit menu items in modal (and >>non-modal) dialog boxes, I urge the Human Interface group to consider >>it. It's easy to forget that new users don't know what we veterans >>have known for a while -- that some things "aren't allowed", but for >>no justifiable reason (apart from programming, which is never a valid >>reason when you're trying to explain to your mother why the skills she >>just used in her MacWrite document suddenly cause the computer to >>beep). > >Technically, it's not at all hard to intercept and handle clicks in >the menu bar from a modal dialog filter proc. The question is whether >the effort involved is worth it. Since it doesn't reduce the program's functionality, nor interfere with its use by experts, I'd say it is worth it. It wouldn't be a question, though, if each application didn't have to support cut and paste itself, in its own idiosyncratic way. >>By the way, Nisus also handles the issue of command-key equivalents in >>dialog boxes with equal aplomb. Instead of forcing you to wade >>through a manual as Word does, Nisus displays the "cloverleaf-letter" >>combinations right next to the buttons as soon as you press the >>command key. So a novice can use the dialog boxes in the traditional >>point-and-click way, a more experienced user is given reinforcement to >>aid his memory, or is just allowed to consider the possibility of >>using command keys without having to haul out the manual, and an >>expert is not slowed down in the least. > >Ooh, I hate those. Talk about some ugly buttons. Yeah, the reminder >is nice from a psychological perspective, but the appearance of the >shortcuts themselves is nasty from an aesthetic perspective, at least >to me. If pressed to justify this judgment, I'd say that the graphic >simplicity and symmetry of a text label is being spoiled by the >addition of an extraneous and assymetrical element. Suitcase does the >same kind of reminder, and I wince every time I look at it. I think you misunderstand. I agree with you about the way Suitcase does things, but this is different than Nisus' implementation. In Nisus, the dialog box looks like any other dialog box on the Mac -- just buttons, one of which is highlighted, but nothing more. However, when you press the command key -- and only when you press the command key -- the shortcuts are displayed next to the buttons, outside of their outlines (i.e., the buttons themselves do not change in any way; instead, some text appears to the left of the buttons that have shortcuts). So from an aesthetic point of view the look of the dialog box is never spoiled or cluttered. But when the person decides that he wants to try out a shortcut (let's say he knows that most buttons have shortcuts but can't remember what they are), he can tentatively press the command key. The shortcuts are displayed for as long as he holds the key down; if he then releases the command key without choosing a shortcut, the dialog box returns to its original state: buttons only, without shortcut labels. This really seems to be the best of all possible worlds, since as with cut and paste in dialogs it provides a great deal of help to novices but doesn't slow down experts. >Shortcuts are for power users, and power users are likely to look in >the on-line documentation for a shortcuts section, while >non-power-users are likely to ignore even the most obvious shortcuts. >This being the case, it's all right to have a single clear hidden rule >for all shortcuts rather than a constant reminder of a diverse set of >variously-chosen shortcuts. My favorite way to do button shortcuts is >still what I did in TOPS Terminal. Outlined buttons take return or >enter. Cancel buttons take Cmd-Period or Escape. All other buttons >are unique in their first letter and take Cmd-Shift-first-letter. >People did in fact use these shortcuts and find them convenient, and >it's very little effort for the programmer to make sure that the >buttons have unique first letters. Sometimes that's not possible though, and I don't think it's so great to have some shortcuts use command while others use command-shift. However, it is good that you went to some extra effort to provide command keys at all; many applications don't. But it would be so much better if Apple support this kind of thing at a lower level. They do for menus, so I don't think it's out of line to ask for additional support for dialog boxes, especially if it can be done as unobtrusively and intuitively as it is in Nisus. >(Though I haven't examined Nisus, I have also heard that the interface >has one of the main problems with all Mac word processors I've used >[MacWrite, Word, FullWrite] -- meaningless graphics littering the >screen, each of which has some secret meaning which, once you've read >the manual, you can figure out and perhaps remember a few hours later, >but which is not at all suggested by the graphic itself. Better just >to use text than to use an arbitrary graphic.) [ As an aside, I remember people saying just this about the Finder when the Mac was first introduced. But I digress... ] Sure, this is one of its failings. To its credit, however, all those commands are accessible from the menubar, so even if you can't remember what an icon means you can still make use of the function. In a sense it would have been better to make that a setting that by default would be disabled; once people get used to the program, they can then take advantage of the speed using icons provides. But when they're first learning it they won't be overwhelmed with inscrutable or ambiguous pictures. Nisus is far from perfect, but compared to many Mac applications it goes a lot further to make things easier for novices. Here's an anecdote that helps describe what the competition is like: In the most recent Macworld (or possibly MacUser), there's a question in the help section about how to get Word to display all the installed fonts. Incredible how confused people get by this. The answer discussed using the bizarro option-+ (or whatever) combination to repeated click on a font to add it to the menu, but then went on to say something like "But you can add all the fonts in one step -- *if* you know about the 'list all fonts' command." It was the "if you know" part that really got me, because the command is only accessible from the dialog box that lets you fool with your menus. And that dialog is as confusing as any I've ever seen. Anyway, I don't want this to turn into a "mine is better than yours" flame fest; I just wanted to clarify why I think Apple should consider changing the standard Mac dialog interface, in addition to clearing up a misconception or two about Nisus. -- Steve Baumgarten | "New York... when civilization falls apart, Davis Polk & Wardwell | remember, we were way ahead of you." baumgart@esquire.dpw.com | cmcl2!esquire!baumgart | - David Letterman
6600pete@ucsbuxa.ucsb.edu (GurgleKat [Pete Gontier]) (03/09/90)
From article <10672@hoptoad.uucp>, by tim@hoptoad.uucp (Tim Maroney): > In article <1831@esquire.UUCP> baumgart@esquire.dpw.com (Steve Baumgarten) > writes: > > Technically, it's not at all hard to intercept and handle clicks in > the menu bar from a modal dialog filter proc. The question is whether > the effort involved is worth it. Especially from an INIT's perspective, which I believe had something to do with the context of this thread. >>By the way, Nisus also handles the issue of command-key equivalents in >>dialog boxes with equal aplomb. Instead of forcing you to wade >>through a manual as Word does, Nisus displays the "cloverleaf-letter" >>combinations right next to the buttons as soon as you press the >>command key. > Ooh, I hate those. Talk about some ugly buttons. Yeah, the reminder > is nice from a psychological perspective, but the appearance of the > shortcuts themselves is nasty from an aesthetic perspective, at least > to me. Here's what Andrew Welch had to say about it on America Online: --- snip snip --- Date: 90-03-08 08:00:42 EST From: AndrewWelc Subj: Re: more Dialog Power To: GurgleKat Well, it is a good idea, but dialog power already does the equivalent -- just in a different way. The problem with the way Nissus does it is that most people don't design their dialogs big enough to support the extra characters -- it would look really ugly. Andrew --- snip snip --- The "different way" he's referring to is the MS Windows // OS/2 PM way of providing command-key short-cuts in dialogs. You underline the letter of the item title for which there is a command-key short-cut. This is provided by 'Dialog Power', the logical extension of the 'Commander Dialog' series (and bits of 'Black Box' -- which was the start of this thread) which is in commercial beta right now. Of course, AW is talking about providing the Nisus method to existing programs, and I think he's right. It remains to be seen whether Nisus dialog command-key short-cuts are the way to go for new applications. -- Pete Gontier | InterNet: 6600pete@ucsbuxa.ucsb.edu, BitNet: 6600pete@ucsbuxa Editor, Macker | Online Macintosh Programming Journal; mail for subscription Hire this kid | Mac, DOS, C, Pascal, asm, excellent communication skills
grobbins@scott.cis.upenn.edu (Grobbins) (03/09/90)
In response to discussion of Nisus' user interface: In some respects, Nisus makes wonderful additions to the Mac user interface. In other respects, it's an ugly hack. But everything that's there is there for a reason. Nisus makes many extensions to the Mac interface which carry on Apple's recommendations to the nth degree. Virtually every editing action is undoable, in multiple stages. Rear windows are all active when the command key is down -- just as in the finder you can drag rear windows by holding down command, in Nisus you can drag, resize, scroll, click buttons, and select text in rear windows, without activating them, by holding down command. An option key modifier means "do to all" here and there in other applications; in Nisus, option-zoom zooms all windows (effectively tiling them), option-close closes all windows, and so on. While these are good extensions (IMHO) even these simple enhancements inevitably bring up problems: should cmd-Z twice be Undo Undo or Undo Redo? (Nisus does the latter, using shift-cmd-Z for the second and further Undos.) Should cmd-click in a rear window act like a click or a command-click (in cases where, in the front window, they would do different things)? As programmers realize, there is no such thing as a _simple_ enhancement. Other issues are clouded by history: should shift-arrow key extend the selection? Hardware snafus made that difficult, even though (as memory serves) Inside Mac recommended it from day one. Because Nisus supports simulated arrows (for pre-Mac Plus keyboards; cmd-space is right arrow, shift-cmd-space is select to the right) arrow key selections were not supported. Labeling buttons in dialogs was an easy win; once a programmer thought of the method (showing equivalents only when cmd was held down) it seemed obvious. Is being able to choose menus from modals a step forward or backwards? I think the latter, because modals should be obviously and completely separate, not "fuzzy" in modality. The programmer used menu selections from dialogs as a way of avoiding scrolling lists in QUED, and due to time and money pressures, the method stayed on in Nisus. While using scrolling lists would be a better method in most cases, there are some where it's not. For example, defining a user text style already takes up a long, complex dialog. Adding lists of font names, sizes, and so on to the dialog only makes it more intimidating. Letting the user select the items from the menus is an easy out, in that situation. While menus during modals started out as a hack, and stayed in because of outside pressures, in the end other arguments keep it alive -- orthogonality (consistency) and overall simplicity. Why are meaningless icons omnipresent in Nisus? Two reasons: no one has suggested more meaningful icons, and users don't want to do without the convenience of having certain controls (like page preview activation) handy. As mentioned before, nearly all icon controls are duplicated in the menus. (Not just because it's the proper Mac way to do things, but also because it made implementing macros easier.) Again IMHO, Nisus has serious user interface problems remaining. (FullWrite is much better thought out.) But it also has some great ideas, worth standardizing. And anyone who can pick up MacWrite without reading the manual would be able to use 85% of Nisus without training. Grobbins grobbins@eniac.seas.upenn.edu (occasional design consultant on Nisus, years ago; no current affiliation with Paragon Concepts, except as a nagging user.)
lsr@Apple.COM (Larry Rosenstein) (03/09/90)
In article <10672@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes: > I don't really think so. I've never observed a novice even *try* to > pull down a menu when a modal dialog is up. It seems obvious to them > that it wouldn't work. So, the only people who would benefit from the > feature are people who are at least semi-experts, people who read that If that's true, then I don't know what you could do to make this feature obvious. It seems that you would have to put individual buttons into the dialog for Cut, etc., or have some kind of popup Edit menu in the dialog. It isn't clear to me, however, that these are better alternatives to just making the standard Edit menu available. Perhaps novice users would have to learn about the new feature the first time, but since it isn't a new concept, it wouldn't be much of a burden. Graying out the unavailable menus is a good idea in general. (MacApp does this automatically if none of the menu items are enabled.) Then in modal dialogs where you couldn't hack in the standard Edit menu, you could gray out all the menus, and the concept would still be consistent. Larry Rosenstein, Apple Computer, Inc. Object Specialist Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1
lsr@Apple.COM (Larry Rosenstein) (03/09/90)
In article <1838@esquire.UUCP> baumgart@esquire.dpw.com (Steve Baumgarten) writes: > Just out of curiosity, does MacApp provide support for this? I don't think that MacApp makes the edit commands available in all dialogs. If you use MacApp 2.0's dialog support, then users can pull down menus while a modal dialog is up (and of course use the command-key equivalents). This is easy to do because the window is implemented like a normal window; not using the Dialog Manager. Most commands end up grayed out (and if all the items in a menu are disabled the menu title is disabled). Specific menu items will be enabled based on what's appropriate to the dialog. If there is no selection, for example, then Cut & Copy will be disabled. (This is the standard MacApp technique.) As an example of what you can do, I wrote an application that displays a modeal about box. The about box displays a picture which the user can scroll through, and the picture can be printed by using the normal print menu commands. I didn't have to do anything special except make sure that the picture view was printable. I once did a patch to ModalDialog that inserted a custom filter proc in every modal dialog. I did this originally to solve the problem that when a modal dialog comes up, the old front window doesn't get a deactivate event. (That's because the event goes to the Dialog Manager, which doesn't know what to do with it.) The effect is that the old front window won't disable its scroll bars. Also, the application will get an activate event when the modal dialog goes away, so you have to be careful about using XOR highlighting. The same basic technique could be used pass command keys through the application's normal event processing code, as a way of making the edit command keys available. Larry Rosenstein, Apple Computer, Inc. Object Specialist Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1
lippin@ronzoni.berkeley.edu (The Apathist) (03/09/90)
Recently lsr@Apple.COM (Larry Rosenstein) wrote: >Graying out the unavailable menus is a good idea in general. (MacApp does >this automatically if none of the menu items are enabled.) Then in modal >dialogs where you couldn't hack in the standard Edit menu, you could gray >out all the menus, and the concept would still be consistent. The concept would still be consistent within your program, but there's still the problem that most other programs would leave menus looking active during modal dialogs, so experienced users won't try them. Does MacApp gray out menus during modal dialogs? Including standard file and the print manager dialogs? But maybe we can all get together on this, and gray out the menus *all* the times they're not available. Maybe even get MultiFinder to gray out it's icon when you can't switch to another application. Add a little more consistency to the user interface. A Human Interface Note might help get this rolling. [As long as I'm griping, why aren't there outlines around the default buttons in standard file?] --Tom Lippincott lippin@math.berkeley.edu "I enjoy working with humans, and have stimulating relationships with them." --HAL
kazim@Apple.COM (Alex Kazim) (03/09/90)
If you're bored, there's a really sick hack to get menus to work with Modal Dialog. ModalDailog will call ErrorSound() on a mouseclick outside the window. So, make your own ErrorSound proc, and check the mousedown in the menubar, call MenuSelect, etc. Not for the weak of heart. ==================================================================== Alex Kazim, Apple Computer "Sometimes you just gotta break the rules" -- Burger King ====================================================================
tim@hoptoad.uucp (Tim Maroney) (03/09/90)
In article <1831@esquire.UUCP> baumgart@esquire.dpw.com (Steve Baumgarten) writes: >>By the way, Nisus also handles the issue of command-key equivalents in >>dialog boxes with equal aplomb. Instead of forcing you to wade >>through a manual as Word does, Nisus displays the "cloverleaf-letter" >>combinations right next to the buttons as soon as you press the >>command key. In article <10672@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >Ooh, I hate those. Talk about some ugly buttons. Yeah, the reminder >is nice from a psychological perspective, but the appearance of the >shortcuts themselves is nasty from an aesthetic perspective, at least >to me. I apologize for my egregious misreading. I completely missed the phrase "as soon as you press the command key" (in the original, it was not at the end of a paragraph the way it is here). My aesthetic concerns do not apply at all to the actual system Steve described. However, a whole bunch of new psychological criticisms apply. If you do it this way, then you lose the virtue of a shortcut reminder. Basically, what you're saying is that if you already know about hidden features of the program, like holding down the command key to display shortcuts, then you can find out what the shortcuts are. So, if you already know about shortcuts, then you can find out about shortcuts. This doesn't seem all that useful to experts *or* novices. It also seems as if it could be distracting, if not frightening, to have something change on the screen as soon as you get ready to do something like Command-X to cut, which normally doesn't do anything until you actually hit the X. Non-gearheads are easily intimidated when programs exhibit unexpected behavior, especially when just about to perform a dangerous operation. Finally, except for Command-Period, I don't believe that dialog shortcuts should use just the Command key unless there are no overlaps with the menu shortcuts, which seems unlikely. If the Nisus shortcuts are Command-Shift shortcuts, there's little chance of modally-created confusion, but it's not clear how you display a Shift key to the user. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "I am convinced that cross-posting is an evil Satanic plot." -- Eugene Miya on soc.net-people, misc.headlines, misc.kids, misc.misc, news.misc, and soc.misc
gdavis@primate.wisc.edu (Gary Davis) (03/10/90)
From article <21518@netnews.upenn.edu>, by grobbins@scott.cis.upenn.edu (Grobbins): > > Nisus makes many extensions to the Mac interface which carry on Apple's > recommendations to the nth degree. Virtually every editing action is > undoable, in multiple stages. Rear windows are all active when the > command key is down -- just as in the finder you can drag rear windows > by holding down command, in Nisus you can drag, resize, scroll, click > buttons, and select text in rear windows, without activating them, by > holding down command. An option key modifier means "do to all" here > and there in other applications; in Nisus, option-zoom zooms all > windows (effectively tiling them), option-close closes all windows, and > so on. > These general meanings for the option and command keys are extended even further. Forinstance, the option key in conjunction with movement in text causes the movement to occur by word rather than by character. In other words, carry out the movement on all characters of the word. The command key permits movement without change in text, conceptually similar to it use as a way to work in windows without activating them. For instance, command-return moves the cursor to the beginning of the next paragraph. All these uses of the modifier keys are orthogonal. Command- shift-option-backspace, for instance, selects the word to the left of the cursor. A somewhat convoluted example, but it follows a simple rule. In contrast to Nisus, many other word processors seem to use rather arbitrary key commands for things like move forward one word. > shift-cmd-space is select to the right) arrow key selections were not > supported. > Actually they are supported in Nisus as I mentioned above. > Is being able to choose menus from modals a step forward or backwards? > I think the latter, because modals should be obviously and completely > separate, not "fuzzy" in modality. The programmer used menu selections > I don't find it fuzzy at all. There are always certain things which can be done in modals and certain things which cannot in any program. Nisus makes it clear what is available in modal dialogs by graying out unavailable menu selections. > > Again IMHO, Nisus has serious user interface problems remaining. > (FullWrite is much better thought out.) But it also has some great ideas, One of my first big disappointments with FullWrite, a program I really wanted to like, was its interface, which I didn't find nearly as nice as had been touted. Maybe it's a matter of personal preference, but I immediately fell in loce with the Nisus interface, though I can certainly agree that it's not perfect. The lack of a completely WYSIWYG text display is one place where it's inferior to FullWrite, but it's also probably one reason why it blows FullWrite away in performance. Let me just give one more example of the nice generality and orthogonality of Nisus. As in FullWrite its possible to search and replace on character attributes, font size, style and so forth (actually Nisus is quite a bit more powerful in this regard). In Nisus, the indicate a character attribute in the Find dialog, you simply select the text in the dialog and apply the attribute from the standard text menus. In FullWrite, you have to go through a separate set of menus. You can even use the standard menu to set text attributes in the macro editor. Well, let me give another example ( I do get carried away with Nisus). Most windows work in pretty much the same way. That is, you can edit text in the clipboard window and even draw graphics. The file catalog is just a read only text window which you can search and copy things from. You can paste a character graphic in the find dialog and and search for it or for the graphic and any character combination (It only goes by the bounding rect in searching for graphics, but this ability still can be useful). Gary Davis
lsr@Apple.COM (Larry Rosenstein) (03/10/90)
In article <1990Mar9.004439.5462@agate.berkeley.edu> lippin@ronzoni.berkeley.edu (The Apathist) writes: > The concept would still be consistent within your program, but there's > still the problem that most other programs would leave menus looking > active during modal dialogs, so experienced users won't try them. Correct, since you would be changing the way things work. It's possible that the system could disable the entire menu bar without breaking existing applications. > Does MacApp gray out menus during modal dialogs? Including standard > file and the print manager dialogs? No. > But maybe we can all get together on this, and gray out the menus > *all* the times they're not available. Maybe even get MultiFinder to > gray out it's icon when you can't switch to another application. All good ideas. Send them to MacInterface@AppleLink.Apple.COM. Larry Rosenstein, Apple Computer, Inc. Object Specialist Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1
ts@cup.portal.com (Tim W Smith) (03/10/90)
< If you're bored, there's a really sick hack to get menus to work with < Modal Dialog. ModalDailog will call ErrorSound() on a mouseclick < outside the window. So, make your own ErrorSound proc, and check the < mousedown in the menubar, call MenuSelect, etc. < < Not for the weak of heart. < < ==================================================================== < Alex Kazim, Apple Computer Isn't it easier to just call FindWindow from the filter proc and then call MenuSelect, etc., if FindWindow says the click was in the menu bar? And this has the advantage of not requiring a strong heart... Tim Smith