Follow by Email

Sunday, March 18, 2012

Overly-ambitious Projects

Sometimes we underestimate how difficult a task is. Like nearly all of the time. But this is not why we choose overly-ambitious ways of solving problems. So let's talk about why.

I have tackled several overly-large projects and sometimes I have chosen to split them up along natural lines. When handling large projects, not all of them are easily split up by top-down decomposition.

Let's first look at a project that can be split up: Overhaul Painter's user interface (UI). First off, why did we do it?

Painter's interface was getting too complex, and needed organization. It also needed to be easier and more accessible. More items in the interface simply called for a better way of organizing it. So this was a redesign borne out of necessity.

But by then with the features of Painter 2.0 and also Painter/X2 in one program, it looked like a big task. We needed to split it up.

This could be divided up, a little bit, and, in the development time frame we had at our disposal, John Derry and I sought to split it up between design and implementation. Just so we could get to the independent implementation part of the job. It sounded like an easy task: just basic planning. But it wasn't easy at all.

Redesigning the Painter 3 Interface

First we examined the items that needed to be in the interface. Then we organized them according to function and sometimes according to property. We worked out some basic areas: choosing brushes to use, choosing materials to paint with or design with, adjusting brush properties, and other. You see, things like selections (which had just been renamed paths from the original term, friskets), layers (which were called floaters by some unfortunate consequence that they had come from floating selections), and scripts had no obvious organization.

We were looking at a five-color-icon organization for these palettes. Based on the problem of icon hell: too many icons made for a totally indecipherable interface. I think all interface designers go through this.

We knew colors could be detracting, so we laid out the palettes in predominantly dark gray, with a texture to them. We wanted things to be three-dimensional and basically understandable because they were analogs of the real thing. It is possible that color was a distracting feature of the user interface and added to the complexity and detracted from the accessibility. The modern version of Painter (12) use icons that are grayscale instead. The texture that backs the palettes is a precursor of skeuomorphic design.

You see the Materials palette. With colors, papers, grads (graduations), sets (color sets) and weaves. OK the weaves was less likely to be used, for sure. But the color picker redesign was clean, effective, and artist-centric. No problem understanding it at all. Actually, it became an iconic symbol of Painter.

The brushes were actually pretty easy. We figured five brushes was a pretty common number of brushes to work with. And may even be overkill. But these were brush categories, not variants. So this was a mistake, I think.

You see the Brushes palette, but this is an early mock-up with the pop-ups not yet functional. Our idea of putting the method up front was probably wrong as well.

But the topmost pop-up was the brush variant, and this was certainly a good thing to have here.

As time went on, it was the individual customized brush variants that the artist actually used and often switched between, and that should have been the list to choose from. Painter 12 gets this right, of course. Good job, Corel!

The brush controls turned out to have a lot of sections. But in Painter 3, we had an idea of having five icons per palette, so we worked the properties into ten areas. Five were in the Brush Controls palette. This became a fairly good split, with size, spacing, bristle, randomness (now called jitter), and nozzle sections, for the image hose.

But there were many more controls, and these got organized into the Advanced Controls palette. This contained sections for the rake brush, the color well (which affected mixing of paints in the canvas, and pick-up of color into the brush), looks (brush looks, which were a customized variant plus a paper texture), sliders (which allowed for many features to be controlled by the expression contained in your brush stroke), and water (for the water color brushes).

So far so good? No. We had already made a lot of bad decisions, I think. The next palette was the Objects palette. Here you can see the sections for paths (selections), a path list (for storing paths), floaters (this was the prototype for the portfolio, a place where you can store layers for reuse within a project), the floater list (like a layers palette), and scripts.

Painter was by now recording everything you did. So you could play it back, and also have a backup of your work. Of course, it got recorded to your Painter folder, in a Scripts subfolder. No - we weren't spying on you. We called these Sessions in Painter 3.

Materials (in the Materials palette) were an interesting case to the interface. Papers, Grads, Sets, and Weaves were all materials.

The Papers section shows a drawer, a user interface drawn from Dabbler and created by John and I. The current paper is shown, and some controls are present to adjust it for use.

So materials used a drawer with material swatches in them. The drawer face acts like a Recent Items list. So the most common items will be present to use again and again. When you open the drawer, you can access more, and also go to change the library. Eventually the Materials palette got bigger, with patterns and nozzles making it a bit more useful. But I think that was Painter 4.

The final palette was the Controls palette. And for this palette there was a separate pane for each tool. So you could think of this as a mini-inspector for tools. Useful features were located here. For the brush, the opacity and grain sliders were present. Also freehand vs. straight-line radio buttons were there so you could easily make straight lines. The color swatches were useful for switching between the foreground and background color.

It was really a whole redesign.

This took most of the time. Then individual elements were designed by the pixel-meister (John) and I designed the clever way of putting it all together, called the complied interface file.

So finally, we were able to split up the work. But in so doing, we had bit off more than we could chew in the original design and decision work.

In Painter 4, we did redesign it a bit, and it was more streamlined. But the redesign was also motivated by having more things in the program.

Once we had it planned out and split up, the implementation took at least a month of grueling work by both of us.

Multiple Undo

One project that was way too ambitious was the implementation of multiple levels of undo for Painter.

This project was so large that every single part of Painter had to be redesigned and retooled so that each operation could be undone. This was particularly difficult in Shapes, the vector illustration layers built into Painter during version 4, which became a graph theoretic problem of unprecedented proportions. This was because of grouping, ungrouping, and the operations of cutting up and joining shapes. Making holes. It just went on and on.

There wasn't any clean way to split this project up. But I did implement a set of primitives (kind of a library and an API) for building undo into each operation.

At one point, I sat down with another programmer, Priscilla Shih (now Priscilla Shih Cinque) and we went over huge areas to the program that needed to be retooled for undo.

It was kind of hopeless, we realized. Now there were two programmers that were overwhelmed by the problem. And I did a particularly crappy job of describing the problem. Perhaps it was just too incoherent. I liked in those days to keep a huge amount of details in my head and I made a gigantic list of primitives to tackle for each of us.

In the end, multiple undo took two revisions of Painter to implement it properly (versions 4 and 5) and eventually it was possible to simply implement undo on each new feature we added. I'm sure the legacy of multiple undo sticks to it with every revision that gets done.

In a future post, I will discuss the dangers of add-on programming. The issue of undo will return as a cautionary tale of something that should be designed in from the very start.

4 comments:

  1. Excellent! Great approach to many interface questions. Painter UI decisions along the time is a very complex and interesting
    By the way. When and why did the Printable Colours Only check box disappear? It was a great feature.
    And someday you have to explain in extend how you guys came to incorporate the color wheel (John´s design based on classics, I suppose) and everything about it. Even Photoshop has not dared? been able? to incorporate such a great thing. Yet. Well, you have a clumsy paid Painter copycat extension.(which I have) Eek.

    Just another question from a daily Photoshop (at work) and Painter (at home/studio) user. Why (technically speaking) Painter brushes are so fluent, any version, any system, and Photoshop brushes are SO slow . What makes the difference?


    Cheers!

    ReplyDelete
    Replies
    1. At some point, I will do the same explanation for the Painter 6 interface, which really solved a lot of the Painter 3 problems, I feel.

      Printable colors, even though we began to use this feature back in 1988 in ColorStudio, was a gamut alarm that became untenable as intellectual property as patent trolls began to appear on the scene and red capitalism began to "bloom".

      The circular color wheel was an obvious step, given color representations. Actually, even during the ColorStudio days, I became obsessed with color theory and I had several programs to create color charts. I have a dozen books on the subject with plenty of charts. After Painter's original triangle color picker, the idea of embedding it in a circle was a natural design decision, given that almost all artist tutorials on color use a wheel.

      Somewhere, I have a hand-drawn chart of the triangle-embedded circular color picker from that era. If I can find it again, I will post on it.

      Painter brushes are fluent because we worked hard to get them that way. Tom worked to get the image into a tiled representation. And I worked to create internal procedures for rendering coherent pixel lists of brush imprint onto the tiles.

      With each revision of Painter, the speed of the brushes was always considered a top priority, particularly when new brushes were implemented, like the liquid brushes and the photo brushes. The multi-bristle brushes in Painter 6 have their own special renderer so they can be fast.

      This represents a huge investment in time and detail-oriented care, a luxury which Adobe probably doesn't have. It appears that Corel still spends time on the bushes, including working on multicore implementations.

      The priority was always the brushes.

      Delete
  2. Patent trolls... that simple? Damnit.
    That simple checkbox would help much. Even having a good color workflow , it´s always frustrating when you convert a bright RGB painting to CMYK . I have my tricks, but I haven´t solved it yet.
    Painter brushes are incredible and your (and their) hard work much appreciated. I can vividly remember how exciting I felt hen I tried Painter (Classic, first version) on the first time. After fifteen years I still feel that way. I would buy Painter version after version even if it came only with my ten favorites brushes. But I would not say that in public. ;)

    On the color wheel. Yes it was obvious, it was there. Sure, but bright (and working) minds are needed in order to joint the dots...

    Still remember, as well, when I went to Photoshop after using Painter. I was like "what the...?" How can´t this thing have the color wheel and how I didn´t realize before?

    Thanks, Sir.

    ReplyDelete
  3. Color: The most important thing for color wheel usage is the ergonomics. Also people think better when they can see the complementary color relationships.

    If I was choosing the optimal color picker, I would make the color wheel more "perceptually" spaced, so equal angle increments would create equal color deltas. Right now choosing a hue near green is easy, but choosing a hue near orange is hard and way too sensitive because small changes result in huge perceptual changes.

    And the triangle might actually be more luminance oriented. This would mean that the saturated point (at the right of the triangle) might go up and down as the hue changed (up in areas that are yellow, down in areas that are blue). This is similar to the shapes of Munsell color pages. This would make the steps in the color picker more closely perceptual.

    The downside of this is that it might not be as easy to pick pure saturated colors like Red, Green, and Blue. And since colors are actually represented internally in RGB, this might pose some problems for the general user.

    Really, color is something that should mix like oil paints and not like RGB colors. This means I would have to spend some time figuring out Kubelka-Munk color theory that governs the admixture of paints. It takes scattering and absorption into account, and can more accurately predict the color that a thin layer of paint will be (known as R zero), and also what a thick layer of paint's color will be (known as R infinity).

    Any new paint program should take these things into account, because there is ample compute power now. Whereas there wasn't really ample compute power when Painter was originally built in 1990.

    --Mark

    ReplyDelete