Notes: Interaction Design, Visual IDs, Oekaki

This weekend, I stumbled across three deeply intriguing ideas that I'm still digesting.

• Cooper-esque Interaction Design
  
• Visual IDs
• Oekaki
  

Cooper-esque Interaction Design
Alan Cooper founded the discipline of interaction design in the 90s. His basic argument is one that you've heard here in the past. Programs designed by programmers tend to be for programmers and other highly technical folks. He calls them Homo Logicus and notes they tend to want very different things than your typical user. Where a normal user might want one simple knob that lets them slide through options, Homo Logicus desire the power of a dozens of knobs. Power and control ends up being more important than daily use.

Interaction design promotes the use of personas, where you create a fictional person that represents your target user. For example instead of designing a game for 'the player', you would design for "Debra, a middle age mother of two who borrows her husband's DS for a quick fix when the kids are at soccer practice." This tool that I've used in the past and find quite helpful. You can no longer suppose the 'user' is really just another way of asking what 'I' would want. Instead, you always ask "What would Debra need?"

Interaction design also promotes goal directed design. Instead of listing features, you measure your success by how well you achieve user goals. In this model it doesn't matter if you add a dozen features if you end up breaking of the cardinal user goals like "I don't want to feel stupid using this product."

Bringing the concerns of the user into the design is always a good idea. These tool help balance our natural geeky urge to focus purely on the production and technical issues with the critical need to build a product that someone actually desires.

Personas
http://en.wikipedia.org/wiki/Personas

Goals Directed Design
http://www.cooper.com/articles/art_goal_directed_design.htm

The Inmates are Running the Asylum
http://www.amazon.com/Inmates-Are-Running-Asylum-Products/dp/0672316498

Interaction Design vs. Extreme Programming
One of the questionable aspects of Cooper-esque Interaction design is the insistence that all design happens up front and that designs hand off finished blue prints to the programmers. How this meshes with agile techniques is worth discussing.
http://www.ftponline.com/interviews/beck_cooper/


Visual IDs
A group of researchers have been playing with using unique procedurally generated icons to help users identify their files. Even when the icons are completely free of recognizable symbols, users were able to find their files more quickly than if they just used similar icons or text labels. Humans are damned good at seeing a visual pattern and reusing it in the future. We master and store visual cues on the fly even if we've never seen them before.

The paper presents the idea of 'visual scenery' and how we use it to navigate complex environments. Visual scenery is merely "...the distinctive appearance of visual objects in place" The existence of unique visual scenery allows our merry monkey brains to rapidly understand a massive slew of data about where we are, what we are looking, our past relationship with the object and more. The match between the effective visual scenery and procedurally generated unique content is a strong one.

Visual ID homepage
http://scribblethink.org/Work/VisualIDs/visualids.html

Visual IDs: Automatic Distinctive Icons for Desktop Interfaces
http://scribblethink.org/Work/VisualIDs/visualids.pdf


Oekaki
We are starting to see all sorts of interesting hybrids of traditional desktop applications and the web. The resulting applications are rarely clones of the past. Gmail has made me squirm when I am forced to use Outlook. DeviantArt's print service makes me wonder why I bothered to purchase my amazing inkjet printer. As an artist and a developer of art tools, I'm completely delighted to discover Oekaki, which is a class of collaborative drawing tool whose genes have been irrevocably munged with that of a forum or chat room.

These are the embryonic lead users of the next generation of art tools. No 'documents', built in collaboration and annotation(it is on by default!), built in sharing, built in version control and brainless usability. Did I mention the complete lack of installation and minimal start up time? Good stuff.

Oekaki Description
http://en.wikipedia.org/wiki/Oekaki

iScribble
http://www.iscribble.net/draw.html

Lead user analysis
http://web.mit.edu/evhippel/www/papers/Lead%20Users%20Paper%20-1986.pdf

Apologies for the link dump. I generally attempt to avoid bothering folks with a regurgitation of my somewhat esoteric browsing habits. :-)
Danc.

Rockets, Cars and Gardens: Visualizing waterfall, agile and stage gate

The further I dig into new product development practices the more I crave a simple way of helping folks new to the concepts visualize them quickly. In that spirit, I've assembled a little pictorial journey through the intriguing landscapes of waterfall, agile, portfolio management and stage gate. For fun, there is also a description of how you can apply portfolio management techniques to individual agile project as a technique for additionally reducing the design risk.

The concepts illustrated here are readily applicable to most software projects including games, websites and of course full desktop applications.


Software development as a learning exercise
All the diagrams start with two premises:

• Knowledge is critical to success: A large number of software projects fail because we build software that has little real world value. If you dig into the reasons, even teams with great production skills claim they focused on the wrong issue or they really didn’t understand what the customer actually wanted. When you build the wrong software, you end up with useless code, loss of political support and eternal development cycles. If only the team had reliable knowledge of what to build, they could deliver value early.
• Most product teams start with very little practical knowledge: Knowledge is great, but we start projects with hardly any. We don’t know exactly what our customers want. We don’t know how our design will work when it runs smack into the complexities of the real world. We don’t know what new opportunities and constraints will emerge in the future. Even when we are experts from a related domain, the best we typically have are theorems, guesses and opinions.

Product development is about rapidly producing targeted solutions that generate maximum customer value. In order to do this efficiently, our teams need to be learning teams that are constantly gathering concrete domain knowledge about customer needs. A team that learns the quirks of its customers, code, and business rapidly will often out perform teams operating without this knowledge. With this concept as a filter, let’s take a look at some typical development scenarios and how they are affect by team learning.

Typical product development of a single product
In most traditional waterfall models, teams gather requirements, develop the product and then test it in order to see if they implemented the spec correctly. Only after they release do they gain any insight into what the customer actually desired. The metaphor that is often used is that of launching rocket towards a destination. You get to aim it once and then you fire it off and pray that you hit the target. All well and good, except A) this is a rocket that burns money for fuel and B) when it misses its target, entire teams (and sometimes entire companies) get the ax.


Now, not all is lost. If your company has enough money to burn, they can try again. There is a good chance the team learned quite a bit about what their customers actually desired by failing in the marketplace, so the next moonshot has a better chance of landing closer to some actual customer needs.



The old joke is “If you want to build a good piece of software, rewrite it four or five times.” Eventually, if you keep trying long enough, you’ll hit a target market that wants your product. Some very big companies have made a staggering amount of money following this dogged pursuit of success. They fail again and again and again, but their few successes fund the further pursuit of new growth businesses. The learning is quite expensive but very valuable.



Room for improvement
This pattern of eventual success through multiple failures has been well established in all sorts of new industries. A few smart companies have identified two basic strategies for speeding up the time it takes to identify a new successful market.

• Standard portfolio model: Fail in parallel. By trying lots of different options all at once, a few will succeed.
• Iterative model: Fail sooner. Try something simple, test it to see it works and repeat.

Standard Portfolio Model
If the waterfall process is like firing a rocket at a target, the portfolio model is like firing a swarm of rockets and hoping one hits. The company greenlights a large number of projects, funds them fully and hopes that one of them will blossom into a success. In return for spending more money, you rarely have to wait until version 3.0 to observe success.



This model tends to be highly useful when the target market is poorly understood or ephemeral in nature. For example, in the music industry, when user tastes change every month, it doesn’t make sense to spend three years attempting to evolve an individual album to fit the market. It also tends to be useful when the cost of development is low and potential payoff is high. The incremental cost of green lighting one more project can be easily offset by the incredible amount of money a successful record produces.

The big benefit of the portfolio model is that it allows you to try completely different options simultaneously. Companies are often put in situations where more than one idea has potential and they lack the information to choose which ones to fund. If they were forced to choose only one, they would often miss out on creating multiple product lines. Instead of putting all your eggs in one basket, a portfolio model spreads the risk and increased the chance of multiple innovative breakthroughs.

The Achilles heel of the traditional portfolio model is cost. Smaller companies have difficulty funding one project, never mind ten or twenty.

The iterative model
Smaller teams have learned to maximize their learning opportunities by building lots of opportunity for rapid feedback into their process. The agile software development movement is the poster child here, but many of the same lessons are found throughout lean manufacturing, kaizen and other successful practices used by product development companies across a broad spectrum of industries.



The common metaphor is that of driving a car as opposed to launching a rocket. At every possible opportunity, you are looking ahead and adjusting the team’s trajectory in order to steer towards. Each change may seem subtle, but due to all the rapid cumulative adjustments, the team hone in on their targets quite efficiently.



It ends up being okay that the team makes little mistakes. If they veer off a little bit to the left, that's fine. They rapidly learn it was a bad idea and correct their efforts. The short feedback cycles ensures the big mistakes happen far less often.



Instead of taking 12 to 18 months to create and evaluate a new concept, they build and put new version in front of users every 2 to 4 weeks. They also work in high bandwidth environments where all the team members are close together and close to the customer. Team members converge on and build concensus around good ideas over a period of hours, not months. Teams become experts through intense hands-on problem solving and testing. This ends up building products much more likely to serve real needs than those imagined in Platonic specs by ivory tower experts.

Agile development is favored by small start up teams because the techniques greatly reduce the risk of an individual team failing. If you only have room for one shot at the target, you might as well steer your way to success using lots of rich information instead of launching blindly into the unknown. Long term, agile processes delivering more value sooner, with lower overall risk.

An agile project is intensely focused. In the rush of completing only high priority features, many alternative concepts never get the chance to be explored. Customers, a rather vague and argumentative bunch at best, are required to speak with one voice in the name of reducing noise and thrash for the team. For many teams struggling just to get software out the door, these traits are a godsend. The downside is that there is little concept of strategic portfolio management.



Agile projects can be a bit like a hill climbing algorithm. They will steer towards the closest customer success story, but may ignore a bigger opportunity further away.

Stage Gate: Cross breeding portolio models and iterative development
We can do better than either pure agile or pure portfolio development. The stage gate process borrows a little bit from both iterative and portfolio techniques. You are still launching multiple products, but then you use iterative development techniques to guide each project towards success. You kill projects that fail to meet your goals.



Imagine that we are gardeners. We seed a diverse portfolio of projects, some high risk, so low. As we add team members and customer feedback, the projects begin to flourish, winding their way up towards the sunlight of launch. The core team development practices can be agile since we want to encourage short cycles of rapid feedback. The best ones start to blossom and ripen with obvious customer value. However, some projects are sickly and seem unlikely to produce much of anything.

As gardeners, it is also our job to groom the garden. The weak projects are trimmed back and turned into mulch that helps nourish the most successful projects as well as create a bed for seeding even more promising ideas. The best projects are harvested and sent off to customers, rich with ripe features, bursting with value. We are constantly seeding new projects to keep our portfolio balanced.

We’ve added three items to the traditional agile model.

• Diverse seed teams: The first is the concept of multiple teams heading in different directions with different goals. There isn’t a single customer, but multiple customers driving multiple potential success strategies.
• Kill Gates: The second item is the concept of gates every few iterations that kill poorly performing projects. It is better to return those resources back to existing projects than to continue investing. You can think of the success criteria that drives the gates as a set of reasonable constraints. The team is allowed to do whatever it desires as long as it meets the outlined constraints that are measured at each gate.
• Concept banks: The third is the concept bank where old ideas are stored for possible recycling. You never know when the remnants of an old idea will nourish a strong new project.

You may start out with dozens of projects, but in the end you’ll only launch a few into the market. The combination of trying lots of directions with very small low cost agile teams dramatically increases your opportunities to learn compared to either pure iterative or pure portfolio techniques.

You spend dramatically less than you would in a pure portfolio model since you don’t have the heavy cost of finishing and deploying the bulk of unsuccessful market explorations. All that waste can go back into either exploring new options or building out projects that show success.

You have a higher success rate than a purely iterative model since you are exploring multiple hills instead of climbing a single hill and hoping that it is the highest one around. This recognizes that not all successes are created equal and it can be easy to get stuck in rut serving a niche. By keeping your options open, you can always shift resources around if a truly great opportunity emerges.

One downside is that cost is a little higher than a pure iterative model. You need to devote a portion of your overall efforts to generating and exploring new opportunities. This is typically more than offset by the earlier access to successful products. Another downside is that some long term projects (such as say…a fusion reactor) are culled before they show their promise. This can be handled through careful tailoring of gates so that break through innovations are properly weighted.

The Harvest Process: Applying a stage-gate model to a single product
A single product can benefit greatly from the ideas in the stage gate model. A single product is composed of a variety of separate features, scenarios and audiences. We can treat each chunk of customer value as a separate project and bundle of high value projects as a product. The basic model is the same as the stage gate process outlined above. However instead of spinning off multiple products, your individual teams tend to be focused on critical workflows or user scenarios for a single product.



Returning to the garden metaphor, as you nurture these areas of value, you should always have projects that are ripe for release. Publishing can be as simple as creating a public release that turns off all the experimental projects, leaving only your best features to show the public. I think of this as harvesting a ripe crop for your favorite customers.

As time passes, the little ideas that you seeded earlier will mature and produce a new crop of high value features. The process just keeps repeating, season after season, release after release.

The cliché in our business is that ‘ideas are cheap’. The shame of the matter is that some of the best ideas are left to rot because they don’t come from the right people and the production schedule has no room for creative thinking. The Harvest process builds innovation in at the lowest level possible. Everyone is encourage to come up with ideas and there is a clear and official process by which those ideas can become reality.

Making it work
In order to pull this off you need some basics in place. There is a substantial expense to running multiple projects and constantly integrating their efforts. With the right people, the right process and the right values in place, it is a very achievable goal.

• Multiple, small agile teams: A single monolithic team has difficulty guiding a multitude of projects. Smaller teams can champion their area more easily.
  
• Highly refactored and regression tested modular code: You need to be able to change one element without breaking the rest of the projects.
• Innovation at the edges: Teams need to be able to innovate in interesting directions without constantly referring back to the ‘master planning committee’
• Kill gates: If you don’t understand success and kill projects that don’t meet the bar, you’ll end up with a cancerous mass of bizarre, unhealthy features that have grown in random directions. Quality kill gates that actually kill projects are critical to success.
• Shared design: You still need to present a unified face to the customer. Each team is under additional constraints to share visual styling and minimize conceptual complexity for the product as a whole. These constraints are built into the kill gates.
• Customer feedback: At every stage, you need to be testing your products with real customers. You should be able to quickly deploy a working product to your customers every day. None of these ideas can succeed without people using working versions of your software and the team being wiling and able to learn from the customers’ reactions.

Conclusion
In the end, any of the techniques outlined above have a chance of working. You need a driven group of people with the right circumstances in place. With the right amount of random luck and persistence, even a waterfall project can change the world. For some fat cats working in bloated large companies, this is enough. However, if failure has a personal cost, you’ll want to look into the alternative techniques such as agile, stage gate, or harvest. Over the long term you’ll notice less overall portfolio risk and your customers will start enjoying your superior, well informed product designs.

If you take away one thought today, it should be that learning is fundamental to software development. We do not live in a Newtonian world where huge mechanical brains can predict the future. Instead, we operate in a constantly shifting organic universe of cultural trends, customer urges, fluctuating cash flow and skeptical sponsors. In order to deliver great products on time, we need to learn from our environment and build a response rapidly and precisely. Portfolio technique increase learning by trying more options. Agile techniques increase learning by shortening the feedback cycle. Build both of these key concepts into your teams and you’ll find that they make smarter decisions and deliver more value to your customers.

Take care
Danc.


References and resources

Original pretty pictures
I was inspired by these image of agile development when I began making diagrams.
http://www.gamesfromwithin.com/articles/0608/000110.html

Small initial teams? Try 20% of one person.
With Harvest and Stage Gate, initial teams can be very small. For example, you could devote 20% of one person’s time for the initial concept stage. That doesn’t sound like much, but if you have every single person in the company devoting 20% of their time to new ideas, you’ll be seeding the equivalent of hundreds of new projects every year for no additional headcount. Google is the golden child of this concept right now, but 3M has been doing it successfully for decades.

Put those hundreds of ideas through a simple checklist that looks for potential customer value. Spin off the best ideas into tiny teams of a couple people and give them an iteration or two to come up with something cool (and testable.) Repeat the process several times and you rapidly gain some surprisingly innovative products .

Iterative techniques
Agile Overview: http://www.agilealliance.org/
Scrum: http://www.controlchaos.com/about/
Kaizen: http://en.wikipedia.org/wiki/Kaizen

Stage gate
Winning at New Products: Accelerating the process from idea to launch, 3rd edition Robert G. Cooper, copyright 2001

Project Horseshoe Report on building games that sell
Many of the ideas in this essay were heavily influenced by discussion inside the Play Dough group at Project Horseshoe 2006.
http://www.projecthorseshoe.com/ph06/ph06r5.htm

Discovering Comet-san

Last night, my wife and I watched Cosmic Baton Girl Comet-san, an anime series aimed at roughly five to ten year olds. I have been avoiding such experiences for quite some time.

I’ve watched a handful of Miyazaki films in my lifetime, but somehow I side stepped the raving fanaticism that tends to burn in the souls of your stereotypical Japanoholic. There are numerous splinter factions within the geek culture and I’ve always considered myself somewhat of an accidental mainstream nerd. There is no doubt that I bear the nerd mark burned upon my forehead. My membership in our little minority was sealed early on once the Community discovered my love of citing scientific studies and my penchant for lugging about Greg Bear novels. At least in America, this is the rough equivalent of not speaking English as your first language or having chocolate skin. Chop, chop…into the box you go. At age seven, you don’t really know enough to make a fuss.

However, the niche Star Trek, Anime, LARPing, Linux subcultures never held much personal appeal. These were the obscure hobbies of my friends, akin to knowing someone who really enjoys raising champion poodles. I’d nod and smile politely before moving on to topics of mutual interest, like differential geometry. Occasionally, I’d borrow a manga that my friends recommended with giant, pleading saucer-like eyes, but any sort of repeatable addiction never really caught fire.

Later in life, I married a wonderful woman. She was smart, stylish, loved long meandering walks in the park and had the sort of dry, razor sharp wit that I imagined only mythical New York café lasses possessed. It was only a couple years later that it fully sunk in that she was in fact Japanese. Talk about being put in a pickle. Once you get the nerd brand, being married to a woman who happens to speak Japanese is instant entry into an entirely new universe of stereotypes. The default assumptions abound. Did you know that I now adore anime? And of course all my previous girlfriends were Asian since I naturally have a certain (wink, wink, nudge, nudge) predilection for very short schoolgirl outfits. Oh, and I speak fluent Japanese due to my extensive stay teaching English in Japan. None of these happen to be true, but how can you not find them mildly amusing?

As a bit of a contrarian, I’ve resisted some aspects of this packaging. Until very recently, it had been years since I had rented anime or read manga. The former are the equivalent of seeing La Vita è Bella (Life is Beautiful) dubbed by the cast of Scoobie Doo high on crack and helium. With the later, I can imagine better uses of my money than spending a tenner on an initial hour of entertainment that promises $400 worth of episodic cliff hangers in the future.

Enter Comet-san
Comet-san is the tale of a magical young girl of about 12 who enjoys twirling batons. The entire show sparkles with wonder. There aren’t merely raindrops falling from the edge of the roof during a rainstorm. Instead, they are little drip people whose job it is to drip with all their might. The animation of the drop creatures pushing themselves away from the ledge with determination and glee inspires me. There are none of the odd sexual overtones, just delightful child-like innocence.

There is a highly appealing animist spirituality woven throughout the series. Ancient trees snore. Miniature worlds fly about the heavens like playful children. This is a feeling that I’ve been attempting to capture in my artwork for many years. We’ve downloaded 21 subtitled episodes over BitTorrent and are merrily munching through them. Each one leaves us both with huge smiles on our faces. I realize that this series is only one of many such series in Japan and that it likely isn’t even a very good one. Yet, I feel like a foreign exchange student in the 90s who has been introduced to Michael Jackson for the first time. For the elite, it may be passé, but for me it is the seed of a brilliantly fresh insight.

We need more child-like delight and wonder in the worlds we create. Enough with the grim, sexually explicit brownness of next generation games and high budget American fear frenzy films. The presence of color and vividly imagined life stirs something creative inside of me that has been dormant for an unfortunately long time. Wouldn’t it be wonderful to just create a game world about a city park grove that thrives with huge moss covered tree gods and scampering, mundane spirits? The everyday world is an appealingly surreal and magical playscape when seen through the proper filter.

Upon watching Comet-san, I’m reminded of a song by King Missile titled appropriately “The Boy Who Ate Lasagna And Could Jump Over A Church”

Once there once was a boy
Who was very happy most of the time.
His life was almost completely complete.
He could sense however,
That there were two things
That were missing from his life,
But he didn't know what they were.

One day, his family took him to an Italian restaurant.
The boy had never had Italian food,
And was mesmerized
By all the exotic sounding names of the dishes.
He asked about the lasagna,
And it sounded delicious,
So he ordered it.
He ate the lasagna, and it was delicious.

The boy knew that one of the things
That was missing in his life
Was no longer missing.

Take care
Danc.

Happy Valentine's Day: Turtles all the way down

Here is the painting I made for Valentine's Day this year. If you haven't planted a big juicy smacker on someone's passionately pleasurable lips, you now have a mission. Precious moments of nibbling and kissing are 'a wasting!

The painting title comes from a hilariously metaphysical physics joke. This is the sort of thing that kept all the science students chortling late into the night as we crunched vector fields and fudged probability envelopes.

A well-known scientist (some say it was Bertrand Russell) once gave a public lecture on astronomy. He described how the Earth orbits around the sun and how the sun, in turn, orbits around the centre of a vast collection of stars called our galaxy.

At the end of the lecture, a little old lady at the back of the room got up and said: "What you have told us is rubbish. The world is really a flat plate supported on the back of a giant tortoise."

The scientist gave a superior smile before replying, "What is the tortoise standing on?"

"You're very clever, young man, very clever," said the old lady. "But it's turtles all the way down!"

With love and respect,
Danc.

"Content is Bad"

I just came across an article by the good folks at Introversion discussing procedural animation and its benefits versus hand crafted content. Some of my favorite games of all time are riddled with procedural content. The universes of Elite, the dungeons of NetHack, the random maps of Age of Wonders...all these are littered with procedural content. And how could I forget Dice Wars. Or Tetris. Or Poker.

The more handcrafted content you build, the more it costs. There are few economies of scale. Want a new level? Add a couple more monkey designers and artists to the team. Want a higher level of detail? Add some more team members. Procedural content has the benefit that despite an initial start up costs, you get immense amounts of content for little to no incremental cost. Procedural content also is inherently more agile friendly than handcrafted content. It can be refactored, unit tested and evolved in an iterative process that lets you try out new ideas quickly.


The problem with hand crafted throwaway content
If we look at content from a rewards perspective, you can classify content in games into two main buckets:

• Throwaway: This is content that the player sees once or twice and then proceeds to ignore every time they see it again. It has a very high burnout rate since the player immediately sucks any value from it, groks it and then filters it out as noise. In order to keep throwaway content exciting, teams produce large amounts of it and direct a steady stream of empty calories at the player. RPG's, Adventure games and many single player FPS have mastered this technique. Most plot points, level designs, conversations with towns folk, etc fall into the throwaway content category.
  
• Reusable: This is content that the player keeps coming back to again and again because it tends to be useful. A new character with abilities, a new weapon that has a unique effect on the environment, a store that lets you trade in resources are all examples of reusable content.
  

Handcrafted content is expensive in bulk, but it has another issue: it is incredibly difficult modify quickly. If you build a clown and then decide that a rapid zombie dog works later, you are forced to rework the models and animations completely from the ground up. You can lose month when you decide to alter your static content. Great game play comes about through rapid cycles of prototyping and playtesting. Visuals, settings and level design are feedback mechanisms like any other and need to be adjusted and iterated upon just as much as the algorithmic simulation underneath.

The more handcrafted, throwaway content that you have, the less agile your development process will be. This dramatically increases the chance that you will fail to converge upon enjoyable gameplay. It also dramatically increases the chance that you'll fall back on conservative game mechanics because the act of trying something new is too bloody expensive.

If you are on a budget, you should start identifying throwaway content and figuring out ways to remove it from your design. It may seem like a great idea to have a clown appear in a scripted scene where he describes his life story. However the incremental value to the customer is rarely worth the cost of production or the loss of project agility.

Using procedural content to replace throwaway content
There are two faces to procedural content. The first is as a hack for throwaway content. It allows you to cheaply replace large amounts handcrafted seemingly meaningful, but actually useless game content with algorithmically generated seemingly meaningful, but actually useless game content.

Ask yourself:

• Is this content critical to a working game mechanic? Identify the feedback that it gives the user and think about how it might provide them with utility. Sometimes you can cut content immediately from the game.
  
• After the user has seen this once, will they ever care about it again? This helps you understand if you are dealing with throwaway content or something meaningful to the player.
  
• If not, is there an inexpensive stylistic tweak that allows me to use a cheaper means of producing the content? If so, there are numerous possibilities here ranging from a less expensive art style, to procedural content, to player generated content. Pick the one that provides the player with the most utility, costs the least and leaves you in a position of greatest agility.
  

You'll find a lot of procedural content generation techniques that fit the bill. These are rarely up to par with the best hand crafted assets, but they will work in a pinch often at a much lower cost.

• Sound generation
  
• Texture generation
• Particle systems
• Procedural character animation
• Ambient animations

Using procedural content to augment reusable content
The second face of procedural content is where it is integral to a reusable game mechanic. In NetHack, the act of exploring the dungeons and coming across different configurations of monsters and items is crucial to the player's slow but steady unraveling of the immensely complex system underlying the game. Each level was somewhat disposable, but the map generation system was actually an intricately balanced algorithmic method of putting the player in unique initial conditions that helped maximize their learning of new skills.

In a card game, the randomness of shuffling the deck and dealing the players an interesting distribution of cards has a big impact on the gameplay that follows. You simply could not play the game without this element of algorithmic level design. Players would figure out the predictable set of hands and all challenge would be removed.

When dealing with reusable game mechanics, procedural content can replace handcrafted content in the following ways:

• Setting up interesting initial conditions, especially with configurations of existing game tokens.
  
• Introducing risk and uncertainty into game mechanics
  

Where procedural content fails
Procedural content is by no means a panacea.

• Procedural content is bad at setting goals: Dynamically generated quests were all the rage at one point. It turns out that people just zip through the text. Players quick discern the pattern and you are left with another high burnout game mechanic lying on the trash heap. Good goals are interesting because they are unique; they promise a brand new opportunity learn, advance or help out. They tend to play upon complex concepts of duty, heroism or desire. If you break down why 'Rescue Princess Peach' is meaningful, you'll have a tome on basic human psychology. These are areas where our algorithms are childishly primitive.
  
• Procedural content is bad at most social factors: In fact, you can generalize the concept to say that procedural concept is miserable at replacing most human aspects of content. Conversations, voice acting, descriptions of long lost cultures, plot, all these are difficult to replace. You can either cut them from your game, turn them into easily refactorable modules (like the descriptions in NetHack) or as a very last resort, use traditional, expensive handcrafted production techniques.
  
• Density: Developers sometimes react to the ability to generate infinite levels by building games that sport infinite levels. This is a very bad idea. When you are using a random map generator to put the player in interesting situations, the key operative word here is 'interesting'. All the standard rules of pacing, flow and burnout still apply. If your procedural content only amuses players for 15 minutes, make a 15 minute game. Otherwise start increasing the density of interesting interactions. No one wants to wander for hours through an infinite maze that has no purpose.
  
• Procedural content requires a programmer-designer or programmer-artist: This shouldn't be surprising, but you really need someone who is both a good programmer and a good game designer to make procedural content work. Someone who only programs or only draws seem to be a dime a dozen, but good programmers with design skills or art skills are rather rare. If you aren't such a magic person, so you need to form a team that has all the skills you need. Sit your designer and programmer next to one another and iterate like mad.
  

Ze sum uppery
The phrase "Content is Bad" is of course hyperbolic. To rephrase it, too much handcrafted throw away content is expensive and decreases the teams agility. Procedural content is one solution, but if there is anything I'd take away from this essay, it is the broader concept of creating agile, refactorable content.

If you are smart, your design will change dramatically over the course of development. You'll discover a hundred little tweaks that end up making your final game far better than the initial design. Always be on the lookout for content that you can refactor in some way so that you can change it more cheaply.

• Procedural content, when properly used, can turn the bulk of hand crafted content into code with all the added benefits of flexibility and cost reduction. You'll still have a bit left over in the form of variables and other compact data, but this will be much easier to manage.
  
• User created content (which is at least another essay or two) offloads handcrafted content to your users.
  
• If all else fails, at least modularize your content into tiny bite sized pieces that can be added or removed without derailing the ability to do frequent, completely playable builds.

Always maintain the ability to make a change to game play and test it with users within the next hour. If content becomes a barrier to this goal, you need to refactor your content-based systems. Be brutal in enforcing this rule, no matter how much you like that cutscene with the clown. It could save your team and your game.

The plague of handcrafted content is only going to get worse in the future. A friend mentioned that a level in his previous game took 2 days to assemble. Now, with the advance in customer expectations, it takes their team two months to build a level. If it costs that much to build a level from scratch, think of the pain involved in propagating a substantial late game design change throughout a series of levels. I can't help but wonder what their production schedule might have looked like if instead they had adopted the philosophy that "Content is bad."

take care
Danc.

References

"Procedural technique is another name for tool."
Jason Booth has a wonderful essay that talk about how much of what we call procedural content is really just another name for tools. They leverage a small bit of creative content to create a lot of gameplay, but they still need to be used in a creative fashion. There is no magic 'make me a world button' and the folks that take this attitude tend to give the whole concept a bad name.
http://jbooth.blogspot.com/2007/02/procedural-content.html

A more comprehensive definition
http://en.wikipedia.org/wiki/Procedural_generation

Introversion discusses procedural generation
The originators of the phase "Content. Is. Bad." They should make a t-shirt with that phase on the back and my favorite character design of all time on the front: "@"
http://www.gamecareerguide.com/features/336/procedural_content_.php?page=1

NetHack
One of the grand daddies of procedural content done well.
http://www.nethack.org/

Desert Bus
A game by Penn and Teller that illustrates the problem of gameplay density quite succinctly.
http://en.wikipedia.org/wiki/Penn_&_Teller's_Smoke_and_Mirrors

Thought experiment: Tiles as an early form of procedural content
"But most games that use procedural content suck" I recommend folks look at games like Zelda or Mario Brothers. Tiles were a huge innovation that allowed the developer to convey complex concepts (like walls, doors, tapestries, rocks, etc) without drawing ever single scene by hand. Instead you create a few modular pieces and then arrange the initial conditions of those pieces in an interesting way. You only use a small core of handcrafted seed data to build some truly enormous worlds.

This may seem like 'not true procedural generation', but compare it to the other popular alternative of the day: Drawing out every screen by hand. The genre that relied upon this technique, graphic adventures, was pushed into niche status. It simply could not compete economically with the richly interactive environments and economic efficiency of procedural techniques like tile-based environments. Food for thought.
http://www.tonypa.pri.ee/tbw/tut00.html

One Billion Buttons Please: Should we build features for experts or newbies?

I just returned from a lovely evening sipping flasks of yogurt-soju cocktails followed by a wobbly post-beverage walk in the brisk wet Seattle air. It is on libationary nights like this that I find myself musing about interaction design. Certainly, such behavior must be an incurable disease rooted deeply in the nerves at the base of the spine, but after this much alchohol, I can't help but give in.

Tonight's stream of thought kept returning to the question: What level of expertise should we target with our product feature? On one hand, web savvy designers swim in a warm sea of learned gurus preaching the religion of simplicity; how it entrances new users, increases our reachable audience and leads to happier customers. At the exact same time our expert users, the ones paying the bills, are screaming for cybernetic time travel juggernaut creation tools complete with one billion intricately labeled switches.

Balancing the tension between new users and expert users need not be a painful task. Here is a simple framework that I’ve used for many sober years to help me make these decisions more easily.


Layers of mastery
First, I always imagine a program of consisting of three distinct layers of functionality.

• Intro: First are the features that are encountered when a new user is introduced to a workflow or scenario for the first time. Often these features require only basic, common skills to understand. .
• Expert: Next are features targeted at the expert user has mastered the workflow and is looking to use the tools provided in an efficient and effective fashion. Expert features require the mastery of several new skills from the user, but they pay off with improved productivity.
• Meta: A meta-feature help extends the capabilities of the product in new directions. Meta-users use functionality like API and construction sets to better serve newly discovered needs that are not directly served by existing expert or intro features. The presence of meta- features enable lead user scenarios and open up entirely new and unexpected markets.

An example
For my last product, a 3D multimedia application called Anark Studio, we were in a tricky situation. Most of our initial users did not like programming, yet they were hell-bent on building complex interactive applications. In response, we created three basic layers of usage.

• Drag and drop behaviors
  
• Core expert concepts
• Program it yourself

Intro: Drag and drop behaviors
At the intro level, users could drag and drop pre-created behaviors onto objects. If they wanted a cool mouse over effect, they just drag one out of the gallery and dropped it on their object. The only skills the user needed to know was how to read an how to drag and drop. We made sure all the defaults on each prepackaged behavior were set to something reasonable, the names of the behaviors were easy to understand, and the results were instantaneous and visible.

New users found this functionality amazing since it broke their preconceived notion that all interactivity required programming. The low barrier to entry helped users overcome much of the fear of failure and lost time that naturally arises when they encounter a new application.

Expert: Core concepts
Some users stopped learning at the intro level, but most were engaged enough to dabble in more complex tasks. In order to provide them with more powerful tools that opened up creative possibilities, we introduced to the users three additional core concepts called slides, actions and symbols.

When providing tools for the expert to master, you can’t simply throw the kitchen sink at them. If you provide a hundred tools that all operate differently, you’ll find the most of them go unused. I’ve found that most expert users are only willing or able to learn 5 or 6 core concepts. These are of course the same users who are asking nuclear powered button tool chests. The trick is to bundling variety of tools together using a familiar metaphor. This allows you to teach one concept that opens up multiple capabilities.

For example with slides, most of our users were familiar with slides in PowerPoint. Even though we really were dealing with a rather powerful state machine full of unique persistence and animation constraints, the familiar metaphor helped them bridge the gap to practical usage quite quickly. They could immediately add, remove and rearrange slides. Only after they were using the slides to create interactive states did they start to notice the unique aspects of our implementation.

Add core concepts and their associated metaphors with great care. You’ll be living with them for many years as you build on new features within the conceptual framework that your users have learned.

Meta: Program it yourself
From the very beginning, we also told users that they could double click on any behavior and edit its underlying code. Every control in the application was build up from atomic elements and we gave the user full access to everything under the hood.

Now, they could certainly dabble in creating new behaviors by modifying our existing samples. However, in order to truly build new behaviors, they needed to have mastered all the expert features to an intimate level. Objects models, property publishing, custom events and all concept unique to the inner workings of an Anark behavior all were required to build new objects that extended the system. At the meta level, users were willing to put up with a lot of learning. They had invested heavily in the program and were excited to extend the application in a myriad of ways.

Early versions of Anark Studio had only a few intro and expert features. However, the existence of meta features allowed users to create a truly impressive set of additional capabilities ranging from new animation techniques to physics systems to large scale enterprise hooks. Many of the subsequent markets where Anark found success were a direct result of the customer driven innovation that formed around the meta features of the program.

Paying it forward
Another lesson that was has stuck with me is that you gain a lot by allowing the efforts of meta-users to be bundled up into modular items that can be used by both expert and intro users. All the code they wrote could be turned into simple drag and drop behaviors. Not only do your meta-users extend their own capabilities, but they also can extend the capabilities of the other users of your application.

Hints for using the model in real world situations
My favorite models are ones that allow me to ask hard questions about a design.

• Do I have a good balance of intro, expert and meta features? Often I’ll find that I ignore a category in a design. Lack of intro features kills my potential market size. Lack of expert features hurts my chances of having a dedicated core audience. Lack of meta features builds the product into a corner, does not leverage customer contributes and reduces future flexibility.
• Am I classifying my features correctly? Sometimes someone will place a very cool and powerful feature smack dab in front of intro users. The few users that make it through the gauntlet are delighted, but the rest disappear without a whimper. You rarely hear from the users that find your product too difficult.
• Am I managing conceptual complexity? Am I use a few key metaphors that are readily accessible to my target audience?
• Do my meta-features empower intro and expert users? If you fail to take this final step, the 1- 5% of your users that a meta-users will end up creating their own isolated community that fails to expand your market and take the burden of creating features off your shoulders.
  

Answering any one of these questions correctly can have a major positive impact on your product’s success, be it a website, a desktop application or a game. Ask them early and ask them often. Do not be afraid to adjust your design if the answers are not satisfactory.

Conclusion
Used correctly, this simple model of mastery layers goes a long way towards creating balanced applications that serve all your users. It never has been about only serving clumsy newbies or only serving the button fetishists. Such a dichotomy is silly. If we step back from all the blathering, it is obvious that intro, expert and meta users are all quite potentially the same person, just at different stages of experience.

Building products that take into account mastery is really a technique for ensuring user delight throughout their entire life cycle of usage. From the first intuitive inaction with the application all the way to the find stages where they play your application like an instrument, we are charged with making our user’s experience chock full of pleasure and value. Each stage matters and we ignore them at our own peril.

Hydrating with tea,
Danc

References

• www.anark.com
  
• http://www.jnd.org/dn.mss/simplicity_is_highly.html: An interesting take on simplicity by Don Norman. I've run into this many times myself. the problem with making something that is easy to learn, but hard to master is that users often don't realize how much power is at their finger tips. In some sense what many users are asking for is something that *looks* powerful, but is very easy to master.
  
• http://www.joelonsoftware.com/articles/fog0000000020.html: Joel on simplicity. Another interesting argument that basically says "All those features are great and computers are advancing fast enough to deal with the increased complexity."