Enjoy the awesome collection of works by illustrator/designer/type aficionado, Alex Trochut. I am getting kinda sick of the whole “blog style” portfolios… can somebody please do something new?

I tend to lean away from most of the random design crap, but there’s something about Nelson Balaban’s work that’s not quite as cliche… or maybe it is and it’s just that I’m in love with the work he did for the “Computer Arts Project”.

Some of the most compelling new online destinations are driven by a participatory model that invites users to create, manipulate, share, curate and distribute digital content. This model creates opportunities for all sorts of network effects, allows for more compelling content to emerge from a diverse population, and engenders a more proprietary feel (a sense of ownership and responsibility), not to mention community involvement.

All very interesting, but how do designers plan for and build online destinations that succeed in this model? Well, there’s clearly no formulaic way to guarantee results, and it would seem that success depends on a lot of intangibles and unknowns like market vagaries, priming, timeliness, confluent fads, etc.

At the same time, we can see that sites that have developed robust and productive communities boil down to an essentially intrinsic value proposition. In other words, they don’t depend on community at the outset. Sites like flickr and del.icio.us make it possible to easily access your stuff anywhere there’s a web connection; the community stuff is great once you get involved, but there’s a sort of prima facie reason for using these sites that helps get you started.

That’s all really high-level, pretty obvious stuff, but here’s something more tangible—I’ve noticed a few best practices in terms of mechanics for enabling user-contributed content:

1. Got to start somewhere: make the button really easy to find
2. Bookmarklets + screen-scraping is the easiest way to let users to bring external web assets into the fold
3. In terms of user input (data, meta-data, etc.) make it clear what’s necessary and what’s optional
4. Leverage known data (time and place, any screen-scraped data, data derived from stuff the user just entered, data derived from stuff other people have entered for similar items, etc.) to enable “smart defaults” 
5. Use active assistance (e.g. field auto-completion) if possible
6. Allow users to preview their contribution
7. Keep things really simple and straight-forward. Framing things up in self-evident structures (1,2,3; what, where when, etc.) can help
8. Two options when users are finished: (1) take them back to where they started from or (2) take them to their newly uploaded content. Which alternative is best depends on the context, or you could give them the choice.

Any others?

Pattern-based design seems to be getting a lot of interest in the UI community lately, and is being taken fairly seriously by some high profile players like yahoo.

Just to refresh, design patterns are general repeatable solutions to commonly occurring problems. There’s a putative measure of objectivity or optimality attributed to design patterns, distinguishing them (in theory at least) from what are often called “best practices,” which tend to be derived through convention.

To sort things out in my own head, I came up with this visual scheme for slotting patterns into the interaction designer’s toolbox. Obviously, this is not the only way to slice things up:

I had a bit of trouble deciding what should go in the top-right box. By quality attribute, I mean desirable traits like learnability, modularity, explorability—the “ilities” of design, which I think are both fairly abstract and context-dependent or subjective. These are sometimes called soft goals or non-functional requirements in systems design.

Back to design patterns. We’ve commented here before that we tend to be cautious about methodologies that are borrowed from other disciplines; we need to constantly ask ourselves, how will this help us improve our work?

Design patterns in software engineering are meant to be used in a deductive, rationalistic fashion. So you have this general problem or requirement, X, design pattern Y solves X, therefore use Y. Now, when I reflect on my own process—and I’ve got reason to believe that I’m not alone here—I find that it’s more organic than that, more inductive than deductive, more bottom-up than top-down.

Obviously, there’s a balance to be achieved. When a project is in the initial bootstrap phase and I’m trying to make the jump from abstract requirements to a concrete design solution, I’ll often perform a sort of breadth-first search in my head/on foolscap. During this phase, I’ve found design patterns to be helpful, allowing me to quickly frame up the design problem in concrete terms.

I think that pattern-based design has the potential to move interaction design forward, but we need to sort out how this will jive with established methodology that works in the other direction (e.g. scenario-based or iterative design), and also how to balance the value of standards and conventions with improvisation and innovation.

Learn more about UI design patterns:

• obligatory wikipedia entry
• repository of website design patterns
• compendium of HCI design patterns (not just for websites)