It was in the Poincaré project that I first started experimenting with visual effects to convey information. I developed panels – interactive version of the boxes commonly used in mathematics texts to highlight important formulas, theorems and other information. The key idea: the panels appeared to be raised, suggesting (I hoped) that there was something linked “behind” them and inviting students to click to find out what that was.

Here are some sample raised panels.

I don’t remember how I made these panels. They look like one-celled tables – perhaps I did them that way and made screen captures, though I seem to remember using SuperPaint as well.. The colours were ugly and badly chosen – I usually have a better colour sense than that, really!

Later in the project, I used a depressed version of these panels to indicate that the student had moved to the corresponding “behind” page. Here’s another raised panel together with its depressed form.

Producing the mathematical text for this project was a major hassle. Since browsers couldn’t handle typesetting mathematical text (and still can’t, at least not with any agility), each mathematical fragment had to be created as a PICT in Expressionist and then pasted into PageMill (which converted it into a GIF). Here are a simple samples.

And another more complicated one: .

(Expressionist was an early editor for mathematical text, similar to the current MathType, and has since changed hands twice to become Expression Editor. PageMill was an early Adobe webpage editor.)

The issues associated with producing mathematical text this way can be horrendous.

• First, in any project with even a moderate amount of mathematical text, the required GIFs have to be managed and edited. A mathematical GIF found to have even the smallest typo has to be located, recreated and reimported back into the webpage. A substantial number of mathematical GIFs requiring editing makes for an impossibly expanded workload for the webpage author.
• A further complication arises if the mathematics is to be displayed inline (as opposed to on a separate line). It is nearly impossible to line up the baseline of the pictorial mathematical text with the baseline of the surrounding non-pictorial text. For example, the last formula above should properly have the w of the mathematical text aligned with the text surrounding the GIF, not above it. Most browsers can only line up the bottom of the GIF with the bottom, middle or top of the surrounding text; the result is usually mis-aligned mathematics. (For example, experimentation shows that the best available alignment for the abovementioned formula for w is "absolute middle" - at least in Safari.)
• The remaining issue is resizing mathematical text. Inline GIFs are created in a single size and do not resize as the surrounding text is resized. A viewer with vision problems who needs to increase the font size must put up with the ugliness of improperly sized mathematics text while still dealing with the difficulty of reading that text.

All of these issues were supposed to become resolved by the development of MathML (Mathematical Markup Language), an application of XML which produces mathematical text on webpages as editable as ordinary language. Unfortunately, though development began a decade or so ago, MathML has not yet evolved much beyond a specialty tool for journals and other high-end technical publishing interests. Most browsers cannot yet display MathML without specialized plugins, and easy-to-use software for creating and editing MathML is essentially non-existent. (The closest contender is MathType.)