I'm mainly a Mac guy. My affair with the fairer platform began thirteen years ago, and I've been developing on the Mac for close to ten years. I can still remember the days of Codewarrior, MPW, and Macsbug. Anyone care to A9F4? So by now, I hope that I've convinced you that I'm very much a fan of the Mac user experience.

I found this to be a mixed blessing. First of all, it's given me a relatively unique perspective on design, which I hope has contributed to some of the niceties in our product. But I must profess an ignorance of the "Windows Way" of doing things, like how most Windows users immediately reach for the F1 (help) key for help upon launching a new program. As such I've occasionally found myself at odds with some of the other design philosophies in our group. Some of my handiwork has what I'd like to think of as a distinct Mac flavor to it, and may seem odd on other platforms. So if this doesn't suit your palette, I'm the cause.

At last a segue into my thesis: palettes. Maple 10 brought with it a vastly expanded array of palettes. It's a far cry from the four choices you had in 9.5 and earlier. Now we have over 1200 symbols, two arrays of units, layout and expression templates, embedded components, a matrix palette, and handwriting recognizer. That's a mouthful.

It started with the specification for our new 2D math editor. We set out to create the best editor in the industry. Bringing such a beast to life requires an immense amount of work. One feature that was in our mandate was the support for as many MathML symbols as we could muster. I was put in charge of making this happen.

Fortunately, we didn't have to create these symbols by hand (and thus were able to save on large turnover in our art department). We discovered the ESSTIX project, a series of TrueType fonts designed by some talented typographers containing a large portion of the symbols we wanted to use. Best of all, this font was GPL, meaning we could incorporate it into Maple. To celebrate this discovery, we held an Alien movie marathon with a lot of beer and pizza.

So that solved the problem of displaying the fonts. But how would our users get them into their documents? ESSTIX brought us well over 1200 available characters.

We started with the idea that you could browse the symbols the same way you would browse a Japanese character dictionary. We arranged the characters into groups related by semantic meaning, and displayed them in these groups like the Symbols palette in Maple 9.5. (The groups were not designed to be mutually exclusive, so you'll see some symbols intentionally duplicated across several palettes.)

We only had forty-odd symbols in the old Symbol palette. Supposing we double that number, probably the largest we could practically make a usable palette, we'd still need around fifteen palettes full of symbols. That's too much to fit on screen at once, so we needed the ability to choose which ones to show or hide. Also, it would have been nice to rearrange them to suit current needs.

We also wanted to allow users to see several groups of symbols simultaneously. Our palettes in 9.5 were based on a popular "card layout" design found in many email clients, such as Outlook. This design was clean and simple, but had the drawback that only one palette of symbols was visible in each palette area.

We had a lot more in mind—the feature list was longer than the list of palettes—but we kept to only the most basic and useful for this release. That left the three big things mentioned above: showing and hiding palettes, showing more than one palette at once, and reordering palettes.

The first item was child's play. We broke the problem down into a simple combination of menu items and a dialog box.

For the second problem, we took cues from two of my favorite applications: Microsoft Word (seriously) and OmniGraffle for Mac OS X. We went with their disclosure triangle-based utility palette design rather than the card layout design in Outlook. This had the advantage that you could see more than one group at once in the same region. As a bonus, we could get away with not having palettes on the top or bottom, which made our main window much less cluttered. But the main advantage was that we were able to create the concept of a spatial unit of symbols that essentially behaved like a miniature window. Since users are familiar with how windows work, it made the solution to the third problem a lot easier.

The third problem was technically the most interesting challenge. Naturally, we wanted to allow users to move palettes with a mouse and with our mini-windows we had an obvious way of doing this: drag the title bar. But this introduced some feedback issues. We had to invent some techniques to do animation with the palettes so that their movements wouldn't be too jarring when dragging a palette between other palettes in the main window. If we don't have sufficient feedback when dragging, it's "oops, where did my palettes go?" Originally, we had the palettes separate by the height of the dragged palette. That was impractical as it often forced most of the palettes off-screen, so in the end we only moved the palettes by a tiny bit and the animation effect is much less pronounced.

We use a similar technique for expanding or collapsing the palettes to provide feedback. You can see the animation at work much more clearly there.

Animation was rather tricky to get right in the first place. It's not as simple as "move, wait, move, wait." If you've used the palettes for a while, you'll notice that each animation always takes the same amount of time. Whether you're running on a 3.6 GHz Athlon or a humble G3 iMac, it takes n seconds to expand a palette. This was achieved by using a separate thread and a whole lot of synchronization. (Java's Swing, the framework we use to display the worksheet, doesn't play nice with threads.) Why go through all this trouble? Because as important and useful as it is, animation is just eye candy, and it should never slow down the system. This is a cue we took from Mac OS X itself. Of all the fancy window animations it has, and no matter how stressed your system is at the time, you'll notice that they never take longer, they only get choppier.

Now that we had a bunch of palettes for the symbols, and a suitable framework to move the around, we decided to push the envelope a little. Of all the possible innovations that we kicked back and forth, the two sexiest ones we found were the matrix palette and handwriting recognition palette. Both look great from a marketing perspective, but more importantly, both are pretty dang useful.

The matrix palette is a very simple device. You click and a drop down menu appears, allowing you to select how many rows and columns you want. It requires virtually no explanation. We threw in a few more options for choosing the structure and whatnot, and before you knew it we were using it all the time in-house. I don't think I've ever seen a matrix editor quite like this so I'll tentatively declare it the first of its kind.

The handwriting palette I like to think of as the star of the show. It's just so cool that you just want to poke it with a stick. This was the most interesting way we came up with to choose symbols in Maple. You make a (possibly crude) rendition of some character with the mouse and it appears like magic, saving you from digging through a dozen palettes.

I'd love to go into the details of how the handwriting recognition technology works and the intricacies of designing a system that has to work with (possibly) poorly drawn input with very little training data for such a large set of symbols. (Some symbols have only one instance of training data.) But that's another blog entry altogether.

That, in a nutshell, is palettes. I think the feature turned out pretty well and I'm proud of it. Of course there are some things that we didn't get around to, but I actually prefer it that way, as it's much better to do a smaller number of things really well than a large number of things half-a—… er, half-heartedly.

So now I open it up to you guys. You've been using our product for a while and I've got some questions for you:

1. Which palette(s) do you use most often?
2. How do you like to arrange your palettes?
3. What would you like to see added to the palette arsenal?
4. What do you find annoying or irritating about them?
5. How do they speed up or slow down your workflow?
6. Do you care about any of this, and do you want to know more about the development process at Maple?
7. Is there anything you'd like to say to me/GUI/Maplesoft?

I know that those of you who are beta testers can leave comments in the forums, but the beta process happens fairly late in the development cycle so we don't get to implement the more extravagant suggestions. I can't promise that every suggestion you leave here will see the light of day, but here's a chance to let us know what you think.

Thank you, and I hope we passed the audition.