I think the real point of this discussion is how should a menu be organized to
facilitate easy and logical navigation to an app.
I think we should not overly subdivide.
How many of us actually have more than 5-10 apps installed for a given field?
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.
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.
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)
Using this rule of thumb, I suggest the following menu changes:
1) XShells goes to Shells>>XShells, and the contents of
Apps>>Shells (thus reducing the number of selections in
Apps)
2) Apps>>Tools>> Add a list of tasks in the
tools menu and subdivide by which program performs that particular task
making sure that only 10 or less programs appear in each item on the
list. Scientists are free to use the tools menu item too.
Unfortunately, this list is not up for discussion on this forum, but I
will add in my suggestion:
Plotting
Simulation
Conversion
Organization
and a few others.....
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
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.
Any comments?