TJACOBS@cc.utah.edu (06/09/90)
Hierarchial Apple Menus - In System 7 they have made the Apple menu configurable by having a special folder in the system folder called the "Apple Menu Folder". You can put DA's, applications, folders, control panel objects, and aliases. If you alias a folder it opens up the folder upon select- ion. What I proposed to Apple is that the user be allowed to configure each folder that appears in the Apple Menu to appear either as a folder or as a hierarchial menu that pops out to show the contents of the folder. Just like HierDA/damenuz does. There are GOOD reasons for doing both. I would like to see my Apple Menu look like this: ----------------- About Macintosh | Set aside Finder | Set aside Others | ----------------- Finder | TelnetNCSA | Word | ----------------- ------------ Applications >>>>| Word | Controls > | Claris CAD | DA's > | Excel | Choose > | Filemaker | Quickmail | MacProject | Vantage | NCSAtelnet | MultiClip | Stuffit | General Controls | ----------- My Work Folder | ----------------- And not like this: About Macintosh Word Claris CAD Excel Filemaker MacProject NCSAtelnet Stuffit Virus Detective Finances DA QuickMail Run'R Vantage ATView MultiClip General Keyboard Mouse Startup Device ClockAdjust Keyboard Kolor MacEnvy Monitors Network SuperClock QuickKeys etc. etc. etc. Now I realize I can do the first without having the folders be hierarchial but it slows things considerably. I don't want to HAVE to wade through any more layers of user interface than I have to. Apple seems to have a definite bias against hierarchial menus and so do I for many things. I don't like any more levels of hierarchial menus than 2. They've done tests that show that menus in windows are not as fast as menus at the top of the screen. Perhaps they have done test relating to hierarchial menus too. IMHO, button pallets are faster than menus, menus are faster than dialogs, and hierarchial menus are faster than bringing up a dialog box and choosing a button. Now the issue of Hierarchial Apple Menus was brought up at the developers conference and the majority of people there boo-ed the subject along with a few cheering souls. Now I can understand that many people would not like this feature and would not use it. But why would anyone dissagree with the notion of allowing the user to choose which way he wants it done? Some will say it is confusing for new/novice users if some people do it one way and others do it another, but think about it, if you see a folder menu with a dark arrow at the end and one without it, can it really be that tought to figure out what the difference is? Now if a new user looks at the two menu examples above, which one do you think will look more confusing? It seems a simple matter to include a checkbox in the info window for folders to show as hierarchial menus in the Apple Menu. I solicit your comments on the matter. I would like to hear from those who favor this approach as well as those who don't. I plan on passing the resulting discussion on the the Human Interfaces group via Applelink. The Apple menu is becoming a control center for the whole Mac and I would like to be able to customize to my liking. Apples step of making it configurable is a great one, I just think they stopped short of making it faster and more organized. Tony Jacobs Center for Engineering Design University of Utah
chuq@Apple.COM (That's MR. Idiot to you) (06/09/90)
TJACOBS@cc.utah.edu writes: >Apple seems to have a definite bias against hierarchial menus and so do I for >many things. Hierarchical menus are the spawn of Satan. They are evil, nasty, ugly things that are hard to control and lead to non-intuitive clutter. There ARE times when they're useful -- usually when the alternatives (menus that scroll off the screen on a 9" monitor) are worse. >It seems a simple matter to include a checkbox in the info window for folders >to show as hierarchial menus in the Apple Menu. NO CHECKBOXES! Ugh! Ack! Bad Interface Karma! I think it's important for the Mac Interface Cops to keep the purity of the interface going. On the other hand, I don't always agree with them. Hiermenus are ugly. Sometimes they're an ugly necessity. the new System 7 Apple menu is a place where I think they're wrong. Hiermenus are ugly. The Apple menu shouldn't -- by default -- support them. But by refusing to support them in any manner I think they're being both overly strict and short-sighted. The little I've played with 7.0 my Apple menu is already going crazy. I *need* hiermenus. There's a way everyone can win, without checkboxes or bad interface Karma. The Apple menu can be made to support Hiermenus *if the user chooses to use them* -- with the default being off, since hiermenus drive naive users crazy (and some of us non-naive users, too). You don't turn them on with a silly checkbox somewhere, though. You turn them on by creating a sub-folder in the apple folder and sticking stuff in it. The name of the sub-folder is the menu-item that roots the hierarchical menu, and the stuff in the folder is on the menu. Then you make sure you only allow one level of hierarchical menu to keep people honest. Best of both worlds -- people get hiermenus when they want them and can avoid them if they don't. And it's not some magic cookie hidden in a CDEV that turns it on, it's a nice, intuitive action that fits in to the current interface. -- Chuq Von Rospach <+> chuq@apple.com <+> [This is myself speaking] Wherefore could I not pronounce 'Amen'? I had most need of blessing, and 'Amen' stuck in my throat. --Macbeth
philip@Pescadero.Stanford.EDU (Philip Machanick) (06/10/90)
In article <68207@cc.utah.edu>, TJACOBS@cc.utah.edu writes: > Hierarchial Apple Menus - In System 7 they have made the Apple menu > configurable by having a special folder in the system folder called the > "Apple Menu Folder". You can put DA's, applications, folders, control panel > objects, and aliases. If you alias a folder it opens up the folder upon select- > ion. > > What I proposed to Apple is that the user be allowed to configure each folder > that appears in the Apple Menu to appear either as a folder or as a hierarchial > menu that pops out to show the contents of the folder. Just like HierDA/damenuz > does. There are GOOD reasons for doing both. > > I would like to see my Apple Menu look like this: > > ----------------- > About Macintosh | > Set aside Finder | > Set aside Others | > ----------------- > Finder | > TelnetNCSA | > Word | > ----------------- ------------ > Applications >>>>| Word | > Controls > | Claris CAD | > DA's > | Excel | > Choose > | Filemaker | > Quickmail | MacProject | > Vantage | NCSAtelnet | > MultiClip | Stuffit | > General Controls | ----------- > My Work Folder | > ----------------- > > And not like this: > > About Macintosh > Word > Claris CAD > Excel [...] > etc. > etc. > etc. [...] > Apple seems to have a definite bias against hierarchial menus and so do I for > many things. I don't like any more levels of hierarchial menus than 2. [...] Hierarchical menus are USUALLY a mistake - the only thing worse is menus with more than the magic number 7 plus or minus 2 items. Mostly, too many/too long/ too hierarchical menus are a design mistake. But let's ignore that for purposes of this discussion (i.e., maybe the Apple menu mechanism needs to be rethought). > It seems a simple matter to include a checkbox in the info window for folders > to show as hierarchial menus in the Apple Menu. I disagree with this strategy - it somehow doesn't seem intuitive, and it requires yet another mechanism. My suggestion: another "Apple Menu Folder" inside the "Apple Menu Folder" indicates another level of hierarchy. Any folders inside this folder would be treated as hierarchical menu items. Then you could easily decide how many levels of hierarchy you wanted, and the menu would clearly reflect the organization of the disk. You could change the menu organization simply by moving things from one folder to another. No new mechanisms, just a simple generalization. Philip Machanick philip@pescadero.stanford.edu
dorner@pequod.cso.uiuc.edu (Steve Dorner) (06/11/90)
In article <41795@apple.Apple.COM> chuq@Apple.COM (That's MR. Idiot to you) writes: >NO CHECKBOXES! Ugh! Ack! Bad Interface Karma! I certainly hope the person who thought up the methods for rebuilding the desktop, getting bi-directional Fast quality Imagewriter II printing, and getting a PostScript file out of the Laserwriter driver will spend his or her next life as a gnat on a warthog's bum. [speaking of karma] >You don't turn them on with a silly checkbox somewhere, though. You turn >them on by creating a sub-folder in the apple folder and sticking stuff in >it. The name of the sub-folder is the menu-item that roots the hierarchical >menu, and the stuff in the folder is on the menu. Amen. This is exactly right. >Then you make sure you >only allow one level of hierarchical menu to keep people honest. What if I don't want to be honest? Why do you want to keep me that way? -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: {convex,uunet}!uiucuxc!dorner
jbr0@cbnews.att.com (joseph.a.brownlee) (06/11/90)
In article <68207@cc.utah.edu> TJACOBS@cc.utah.edu writes: >What I proposed to Apple is that the user be allowed to configure each folder >that appears in the Apple Menu to appear [...] as a hierarchial >menu that pops out to show the contents of the folder. I like this idea. I, too, have problems with hierarchical menus in many situations. However, in the case of the 7.0 Apple Menu, I would trade the "inconvenience" of the hierarchical menu for better organization. The best part is, I have the option to make that choice, while other who want a "flat" menu can opt for that. I would simply have it place any folders in the Apple Menu Folder in the menu as hierarchical choices, which allow the user to select one of the items in that folder. This would allow me to group things by type (applications, DAs, etc.), or perhaps functionally, or any other way that I might like. And, to top it all off, it would not even be terribly difficult to implement something like this. -- - _ Joe Brownlee, Analysts International Corp. @ AT&T Network Systems /_\ @ / ` 471 E Broad St, Suite 1610, Columbus, Ohio 43215 (614) 860-7461 / \ | \_, E-mail: jbr@cblph.att.com Who pays attention to what _I_ say? "Scotty, we need warp drive in 3 minutes or we're all dead!" --- James T. Kirk
chris@imagine.ADMS-RAD.Unisys.COM (Chris Sterritt) (06/12/90)
In article <41795@apple.Apple.COM> chuq@Apple.COM (That's MR. Idiot to you) writes: >The Apple menu can be made to support Hiermenus *if the user chooses to use >them* -- with the default being off, since hiermenus drive naive users >crazy (and some of us non-naive users, too). > >You don't turn them on with a silly checkbox somewhere, though. You turn >them on by creating a sub-folder in the apple folder and sticking stuff in >it. The name of the sub-folder is the menu-item that roots the hierarchical >menu, and the stuff in the folder is on the menu. Then you make sure you >only allow one level of hierarchical menu to keep people honest. HEAR HEAR! This is an excellent suggestion. I second this suggestion wholeheartedly, as will all right-thinking mac users :-) :-) :-). An added benefit is that extremely-frequently-used applications (etc.) don't *HAVE* to be at a lower level -- they can be at the top level. Then, less frequently used things can be at the second level. Good thinking! chris sterritt ============================================================================ = Chris Sterritt - "Kleenex makes my nose run" - chris@adms-rad.unisys.com = = "The secret is dirt. D-I-R-T. 'D' as in dirt, 'I' as in dirt, 'R' as in = = dirt, 'T' as in Orange Pekoe." -- Churchy LaFemme = ============================================================================
philip@Kermit.Stanford.EDU (Philip Machanick) (06/12/90)
In article <1990Jun11.140654.15033@ux1.cso.uiuc.edu>, dorner@pequod.cso.uiuc.edu (Steve Dorner) writes: > In article <41795@apple.Apple.COM> chuq@Apple.COM (That's MR. Idiot to you) writes: > >NO CHECKBOXES! Ugh! Ack! Bad Interface Karma! > > I certainly hope the person who thought up the methods for rebuilding the > desktop, getting bi-directional Fast quality Imagewriter II printing, and > getting a PostScript file out of the Laserwriter driver will spend his or > her next life as a gnat on a warthog's bum. [speaking of karma] Yes, not to mention the person who devised the technique for zapping the PRAM and the person who hid the feature for changing the parameters for the Mac IIci built-in video. System 7 is supposedly curing so many ills. For the sake of the warthog, I hope these are among them. Philip Machanick philip@pescadero.stanford.edu
lsr@Apple.COM (Larry Rosenstein) (06/12/90)
In article <68207@cc.utah.edu> TJACOBS@cc.utah.edu writes: > The Apple menu is becoming a control center for the whole Mac and I would If this was true, then adding hierarchical menus to the Apple menu would be the right idea. But I don't think this is true. The Apple menu isn't intended to be the Macintosh control center. That's the Finder's job. The Apple menu is a simply short cut for accessing a few icons. I agree that putting 40 things in the Apple menu isn't a good idea. But I don't think there is any reasonable way to access 40 items from a single menu. Fortunately, there are other mechanisms in System 7 for organizing one's hard disk (eg aliases), so that it should be easier to access icons than in previous systems. Larry Rosenstein, Apple Computer, Inc. Object Specialist Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1
chuq@Apple.COM (That's MR. Idiot to you) (06/12/90)
lsr@Apple.COM (Larry Rosenstein) writes: >In article <68207@cc.utah.edu> TJACOBS@cc.utah.edu writes: >> The Apple menu is becoming a control center for the whole Mac and I >would >If this was true, then adding hierarchical menus to the Apple menu would >be the right idea. But I don't think this is true. The Apple menu isn't >intended to be the Macintosh control center. On the other, other hand, intentions or not, I think it WILL be. AppMenu and OnCue (among others) whos that pretty clearly. -- Chuq Von Rospach <+> chuq@apple.com <+> [This is myself speaking] Wherefore could I not pronounce 'Amen'? I had most need of blessing, and 'Amen' stuck in my throat. --Macbeth
macman@wpi.wpi.edu (Chris Silverberg) (06/12/90)
LR> I agree that putting 40 things in the Apple menu isn't a good idea. LR> But I don't think there is any reasonable way to access 40 items LR> from a single menu. Fortunately, there are other mechanisms in LR> System 7 for organizing one's hard disk (eg aliases), so that it LR> should be easier to access icons than in previous systems. But... I didn't pick up your opinion of user constructed hierarchial menus (through putting folders within the Apple Menu folder). It seems that there has been a VERY positive response to this just based on what I've read.... Do YOU favor the idea? - Chris ._._._._._._._._._._._._._._._._._._.._._._._._._._._._._._._._._._._._._._. Chris Silverberg AOL: Silverberg Worcester Polytechnic Institute GEnie: C.Silverberg INTERNET: macman@wpi.wpi.edu SYSOP: Main Street U.S.A. BBS FIDONET: 322/575.1 508.832.7725 (1200/2400)
brendan@batserver.cs.uq.oz.au (Brendan Mahony) (06/12/90)
TJACOBS@cc.utah.edu writes: >Hierarchial Apple Menus - In System 7 they have made the Apple menu >configurable by having a special folder in the system folder called the >"Apple Menu Folder". You can put DA's, applications, folders, control panel >objects, and aliases. If you alias a folder it opens up the folder upon select- >ion. >What I proposed to Apple is that the user be allowed to configure each folder >that appears in the Apple Menu to appear either as a folder or as a hierarchial >menu that pops out to show the contents of the folder. Just like HierDA/damenuz >does. There are GOOD reasons for doing both. >I would like to see my Apple Menu look like this: >----------------- >About Macintosh | >Set aside Finder | >Set aside Others | >----------------- >Finder | >TelnetNCSA | >Word | >----------------- ------------ >Applications >>>>| Word | >Controls > | Claris CAD | >DA's > | Excel | >Choose > | Filemaker | >Quickmail | MacProject | >Vantage | NCSAtelnet | >MultiClip | Stuffit | >General Controls | ----------- >My Work Folder | >----------------- I use Suns all day long and the hierarchical menus are nice for ensuring things are easy to find, but I find it very difficult to control the selection mechaonism. I'm no quadraplegic so I reckon that these things are hard to control. The Mac already has an hierarchical menu structure, it reads left to right accross the top of the screen. Why not use it instead? Allow users to have more than one `constant' menu. The above menu hierarchy would then appear |AppleMenu |Applications |Controls |DA's |Choose | |-----------------| |About Macintosh | |Set aside Finder | |Set aside Others | |-----------------| |Finder | |TelnetNCSA | |Word | |-----------------| |Quickmail | |Vantage | |MultiClip | |General Controls | |My Work Folder | ----------------- Each of the menus could be constructed by placing a folder in the system folder. There are a lot of related issues that would need addressing such as aliasing and linking, rapid search for applications etc. -- Brendan Mahony | brendan@batserver.cs.uq.oz | Department of Computer Science | University of Queensland | Australia |
lsr@Apple.COM (Larry Rosenstein) (06/13/90)
In article <13407@wpi.wpi.edu> macman@wpi.wpi.edu (Chris Silverberg) writes: > has been a VERY positive response to this just based on what I've read.... No one ever said that user interface design should be done by popularity polls. There was lots of support for a hierarchical Apple menu on AppleLink as well, although I heard it was booed at the Developers Conference. > Do YOU favor the idea? I don't favor adding hierarchical menus to the Apple menu. I almost always cringe when I see a hierarchical menu. I find it interesting that many people began their arguments in favor of hierarchical menus by saying "Well, I don't like hierarchical menus, but in this case..." The current implementation is very simple to explain and understand, since there's a 1-1 mapping between items in the Apple Menu folder and items in the Apple menu. Selecting an item from the menu is equivalent to opening the icon. Adding hierarchical menus would complicate things. First, I think people wanted a choice for each folder of whether its item in the Apple menu included a hierarchical menu of its contents. So you need an additional mechanism to make this choice. Then there was the issue of limiting the number of levels, which makes it harder to explain to users. Right now the Apple menu corresponds to the contents of the folder. If you add one level of hierarchical menu then you are partially modelling the hierarchical folder structure. Regardless of how you organize the menu, the more items the system has to keep track of, the more time and space it will require. Some one suggested that selecting items from palette is faster than from a menu. In that case, opening an icon from a Finder window (in View by Name mode) should be faster than choosing the same item from a hierarchical menu. You can make the folder instantly appear by selecting it from the Apple menu, rather than hunting for it as you have to do today. This may take an additional step, but it may be just as fast, given the difficulty of selecting from hierarchical menus. (If it isn't fast to do this, then perhaps the Finder needs to be optimized for this kind of case.) I don't have a good rebuttal to the argument that the hierarchical Apple menu would just be an option for those who want it. For one thing, a lot of Macintoshes aren't used by a single person, so there's a good possibility that users will encounter it unexpectedly. I think the same argument could be applied to any user interface feature, but I wouldn't want to add every feature that someone comes up with, or that some other program has. It's usually a mistake to use the wrong tool for a job. I also think it's a bad idea to add more and more features to a tool in the hope that it can handle different jobs. The trend today is towards applications/utilities that do one job very well and that integrate with other applications. As I said before, I don't think you can turn the Apple menu into the central control center of the Macintosh. If there's a need for additional navigation features beyond what System 7 provides, then I think it's better to address that problem directly, rather than slap on hierarchical menus. -- Larry Rosenstein, Object Specialist Apple Computer, Inc. 20525 Mariani Ave, MS 77-A Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr
cory@three.MV.COM (Cory Kempf) (06/13/90)
TJACOBS@cc.utah.edu writes: >Hierarchial Apple Menus [...] Well, they torpedoed the idea on Applelink... maybe if a bit more heat were generated, we can convince Apple to listen, instead of forcing yet another INIT incompatability on us. Yes, in general, HeirMenus are bad. New users lack the mouse-eye coordination to use them. However, the Apple Menu warrents them as an option. For one reason, if Apple doesn't include it as part of the system release (when it would be a small change, the modification of an existing thing), someone will have to make it into an INIT, patching out and rebuilding the beaste from scratch. Something will break. Bet on it. But even that is not sufficient reason for apple to change (excuse me, FIX) the interface. The fact that opening a folder (in some location where my mouse probably is NOT) and making me double-click on an ICON from the folder (then making me close the folder) is MUCH SLOWER and MORE INTRUSIVE than heirarchical menus have ever been. But that too will probably not convince Apple. After all, the only people who would want such a feature are "Power Users" (isn't one of the ideas behind the Mac to help ALL users become power users? Didn't Apple have an Ad campaign with the slogan "The *POWER* to be your best?" implying that they were supplying features that those power users might want? Haven't several studies shown that Mac Users generally user about 6-12 different Applicaations? Don't most Mac users have several DA's in addition to their Applications?). Oh well. Lets see... patch out the AddResMenu command... have it special case for type 'DRVR' to find the Apple Menu Folder... list the file names (with the small icons -- hey, while we are at it, why don't we fix the lack of colour as well?)... check for folders... oops! Apple only allows 256 Heir/PopUp Menus... wonder what we will break? (we could always add a second patch)... Add in the Heir menus... create the menu resource... Now, about the other cases... +C -- Cory Kempf I do speak for the company (sometimes). Three Letter Company 603 883 2474 email: cory@three.mv.com, harvard!zinn!three!cory
bruner@sp15.csrd.uiuc.edu (John Bruner) (06/13/90)
What is the mechanism for putting all of this stuff in the Apple menu when an application creates its menus? I assume it is done automagically (similar to the way that Multifinder does it). If desk accessories are now just entries in the Apple Menu folder, then what is the effect of calling AddResMenu (in the old fashioned way)? Should applications do this (if only for backward compatibility) or will the practice be discouraged in System 7.0? -- John Bruner Center for Supercomputing R&D, University of Illinois bruner@csrd.uiuc.edu (217) 244-4476
rjohnson@seas.gwu.edu (Ray Johnson) (06/13/90)
This discusion on apple menu is rather interesting to me. First of all I am in favor of the idea. Curently I use the heir-da shareware product and DiskTop to produce something to the same effect but on a most restricted level. However, as an admistrator of a lab I understand that it is not a great idea to have so many options availible to users because they often know very little about the mac. So what do you do? I think the best way would be to have the ability to turn the option on or off using say ResEdit. This way novice users, and indeed users on the whole, would have a simple flat apple menu. On the other hand, power users that wish to rearange the system to thier liking have the ability to do so. -- Ray Johnson Internet: rjohnson@gwusun.gwu.edu Phone: (202)994-6853 The George Washington University
dave@PRC.Unisys.COM (David Lee Matuszek) (06/13/90)
In article <41795@apple.Apple.COM> chuq@Apple.COM (That's MR. Idiot to you) writes: [omitted stuff...] >Hiermenus are ugly. The Apple menu shouldn't -- by default -- support them. [omitted stuff...] >You don't turn them on with a silly checkbox somewhere, though. You turn >them on by creating a sub-folder in the apple folder and sticking stuff in >it. The name of the sub-folder is the menu-item that roots the hierarchical >menu, and the stuff in the folder is on the menu. Then you make sure you >only allow one level of hierarchical menu to keep people honest. [omitted stuff...] Generally I agree, but I suspect you haven't thought this through. Personally, I'd like to have hierarchical menus, and it would be great to have them automatically reconfigured every time I moved stuff in and out of folders, or renamed folders. But how do you "only allow one level of hierarchical menu"? Do you disallow folders from being nested more than one deep? Or if not, what do you do when they are more deeply nested? Your basic suggestion sounds very good. The test is whether a way can be found to make this work reasonably in *every* case and still convince the user that its behaviour is obvious and intuitive. It's easy to make an interface that behaves well in the most common cases; but to integrate all the aspects, and to have it behave intuitively through-and-through -- that's hard. As I say, the basic idea is a good one. I hope you are sufficiently supportive of it to try to work out the details, and -- if they can be worked out well -- to try to convince Apple to adopt it. -- Dave Matuszek (dave@prc.unisys.com) -- Unisys Corp. / Paoli Research Center / PO Box 517 / Paoli PA 19301 -- Any resemblance between my opinions and those of my employer is improbable. < You can put a mouse on an IBM. And you can put a radio on a motorcycle. >
lander@bulean.enet.dec.com (Vadim Lander) (06/14/90)
In article <14112@burdvax.PRC.Unisys.COM>, dave@PRC.Unisys.COM (David Lee Matuszek) writes... >In article <41795@apple.Apple.COM> chuq@Apple.COM (That's MR. Idiot to you) writes: > >>Hiermenus are ugly. The Apple menu shouldn't -- by default -- support them. Do you people think someone will come up with an init allowing sub-folders in the "Apple Menu Folder" to get hiermenus?
chuq@Apple.COM (That's MR. Idiot to you) (06/14/90)
dave@PRC.Unisys.COM (David Lee Matuszek) writes: >Generally I agree, but I suspect you haven't thought this through. I try. Probably I'm not perfect. >But how do you "only allow one level of hierarchical menu"? Do you >disallow folders from being nested more than one deep? Or if not, >what do you do when they are more deeply nested? The software ignores nested folders. If you think about it, that might be an advantage, because then you can easily disable stuff in the Apple menu by copying it into a folder in the same hierarchy, rather than sticking it off in a corner somewhere and then trying to remember where it should go to turn it back on. >As I say, the basic idea is a good one. I hope you are sufficiently >supportive of it to try to work out the details, and -- if they can be >worked out well -- to try to convince Apple to adopt it. What I've been told is that it won't be in 7.0 (which actually makes sense. The software isn't done, but we're far enough along that all the manuals, examples,t raining material, books, etc, etc, etc would all have to be changed, and that's a production nightmare) but it will be considered for down the road. So an open mind is being kept. Right now, the focus is fixing bugs, not adding new functionality and I'd personally HATE to find out system 7 slipped because of something like this. Especially since (hint, hint) what HierDA did for the old Apple menu, an INIT can do to the new Apple menu. This wouldn't be a tough thing to graft on the system with a patch of some sort. -- Chuq Von Rospach <+> chuq@apple.com <+> [This is myself speaking] Wherefore could I not pronounce 'Amen'? I had most need of blessing, and 'Amen' stuck in my throat. --Macbeth
TJACOBS@cc.utah.edu (06/14/90)
In article <41889@apple.Apple.COM>, lsr@Apple.COM (Larry Rosenstein) writes: > In article <13407@wpi.wpi.edu> macman@wpi.wpi.edu (Chris Silverberg) writes: > >> has been a VERY positive response to this just based on what I've > read.... > > No one ever said that user interface design should be done by popularity > polls. There was lots of support for a hierarchical Apple menu on > AppleLink as well, although I heard it was booed at the Developers > Conference. Was the booing for hierarchical menus in general or for them in the Apple menu? I think the replys so far indicate it was the former. > >> Do YOU favor the idea? > > I don't favor adding hierarchical menus to the Apple menu. I almost > always cringe when I see a hierarchical menu. I find it interesting that > many people began their arguments in favor of hierarchical menus by saying > "Well, I don't like hierarchical menus, but in this case..." I think one of the reasons people have a bad feeling about hierarchial menus is that there are good things to use them for and bad things to use them for. Having 3 or 4 levels you *HAVE* to go through is not fun. It is much better to bring up a dialog box for many things like that. I think the problem lies in defineing the good uses and the bad uses. Part of the problem also lies in a lack of education on how they work. You DON'T have to go throught the narrow horizontal channel to get to the sub menu. > > The current implementation is very simple to explain and understand, since > there's a 1-1 mapping between items in the Apple Menu folder and items in > the Apple menu. Selecting an item from the menu is equivalent to opening > the icon. There isn't a 1-1 mapping if you want to get technical. Folders are hierarch- ical by nature. If your going to have folders in the menu why not have them actin a similar manner to how a folder does? I just thought of another possible mechanism for hierarchial apple menus: Real folders in the Apple menu folder show as hierarchial, aliased folders show as just the folder. > > Adding hierarchical menus would complicate things. First, I think people > wanted a choice for each folder of whether its item in the Apple menu > included a hierarchical menu of its contents. So you need an additional > mechanism to make this choice. I don't see whats so complicated. Either the folder is hierarchical or not. Sure there needs to be a mechanism, just because there is doesn't mean it really complicates things significantly. If the utility gained from the feature is significant then things are in whole simplified. What I origionally meant by the apple menu becomming a central control center is that people will be going to the apple menu to initiate a lot more things in System 7 than ever before. The apple menu will become a short-cut center with System 7. I believe that hierarchial menus make the cut a little shorter. Example: I want to bring up a particular control panel item (not a really common one as I would likely put it directly in the apple menu), if it was in a hierarchial menu I would select it directly, and it would come up in it's own memory partition. If I had to bring it up in a real folder then a switch to the Finder takes place and the folder has to come up. This takes time (which could perhaps be optimized), then you have to visually locate the control file you want and then you have to double click to open it up. Now don't forget you also have one additional thing to do after your done, you have to put the folder away. All this additional mousing around is totally unecessary and wastes my time. Remember that seconds, even split seconds add to the perception that a computer is fast and/or usefull. I want to do my work and not think about the 3 or 4 extra steps it might take to do a job. > > Then there was the issue of limiting the number of levels, which makes it > harder to explain to users. Right now the Apple menu corresponds to the > contents of the folder. If you add one level of hierarchical menu then > you are partially modelling the hierarchical folder structure. I don't think there should be a limit to the levels. Let the user choose. I would personally choose 1 additional sub level in most cases. > > Regardless of how you organize the menu, the more items the system has to > keep track of, the more time and space it will require. I don't think this is a very good argument. Very little time or space. > > Some one suggested that selecting items from palette is faster than from a > menu. In that case, opening an icon from a Finder window (in View by Name > mode) should be faster than choosing the same item from a hierarchical > menu. That would be true if the window were already open and in view, which is probably not the norm. One of the points I made above is that if you don't have to switch to the Finder it saves time. > > You can make the folder instantly appear by selecting it from the Apple > menu, rather than hunting for it as you have to do today. This may take > an additional step, but it may be just as fast, given the difficulty of > selecting from hierarchical menus. (If it isn't fast to do this, then > perhaps the Finder needs to be optimized for this kind of case.) > Difficulty? Maybe a slight delay. I just timmed how long it takes to select the "Genreal" control panel item using HierDA/DA menuz and it took me 4 seconds to select it. That includes the time it took to start the timmer in SuperClock! and the little hunting for the item in the menu (I have 28 items) because I didn't see it right off and the time to overshoot by two items and back up to the actual item. Now go time how long it takes with System 7. If you want to do a fair test have 28 items in the folder and use SuperClocks timmer. You should also do the test while in another application besides the Finder as thats where most people should be. I'll go do the test myself and report back how long it took me. > I don't have a good rebuttal to the argument that the hierarchical Apple > menu would just be an option for those who want it. > > For one thing, a lot of Macintoshes aren't used by a single person, so > there's a good possibility that users will encounter it unexpectedly. > My wife is a supreme novice. I just asked her what she thought the arrow next to the menu meant. She replied that she didn't know, then after selecting that menu she saw the sub menu pop out and she said it was additional items to choose from. Plenty easy enough for the new user. > I think the same argument could be applied to any user interface feature, > but I wouldn't want to add every feature that someone comes up with, or > that some other program has. > If the feature helps organize things and speeds computer use, would you want to add it? > It's usually a mistake to use the wrong tool for a job. I also think it's > a bad idea to add more and more features to a tool in the hope that it can > handle different jobs. The trend today is towards applications/utilities > that do one job very well and that integrate with other applications. If you're talking about the apple menu as the tool then what System 7 does to it is add more features! Now you can launch applications directly from the menu. Before you could just run little utilities called DA's. Some of those utilities didn't really fit anywhere else like the Chooser and the Control panel. With System 7 it also adds links to the Finder. I claim Apple is making the Apple menu a short-cut center in addition to the "About", "Controls", and DA's. They're moving the current application switching & window hiding items to the MF menu under the silly guise of needing that icon to be a menu. Perhaps the real reason is to simplify the Apple menu to make way for the new stuf! Allowing hierarchial menus in the Apple menu is letting the user tune this tool (the Apple menu) to function as a more efficient and organized tool, this is a good idea. Adding the hierarchial feature doesn't allow the Apple menu to do a function it couldn't without them, it allows one to do it faster and in a more organized fashion which improves the usefullness of the tool. > > As I said before, I don't think you can turn the Apple menu into the > central control center of the Macintosh. If there's a need for additional > navigation features beyond what System 7 provides, then I think it's > better to address that problem directly, rather than slap on hierarchical > menus. > -- > Larry Rosenstein, Object Specialist > Apple Computer, Inc. 20525 Mariani Ave, MS 77-A Cupertino, CA 95014 > AppleLink:Rosenstein1 domain:lsr@Apple.COM > UUCP:{sun,voder,nsc,decwrl}!apple!lsr I appreciate your comments. I'm not trying to beat this thing to death. I work in an environment where continued discussion brings out the best features in any particular idea and this discussion is helping me to understand the issues a lot better. Tony Jacobs Center for Engineering Design University of Utah
mrys@ethz.UUCP (Michael Rys) (06/14/90)
What I really want to have is the Control Center (e.g. the Apple menu) where I need it. Is it possible to tear the menu off or have it as a popup menu? I'm tired of moving my mouse to a far place to get something done. Cheers.../Michael P.S.: What I really wnat is a three button mouse, but that belongs to comp.sys.mac.hardware.religious.... :-) +---------------------------------------------------------------+ | Michael Rys, V. Conzett Str. 34; CH-8004 Zuerich; Switzerland | +---------------------------------------------------------------+ | UUCP: mrys@ethz.UUCP or EAN: mrys@ifi.ethz.ch | | mrys@bernina.UUCP IPSANet: mrys@ipsaint | | Voice: +41 1 242 35 87 | +---------------------------------------------------------------+ -- Wovon man nicht sprechen kann, darueber muss man schweigen. -- Ludwig Wittgenstein, Tractatus logico-philosophicus
eb1z+@andrew.cmu.edu (Edward Joseph Bennett) (06/14/90)
>>You don't turn them on with a silly checkbox somewhere, though. You turn >>them on by creating a sub-folder in the apple folder and sticking stuff in >>it. The name of the sub-folder is the menu-item that roots the hierarchical >>menu, and the stuff in the folder is on the menu. Then you make sure you >>only allow one level of hierarchical menu to keep people honest. >But how do you "only allow one level of hierarchical menu"? Do you >disallow folders from being nested more than one deep? Or if not, >what do you do when they are more deeply nested? I also agree that this is a good idea. But your original intention was to allow users to intuitively configure it how they wanted. If a user wants more than one level, then why not, you can limit yourself to one if that's what you want or zero if people don't want hier menus at all. So that solves both problems in an intuitive manner. I hope someone at Apple is reading. Another observation: The alias files (and can you also make alias copies of folders?) If so that could radically change the concept of folders being nested hierarchially all together. You could make a system of links to folders that would be similar to linking cards in a hypercard stack. Ed
dorner@pequod.cso.uiuc.edu (Steve Dorner) (06/15/90)
> The current implementation is very simple to explain and understand,
The following things were also simpler:
1. MFS
2. No slots
3. No SCSI
4. Single finder
I each case, the "simple" was discarded because it didn't have enough
depth to handle complexity.
IMHO, we have an exact parallel between MFS and a flat apple menu. The
same mistake is being made; you just can't provide users with too many
tools for dealing with complexity.
[Yes, I know that disks manage more docs than the apple menu is likely to.
Yes, I know that the Finder's "pseudo-folders" made MFS more confusing than
it might have been. The analogy still holds.]
The suggested "folder-means-hier-menu" would provide a valuable tool,
but would cost nothing for the novice.
[As for the "but a novice might use an expert's machine," argument, I detect
a definite red coloration and fishy smell...]
--
Steve Dorner, U of Illinois Computing Services Office
Internet: s-dorner@uiuc.edu UUCP: {convex,uunet}!uiucuxc!dornerlsr@Apple.COM (Larry Rosenstein) (06/15/90)
In article <69651@cc.utah.edu> TJACOBS@cc.utah.edu writes: > Was the booing for hierarchical menus in general or for them in the Apple > menu? I think the replys so far indicate it was the former. I wasn't there, so I don't know the exact story. > is that there are good things to use them for and bad things to use them I object to hierarchical menus because I find them difficult to use. I haven't met a hierarchical menu that I liked. > ical by nature. If your going to have folders in the menu why not have them > actin a similar manner to how a folder does? I think you are taking too technical a view. If there are 10 icon in the Apple Menu folder, there are 10 items in the Apple menu. Selecting an item from the menu does the same thing as selecting the icon and opening it. It happens that folder do something different when opened than an application. That's because they are a different kind of object. > Real folders in the Apple menu folder show as hierarchial, aliased folders > show as just the folder. I don't like this idea because it makes an artificial distinction between aliases and the real thing. It also puts restrictions on where you can use aliases, which defeats their purpose. > I don't see whats so complicated. Either the folder is hierarchical or not. > Sure there needs to be a mechanism, just because there is doesn't mean it It's one added mechanism in a system that already introduces a lot of new mechanisms. > That would be true if the window were already open and in view, which is > probably not the norm. One of the points I made above is that if you don't > have to switch to the Finder it saves time. If the window is open, it doesn't have to be in view, because selecting it from the Apple menu will make it visible. If it was in view, you could double click on the icon directly. And you don't necessarily have to put the folder away. Your description of the test using HierDA, indicates that it wasn't a trivial task. (You mentioned that you overshot the item, for example.) And you are an experienced user of hierarchical menus. You won't be able to do a fair test with System 7, because it's only an alpha version, and that version is known to be very slow. > do a fair test have 28 items in the folder and use SuperClocks timmer. You I would like to see some info about how many things people keep in their Apple menu (or OnCue menu). I have 18 in mine, of which I use 11 regularly. > menu she saw the sub menu pop out and she said it was additional items to > choose from. Plenty easy enough for the new user. It's one thing to explain what the triangle means. There's also the question of how well an inexperienced user can use them, and in the case of the hierarchical Apple menu explaining how to control whether a folder appears with a hierarchical menu or not. >If the feature helps organize things and speeds computer use, would you want >to add it? It's impossible to say without being explicit. The System 7 Apple menu was a simple generalization of the existing DA menu. It's not a "free" improvement because you have to explain the connection between the Apple menu folder and the menu itself. But it also ties in with the change that reduces the difference between DAs and applications. People have asked for the ability to popup a menu annywhere on the screen that duplicates the menu bar and lets you select an item from a hierarchical menu. But when someone tested this interface they found it was slower than having the menu bar at the top of the screen, even on a large monitor. (See the CHI 1990 Proceedings.) > If you're talking about the apple menu as the tool then what System 7 does to > it is add more features! Now you can launch applications directly from the System 7 removes the distinction between DAs and applications. Therefore, it doesn't make sense to limit the Apple menu to just DAs. (In a sense the concept of a DA is gone from System 7. DAs are just applications that are written in a special way.) It is a natural extension to include applications in the menu. The new concept is that the way to configure the menu is to put icons in a special folder. That is a new feature. It isn't necessary that folders be allowed in the Apple menu. After all they aren't launched in the same way that applications & DAs are. In this case, I think it makes sense to include them because it eliminates a set of special cases. And if new kinds of objects get added to the Finder, there's no question about whether then can be put into the Apple menu. > I claim Apple is making > the Apple menu a short-cut center in addition to the "About", "Controls", I agree that the Apple menu is a short-cut center. What I disagree with is the idea that a menu containing 40 items (regardless of how they are organized) can be considered a short-cut. > to the MF menu under the silly guise of needing that icon to be a menu. Perhaps > the real reason is to simplify the Apple menu to make way for the new stuf! I think one reason is to move things out of the Apple menu, so that it can accommodate more shortcuts. But putting the applications into their own menu also allows us to get rid of the hidden feature of setting aside all but the current application's windows. I agree that the implementation in the alpha version is weak, and I think the Human Interface people are working on it. Larry Rosenstein, Apple Computer, Inc. Object Specialist Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1
lsr@Apple.COM (Larry Rosenstein) (06/15/90)
In article <1990Jun14.185425.640@ux1.cso.uiuc.edu> dorner@pequod.cso.uiuc.edu (Steve Dorner) writes: > The following things were also simpler: [list omitted] Every change involves a cost-benefit tradeoff. Cost must take into account use by inexperienced as well as experienced users, development time & space, testing time, etc. > IMHO, we have an exact parallel between MFS and a flat apple menu. The > same mistake is being made; you just can't provide users with too many I disagree. To the user, there seemed to be a hierarchy under MFS. In fact I would argue that HFS simplified things by removing the quirks of the fake hierarchy. (You could get a message about replacing a file even if it was 10 levels deep.) Also, I don't think the 2 features are analogous. You have to be able to reach every file from the Finder, so you need a hierarchical structure. (MFS vs. HFS is just an implementation detail.) You don't have to be able to reach everything from the Apple menu. > but would cost nothing for the novice. It's one more thing to be explained in the manual. You would need a mechanism to turn it on and off (another thing to explain), since System 7 installs the Control Panels folder in the Apple menu. >[As for the "but a novice might use an expert's machine," argument, I detect >a definite red coloration and fishy smell...] Since there is no mechanism for users to "login" and configure the machine, this situation will arise. We know that this happens all the time in universities, and it turns out that a lot of business users share their machines. (I think there should be some way to customize the system for each user.) I don't buy the argument it's OK to add any particular UI feature to the system, since novice users won't see it. The Human Interface people have an obligation to ensure that the Mac user interface is the best one available. I'm sure that someone will do an INIT to provide hierarchical menus. It should be easier to do because System 7 documents more of the stuff needed to make this work. Larry Rosenstein, Apple Computer, Inc. Object Specialist Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1
cory@three.MV.COM (Cory Kempf) (06/15/90)
lsr@Apple.COM (Larry Rosenstein) writes: >In article <68207@cc.utah.edu> TJACOBS@cc.utah.edu writes: >> The Apple menu is becoming a control center for the whole Mac >If this was true, then adding hierarchical menus to the Apple menu would >be the right idea. But I don't think this is true. Unfortunately, from what I have seen, both here and on Applelink, the users (yes, I admit that they are engineering users) seem to disagree. > The Apple menu isn't >intended to be the Macintosh control center. That's the Finder's job. >The Apple menu is a simply short cut for accessing a few icons. Since when has Apple decided that there shall only be one way to do something? What ever happened to the idea of customization? Like letting the USER (you remember users, don't you? -- the ones who BUY Macs) choose? The alternative (for reasonably quick access) is to clutter up the desktop with a herd of aliases. Not the best of alternatives. >I agree that putting 40 things in the Apple menu isn't a good idea. But I >don't think there is any reasonable way to access 40 items from a single >menu. Unfortunately, you have the problem that control pannels and desk accessories (in general) belong in the Apple menu. If for no other reason that they have been there since the dawn of time (or at least since the Mac was invented). A typical control pannel contains about 10-15 items. The typical user (at least the ones that I have seen) have about 10 DAs that they can't live without. Now, the normal Mac users uses about 5-10 applications regularly. (word processor, drawing/painting program or two, page layout application, spreadsheet, 2-5 games, Hypercard, and an application specific program (comm program, a database, a scanner package, a flowcharting program, etc)). The user, upon learning that they can put an alias of these programs into the Apple menu, will most likely proceed to do so for most of his or her working set. By my count, we have a conservative 25 entries... Power users will, of course, have more, as will graphic arts people, engineers, and people with multiple work contexts. +C -- Cory Kempf I do speak for the company (sometimes). Three Letter Company 603 883 2474 email: cory@three.mv.com, harvard!zinn!three!cory
jbr0@cbnews.att.com (joseph.a.brownlee) (06/15/90)
In article <41889@apple.Apple.COM>, lsr@Apple.COM (Larry Rosenstein) writes: > In article <13407@wpi.wpi.edu> macman@wpi.wpi.edu (Chris Silverberg) writes: >> has been a VERY positive response to this just based on what I've > read.... > > No one ever said that user interface design should be done by popularity > polls. There was lots of support for a hierarchical Apple menu on > AppleLink as well, although I heard it was booed at the Developers > Conference. I'm not sure I agree with the "popularity poll" comment in this context (and after all, wouldn't you put "booing developers" in that class, too?). In general, you are right -- you do some research and testing, you work with your potential user base, or perhaps you rely on past experience with similar interfaces. In these cases, you are often making a choice between two or more different interfaces which are often mutually exclusive. However, in this case, the choice involved is adding additional functionality to an existing feature set, which is not incompatible, and is completely user- selected. The user must configure the Apple Menu with sub-folders, just as the user must add choices to the existing (well, in the 7.0 context we are discussing) flat Apple menu. The user that does not want hierarchical menus does not have to have them, and the novice user need not know anything about this feature. My point is that in my experience (I have been desigining user interfaces and working closely with users for about 10 years) you are just about always better off when you offer the user the *choice* of how to configure something, especially if the choice can be easily and cleanly made. Further, you are usually best off when the "power user's" choice is one that by default is completely transparent, but can be easily activated. That's the situation I see here -- the novice won't necessarily even know or care that the hierarchical menu facility exists, while a power user can set it up by just creating a folder or two and moving some files around. This seems to be the very essence of simplicity to me, allowing the *user* to decide how the system will work best for them. I do agree with the comment from one of the Apple folks that it is awfully late to add something like this to 7.0, but I think that this is very worthy of consideration for 7.1 (or whatever release comes next). But before disregarding this idea because of a lack of emprical data on its merits, realize that the *many* positive responses here should be considered part of the data. Perhaps the people in this forum don't represent the "average" Apple user, but they do represent the core of the user community, and their opinions should be important in determining Apple's product directions. Perhaps he customer isn't _always_ right, but they do, after all, pay the bills... -- - _ Joe Brownlee, Analysts International Corp. @ AT&T Network Systems /_\ @ / ` 471 E Broad St, Suite 1610, Columbus, Ohio 43215 (614) 860-7461 / \ | \_, E-mail: jbr@cblph.att.com Who pays attention to what _I_ say? "Scotty, we need warp drive in 3 minutes or we're all dead!" --- James T. Kirk
TJACOBS@cc.utah.edu (06/15/90)
In article <41915@apple.Apple.COM>, chuq@Apple.COM (That's MR. Idiot to you) writes: > > What I've been told is that it won't be in 7.0 (which actually makes sense. > The software isn't done, but we're far enough along that all the manuals, > examples,t raining material, books, etc, etc, etc would all have to be > changed, and that's a production nightmare) but it will be considered for > down the road. So an open mind is being kept. Right now, the focus is fixing > bugs, not adding new functionality and I'd personally HATE to find out > system 7 slipped because of something like this. > > Especially since (hint, hint) what HierDA did for the old Apple menu, an > INIT can do to the new Apple menu. This wouldn't be a tough thing to graft > on the system with a patch of some sort. > -- > Chuq Von Rospach <+> chuq@apple.com <+> [This is myself speaking] > > Wherefore could I not pronounce 'Amen'? I had most need of blessing, and > 'Amen' stuck in my throat. --Macbeth Perhaps you could find out if the Finder team has included hooks into the Finder so that this can be done seamlessly to avoid a bunch of low level hacks and patches to the toolbox calls. Perhaps if there aren't any hooks, they could be convinced to include some for this very purpose. The "Power" to be your best? Not quite. But someday they'll get there, then I'll have a different best in mind! ;^) Tony Jacobs Center for Engineering Design
long@mcntsh.enet.dec.com (Rich Long) (06/16/90)
FWIW, I favor the hierarchical menu structure for the Apple Menu, i.e. folders in the Apple Menu Folder become hierarchical entry points. I guess I'm one of the few who LIKES hierarchical menus (for the same reason I like subdirectories). The hierarchy should be optional, though, to please everyone. If it's turned off, then all items in the Apple Menu Folder are added to the menu in a "flat" fashion. ------------------------------------------------------------------------------ /'') /'~ / | long@mcntsh.enet.dec.com | Don't take life too /''\ /,, /,, | ...!decwrl!mcntsh.enet.dec.com!long | seriously; you won't Richard C. Long | long%mcntsh.dec@decwrl.enet.dec.com | get out alive anyway.
d88-jwa@nada.kth.se (Jon W{tte) (06/16/90)
Hey, let's all hear it for the hiearchical menus !
It's just TOO BAD that we can't have more than 255
at a time !
(Well, I actually almost mean that ! I LOVE them !)
Jon W{tte, Stockholm, Sweden, h+@nada.kth.sermh@apple.com (Rick Holzgrafe) (06/16/90)
In article <372@three.MV.COM> cory@three.MV.COM (Cory Kempf) writes: > A typical control pannel contains about 10-15 items. The typical user (at > least the ones that I have seen) have about 10 DAs that they can't live > without. Now, the normal Mac users uses about 5-10 applications regularly. > (word processor, drawing/painting program or two, page layout application, > spreadsheet, 2-5 games, Hypercard, and an application specific program (comm > program, a database, a scanner package, a flowcharting program, etc)). The > user, upon learning that they can put an alias of these programs into the > Apple menu, will most likely proceed to do so for most of his or her working > set. By my count, we have a conservative 25 entries... Power users will, of > course, have more, as will graphic arts people, engineers, and people with > multiple work contexts. Boy, not me. I agree with Larry: a menu with that many items in it is going to be too cluttered to use, no matter how it's organized. The stuff that'll go into my Apple menu *won't* be everything I use often. (Yes, I have dozens of things I use every day, too.) It'll only be those items which I use often and which either have no double-clickable documents or which I use often to create documents in empty folders. Whew - that last sentence is nearly unreadable. What I mean is this: ResEdit goes in my Apple menu because I use it frequently from folders where there is no double-clickable ResEdit document. But MacPaint doesn't go in my Apple folder, because most of the time I use MacPaint on existing documents in a project folder that I already have open. I only need to double-click the document to launch MacPaint. In fact, some things will *disappear* from my Apple menu. I have DAs and CDEVs I can't live without, but which I don't use often. Now I can dump them in some well-placed folder where I can find them easily but where I won't trip over them every time I pull down my Apple menu. To run them, I just open their folder and double-click. About this business of "explaining things to the novice"... bear with me and let me tell you a longish story with a moral. I've had the dubious pleasure of teaching vi (the Unix text editor) to people who haven't used it before. Almost to a person, they viewed it with a sense of panic: it was *so* feature-laden that it terrified them. Every key-click did *something*, and they lived in terror of hitting the wrong key and trashing something important and not being able to recover. (This applied to secretaries and high-level software engineers alike!) Vi enthusiasts would explain that "you don't have to use anything you don't understand" but it did not calm anybody. They saw every unknown as a hazard that could "get them" if they didn't understand it... and they didn't want to take the time to learn about them all. Most of them vehemently wanted a simpler editor. (By "vehemently", I mean some people shouted and swore!) Well, I'm a good teacher (if I say so myself :-) and I did get all those folks calmed down, well-taught, and I left them all productively tapping away. The moral is not that vi is a bad editor (it's not) or that it's impossible or even difficult to learn (it isn't). The moral is that too many features scare the bejabbers out of newcomers, and create mental and emotional blocks to learning and using the system. This is frustrating to developers, who want to empower their users and often can't understand why the users are "fighting" them about it. But it is a fact of life: all the sweet reason in the world won't appease a user who thinks the manual is a bit thick and wants something simpler. The Mac was designed to be a "warm, fuzzy" computer. It has *got* to seem simple to novices: they, not the power users, are the bulk of the Mac's market. Of course the Mac must also be powerful, and a truly great user interface is one which is both simple and powerful. But you can't always avoid the trade-off between power and simplicity. Some extra disclaimers, in addition to my usual: I'm not involved in System 7.0 or in user interface design (any more than anyone else at Apple). I'm just contributing my two cents to this thread - and probably worth every penny, too. :-) And I don't mean to imply that everyone in the world is intimidated by apparent complexity. Many brave souls sail into every new learning experience with verve and delight. On this newsgroup I expect the proportion of such folks is high - but trust me, out there in the mundane world, it isn't. ========================================================================== Rick Holzgrafe | {sun,voder,nsc,mtxinu,dual}!apple!rmh Software Engineer | AppleLink HOLZGRAFE1 rmh@apple.com Apple Computer, Inc. | "All opinions expressed are mine, and do 20525 Mariani Ave. MS: 77-A | not necessarily represent those of my Cupertino, CA 95014 | employer, Apple Computer Inc."
jmm@lsuc.on.ca (John Macdonald) (06/16/90)
In article <41889@apple.Apple.COM> lsr@Apple.COM (Larry Rosenstein) writes: > >I don't favor adding hierarchical menus to the Apple menu. I almost >always cringe when I see a hierarchical menu. I find it interesting that >many people began their arguments in favor of hierarchical menus by saying >"Well, I don't like hierarchical menus, but in this case..." Generally, the only place people have seen hierarchical menus previously has been when using a program that had them - with the hierarchical organization that seemed logical to the programmer who wrote the program. Naturally, the chosen hierarchical layout seems wrong or confusing to a significant number of users. However, the proposal on the floor is for a hierarchical menu that can be set up to present the choices using the user's own hierarchical organization - they have the choice of laying things out as well (or as poorly) as they currently have the choice of laying out their files within folders - I presume that noone would suggest that the MFS should have been left alone and the HFS not introduced. While the Apple Menu is not hitting the limit of having thousands of entries, it does share the aspect of having a user-extendable, arbitrarily large set of things to organize. >Some one suggested that selecting items from palette is faster than from a >menu. In that case, opening an icon from a Finder window (in View by Name >mode) should be faster than choosing the same item from a hierarchical >menu. > >You can make the folder instantly appear by selecting it from the Apple >menu, rather than hunting for it as you have to do today. This may take >an additional step, but it may be just as fast, given the difficulty of >selecting from hierarchical menus. (If it isn't fast to do this, then >perhaps the Finder needs to be optimized for this kind of case.) Clearly, System 7's new features will take some getting used to - aliases and their use from within the Apple Menu seem to cover much of what is being requested with hierarchical menus. There is one major perceptual difference - going to the finder and opening a folder has (to me) the perceptual overhead of being a change to the desktop view of the world, while pulling down a menu (whether hierarchical or not) is a temporary overlay on top of the desktop that will disappear after selection (while the selection may cause a new window to appear, it will not leave the menu on the screen). >Larry Rosenstein, Object Specialist >Apple Computer, Inc. 20525 Mariani Ave, MS 77-A Cupertino, CA 95014 >AppleLink:Rosenstein1 domain:lsr@Apple.COM >UUCP:{sun,voder,nsc,decwrl}!apple!lsr
kehr@felix.UUCP (Shirley Kehr) (06/17/90)
I'd like to know what is so horrible about hierarchial menus. Adobe Type Reunion is the best thing that ever happened to my font menu. It makes order out of chaos. I certainly don't want to see another kind of chaos in System 7. I liked Chuq's suggestion to let us make our own folder of items and let the name of the folder be the name that shows up on the Apple menu. Shirley Kehr
tonyrich@titanic.cs.wisc.edu (Anthony Rich) (06/27/90)
>> What would be nice is if each DA or application or whatever had some >> type of context list that you made that would allow only the DA's & >> applications you want to appear in a given application. For example >> it would be nice to have unstuffit and binhex to be in the Apple >> menu of *only* my NCSA Telnet and AppleLink programs. >Interesting idea. Maybe one could extend "apple menu folder inside system >folder" to "apple menu folder in same folder as application". Launch Word 4 >and get all the DAs etc. from the system folder + Word Finder from the >apple folder within the folder Word 4 is in. This sounds to me like a >much neater solution than hierarchical menus - especially if you can use >symbolic links to avoid real duplicates. Yes. This is something like having "local scope" in a programming language. One could set up a small collection of "local" DAs & apps that are particularly useful with a given application, and they wouldn't be swamped by a lot of irrelevant ones in the same menu. It would still be nice to have a second menu (or perhaps a submenu) listing all the other "irrelevant" DAs & apps also (the "global" scope), so that if you found you suddenly needed one of them, you could still get to it fairly easily, without leaving the current application. -- ----------------------------------------- | EMAIL: tonyrich@titanic.cs.wisc.edu | | Disclaimer: I speak only for myself. | -----------------------------------------
barnett@grymoire.crd.ge.com (Bruce Barnett) (06/30/90)
In article <8225@uhccux.uhcc.Hawaii.Edu> mah@uhccux.uhcc.Hawaii.Edu (Michael Hoffhines) writes: > most people like hierMenus for > their organizational capabilities but find them difficult to traverse. I > agree 100%. I hate heirMenus simply because they are a pain to access. > Soooo...what if the menus were of the pop-down variety and all one would have > to do is to click on the sub-menu 'title' to freeze the sub-menu so that the > user could wander over to the sub-menu and click on the desired item. Some systems with pop-up hiermenus (pull-right) remember the last choice, so when you pop up the menu, your nest of menus re-appear. That is, if you are 4 levels deep, the next time you choose the menu, you end up at the same sub-sub-sub-menu. You only have to move the mouse a few pixels to either go to the same choice, or back up to branch up the parent menu. Sometimes the pull right menus are made easier to traverse by moving each menu up or down so your last choice is a straight line from your current mouse position. HierMenus aren't necessarily difficult to traverse. It's the Pull Down Menu combined with the HierMenu that makes it difficult. -- Bruce G. Barnett barnett@crd.ge.com uunet!crdgw1!barnett