[Top][All Lists]

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

[Axiom-developer] A Canonical Axiom GUI

From: C Y
Subject: [Axiom-developer] A Canonical Axiom GUI
Date: Thu, 7 Sep 2006 13:28:51 -0700 (PDT)

While I agree that it is desirable to have Axiom be as easy as possible
to interface with from a GUI standpoint, I disagree that there
shouldn't be a canonical Axiom GUI.  This does not, please note, mean
that I think there should be ONLY one GUI for Axiom - people should be
free to make as many GUIs as they want.  The observation that different
people will want (and be more productive in) different environments is
quite correct.  However, there should be one GUI that is designed to be
the "default" GUI for Axiom.

For both Maple and Mathematica, there is one GUI which is designed to
offer an intelligent, organized way to deal with mathematical problems,
objects, and documents.  In each case this GUI is the "public face" of
the program and serves as both a convenient tool for document
formatting and as visual evidence of the effort put into making the
product a "finished, polished tool."  It is a re-assurance (however
potentially false) that work has gone into making sure that the user
won't have to deal with problems that programmers would normally deal

I won't argue with those who will point out that this doesn't mean
anything about how good the mathematical abilities of the software are
- indeed, I agree with them.  But for those who will evaluate Axiom as
a tool to use, the metrics they will be using in some form are:

1.  Does this project look like a serious, able, and high quality
2.  How friendly is it to use to do what I need to do?
3.  How much time will it take me to learn enough with this tool to
become productive?

It takes enough time and energy to evaluate a tool such as Axiom in a
non-trivial way that the motivation to do so must be extreme.  (How
many people here have seen a sub-optimal tool used simply because
people already knew it and thought it would be faster to use that tool
instead of learn one they knew might be better?)

For serious research, this may not be a problem.  Axiom has a very
strong foundation, and there are very probably lots of projects where
the time spent learning Axiom will pay off well enough to motivate
people to learn it, GUI or not.  Many more, however, will not be that

I would personally prefer that there exist a GUI for Axiom that is
designed by the same people who are intimately familiar with the system
itself, and (for example) might be able to teach a graphical
environment to associate type information with graphical behavior in
the GUI.  (Imagine, for example, a GUI that would let someone drag a
polynomial into an integration template but would refuse a matrix as an
incompatible type.  Or a formula template for ballistic motion that
would reject anything with the wrong type in its slots.  The visual
display may or may not contain all of the important information for the
user, but a GUI working with the type system itself could be far more
intelligent.)  My guess is 3rd party graphical systems are not likely
to be interested in this type of work, preferring instead to simply use
Axiom as a mathematical engine to get answers to common problems.  

I think it would be desirable for people who download and install
Axiom, when they type "axiom" or click their Axiom icon, to have a GUI
environment available that is similar in concept to the Maple and
Mathematica environments, but perhaps with more or different
functionality.  Our "first impression" with potential users is what
they see when they start the program, and I would personally like there
to be a smooth, polished, and professional GUI as our first foot

Of course, someone would need to create such an environment, and code
always speaks louder than emails.  I have looked at these issues a
little bit and will attempt to pursue them further, but I know the
problem is significant.  I guess it boils down to this:

1.  I think a default GUI for Axiom would be a Very Good Thing
2.  The project is not yet a a point where this should be a major focus
for the project as a whole.
3.  The work to make Axiom more friendly to ALL GUIs should be more
important, because it will be useful to a very broad spectrum of
applications.  (Indeed, even the command prompt probably should work
off of the same API some day.)
4.  Code counts more than opinions, so I'll be quiet until I have more
of the former ;-).


Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]