[snip]
The first point is true, but should be stressed as to WHO uses this menu for easy and logical navigation. The people who regularly use a particular application rarely use the menu system to access it, and instead simply type in the appropriate command. This means that logical navigation is a bit more important that easy navigation. We are designing this menu for NEW users, who have no idea what programs are available to them and do not know any other way of finding them. Naturally, they will want to browse what is available in their particular speciality, but when they begin to get to work, they may also want to browse by the functionality of the program, not which discipline tends to use it.
That is a very good point. I never use the menu at all, primarily because navigating the menu IS so convoluted. I was thinking I might actually use it more if there was better organization, but I like your point.. the menu system should really be thought of as a tool to organize apps for one who doesn't know what app they want to use, but knows what they want to accomplish.
The second point is very important, but only to a limit. Browse the Apps>>Tools on the debian menu, and you will find WAY too many programs, thus making the entire menu system useless.
Heh, I was thinking of making the exact opposite statement. On my system, "apps->tools" contains 21 items (though I don't have all of kde and gnome on this system). I find that perfectly easy to scan down and see potential programs. However, if a menu is too deep (i.e. greater than 4 levels), it becomes virtually impossible to 'browse' since one has to constantly backtrack without falling off the menu with the mouse. I was therefor thinking of proposing an upper limit on menu depth rather than width. You make a great point though, so maybe the issue comes down to finding an aspect ratio that is a good balance between the two.
I suggest that each end category contain a maximum of ten programs. If more are written we can further subdivide that particular branch (science or tools)
My preference would be for an upper limit of more like 15-20 items per list, but I like the idea. [snip]
3) Apps>>Science>> This is where we can provide ONE list of GENERAL science topics. I suggest using names of departments in a large university. I used life sciences and social sciences to minimize on the number of menu items, while maintaining clarity. I suggest: Engineering Chemistry Physics Medicine Geography Computer Science Statistics Life Sciences Social Sciences
I like this list. I think the length is good and leaves few gaps. Logically, I tend to think of Medicine as a category under Life Sciences, but perhaps the disproportionate number of potential entries under Med warrant it's separation. Also, Statistics seems out of place under science. I would suggest putting it in the tools section you mentioned before or under a broader section such as "math tools" under science. Several suggestion have been to look at classifications used in Universities, but maybe going the other direction is better. The broader groupings used in High Schools or the equivalent might keep things simpler.
As an engineer, who is also a scientist (and many are not), I will defend the need for a separate menu item. In the future, when more academics learn how to program, we will have many more science programs to use, and at that point we can add subdivisions to these categories.
I'll agree that a separate menu item is warranted (especially for things like CADand design programs), but does it belong under science? Cheers, JDR