Mathematica 9 is now available
Services & Resources / Wolfram Forums
-----
 /
MathGroup Archive
2005
*January
*February
*March
*April
*May
*June
*July
*August
*September
*October
*November
*December
*Archive Index
*Ask about this page
*Print this page
*Give us feedback
*Sign up for the Wolfram Insider

MathGroup Archive 2005

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: Getting a pure text widget?

  • To: mathgroup at smc.vnet.net
  • Subject: [mg61386] Re: [mg61355] Getting a pure text widget?
  • From: "David Park" <djmp at earthlink.net>
  • Date: Mon, 17 Oct 2005 02:29:55 -0400 (EDT)
  • Sender: owner-wri-mathgroup at wolfram.com

Steven,

I'm certainly glad I don't have Linux! A friend with Linux couldn't use a
style sheet I designed because it used Helvetica font in some of the titles
and apparently Linux doesn't handle Helvetica. I finally changed the style
sheet to accommodate Linux people. Your problems sound even worse. If the
notebook interface works so poorly that you are seriously thinking of
writing your own GUI, then I think you have real cause for complaint. Maybe
you should think of a Mac, or a Microsoft system, at least for Mathematica.
It certainly will be much less expensive than writing your own GUI.

I think that your difficulty with the notebook concept is mostly that you
don't have an implementation in which it works properly. That rather
destroys the chances of getting the most out of it. It's not difficult to
use - when it is working.

In any case, let's hope that Mathematica and Linux get better in step.

In Mathematica notebooks you can put much of the source code in special
initialization sections that the reader might not look at, unless they are
curious. You can also put source code in a package. You can hide the input
code for graphics by putting it in a closed cell, which occupies only a thin
space with a bracket at the right. The user can evaluate the cell and get
the graphics without seeing the code. But the code has to be somewhere,
either in a package or special Sections or in closed cells, and of course in
the kernel. Otherwise there will not be an interactive system. And sometimes
you will want the reader to see the code. It depends on what you're
communicating and who you're communicating to. I think it would be possible
to hide all of the source code. Sometimes I like to do derivations where I
use Print statements to annotate the steps. One could close the input cell
and just have the steps with the annotation.

There are things in Mathematica notebooks that I would like to see improved.
I've posted on this before. None of the supplied style sheets are entirely
to my taste. Some of them are downright silly. But since we can design our
own style sheets (if we have a system that works!) this is not a serious
point. Except that it would be nice to work with a style sheet that
everybody has. Some of the things I would like to see are:
1) The font size for text should be more commensurate with the font used in
input and output cells. In scientific papers the fonts are approximately the
same size.
2) I would like to see group open/close icons on all Section type headers -
but NOT on anything else. The open/close icons are intuitive and everybody
figures out how to use them. Double-clicking the rhs bracket sometimes
eludes even super geniuses.
3) I would like to see one extra level of Section header.

If the reader has the option of typing any expository text he wants, if he
can evaluate any command that is in Mathematica, the notebook or a loaded
package, if he can make any kind of graphics he wants, then how can a
palette provide better options? Palettes generally do not give freedom but
restriction. The most useful ones are ones that simply paste very common
constructions that are difficult to type. It is very difficult to design
general purpose palettes that will have wide use. The more sophisticated and
interactive the palette is, the more difficult it is to learn. Also if the
output is displayed in the palette or widget, then it is also usually
replaced when other choices are made and there is not a permanent record.

So I still think that the classic text-equation-diagram notebook interface
is the best and most versatile - provided one has one that works.

David Park
djmp at earthlink.net
http://home.earthlink.net/~djmp/


From: Steven T. Hatton [mailto:hattons at globalsymmetry.com]
To: mathgroup at smc.vnet.net


[I'm not sure what the fate of this mail will be.  I just subscribed to the
mailing list.  I had been using the usenet interface exclusively.]
On Sunday 16 October 2005 13:46, David Park wrote:
> Steven,
>
> I am going to take a different position on this. I think that Mathematica
> has a perfectly good user interface, which is the Mathematica notebook.

I suggest you read this through before commenting.  There are two levels of
ideas presented here.  One has to do with how the Mathematica document
concept could be improved.  That is really secondary to my current
objective.
My current objective is to have a GUI that works.  The current GUI
distributed with Mathematica 5.2 for Linux is obsolete and broken.

The Notebook itself is something of a nebulous concept.  We have the
document
class called Mathematica Notebook which typically has a filename extension
of .nb.  We also have the runtime instance which is represented by an
instance of the Mathematica FrontEnd window.  The FrontEnd window could be
considered as a superset of the actual runtime instantiation of a
Mathematica
Notebook.  For purposes of this discussion I will try to distinguish between
the textual entity stored persistently on a harddrive, the runtime
representation of that entity, and the GUI used to control that runtime
instance.  I believe all three of these classes are flawed in their own way.

Mathematica Notebooks are stored as monolithic entities with both program
generated data and user produced source code intermingled.  For example,
graphics data is stored in the same file as user source code.  There are
significant disadvantages to that.  It's more difficult to decouple input
from output when transferring informmation.  Sourcecode becomes vulnerable
to
corruption of output data, etc.  The syntax in which the sourcecode is
stored
is very hard to read because of the nesting of quotation and other escape
characters.  Ideally content should be decoupled from presentation as much
as
possible.  That is currently not how notebooks are structured.

> The Mathematica notebook follows a tradition of technical publication that
> goes back at least to Euclid. The interface is the blending together of
> expository text, equations and diagrams. This is what one sees in
> mathematical, scientific and technical journals today. It is what one sees
> in textbooks. One might call it the classic text-equation-diagram
> interface.

I've stated in the past that the facility for typesetting mathematical
notation, and also processing that notation is very impressive.  That is one
of the features I am eager to maintain in any UI I happen to create (though
from the looks of things, I don't believe I can achieve my objectives with
the tools available.)

> But the Mathematica notebook is a revolutionary advance over the classic
> interface. It is so new that only a few have absorbed its capabilities and
> made effective use of them. With the Mathematica engine behind it, a
> Mathematica notebook follows but becomes much more powerful than the
> classic interface. A short notebook can generate calculations, graphics
and
> animation. A reader can modify any of these elements. A notebook can
> include routines and tools that a reader can use to check or extend the
> material in the notebook. A reader can add calculations and also add
> comments and text. In other words a Mathematica notebook is an active
> text-equation-diagram document.

It would benefit greatly from a formal document definition facility, as well
as document definitions based on that facility.  The current stylesheets mix
structure and presentation in ways that make it difficult to decouple.
Also,
the existing stylesheets are poorly documented.  That is, unless there is
documentation I am not aware of.

> A Mathematica notebook, if handled properly, is already far superior to
> classic techincal papers and instructional material.

I do not believe Mathematic is the superlative mathematical editing tool.
Support or XML DTDs, or other formal document definition formats would
greatly improve its usability.  A stylesheet definition along the lines of
CSS would also be of value.

> In my limited experience I have observed that most users do not bother to
> learn how to use the notebook interface. They don't know how to use Text
> cells, or enter mathematical expressions in the text cells. They don't
know
> how to use the Section/Subsection organization of a notebook. They often
> opt for Manual Grouping, which practically destroys the notebook concept.
> Manual Grouping destroys the reader's ability to easily add material to a
> notebook and that's one of the revolutionary advantages! They put in a
> rainbow of colors that has no meaning to the typical reader and that only
> distracts from the presentation of the material. Instead of using Titles
> and Subtitles at the top of the notebook they put them anywhere and
> sometimes use them for comments! They don't know how to use graphics and
> animation. They generally slight textual exposition, which is just as
> important as the calculations.

It may also be the case that the current implementation is unnecessarily
difficult to work with.  It doesn't help that the stylesheet implementation
on Linux is simply broken, and does not function as documented, nor does it
function in a coherent fashion.  This has been broken for a long time.

> I believe that we are still learning how to use the notebook style.
Perhaps
> the great Masterpieces of 'Classical Mathematica' have yet to be produced.
> It's a metter of good material, good writing, good style and elegance.

Mathematica does not have a monopoly on structured document formmat.  I find
XEmacs, PSGML, and the DocBook DTD to be superior to Mathematica for
producing structured documents.  The biggest limitation is the ability to
fromat mathematical expressions as they are input.

> As for widgets and palette interfaces - I'm generally opposed to them for
> several reasons.
>
> 1) It is extremely difficult to make an interface that is as versatile as
> the text-equation-diagram interface. Non-notebook interfaces usually end
up
> being limited choice devices and are therefore quite restrictive.

The current FrontEnd GUI on Linux doesn't even allow the user to paste a
string into the search dialog when doing search and replace.  The help
browser truncates the display of long section titles, and offers no way to
scroll the display, nor to change the size of the displayed window.  The
file
access widget is extremely painful to use.  The property browser is
non-functional 50% of the time.  For some reason it rebuilds the display
while the user is making modifications.  The users modifications are
therefore reset to the values they had when the dialog was opened.  The
commands described in the Mathematica book for opening and otherwise
controlling notebooks do not behave as documented.  Not even the scrollwheel
for the mouse works.  And imwheel is not an option.

My current objective is simply to create a GUI that works correctly.  The
one
provided for Linux is broken.

> 2) People already understand the text-equation-diagram interface.
(Actually
> many don't but they are in a preliterate state.) Each new pallete or
widget
> interface presents a new learning challenge. It's true that the
> introduction of Windows type GUI computer interface from PARC was a vast
> improvement on the old command line computer interface. But it only
brought
> us back to the possibility of an active text-equation-diagram interface.

Pallets are useful in presenting the user with a range of options which
would
be difficult to present using only the document interface.  The most
valuable
pallets tend to be the ones which show the alternative methods of inputing
the same information.  Pallets are, for the most part, pedagogical devices.
I don't use them very often.  Nonetheless, I just looked at the available
pallets and discovered new features of Mathematica's diffeq support.

> The Mathematica notebook already incorporates this. It may be possible to
> come up with something different and better - but it's going to be very
> difficult.
>
> 3) Is the widget going to completely replace notebooks or is it going to
be
> some kind of extra palette tool? Competition to get your widget on the
> desktop is fierce. Desktop space is precious. One will have to come up
with
> something really good to get one's widget on very many people's desktops.

How 'bout a Mathematica Notebook interface that works as documented?  The
widget I want is almost identical to the one you get when you type in
`mathematica' in a xterm.  The only difference between that and what I want
is the one I want will not have any Motif functionality.  I will provide my
own file browser, etc.

--
Regards,
Steven


  • Prev by Date: Re: Getting a pure text widget?
  • Next by Date: boolean function, interpolation
  • Previous by thread: Re: Re: Getting a pure text widget?
  • Next by thread: Re: Getting a pure text widget?