"As simple as possible, but no simpler." For my current Flex project I reached this point pretty quickly. Inspired by improv, it is a chat site that creatively orders group chat. There are roles (Host, Quizzer, Conservative, Blind Date, etc.) for a variety of scenarios, mostly drawn from pop culture. Chatterers vote for a scenario leader, who plays one role and picks others for the remaining roles.

For a game, it's not complicated. For an interface, it is. Some sort of help was required. The obvious recourse was to a video link on the landing page. But while video help is a mega improvement on text help, it has the same mega drawback: it whisks the user away from the interface.

So how could help be directly integrated into the interface? Before going further, I laid down some requirements:

1. No going away.
2. Turns on and off quickly.
3. Scannable, bookmarkable.
4. Demonstrates whole use cases.
5. Updates automatically.

The implementation:

1. A slider as well as last/next buttons lie at the bottom of the site. Each page entails a new label and help contents.
2. Here is the novel element: Clicking the buttons or dragging the slider causes the interface ITSELF to change: components are loaded with dummy data, controls are called out, navigations done. (And since the help is just steps thru the interface, when the interface is updated, the help is automatically "updated.")
3. If the help controls lose focus, help disappears. Once they regain focus, the user finds herself at the same point in help. The slider can be used to scan help steps.

Only user testing will tell whether this kind of self-explaining interface is better than video. Either way, it's a good example of what a rich, stateful client like Flex can do.

Here is the package. Not commented. I'll clean it up if people are interested. It's basically commands structured in a composite hierarchy that is flattened and stepped thru. I thought about elaborating Flex states, or using the state interface that the history manager uses for deep linking, but neither was general enough. I wanted help sequences that could build hierarchically or linearly, and involve callouts or navigations or whatnot. The result might be useful inside a testing framework.

If you live with Google for a while, the controversy about the Web's inclusivity--how can we sift the smart from the dumb?--is useless. When I was a stupid programmer, I found a lot of slightly-less-stupid blog posts, tutorial and articles that spoke to the stupid in me. When I become less stupid, other voices beckoned. The web grows with me.

Lately I've been wondering whether the web should preserve even more stupidity. When I really look at the hours I rack up programming, far too many of them are consumed with stupid mistakes, especially when starting fresh on a new kind of task, language or project. Google is still helpful then, but all too often I find myself grinding through some stupidity alone.

This is partly due to the fact that the set of smart, conceptual mistakes is a minor subset of all possible mistakes. "It's" v. "Its" is downright hi-concept... "accommodate" v. "acommodate", "accomodate", "accommadate" is nearly random in comparison. Not even the web can preserve all the permutations of sheer error.

But there are other factors that inhibit the free flow of stupidity onto the web. One is, of course, shame. Who wants to be that guy, who, in middle of a series of comments on an exciting blog post, whines "But I can't compile!!!!" I certainly don't...and the web is definitely a better place for this reticence.

Another factor is interest. Some mistakes are inherently interesting. Correcting them leads one deeper into the mystery. Others, not so much. We identify them, we move on.

There is a cost to this. How many times have I sat typing into a input box, then, forced by articulation to confront my stupidity, seen right through it? And how many times have I then minimized the browser and gotten right back to work? And because I kept this "duh!" to myself, how many others have to sit typing into their input boxes...

So be it, you might say. Google is the instructress of the self-taught, and she alternate sterness with indulgence, occasionally forcing us to gut it out. But isn't it better to spend those hours wrestling with onward-leading mistakes rather than infuriating trivia?

Clearly this is an interface problem. A stupidity-preserving interface would encourage people to post stupid problems and stupid solutions. Newbie forums are an excellent start. But less segregated solutions would entail giving forum or wiki members temporary anonymity, or allowing them to rank their own contributions or questions low priority or "stupid," or allowing discussions to branch.

You know when you write a class and then instantiate it and throw a couple of curveballs at it just to make sure it works? And then you write a related class, and throw both of them in the air for a few compiles?

That's it. That's what unit tests do. I had read a few tutorials on it, but their simple data class examples weren't vivid enough to help me make this connection to my own practice.

It's turning my stomach a little to realize how much time I've wasted. Informal unit testing is hugely inefficient. With informal unit testing, your little experiments are pretty much tossed into a big dark ditch. With formal unit testing, you can always run them again, which is priceless when you make a modification and need to make sure nothing has been broken. I get that now. Amen.

He patiently explained to me that my personal likings were not the only factors to consider. There was a lot of AS2 code that could be re-used. AS3 developers were rare and expensive, and training takes time. Etc.

In truth, weighing all these factors is above my pay grade. He is probably right in this case. But, of course, that's not what I said. Instead, I threw out that AS3 development is just faster.

Faster? Because of the event model? The display list? My boss didn't quite believe me. He knew about the performance gains, but AS3 looked quite similar to AS2 to his coder's eyes.

They do look similar, but because I've developed with both, I can say that whatever takes me 100 minutes in AS2 takes me 70 minutes in AS3.

Why? It mainly has to do with two very mundane factors: the compiler catching undefined variables (a.k.a. typos), and the player catching run-time errors. When I'm working in AS2, without these advantages, I have to compile every few lines. Otherwise you find yourself with a program that does not work and absolutely no frakking idea where it went wrong.

Unfortunately, the staccato interruptions of compile-compile-compile is like babysitting a small child. It prevents me from thinking clearly about programming logic. Developing with AS3, on the other hand, is like conversing with an adult. I can actually finish a continuous thought. I'll often sketch out a whole structure in code, and even modify it once or twice, before compiling. Then I'll spend a few minutes mechanically correcting the little mistakes--and bang, it works. Honestly, it still surprises me.

The structure of the language also helps me think clearly. To make AS2 sing, you have to keep a large number of hackish details at your finger tips: delegates, attachBitmap, MovieClip, etc. Mastering these hacks is not rocket science, but only when you move to AS3 do you realize how much of your mental RAM has been engorged by them.

AS3 is just simpler and more logical. Often I can skim a native package and guess what classes can be found within, or just instantiate an unfamiliar class and use auto-completion to locate the likeliest methods. I don't have to keep the details in mind because the details follow from one another. As a result, I spend less time thinking about the language, and more time thinking about something much more interesting--solving problems.

It could be AS3 gives me an unsually large productivity boost because I'm not as detail-oriented as the average programmer, and an organized language compensates for my unorganized mind. But what about you? I'd love to tell my boss that other programmers are developing faster with AS3.

I fear that the site will have all the charm of exposed pipe for the average Flash designer. My fear is based partly on my primitive graphic-design skills, but mostly on the unusual nature of the interface.

Here is the interface:

When the user rolls over a button on the home page, information about the potential destination appears in a centralized "hotbox," temporarily replacing the title. A hotbox is like alert, except that it is statically integrated into the design and--like a status bar--is continually updated by user actions. A hotbox is especially useful when a user wants to quickly browse a bunch of options and make decisions with more information than a label or a sentence can impart:

When a user clicks, if the content is loaded, it immediately appears in the center; otherwise a progress bar intercedes between the click and the content:

Notice that controls special to the content appear above the default controls, a home button and a history slider. Either control allows the user to restore home quickly.

Not the most complicated site. But deliberately so. Let me point out several unusual simplifications:

The default transition animation is none. Why animate a transition? Web browsing and desktop applications have accustomed users to content that blinks into existence, displacing existing content. There might be a few occasions where animations orient users, but how many add cognitive value on the average Flash or Flex site? 1 in 50?

Worse than unnecessary, animation transitions are slow and typically impede the interaction. Who wants to wait, even half a second, especially for content the happy-clicking user is just checking out? Also, it's repetitious. The same animation plays every time the user loads the same content, or--cue gritting of teeth--every time the user loads any content. Hey, Flash designer, say something once, why say it again?

Often transition animations hide downloads. But this sleight of hand is weak. It forces the designer into a foolish consistency (playing the animation again even when content is already loaded), or into a foolish inconsistency (the second play differs from the first). Better to be candid and show the progress bar or a content-specific preview.

The slickest Flash designers have already started abbreviating their transitions. Many employ now what I think of as "last, longest yard" animations: the animation is essential completed before it begins, like the fade-in that starts at 75% alpha and briskly reaches 100%. I wonder why these designers don't--like Cosmo Kramer trying out boxers, then going commando--take the next logical step and abolish the animation altogether.

Could it be that they fear that if they took all the transition animations out of their bag of tricks, it would be empty, and HTMLers could take their jobs? I think that Flash has become an entire, powerful platform, and there are tons of potential designs that don't require the tedium of transition animations or the tics of motion design.

You might think I'm talking about applications, not traditional rich-media sites. Actually, no. Even on a movie site, for instance, superflous, self-import transitions make me want poke the designer in the eye. There are a multitude of expressive ways to use Flash on such a site, and I'll bet designers would find them if they weren't busy shaking Adobe Inc.'s moneymaker.

History is absolutely necessary. HTML has its virtues. One of the most outstanding is the history. Because users know they can always hit the back button, they carelessly explore. Another winner is scrolling. The don't-look, can't-miss scroll bar nicely separate the action of the eye and the hand so the two can work together, the eye scanning while the hand drags.

I've combined these two HTML powers in one Flash widget: a history slider. Notice how the darker regions indicate the extent of the history:

Designers now enjoy a sliding history in the Flash IDE. Why not let users enjoy it, too? Since historical content has already been loaded (or at least browser-cached), it should be available for users to slide backwards and forwards.

Of course, for the slider to work, all the navigation transitions need to be immediate. Theoretically, a slider could scrub through tweened transition animations; practically, a long slider and cinematic reverse would be awkwardly literal.

Obviously this straight-to-content requirement is no deal-breaker for me. But you might wonder if I've put on a straightjacket when it comes to transition animations. I haven't. In you peruse the playground site, you will see that I employ them when warranted.

To ensure that every navigation can be immediate, I created a two-track navigation system. In it, each navigation can take a slow track (if reacting to a click), or a fast track (if reacting to a slide). In practice, since I favor immediate transitions by a wide margin, the slow track is identical to the fast or immediate track in the majority of cases. On occasion, a separate "slow" navigation (a fade-in, for example) is separately defined.

After making the history slider, I become so psyched about sliding that I constructed a slider-inspired widget, the "puller." The puller looks like a button, but acts like a slider. As the button is pulled (in any direction), content--whether texts, pictures, audio, or a combo--cycles through the hotbox:

The advantage of the puller is that it takes up less space than a slider. It's best for unlabeled or easily identified content. In my site, each experiment is accompanied by an information or "i" button that can be pulled.

Controls should be grouped together. Whether Flash- or HTML-based, web sites differ from electronic gizmos because, instead of grouping controls, they disperse them.

The reason for this is obvious: a site has divided content, and the controls follow the content. Think of a typical site whose home page is divided into boxes, each with a link button at the bottom right of the box. Nothing could be more natural than examining the contents of the box, then clicking on its link.

Still, up against the principle of "controls follow content," I propose a countervailing principle. Just as developers have sought to divide form from content, I think designers should attempt to "divide controls from content." The obvious example is a navigation bar, which remains in its own static space while the content changes.

In my playground site, the default controls (home button, history slider) sit at the bottom center. As new content is selected, the controls for the content typically appear above these default controls. This arrangement has two advantages:

1) When users wants to exercise control, they know where to look.

2) Controls are often used together (pause/play, home/new selection, last/info/next). Grouping them together allows the user to move easily from one to the next, and to form temporary habits, even muscle memories, which speeds up the tempo of action/reaction. Jerking a cursor from one control to another far-off control breaks up this tempo.

Notice that I have taken other measures to increase user confidence in the controls:

1) The controls are big for quick, brainless access. (Users can also right-click for a context-sensitive control menu.)

2) The controls are stylistically uniform and contrast with the content.

3) The controls are conventional, so, for example, the home button is like the browser home button.

4) Form follows function, so irrelevant distinctions are dropped. So video controls (play, pause, scrub) look exactly the same as audio controls and slide show controls.

Here are some controls:

I realize that these screen captures convey a definite exposed-pipe look for the controls. That I don't mind: I prefer Flash as vector punk (The Sex Pistols) to Flash as wannabee After Effects (Pink Floyd). Besides, my overarching aim was to create a mean, lean content-delivery beast that can deliver a wide range kind of content (video, audio, red, green, sad, happy) and curl up in the background without slanting the content.

A better, more graceful designer with a more restricted range of content to deliver could make a prettier site out of the same interface. And that is my hope! I don't intend this interface as a quirky personal expression, but as a template for forward-looking designers. Instant transitions, included history, and separate, grouped controls are formal structures that can be modified, mixed and matched.

For the next post in this series, I'll discuss the experiments on the playground, and speculate more generally about what Flash content can be.

Having developed other skills and burnt though other passions, I was self-conscious about the joys of programming; I wanted to know what this new thing was, and why it thrilled me.

Some joys were not specific to programming per se but would attend the learning of any skill. Obviously, it's cool to know how to do stuff. I remember vividly the stultification of my three brothers (an accountant, a lawyer, an engineer) when they started their careers, and even more vividly how they slowly got pulled into the details and the drama of their craft. As Moby Dick proved with whole chapters on subjects like stripping of whale carcasses, almost anything can be made intriguing. In the future, maybe bird-watching, souffle and design patterns will each have a cable channel devoted to them.

Then there were the programming-specific joys:

Direct Power Just about any activity can be described as a feedback loop: act, observe, act again. And just about any job, too. But, as you might be aware, in most jobs, the loop is broken, or just as often, necessarily indirect or complicated.

The act of programming in contrast is a freaking video game. The result of your action is as immediate as a trace(), and the solution is in your power, Space Cadet Jones! I'm exaggerating, but between the M.B.A. with her estimates and the painter standing back to appraise his latest stroke, the programmer stands nearer the painter.

Program as Person I can track my evolution as a programmer by relative prominence of bug types: first the mangled syntax, then the logical slips, then the crossed wires, and so on.

At some point, the bugs become weirdly...inflected. They seem stupid and stubborn, yes, especially when the debugging has gone on too long, but also cute, ironic, tart. This happens when the program becomes so complex that you can't load all its mechanisms in your mind at once. At that point, the program begins to seem autonomous, like a separate, self-directed entity.

Human beings have demonstrated a capacity to "humanize," personifying trees, rubber dolls, cars, etc. So it shouldn't be be surprising when programmers relate to their thinking machines likewise. In fact, I was not surprised when I found myself being cross with a program, sometimes even feeling betrayed. I've kicked and cursed my Honda, after all.

What did surprise me was the flip side of this low-level personification. If I felt hostile sometimes, sometimes I also felt like the program was like an especially helpful comrade, or an interesting woman who entices and eludes me, or a child in need of nurturing. Maybe I should get out of the house more, but I count these feelings among the joys of programming.

Cosmic Delusion There's a great scene in Johnson's Rasselas where Rasselas and his roving crew visit an astronomer. The astronomer lives alone in a tower, and he sheepishly confesses that he has come to believe his thoughts can move the stars.

As I start dealing with non-language specific patterns and information architecture, I often remember the astronomer, because the more abstract my programming becomes, the more prone I become to random cosmic sensations like those I had as a LSD-addled youth watching cigarette smoke swirl: "It's all part of this vast...system."

These sensations are partly triggered by the abstraction. Once you construct a useful model, it's easy, like Plato, to think the model itself is a higher, better reality.

But there is also something in the nature of programming itself that gooses the mind's ambitions. First, it's an odd mixture of subjective and objective. A programmer works alone at his desk writing characters in a text file, knowing full well there are myriad ways to write these characters, depending on his habits and mood...and at the same time, the result of this extremely subjective process is objective: it works, and works the same for anyone who runs the code. So it's understandable if a programmer having a very productive day mistakes his over-caffeinated intuitions with something grand or objective.

Second, programming demonstrates the astonishing power of reduction. The first rush of a neophyte programmer is realizing that programming languages largely depends on a small set of concepts: conditionals, datatypes, arrays, loops, etc. Once she masters these, the next language is just a few weekends and a "hello world!" away. The next rush is realizing what a broad spectrum of problems can be solved by combining these narrow concepts. It's as if you've just learned the 26 letters of the alphabet and realized that you could write an entire dictionary. (The only comparable rush I've had is reading German philosophers, who permutate a small number of concepts with such subtlety that their systems seem to absorb any fact, no matter how particular.)

Scientist gave up the idea that the whole universe can be explained by a few basic laws in the nineteenth century...but when a programmer wrestles with a stretch of code, making it simpler and simpler until simplicity, beauty and utility converge, then, for a bit, the old-timey dream of a few special, cosmic keys revives.

I don't mean to imply here that programmers are more cosmically-inclined than the average person. The reverse is definitely the case. I'm just guessing at the whys and wherefores of the transient highs I've felt while coding. Nor I am criticizing those joys based on delusion. I accept that most pleasures are laced with delusion. When I look at my Rosario Dawson wallpaper, some small, silly part of me thinks I might get to sleep with her, just as when I was a student and swam far into the Pacific ocean with a fearless, seal-like Norwegian buddy of mine, some small, silly part of me exulted that death was cheatable.

Of course, I'm never going to sleep with Rosario Dawson, or cheat the Grimster. But I'm going to treasure that wallpaper and keep swimming, and I hope programming remains a blast.