craig@unicus.UUCP (Craig D. Hubley) (06/21/87)
UNICUS is writing a telecommunications product for the Mac (I apologize for the occasional product specific, but it may help to understand what follows). What I need is feedback on what Mac users want in their software and where the Mac user interface definition is going with the new software and machines, so that we can keep our product friendly and Mac-consistent. Several dialog boxes that support very intensive user configuration are being designed. Naturally, there are many many commands with several different scopes and the potential for great confusion, particularly when operations do slightly different things depending on what you've selected. Since submenus and pop-up menus are now supported on the Mac, we have relied heavily on the former to help reduce the complexity of the user view. But submenus, and where they fit in the Mac UI definition (the user interface guidelines in IM) are quite clear. Pop-up menus are less clear. Currently, the software we have seen has used pop-up menus simply to provide an easy means of filling in fields in a form. That is, one clicks on the type of thing, and the list of things of that type appears and can be selected from. No action occurs as a consequence save filling the field. We have seen no Mac application do anything else with this capability. One of our ideas to reduce complexity was to display all of the current set of capabilities in a dialog box/window/whatever, and selecting one brought up a list of things you could do with it: Remove it, rename it, whatever. This would avoid creating a large cramped dialog box with a dozen buttons. Since the capabilities are heavily interdependent, I do not want to separate them up by type, else you lose the view of the set as a whole, its "gestalt". This would imply that pop-ups could be used to invoke commands, similar to Smalltalk, Xerox Lispmachines, and object-oriented systems in general. These systems command their components by sending messages in a common protocol, varied somewhat (method-specialized) for each subclass of the base classes. So these are the pros: - We can avoid displaying the complete and intimidating command set. - We avoid scope confusion, since no operation can be selected for a given "object" where the operation is invalid. - We now have the capability to expand the name of each command for each type so that the user clicks on "Rename this thing" rather than selecting the thing and clicking "Rename"... the system is thus capable of telling you WHAT you are doing, not WHAT KIND OF THING you are doing. Particularly useful with naive users. - We gain much space in the dialog boxes proper, to use for comment fields, help strings, and other aids to the user. - We are more consistent, in general, with an object-oriented metaphor which will aid us conceptually, let us use basic research results more effectively, and make the program more consistent across machines when we port it. And these are the cons: - Submenus and popups haven't been seen or used by many Mac users. - We risk diverging from the IM path (or worse, the MacWorld path :-)) in using such capabilities before they are used in the system software and their purpose clearly defined in IM. - The capabilities themselves may have been implemented with bugs. Anything that readers of comp.sys.mac can add to either of these lists will be appreciated. Particularly, I would like to hear from someone inside Apple about where the IM guidelines, and the Mac environment in general, are heading. If something anyone has to say is of general interest, please post it generally, since these issues are a concern for all developers and users. After all, the more developers know about the intention of the guidelines, the better they can implement them. And the easier it will be for users. If anyone feels that this posting is commercial in nature, I apologize and will respond privately to flames. But totally abstract descriptions of problems tend to produce totally abstract solutions: several of them, to be weighed heavily by everyone. I would prefer to see real live opinions, based on a real live problem that has a sort of limited scope. I want to appeal to users and developers, not armchair speculators. So from Apple, developers, and users... what are these tools? What do you want them used for? What should we avoid? What's coming up next. If what I get is primarily mail, I will summarize and post. Please state in any such response roughly where in the Apple-developer-user spectrum you stand. It will make it much easier to figure out who thinks what. Anyone else confused about pop-ups?
oster@dewey.soe.berkeley.edu (David Phillip Oster) (06/22/87)
Pop-up menus are used in the macintosh system software, and have been
for some time. The one spot they occur is in the HFS
SFGetFile/SFPutFile dialogs, where a pop-up menu shows the user what
his current directory is, and what directories are available between
that one and the root. You should be able to use pop-up menus in a
program in an analagous manner and explain them by reminding users of
the standard file dialogs.
--- David Phillip Oster --My Good News: "I'm a perfectionist."
Arpa: oster@dewey.soe.berkeley.edu --My Bad News: "I don't charge by the hour."
Uucp: {seismo,decvax,...}!ucbvax!oster%dewey.soe.berkeley.edu