Re: Bug#361418: Debian menu and the Apps/Science section
[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
Reply to: