potts@itl.itd.umich.edu (Paul Potts) (05/25/91)
Ashwin Ram (ashwin@cc.gatech.edu) writes: >why not allow me to point to what I want help on and hit the HELP key on my keyboard? >(It is also pretty counter-intuitive to have a help key on your keyboard that doesn't do anything.) Well, for one thing, only a relatively small portion of Mac users have extended keyboards. Plus users, LC users, and other Mac users who didn't buy extended keyboards lose out. Maybe you could have the help key turn balloon help on or off - but Apple has indicated that the extra keys on your extended keyboard are pretty much for the application to define, not the system. Intercepting the HELP key might mess up terminal packages that support the help key for another purpose. >the balloon help icon on the menu bar could easily be replaced by a "Help" item in the Apple Menu. Well, maybe. The reason for the help menu (read IM-6) is not just to turn balloon help on and off, but to provide a standard place for your appplication to attach help menu items of its own. Separating it out also helps to ensure compatibilty with applications that control their own dimming of menus when modal dialogs are up. >Another nice feature would be to have a "documentation" button in the balloons which you could click to get to the appropriate section of the manual for full documentation. I agree. Balloon help is really designed to be a sort of bare minimum level of help support. Applications should put their online documentation, glossaries, etc. in the help menu. Then you could bring these up even with a modal dialog active. Putting a button within a balloon, though, would totally destroy the interface. Balloons could include a reference to part of the manual. Or they could automatically bring up the appropriate part of the on-line help. They are very extensible. >instead of having all possible Balloons popping up as I move my mouse, why not allow me to point to what I want help on and hit the HELP key on my keyboard? I agree that the constant balloon animation can be a bit painful. I also agree that it ought to be possible to turn the help item off altogether. I think that people are taking the particular example of balloon help as it is implemented in the Finder (minimally) and extrapolating from this to make assumptions about how help systems in general will work. Your application can override the balloon help on standard system objects (like windows) and can implement any sort of additional help system that it wants. You don't need to support balloon help at all, although it would be impolite for your application not to allow the system to give help on the system elements while you are running in the foreground. If there is anything that I've learned from working with Macs and teaching other users to work with Macs, it is that the same consistent and standard interface elements that experts complain about, novices love. For example, when I first saw Word 4.0, it took me some time to figure out the bizarre popup menu in the ruler. Now Apple has released a standard popup menu definition, so developers will be less prone to implement popup menus each in their own way. It is easier to use the supported and standard tools, both on developers and on users. Give the developers a chance and see what other companies do with the new help manager. If you're interested in the possibilities, check out IM-6. It is interesting to read even for non-developers. In another message, you write: >Can someone explain why this doesn't happen under system 7? Have I configured my upgrade wrong, or is there some reason that printing, copying and formatting are different from all other types of tasks? (Seems weird if that is so... regular multitasking machines (e.g., Unix machines) run these as standard processes that respond to standard job control operations.) I am typing this while a file copy is going on in the background. when you do a file copy, System 7 figures out whether it will have enough CPU power left to manage its other tasks. If it will, the copy progress indicator is not modal (that is, you can switch something else into the foreground). If it isn't, the watch cursor stays up and you have to wait. It probably varies by CPU type and by the type of task you are doing. For example, on my IIcx at work I can do a floppy disk copy in the background, but doing something from a file server over the network won't let me put it in the background. Printing runs in the background if you are printing to a driver that supports background printing. When I print to a LaserWriter, the contents of my print job get spooled to the hard disk, then control returns. A background program called Print Monitor handles the print job while I work on something else. For other printers, it depends on the driver. There are third-party products that will do spooling of the output from other drivers. My roommate uses SuperLaserSpool with a DeskWriter. I think I read somewhere that output to a StyleWriter can be spooled, but I'm not certain of that. One of the pieces of the original system 7 pre-announcement was an improved print architecture. This piece was left out of the first release of system 7, because the developers realized they had enough work on their hands to get out the revisions they did make (and probably also because they wanted to give users and developers time to catch up on compatibility without drowning them in changes). I think print spooling is supposed to be part of the revised print architecture. Sorry if it sounds like I'm lecturing. I'm a developer, although a small-time developer, and I am simply amazed at what Apple is doing with their system software. The amount of work that must have gone into 7.0 and the QuickTime extensions is staggering. I've been reading IM-6 bit by bit (at this rate, I ought to finish it by - oh, say, November...) and am constantly impressed by the foresight and vision that went into the new system. It is easy to say "Oh, I would have done that differently," but then, I've never been involved with a piece of software of anywhere near the complexity of system 7, and suspect not many of us have. If you've got a well-reasoned suggestion for an improvement to the interface, send it to the human interface folks. The address is in the latest release of Human Interface notes, I believe. I sent them a bunch of suggestions some months ago. I didn't hear back, but one must have faith... cheers, -Paul- potts@itl.itd.umich.edu