[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian menu and the Apps/Science section



gnwiii@gmail.com wrote:
On 5/14/06, Paul E Condon <pecondon@mesanetworks.net> wrote:

I suggest that the heirarchy be patterned after the organizational
structure of the faculty of a major university. There is, I believe, a
lot of agreement on this structure.


No there is not agreement.  Harvard ended up with the Divison of
Engineering and Applied Sciences (DEAP) as it was called only after
a bid to transfer the funds to MIT was blocked by the court.  Superb
research programs have encountered difficulties because they were
considered "off-topic" by the conventional disciplines -- too applied for
the maths dept, too mathy for the botany dept.

One way to defeat the tradional academic breakdown would be to
permit multiple categories, e.g.,

Ag(riculture), Bo(tany), Ch(emistry), Ec(onomics), Ma(thematics), Ph(ysics),
Ag+Ma, Ma+Ph, etc.

Some may object that certain
departments at their university don't really do Science with a capital
's'. But few would hold that these non-Science departments do not
actually exist. So, the structure provides a convenient place to put
any software associated with any activity whose practitioners aspire
to being 'scientists'.  Any other structure, opens Debian to becoming
a battleground for an academic war. Because I am somewhat parochial
American, I suggest some sort of union of the tree structures of the
several Ivy League schools.


Some math dept's would put "mathematical software" in the category of
non-math just as some physics depts would put economics in non-science.

Alternatively, look at the faculty structures of the top dozen schools
in the world in terms of the number of Nobel Prize winners on the
faculty. But this alternative suffers from there being good scientific
activities for which there is no Nobel Prize.


The goal for Debian should be to make it easier for users to locate
tools for their problems.  There are many tools that are specific to
a narrow subject area (e.g., DNA sequencing apps could be biology,
medicine, forensic, agriculture, fisheries) and others (vector/matrix
languages such as octave, Gnu Data Language, S+) that are used in
many different fields.  One way to implement this would be to support
multiple established classification systems and and let authors/packagers
choose the system(s) that feels right to them.  The top level breakdown
would be done by the classification scheme.  Multiple schemes would
be handled by having, e.g., AMS, GAMS, AMS+GAMS, ..., "3 or more".

I'm familiar with GAMS and the AMS 2000 schemes:

    <http://gams.nist.gov/Taxonomy.html>.
The current GAMS scheme is viewed as part of a larger scheme
encompassing all software, but I don't know if the larger scheme
has ever been put to practice.

American Math Society 2000 Mathematics Subject Classification
<http://www.ams.org/msc/>

http://xml.coverpages.org/classification.html lists many classification
systems -- if someone feels they can't use GAMS or AMS, the might
find something here.

The problem is that deciding on a menu structure will never satisfy all
users, especially when there are equally valid choices.

It is no good aiming to satisfy only 90% of users. If each choice/feature
in a system (such as the linux desktop) satisfies 90% (and dis-satisfies 10%),
then after 21 such features, 90% of users will be dis-satisfied with *something*.

The thing that should be fixed is that a window manager or menuing service should
allow a user to easily configure (preferrably with visual drag-n-drop) where the
new menu entry should be placed when an application is installed.

Menu attributes of an install package should all have equal precedence so that
no hierarchy is implied, other than a sensible default. Eg, an app might have
the menu attributes:

science, physics, relativity

and that can reflect the default menu hierarchy. However, if the user already has
a menu structure with:

science|relativity|physics
science|relativity|philosophy
etc

then the app can by default put an entry into science|relativity|physics.

The user could even set an option so that if there is no menu path matching
all the menu attributes of a package, then a dialog could be displayed for
the user to choose/create a menu path.



Reply to: