chuck@melmac.harris-atd.com (Chuck Musciano) (09/25/89)
I am currently in the midst of a quandary involving two different
menu interaction techniques, and I was wondering if there is anything in the
literature regarding either of the following two hypotheses.
I have been of the opinion that menus used in an interface should remain
"static": the position and contents of the menu should not change over the
course of using the interface. I was under the impression that menu usage
becomes an instance of "gesturing" or "stroking" and the cognitive loading
is moved into the "muscle memory" of the user.
I recently used a system wherein the menu contents constantly changed
based upon the mouse position and the current interface context, including
which interface items are selected. I found the interface confusing, and said
that it would be hard to learn. The designers claimed they were using
"progressive disclosure" and that such a system was actually more productive
for the user, since the user only ever saw options which made sense in his
current context. I contended that each menu usage would require a visual
search and explicit select action, making it harder to use.
Is there anything in the literature which supports either (or both) of
these claims? Any thoughts or opinions?
Chuck Musciano ARPA : chuck@trantor.harris-atd.com
Harris Corporation Usenet: ...!uunet!x102a!trantor!chuck
PO Box 37, MS 3A/1912 AT&T : (407) 727-6131
Melbourne, FL 32902 FAX : (407) 727-{5118,5227,4004}
Gee, Beaver, everything that's fun can get you in trouble. Haven't you
learned that yet? --Gilbertjhc@iris.brown.edu (James H. Coombs) (09/25/89)
In article <2722@trantor.harris-atd.com> chuck@melmac.harris-atd.com (Chuck Musciano) writes: > I contended that each menu usage would require a visual > search and explicit select action, making it harder to use. I have seen no research on this, so I will offer an observation. I frequently find that I select the wrong item or no item at all when I attempt to select from a menu without focusing my vision on the desired item. I have not experienced the equivalent of touch typing with menu selection. D. A. Norman is right on target: menus are optimized for selection but pessimized for performance. --Jim Dr. James H. Coombs Senior Software Engineer, Research Institute for Research in Information and Scholarship Box 1952, Brown University, Providence, RI 01912
engelson@cs.yale.edu (Sean Engelson) (09/26/89)
In article <16179@brunix.UUCP>, jhc@iris (James H. Coombs) writes: >In article <2722@trantor.harris-atd.com> chuck@melmac.harris-atd.com >(Chuck Musciano) writes: > >> I contended that each menu usage would require a visual >> search and explicit select action, making it harder to use. > >I have seen no research on this, so I will offer an observation. I >frequently find that I select the wrong item or no item at all when >I attempt to select from a menu without focusing my vision on the >desired item. I have not experienced the equivalent of touch typing >with menu selection. D. A. Norman is right on target: menus are >optimized for selection but pessimized for performance. Supposedly there's been some research that's shown that pie-menus (menus with selections in wedges around a circle) allow muscular memory to take over. My experience with pie-menus under NeWS bore this out---I could just click-move-click-move-click (for nested menus) and get exactly what I wanted, even if the menus hadn't even popped up yet (due to the slowness of the window system). Regular menus require search, and precise positioning, while pie-menus require only directional information, which is easier to remember. ---------------------------------------------------------------------- Sean Philip Engelson, Poet Errant Make your learning a fixture; Yale Department of Computer Science Say little and do much; Box 2158 Yale Station And receive everyone with New Haven, CT 06520 a kindly attitude. ---------------------------------------------------------------------- Esperanto: la metodo por krei paca mondo. ---------------------------------------------------------------------- I see the eigenvalue in thine eye, I hear the tender tensor in thy sigh. Bernoulli would have been content to die Had he but known such a^2 cos 2(phi)! --Stanislaw Lem, "Cyberiad"
don@brillig.umd.edu (Don Hopkins) (09/27/89)
In article <16179@brunix.UUCP> jhc@iris.brown.edu (James H. Coombs) writes: >In article <2722@trantor.harris-atd.com> chuck@melmac.harris-atd.com >(Chuck Musciano) writes: > >> I contended that each menu usage would require a visual >> search and explicit select action, making it harder to use. > >I have seen no research on this, so I will offer an observation. I >frequently find that I select the wrong item or no item at all when >I attempt to select from a menu without focusing my vision on the >desired item. I have not experienced the equivalent of touch typing >with menu selection. D. A. Norman is right on target: menus are >optimized for selection but pessimized for performance. > >--Jim > "Mouse ahead" (the mouse equivalent of "touch typing") works very well with pie menus. Since each pie menu item is in a different direction from the cursor, you can make a menu selection very quickly without looking at the menu, if you know which direction it's in. Linear menus require your visual attention, because they depend on the distance you move the cursor, and you can't tell that for sure without looking. Pie menus just depend on the direction of movement, with the added advantage that you can move the cursor out further in whatever direction to get more angular precision (pie slices are much wider on the outside of the pie than in the middle). I found that mousing ahead into familiar pie menus was so easy, that I implemented "mouse ahead display supression", where the display of menu is supressed if you complete a selection fast enough. This feature really speeds up interaction with commonly used menus, such as the menu of window managment functions. If you know the direction of the item you want, then there is no need to see the menu, and it really slows down interaction for the computer to pop it up, paint it, and pop it right back down, after you've already completed the selection. I use pie menus regularly, and I can make menu selections reliably and quickly from a reasonably sized pie menu (8 items is /very/ reasonable), even with my eyes closed. Pie menu interaction is very gestural, and the layout of the items in a pie menu can be designed to take good advantage of muscle memory. Of course, muscle memory only helps you with static menus. When the number of items in a pie menu change, the direction you have to move the cursor to select each item changes. I agree with Chuck, especially in the case of pie menus, that muscle memory really helps speed up interaction with static menus, but muscle memory works against you with dynamic menus. Enclosed is a blurb about pie menus. If you would like to try them out first hand (the only way to really know what they're like), I'd be glad to send you the PostScript source code that implements them for the NeWS window system, along with a window manager designed to take advantage of pie menus. My implementation is in the public domain, and freely redistributable. The idea is not patented or proprietary, and I encourage you to implement them for your favorite toolkit; just send me some mail, and I'll share with you what I've learned. -Don Directional Selection is Easy as Pie Menus! Don Hopkins University of Maryland Human Computer Interaction Lab College Park, MD 20742 (301) 454-1517 Simple Simon popped a Pie Men- u upon the screen; With directional selection, all is peachy keen! The choices of a Pie Menu are positioned in a circle around the cursor, instead of in a linear row or column. The choice regions are shaped like the slices of a pie. The cursor begins in the center of the menu, in an inactive region that makes no selection. The target areas are all adjacent to the cursor, but in a different directions. Cursor direction defines the choice. The distance from the menu center to the cursor, because it's independent of the direction, may serve to modify the choice. The further away from the Pie Menu center the cursor is, the more precise the control of the selection is, as the Pie slice widens with distance. With familiar menus, choices can be made without even seeing the menu, because it's the direction, not the distance, that's important. "Mousing ahead" with Pie Menus is very easy and reliable. Experienced users can make selections quickly enough that it is not actually necessary to display the menu on the screen, if the mouse clicks that would determine the selection are already in the input queue. The circular arrangement of Pie Menu items is quite appropriate for certain tasks, such as inputing hours, minutes, seconds, angles, and directions. Choices may be placed in intuitive, mnemonic directions, with opposite choices across from each other, orthogonal pairs at right angles, and other appropriate arrangements. Pie menus have been implemented for uwm, a window manager for X-Windows version 10, for the SunView window system, and for NeWS, Sun's extensible PostScript window system. Don Hopkins did the uwm and NeWS implementations, and Mark Weiser did the SunView implementation. Jack Callahan has shown Pie Menus to be faster and more reliable than linear menus, in a controlled experiment using subjects with little or no mouse experience. Three types of eight-item menu task groupings were used: Pie tasks (North, NE, East, etc...), linear tasks (First, Second, Third, etc...), and unclassified tasks (Center, Bold, Italic, etc...). Subjects were presented menus in both linear and Pie formats, and told to make a certain selection from each. They were able to make selections 15% faster, with fewer errors, for all three task groupings, using Pie Menus. Ben Shneiderman gave advice on the design of the experiment, and Don Hopkins implemented it in Forth and C, on top of the X-Windows uwm. The disadvantage of Pie Menus is that they generally take up more area on the screen than linear menus. However, the extra area does participate in the selection. The wedge-shaped choice regions do not have to end at the edge of the menu window -- they may extend out to the screen edge, so that the menu window only needs to be big enough to hold the choice labels. Proper handling of pop-up Pie Menus near the screen edge is important. The menu should idealy be centered at the point where the cursor was when the mouse button was pressed. If the menu must be moved a certain amount from its ideal location, so that it fits entirely on the screen, then the cursor should be "warped" by that same amount. Pie Menus encompass most uses of linear menus, while introducing many more, because of their extra dimension. They can be used with various types of input devices, such as mice, touch pads, graphics tablets, joysticks, light pens, arrow keypads, and eye motion sensors. They provide a practical, intuitive, efficient way of making selections that is quick and easy to learn. And best of all, they are not proprietary, patented, or restricted in any way, so take a look and feel free! References: Pies: Implementation, Evaluation, and Application of Circular Menus By Don Hopkins, Jack Callahan, and Mark Weiser (Paper in preparation. Draft available from authors.) A Comparitive Analysis of Pie Menu Performance. By Jack Callahan, Don Hopkins, Mark Weiser, and Ben Shneiderman. Proc. CHI'88 conference, Washington D.C.: available from ACM, NY. A Pie Menu Cookbook: Techniques for the Design of Circular Menus By Don Hopkins (Paper in preparation. Draft available from author.)
ria@PacBell.COM (Richard I Anderson) (09/28/89)
In article <2722@trantor.harris-atd.com> chuck@trantor.harris-atd.com (Chuck Musciano) writes: > > I am currently in the midst of a quandary involving two different >menu interaction techniques, and I was wondering if there is anything in the >literature regarding either of the following two hypotheses. > > I have been of the opinion that menus used in an interface should remain >"static": the position and contents of the menu should not change over the >course of using the interface. ... A relevant study is reported in: Mitchell, J. & Shneiderman, B. (April, 1989) Dynamic versus static menus: An exploratory comparison. SIGCHI Bulletin, 20 (4), 33-37. This study did NOT investigate menus that changed in accordance with context, but it did look at menus that changed versus menus that did not. Ablex is publishing a book by Kent Norman entitled, "The psychology of menu selection..."; I would hope that it addresses the issues of concern to you. I collected some somewhat relevant data via usability testing I did early this year. Menu item position did not change in accordance with context, but cursor placement within the menu did. The initial "qualitative" analysis suggested that this change prompted user confusion. However, subsequent examination of the tapes and preliminary quantitative analyses suggest that the detected confusion may have actually been due to design weaknesses encountered earlier and that the changing cursor placement was significantly beneficial. Jonathon Grudin has a nice discussion about such menus in: Grudin, J. (January, 1989) The case against user interface consistency (Technical Report Number ACA-HI-002-89) Austin, TX: Microelectronics and Computer Technology Corporation. In article <2722@trantor.harris-atd.com> chuck@trantor.harris-atd.com (Chuck Musciano) writes: > ... I was under the impression that menu usage >becomes an instance of "gesturing" or "stroking" and the cognitive loading >is moved into the "muscle memory" of the user. In article <618@cs.yale.edu> engelson@cs.yale.edu (Sean Engelson) writes: >Supposedly there's been some research that's shown that pie-menus >(menus with selections in wedges around a circle) allow muscular >memory to take over. My experience with pie-menus under NeWS bore >this out ... Aah - muscle memory again. Don Norman talked about muscle/motor memory the last time this topic surfaced here. I happened to have saved his words: >From: norman@sdics.ucsd.EDU (Donald A. Norman) Newsgroups: comp.cog-eng Subject: Re: A Dvorak keyboard experiment Date: 24 Jun 88 17:10:56 GMT Organization: UC San Diego Institute for Cognitive Science ... Do not get too excited about the advantages of "motor memory." Nothing special about "motor." The same phenomenon works with anything that is over-learned, over-practiced. Such skills become automated and, thereby, sub-conscious. These skills can be done with minimal interference to other ongoing tasks, with little or no conscious attention, and with great precision and speed. And once a skill reaches this level of automation, it is very difficult to change. PIE MENUS: I suspect that pie-menus are good things, but not because they are motor. Rather, they are good because items appear in a consistent place and it is easy for a single movement to select them. Regular pop-up or pull-down menus may be consistent, but visual attention is needed to find the desired target. Of course, pie menus only work with a limited number of entries (so that the selection stroke does not require high angular precision). I predict that if you add too many entries, they will require visual attention just like regular menus. Don Norman R. I. Anderson Human Factors Consultant Pacific Bell 2600 Camino Ramon, Room 2E850 (415)823-3715 San Ramon, CA 94583 ria@pbhyg.PacBell.COM
rock@lighthouse.com (Roger Rock Rosner) (09/28/89)
In article <19812@mimsy.UUCP>, don@brillig.umd.edu (Don Hopkins) writes: >Proper handling of pop-up Pie Menus near the screen edge is important. >The menu should idealy be centered at the point where the cursor was >when the mouse button was pressed. If the menu must be moved a certain >amount from its ideal location, so that it fits entirely on the screen, >then the cursor should be "warped" by that same amount. I am quite excited about this idea of Pie Menus, but I must disagree with the above point. Admittedly I have no background in this subject, but I (and, it seems, Apple and NeXT) consider "warping" the mouse an egregious user interface sin. Optimizing for "muscle memory" would seem to preclude automatically relocating the mouse (although partially obscured Pie Menus are probably not so great either). Roger Rosner Lighthouse Design, Ltd. Usenet: ...!uunet!lighthouse!rock Internet: rock@lighthouse.com US mail: 7100 Edgevale Street Chevy Chase, MD 20815-5906 Phone: 301-907-4621
ianf@nada.kth.se (Ian Feldman) (09/28/89)
In article <618@cs.yale.edu> engelson@cs.yale.edu (Sean Engelson) writes: > Regular menus require > search, and precise positioning, while pie-menus require only ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Let us not forget the hierarchical menus either - where regular drop-down menus usually make use of eye-muscle coordination in one dimension only (up-down) the hierarchical ones require another one - the left-right one. The coordination-load (for want of a better word) of the "menu-ee" grows exponentially with each dimension - ie a one-branch hierarchical menu is in all probability 4 times as hard to select from as a standard oe-dimensional one. IMHO that pretty much rules the hierarchicals out of any serious consideration when designing user interfaces. As to the question of fast vs. movable/ context-dependent menus I'd like to hear some comparisons of selection and menu-orientation process from someone with Macintosh experience, who is now working with the NeXT (cube? computer?). As I understand the NeXT menus are of unusual design being, first, two-tiered (ie, two columns of square aligned "buttons" constitute a menu) and, second, freely movable on the screen. -- ---- ------ ianf@nada.kth.se/ @sekth.bitnet/ uunet!nada.kth.se!ianf ---- --
chac@aratar.UUCP (Chuck Clanton) (09/28/89)
In article <16179@brunix.UUCP> jhc@iris.brown.edu (James H. Coombs) writes: >I have not experienced the equivalent of touch typing >with menu selection. D. A. Norman is right on target: menus are >optimized for selection but pessimized for performance. this is my experience as well. on frequently used menus and slow machines, i can get the cursor (and my eyes) close to the right item before it appears but i still must see the item and correct before clicking on it. i have a very small amount of experience with pie menus and wonder if they are better. people who use have used them extensively speak of using "muscle memory" to "navigate" through the pie menus they are familiar with. it seems to me that the ergonomics of a linear array of menu items resembles that of a control panel composed of a row of identical switches. it is easy to make mistakes without careful visual verification of a choice. but a keyboard is just a long row of identical switches too. it is different only so long as the hands stay on the home row such that the keys are distinguished by position relative to a given fingers home position. whenever i move my hands to the mouse, i have exactly the same problem that i have with menu item selection--i must focus my attention on the keyboard to insure that i recover the correct hand position. so, it certainly seems like a reasonable hypothesis that pie menus with items in differing directions relative to the starting position might provide more of the performance and selection characteristics of "touch typing" and be less like the linear array of switches of normal menus.
chac@aratar.UUCP (Chuck Clanton) (09/28/89)
In article <2722@trantor.harris-atd.com> chuck@trantor.harris-atd.com (Chuck Musciano) writes: >I am currently in the midst of a quandary involving two different >menu interaction techniques... >Is there anything in the literature which supports either (or both) of >these claims? Any thoughts or opinions? With apologies that this is not an answer to your question, but I have some experience with a related popup menu interaction technique that seems quite useful so I thought you might like to hear about it. I am using a menu assisted text editor where the menu items are always the same and always in the same position with the exception that the most recent search string is added to the bottom of one menu, and the various windows/files that have been opened are available for selection at the bottom of another menu. However, when you pop up a menu, the highlighted item is always the last item selected. My first thought was that this would make it hard for me to learn to find menu items since my starting place was always different. Probably true but it has not turned out to be a very big loss since, as others have pointed out, selection from linear menu arrays never quite has the facility of "touch typing" anyway. Instead I quite like the fact that this menu interaction style creates kinesthetic "idioms" that are useful and quite a bit like touch typing. For example, repeating a search is done by first typing a search string and executing it, then the second time carefully selecting the search string on the menu from the middle mouse button popup menu (presuming the last use of that menu was not for a search). Then, subsequent searches are done by merely clicking the middle button rapidly without looking. Similarly, if I want to paste the same string in multiple places, I can select the location on the screen with the mouse then carefully select the paste menu item, then select another place and paste with a single rapid click. Another frequent idiom is to select with the mouse, then click on the cut menu item. Repetion here also becomes a simple select/click idiom. With three mouse buttons, I have the potential for interleaving three "current" actions. So far, I have not noticed using more than two, and some frequent sequences are not possible because they appear on the same menu. The menus are arranged logically, and I wonder if that is optimal. They are easier to learn as a result, but perhaps it would be better to look for the highest frequency of paired actions (search-paste, for example) and put those on different menus. This brings up another more subtle idiom. I changed the menus to place the search string and paste items adjacent thereby disrupting the "logical" order of the menu items. While the repetetive action of search and replace is not quite a simple click, it did become "touch typable" as well. I was able to learn the amount of movement to go to an adjacent menu item so I can go back and forth between the two items without visual confirmation. Finally, one difficulty with this scheme. It is not easy to click the mouse without a small cursor movement. There is evidence that this is a very common user error. Larry Tesler described the solution that I believe apple used in the lisa and in the mac. The mouse driver ignores small movements occurring with a button click. The interface I described above is quite sensitive to the much more "accurate" mouse driver of my $20,000 workstation. So while I dont have to look at the screen, I do have to be quite careful to hold the mouse still while clicking the button.
kent@sunfs3.camex.uucp (Kent Borg) (10/03/89)
In article <19812@mimsy.UUCP> don@brillig.umd.edu.UUCP (Don Hopkins) writes:
[Interesting stuff on the ability to mouse-ahead and that specific
menu items can be learned as motor memory in a way which is impossible
with linear menus.]
I begin to see the value in pie menus, but I am not yet convinced of
the extent of that value.
I think my concerns boil down to the following: menus are for more
than quickly making selections, but first let's look at the speed
issue.
Being able to mouse-ahead is most valuable as a dramatic illustration
of the fact that a user can remember how to make a choice without
careful use of visual feedback. That is a good feature, but let's not
put too much value on mousing-ahead. The bottom-of-the-line Macintosh
Plus manages to display menus very quickly. I don't think we should
excuse high-end workstations from at least matching that speed.
The other value to menus is that they present the user with choices
which must be recognized, but need not be remembered. Seen from that
perspective, the Macintosh menu bar is not a linear menu system.
Rather it is a very compact 2-dimensional menu system. The user can
fling the speed-scaled mouse at the top of the screen and hit the
mouse button. One remembered action and she is using the menus. Next
she can move the mouse left and right and be quickly be presented with
well over a hundred uncluttered menu choices.
Yes, for the Macintosh to operate on a screen which is narrower than
the sum of the widths of all of the indidual pulldown menus, the user
can only pull down one at a time, and the movement to do that is more
complicated because of it, but the pay-off is enormous.
The speed and ease with which the user can see all of the first level
menu choices is very important. It is one of the reasons I can sit
down at a new Macintosh program and immediately start using it.
I don't mean to get into a Macintosh menus vs. pie menus fight, but I
understand Macintosh menus and use them as a reference point.
Certainly the Macintosh user interface has problems, like the fact
that the menu bar keeps getting farther and farther away as we get
more and more screen real estate (though the above mentioned
speed-scaling of the pointer is very important in making life as easy
as it is now).
How do pie menus do at quickly presenting the user with lots of
choices?
--
Kent Borg "Then again I could be foolish
kent@lloyd.uucp not to quit while I'm ahead..."
or -from Evita (sung by Juan Peron)
...!husc6!lloyd!kent shf@well.UUCP (Stuart H. Ferguson) (10/09/89)
+-- kent@lloyd.UUCP (Kent Borg) writes: | In article <19812@mimsy.UUCP> don@brillig.umd.edu.UUCP (Don Hopkins) writes: | [ ... ] | The other value to menus is that they present the user with choices | which must be recognized, but need not be remembered. Seen from that | perspective, the Macintosh menu bar is not a linear menu system. | Rather it is a very compact 2-dimensional menu system. The user can | [ ... ] quickly be presented with | well over a hundred uncluttered menu choices. | | The speed and ease with which the user can see all of the first level | menu choices is very important. It is one of the reasons I can sit | down at a new Macintosh program and immediately start using it. | [ ... ] | How do pie menus do at quickly presenting the user with lots of | choices? So what's so great about hundreds of menu choices? Most of the programs I've seen with these kinds of menus suffer from what I would call, "digital watch syndrome." Dozens of different functions are all cramed together into the same interface without regard for a logical, coherent structure for them to coexist. The result is like those watches that do about 57 different things all controlled with four buttons. The Xerox Star interface had very few menus, perhaps half a dozen or a dozen per application, and most of those were "expert features." Much of the interaction was done through "Property Sheets," which were control windows that let the user set the attributes of an object in the interface. The user selects the object she wants, presses the PROP'S key on the keyboard, and the property sheet opens, which can be examined and optionally modified. Probably 90% of the interaction was done using property sheets and a set of eight standard function keys that operated polymorphically across the objects in the system. (Sort of like the Cut, Copy and Paste are supposed to work on the Mac, but don't.) The result is a much more "browse-able" interface. The user need only be concerned with the object that needs changing at the moment, and never even needs to see the options available for any others. The user also doesn't have to figure out by trial and error which commands and options apply to which objects. If she wants to change the attributes of a paragraph, she just selects that paragraph and looks at its properties. All the properties for a paragraph are right there. It's true that all the options in a Mac program are visible immediately, but I don't necessarily consider this an advantage. Global and object-specific commands, as well as global and object-specific options are all intermixed in the same hierarchical menu structure, with only very loose guiding principles for what items go together or don't. If someone thinks of a neat feature, it can just be added to the menu somewhere, like another digital watch function. The Star had a lot of really nice ideas that seemed to get dropped along the way somewhere. When I first started playing with the Star- style of user interface only a short time ago, I was quite astonished at how it got by with so few menus, and replaced a proliferation of menus with a system of interaction that was better organized, cleaner and easier to learn. The trend these days seems to be that if a program has more menus, it must be better. I would be very happy if this reversed, so that a program with fewer menus was considered the better. P.S. A Xerox Star retrospective was published in an IEEE mag recently. Perhaps someone would be kind enough to give the full reference, as my Xerox copy doesn't. -- Stuart Ferguson (shf@well.UUCP) Action by HAVOC (ferguson@metaphor.com)
ria@PacBell.COM (Richard I Anderson) (10/10/89)
In article <14011@well.UUCP> shf@well.UUCP (Stuart H. Ferguson) writes: >P.S. A Xerox Star retrospective was published in an IEEE mag recently. >Perhaps someone would be kind enough to give the full reference, as >my Xerox copy doesn't. IEEE Computer, September 1989, volume 22(9). Five of the authors also presented a variation of this retrospective at the September BayCHI meeting at XEROX PARC. Both were well worth my time. Richard I. Anderson Human Factors Consultant Pacific Bell 2600 Camino Ramon, Room 2E850 (415)823-3715 San Ramon, CA 94583 ria@pbhyg.PacBell.COM
kent@sunfs3.camex.uucp (Kent Borg) (10/13/89)
In article <14011@well.UUCP> shf@well.UUCP (Stuart H. Ferguson) writes: >+-- kent@lloyd.UUCP (Kent Borg) writes: >| The other value to menus is that they present the user with choices >| which must be recognized, but need not be remembered. Seen from that >| perspective, the Macintosh menu bar is not a linear menu system. >| Rather it is a very compact 2-dimensional menu system. The user can >| [ ... ] quickly be presented with >| well over a hundred uncluttered menu choices. > >So what's so great about hundreds of menu choices? Most of the programs >I've seen with these kinds of menus suffer from what I would call, "digital >watch syndrome." Dozens of different functions are all cramed together >into the same interface without regard for a logical, coherent structure >for them to coexist. The result is like those watches that do about 57 >different things all controlled with four buttons. Yes, many Macintosh programs suffer from bad cases of featuritus, and when someone complains about it they often use the original MacDraw as an example of a clean user interface. I don't hear people complain that the original MacDraw was too cluttered. In fact, MacDraw 1.9.5 was the program I looked at to estimate the number of menu choices in a `typical' Macintosh program. There are 152 individual menui choices in MacDraw 1.9.5, plus whatever fonts you have installed. Sounds like a lot, but when you use the program it doesn't look so bad. The "Fill" menu has a block of 36 different patterns, and the "Pen" menu is the same, but because they are visually clear, users do not need to wade through those 72 items when looking for the way to control layering or drawing size. The "Line" menu is also visually clear--being samples of the line weights available. That makes 3 of the 9 menus easily understood. Of the remaining 6, "File" and "Edit" are where they always are and pretty much do what they always do. Next, the "Style" and "Font" menus are also easily recognizable by a Macintosh user. That leaves "Arrange" and "Layout". These two menus and their 25 items are the main place a new MacDraw user needs to look to see what MacDraw is about. The "well over a hundred" menu choices need not look like the clutter of two decks of cards dropped on the floor, they should be well layed out and be quite clear. >The user need only be concerned with the object that needs changing >at the moment, and never even needs to see the options available for >any others. I can see how that makes dealing with that current object easier than being confronted with the whole program the whole time, but it seems to me that being confronted with a multitude of changing option sets depending on the current object would make it so the the user can never feel that she knows the program and has seen what it can do, instead she is constantly obligated to rescan the menus to see what new options might be available now. >The Star had a lot of really nice ideas that seemed to get dropped >along the way somewhere. When I first started playing with the Star- >style of user interface only a short time ago, I was quite astonished >at how it got by with so few menus, and replaced a proliferation of >menus with a system of interaction that was better organized, cleaner >and easier to learn. Sounds interesting. I have never met a Star in the flesh, anybody in the Boston area have one I could see? -- Kent Borg "Then again I could be foolish kent@lloyd.uucp not to quit while I'm ahead..." or -from Evita (sung by Juan Peron) ...!husc6!lloyd!kent