Boxes and Arrows

Using Wikis to Document UI Specifications

Peter Gremett — Mon, 29 Jun 2009 08:16:54 GMT

Introduction

The role of the interaction designer is to specify the interface’s behaviors and elements, so that engineers know what to build and how the product should operate. This documentation is commonly known as a UI specification or UI spec. There are several applications for authoring a UI spec, with wikis being a relatively new tool. However, designers should be aware of a wiki’s benefits and drawbacks for documentation, since UI specs uniquely reflect a project and its context. The documentation needs are often based on the size of the project, launch date, team dynamics, audience, technology, and the product development process. The development process usually plays a major role in how teams interact and how work is completed or delivered, thus, there is a direct relationship between the UI spec and the process the team is using.

Description of the Problem

There are many product development processes and one that has garnered much attention is agile. Agile refers to a group of software development methodologies that promote the project development lifecycle through iterations, open collaboration, and process adaptability. It moves away from traditional process-heavy methodologies and instead focuses on quick actions and an evolving plan as steps are taken.

The Agile Manifesto¹:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a strict plan

Many claim that agile methodologies help companies increase revenue, reduce costs, improve quality, ensure compliance, and drive innovation throughout the product lifecycle. As designers, we often find ourselves working with teams that are using agile processes. I propose that the UI spec is best documented through a wiki when working in such an environment. This method is both adaptive and sufficient for teams building and delivering products, and helps to foster the collaboration that agile development requires. Problems with traditional UI specs include the following:

Documentation is expensive to write and maintain
Encourage a waterfall methodology
Slow downloading time for documents filled with tables, images, and cross references
Difficult to facilitate collaboration within the document
Rely on one central author to write and maintain the document

Wiki Overview

Before you can write anything you must have wiki software² established on a private server. There are many articles available³ to help you choose the right wiki software⁴. Once you have the software installed it’s time to get going! The quickest way to make progress is to create a template that you can use for every project. A basic template frees you from having to repeatedly format a wiki page each time you begin a new project. You can modify your starter template and learn what format works best for you and your team. Template elements to consider include the following:

Table of Contents: A list of topics related to the project in order of appearance.
Tea List and/or RASCI Model: Owner, accountable person, or support role on the project; someone who provides input or expertise on its outcome.
Issues Section: Captures running problems or questions that need to be resolved.
Tables: How to layout information in a grid format.
Titles: Attributes such as bold, color, size, etc.
Subtitles: Attributes such as bold, color, size, etc.
References: Links to related information resources.
Figure References: How you refer to a figure or diagram within the document.
Images: Thumbnails and full images, as well as defining rules for opening a new window.

As you gather information and ideas, you can document them in the wiki. The nature of the wiki makes it fast and easy to record ideas, which helps to spawn additional ones and encourages participation. This process allows you to have a repository that can be easily reviewed by your team members. Undoubtedly, the wiki spec will start conversations among team members both online and in person. As you add more detailed material, your team members will be more likely to contribute. My experience has been that if someone needs clarification on a topic, they are vocal about it and team members will make sure the required information get added to the wiki. Before you know it the spec will be complete.

Benefits

Collaboration

Collaboration is the single best advantage of a wiki spec over a traditional one. The supposition of a wiki is that there are many authors and contributors to the document, and therefore, you have the right environment for collaboration. This is a huge advantage for product specifications. As the interaction designer you don’t have to sit in a cube by yourself and define everything on your own. It’s fine not knowing all the answers and you can rely on your team to help fill in the blanks.

Team members can add clarifications, details, or make edits to content. Oftentimes, the details and clarifications build upon one another to complete the document. For example, if the designer has specified the layout and behavior for a button, the tech writer can add in the rollover text without disturbing the designer or the flow of the project process. To follow the example further, the tech writer can then add the help content to the wiki, allowing the engineer to upload the information onto a server and post the URL. The transparency and collaboration are quite amazing. Team members are able to get the information they need to perform their jobs and help the project along.

Speed

Speed is a major benefit of wiki specs. This is also why it’s a good match for agile projects. Speed comes in two forms: writing and consumption. It’s easy to add content because of the WYSWIG interface. As you begin writing content, it can be instantly viewed by team members. I have found that the sooner you post sketches and thoughts the better. It gets the whole team collaborating and they can offer feedback immediately.

Flexibility

A wiki spec is extremely flexible. This characteristic allows you to morph its structure and organization as the project evolves, reflecting the nature of agile processes. The team is able to keep up with the changes that occur in an agile project because all edits can be instantly viewed. Additionally, if anyone wants to be informed of the most recent wiki changes, an email notification system can be set up by any team member.

Reversible

In the event that a change was accidental or a major disagreement arises, the wiki spec can be reverted to its previous version. This does not happen very often, but when it does, it’s a real life saver.

Figure 1: The image above shows the wiki revision history, including the date and time of the latest modifications.

Centralized Image Updates

As they say, “a pictures is worth a thousand words” and the old expression applies to UI specs as well. No spec would be complete without images to help the team see what it is building. Once an image has been uploaded it’s easy to update all instances of that image. All that’s required is uploading a new image with the same name. This step saves time for team members and interaction designers, since we’re usually creating screen mockups as we go.

Informal Approval Process

A team typically has an approval step or sign-off for a UI spec. This is often used to ensure that all issues have been resolved and everything has been documented to the team’s satisfaction. With wiki specs this step is unnecessary, since team members have been participating in writing the spec all along. This saves time and the formality of having a spec review. If the team does insist on a spec review, you can capture notes and issues in real time as the meeting is occurring and everyone can easily see the discussion progressing. As issues are resolved, the wiki can reflect the updates and decisions that were made after the meeting is adjourned. Team members can then modify entries and resolve any issues that remain outstanding.

Challenges and Solutions

Installing the Wiki

If you are lucky enough to have either the technical prowess to install the wiki software yourself, or have someone on your staff do the work, then you will have overcome the first hurdle in wiki specs. There are many free wiki software programs available online, so you might be able to skip this first step all together. However, if you are working on anything that is propriety or secure, I would not recommend hosting it on a third party site. You might be exposed to competition or legal issues, not to mention someone else will have your product specs.

Syntax

Another consideration is that wiki contributors must learn some syntax. This can be off-putting for non-technies, but the syntax is not difficult to learn and is similar to HTML. Many wiki software programs make it easy by providing a WYSWIG interface that allows for basic formatting while creating the syntax for you. This lets you focus on what you are writing rather than the syntax. Other ways around learning or creating complicated syntax is to pilfer code from another wiki template by simply copying and pasting it. If copy appears incorrectly, you can remove it or revert to a previous version. Wiki syntax also forces you to keep the document simple rather than spending time writing syntax for a spec.

Figure 2: This interface shows the code created by the WYSWIG editor.

Portability

Some people like the capability to read and write documentation wherever they are. With wikis you have to be online for either of these activities. Even though connectivity is increasing, most companies have firewalls or VPNs that can make access more difficult.

Simplicity

Some designers take pride in their documentation and deliverables. They spend a significant amount of time creating deliverables that are functional and beautiful. Wiki specs do not support this capability. They are essentially text editors that can be used to make documents more appealing by adding images, but they don’t really support the easy customization and flexibility that some designers would like to have. Images must be added one at a time and wikis don’t support many file formats. This may limit a person’s creativity in designing the document.

Printing

You may often see people printing traditional specs so that they can read them during their commute or at their desks. Wiki documents can be printed but they lack the basic characteristics that you would find in a traditional spec. Most of the issues involve pagination. Images get bumped to the next page unexpectedly or tables are displayed across multiple pages. This makes reading difficult, but it can be done. Although I do understand why some people like to print, I would argue that it’s not good for the environment and you should try to work on screen as much as possible. However, the functionality is there for those who prefer to print.

Trust

Trust is a major factor among team members. Some projects outright fail because of the lack of trust among individuals. Wiki specs can exacerbate a trust issue because team members have editing capabilities. If a lick of trust exists among your colleagues, you may see this manifested in the wiki via reverts and lots of edits or re-edits. This can be time-consuming and frustrating. If you have trust issues with your team or certain people need their roles clarified, you might want to consider an alternative method rather than a wiki spec.

Conclusion

Today’s economy and globalization are forcing companies to accelerate growth and increase revenue. In order to meet these demands companies are using new methodologies like agile, to bring products to market. As interaction designers we find ourselves working with these processes and playing an important role in the creation of new products. One of our major contributions is the UI spec, and the best way to document it for agile projects is through a wiki. It’s adaptive and allows for a collaborative experience.

References

¹“Agile Manifesto”:http://www.agilemanifesto.org

²“List of Wiki Software”:http://en.wikipedia.org/wiki/List_of_wiki_software

³“Wiki Engines”:http://www.iterating.com/productclasses/Wiki-Engines

⁴“Wiki Feature Comparison Table”:http://www.wikimatrix.org

UI Pattern Documentation Review

Patrick Stapleton — Mon, 29 Jun 2009 08:16:40 GMT

Introduction

User interface (UI) patterns have the potential to make software development more efficient. The prospect of such efficiency gains has led to interest in user interface (UI) patterns by individuals and organizations looking for ways to increase quality while at the same time reducing the costs associated with software development.

The very nature of UI patterns requires that they be familiar to end-users. An individual UI pattern is a discrete, repeatable unit of user experience. I refer to collection of patterns as a library.

In many cases, less proprietary patterns are more useful in solving a design problem as they can be implemented more uniformly across platforms. This characteristic and the efficiency gains make patterns an excellent opportunity for software companies to come together and promote UI patterns to the wider development community.

Producing a common pattern library, however, implies that the patterns presented are at the very least, consistently documented and most probably presented in the same single classification system. Currently though, patterns are classified and documented in various manners across publishers with no clear standard evident.

The problem

To date, the most common approach to propagating a single user experience standard is the development of UI guidelines and principles documentation within an organization. Development teams — usually incorporating a user experience specialist — then reference this documentation during implementation and upgrade processes.

However, as the numbers of systems grow within an organization, so does the effort needed to maintain the quality and consistency of the user experience. For many organizations, it is now impossible to assign much, if any, time of a user experience specialist to all implementation efforts, and experience has shown that the UI guidelines and principles approach to propagating a single user experience standard does not scale well.

There are two common issues, both major.

The first issue is ensuring developers are familiar with all the principles and guidelines.

Documentation to fully describe a UI standard is, by its nature, extremely detailed and complex. Getting developers to know all this information intimately is an ongoing and often un-winnable battle.

The second major issue is that the application of guidelines and principles can be open to wide interpretation.

Requiring developers to combine guidelines and apply principles together to create a complete UI can be inefficient. This synthesis process can result in widely-varying solutions to a single design problem across teams — especially when working with widely distributed and possibly culturally diverse groups. Removing these variances to create a more consistent user experience requires rework.

The solution

UI patterns to a great extent mitigate the problems of weight and interpretation experienced with the principles and guidelines documentation approach of the past. In essence, patterns can be seen as prepackaged solutions based on guidelines and principles.

Patterns and pattern libraries are more convenient for developers because they solve common higher-level design problems without the need for deep knowledge of often-complex guidelines and principles documentation. Also, they implement best practices, so developers don’t synthesize what are often “slightly original” solutions that would need to be reworked later.

Much of the value of a pattern to the developer is its less granular and more physical nature. Principles of good UI design dressed up as UI patterns add little value over traditional guidelines and principles documentation, as seen in many of the UI patterns as described in the Design of Sites; examples such as “Low Number of Files” — while an important design principle or guideline — do not deliver up a usable UI component.

Also important is creating the patterns to begin with. The guidelines and principles that form the foundation of patterns still need to be developed before any patterns themselves are developed.

Integrating UI patterns

Integrating UI patterns into the culture of software development is to a large extent still beginning. Next-generation development tools such as those proprietary ones being developed by enterprise software companies that implement patterns natively are now or will be soon in the hands of developers around the world.

Embedded drag and drop UI patterns hold the promise to empower developers to create better user interfaces, faster — unsupervised by user experience specialists. While this may strike fear in the hearts of many a user experience specialist, issues of scale dictate such a pragmatic approach. Be aware though, that they also can perpetuate problems if the UI patterns implemented are out of sync with end-user expectations.

Why standardize UI patterns?

Currently, there is no recognized standard for the classification or documentation of UI patterns, as seen by browsing through pattern libraries from:

Martin Welie’s UI patterns
Jennifer Tidwell’s UI Design Patterns
Sari Laakso User Interface Design Patterns
The Design of Sites: Patterns, Principles and Processes for Crafting a Customer-Centered Web Experience by van Duyne, Landay and Hong.
Yahoo Design Pattern Library

The variety isn’t surprising, since applying the pattern concept to user experience design is a relatively recent phenomenon. However, the successful introduction of a single classification and documentation standard could significantly increase the value of a UI pattern library to developers by…

Reducing confusion among pattern versions across collections. Not surprisingly, many of the same patterns exist across collections. A standard classification system (discussed below) can help developers make sense of both these patterns and their different versions in collections across the web and in paper publications.
Promoting development of net new UI patterns. A clear classification taxonomy is likely to make the “holes” in the current crop of pattern libraries more apparent, which in turn hopefully will increase the pace of development of new UI patterns.
Providing a standard UI pattern interface. As the number of patterns increases, pattern search tools will become more important. A standard classification and documentation approach will enable developers to quickly display their UI options.
Promoting UI pattern adoption. A clear classification taxonomy is likely to have the effect of making patterns easier to find and in turn increase their use.

Problems with the solution: UI pattern Classification Approaches

The following is a high-level analysis and discussion on classification approaches of the previously mentioned UI pattern collections. Each collection is mapped and discussed from a classification and documentation perspective.

Martin Welie’s patterns

Classification Analysis

Patterns in Interaction Design

Figure 1. Classification Map (click image to enlarge)

Welie divides the patterns into three delivery methods: Web design patterns, GUI design patterns, and mobile design patterns. Within the web design patterns channel (the focus of this document), the patterns are categorized into ten groups based on a mix of content and functional subjects.

Documentation Approach

Figure 2. Documentation Map (click image to enlarge)

Welie’s documentation approach is simple, with a focus on visual elements to explain the function of the pattern. It can be broken into three main parts:

Description: This area of the documentation provides the name and image to describe the pattern.
Rationale: This area provides a description of the problem that is solved by the pattern, how it works, and the scope of its use.
Associations: This area provides links to other patterns related to the current pattern.

Jennifer Tidwell’s patterns

The following is a map of Jennifer Tidwell’s UI Design Patterns. (Click image to enlarge.)

Unlike Welie, Tidwell does not take into account different delivery methods. The eight categories she does specify look to be based on functional subject areas only.

Sari Laakso’s patterns

The following is a map of Sari Laakso’s UI patterns. (Click image to enlarge.)

Like Tidwell, Laakso does not differentiate between delivery methods; he bases all seven of his categories on functional subject areas.

The Design of Sites’ patterns

The following is a map the patterns presented in “The Design of Sites.” (Click image to enlarge.)

The most extensive pattern collection of the four sampled, Design of Sites does not specify delivery methods, and, in some cases, the items presented could be regarded as design guidelines or principals rather than patterns. Twelve categories are presented with a mix of content and functional subjects.

Summarizing the classification types

From this analysis three main types of classification are present — content subject, functional subject, and delivery platform.

Content subject classifications normally specify an application genre (for example, ecommerce and supply chain management). Examples of content subject based classifications can be found in the Design of Sites collection under “Site Genres” and in Welie’s collection under “Site Types.”

Functional subject classifications are based on logical breakup of functionality (for example, shopping cart and two-panel selector). This is the most common prevalent classification type and is found in all the collections sampled.

Delivery method is used to describe the platform on which a pattern has been designed to operate. This classification type opens up the possibility for unique patterns to be developed for the same subject classifications across platforms. This classification type has the potential to provide more resolution for developers looking to offtake a pattern within a specific UI delivery platform such as mobile, desktop, or web.

Based on the publicly available pattern libraries available today, there is no clear indication as to whether “delivery method” is a valid classification type. An argument could be made that the process of binding a pattern to a specific technology is will reduce the life of the pattern as platforms develop. However, the timelessness of a pattern is of little consequence to developers whose primary goal is product delivery rather than pattern lifecycle.

Another Classification type – Level

This author would like to include an additional classification type: Level.

The level classification would further divide patterns into the following areas of concern:

Navigation architecture: Patterns relating to the navigation of content within an application
Screen architecture: Patterns which position functionality and content within a screen
Site furniture: Patterns for formatting functionality and content

In the case of the collections previously reviewed, the great majority of patterns would be classified as falling under the “site furniture” level type. However, it is this author’s view that considerable potential remains to develop patterns within the proposed navigation architecture and screen architecture level types.

A proposed classification system

The above diagram (click image to enlarge) describes a potential pattern library classification hierarchy. In this case, client classification nodes are presented at the top of the tree similar to that of the Welie collection; the proposed new level classification nodes are added above subject.

Content and functional subjects would be implemented as tags because these classifications would occur across levels.

Why have a classification hierarchy — aren’t filters or tags more useful?

In many cases, being able to filter by classification node as required is more flexible than drilling down through a preset hierarchy. However, a present classification tree is also useful to:

Automate the generation URLs to enable cross linkages within the UI pattern library.
Provide a simple drill experience for end users who have no specific problem to solve but rather just wish to browse to learn and or generate ideas.

UI pattern Documentation Proposal

The value of a standardized UI pattern documentation to developers is a single interface for search tools. Such tools hold the potential to streamline the off take of UI patterns by developers with specific problems to solve in a world with hundreds and potentially thousands of UI patterns to choose from.

UI patterns are by their nature visual. It must be noted that strong support for pictorial content would seem obvious and reduce the necessity for long verbal descriptions that add little value next to their visual equivalents.

UX Book Clubs

Steve Baty — Sat, 16 May 2009 09:00:22 GMT

In early Nov 2008, I started to talk to a few people about the idea of a book club in Sydney to discuss User Experience (UX) books. Russ Unger and Donna Spencer encouraged me to let other people hear about it, and when I did – through the Information Architecture Institute (IAI) Members discussion list, and then through the Interaciton Design Associaton (IxDA) – many people thought it was a good idea.

And then something surprising happened, people liked the idea so much that they started doing things to make it happen. Andrew Boyd registered the “uxbookclub.org”:http://uxbookclub.org/doku.php domain, set up the wiki, and starting the content rolling. Will Evans designed a logo, wrote a whole bunch of content, set up a decent structure, and let everyone use either, or both, if they wanted. Andrew’s been in on the wiki each day tidying and gardening, making sure it doesn’t get out of control.

First one volunteer, then another, and another put their hand up and offered to organize a UX Book Club in their local area. New York City joined Sydney, Canberra, and Washington D.C. By the end of that first week over 28 cities had a local UX Book Club under way, and nearly 400 people had signed up to take part.

The first meeting was held in Silicon Valley in mid-December, followed by meetings in New York and Los Angeles, Philadelphia, Chicago, Canberra, Sydney & Austin. Through the second half of February meetings were held in Atlanta, Minnesota, Melbourne, Tel Aviv, Brisbane, Toronto, London and Chicago.

The What and the Why

UX Book Club is a fairly simple idea: get a group of people together, choose a book, and agree on meeting details. Go away and read the book. On the date set, come together and discuss the book. Talk about how you might use what you’ve read in your work; how your experiences run counter to the book; an example of how the book is spot on. Have a bloody good argument about it, then go have a drink and talk about it some more.

At a UX Book Club you have an incentive to read some of those user experience books you’ve heard about but still lays on your bookshelf. You discuss the book with other UX practitioners, which will help you get more out of the book. And you meet fellow UXers working in the same town as you.

You also hear about a lot of books that other people have read, found interesting, but aren’t suitable for discussion by the group. That may be because they’re too long, or highly specialized, or too expensive for a large group of people. Hopefully, though, you’ll be exposed to a much broader range of books than you do on mailing lists or blog posts currently.

How It Works

The Sydney meeting – held on February 3rd – seems to have been fairly typical of the experiences across the board – with local variations in terms of weather, location, and numbers. But the stories seem to have a consistent theme: great discussion, lots of energy, and a good time had by all.

“It was fairly incredible how natural—how routine—it felt. I mean, here was a group of people, many of whom had never participated in any community event, and none of whom (to my knowledge) had ever engaged in an extrinsically focused book club. The book became the medium for discussion, though the topic remained entrenched in UX and design.”  - Jonathon S Knoll, UX Book Club NYC

UX Book Club Sydney held the February meeting at the offices of the “News Digital Media”:http://usit.com.au team in their “New York Lounge”. Their hospitality was greatly appreciated, and the space was perfect for the event.

The event was structured along the same lines as those used by New York City (thanks to Cindy Chastain) and applied successfully in Los Angeles. The meeting opened with a brief welcome and introduction, then a volunteer from the group gave a 5-minute overview of the book (in our case Bill Buxton’s Sketching User Experiences). We broke into two groups (10 and 13 people, respectively) and headed to opposite ends of the Lounge to discuss the book in detail. Cindy’s rationale for the smaller groups was that they give everyone a much better opportunity to contribute to the discussion – and this was borne out by the comments I received afterward.

After a good solid hour or so of group discussion we came back together, had a bit of a recap, thanked everyone for attending, and relocated to a nearby pub to carry on. The ‘official’ proceedings kicked off at 6pm and ended just after 8pm. The ‘after-hours’ discussions wound up around 10pm. Not bad for the first event.

The entire event was terribly uncomplicated, and I highly recommend the format. Better yet, the discussion highlighted areas of the book I hadn’t really considered important on first reading. This new information encourages me to go back and re-read those parts, armed with some real-world anecdotes to help make it more concrete.

“UX Book Club got me to finally pick up a book I had been meaning to read, and to have the chance to exercise my brain a bit. I found myself waxing philosophical with my fellow book clubbers about education and urban planning, as well as positive (and negative) user experiences we’ve had.”
- “Roz Duffy”:http://stellargirl.typepad.com/stellargirl/2009/02/my-current-muse-ux-book-club.html, UX Book Club Philadelphia

The events serve as both means and end. Reading the books being discussed is a good thing, in and of itself. You will get more out of the event having read the book, and the overall level discussion and engagement will be higher for everyone.

But reading the book isn’t required. The book acts as a starting point for a wider-ranging discussion around the topic. Each person brings not only their understanding of the book, but alsp the full breadth of their professional and educational experience to the discussion. So whilst reading the book provides everyone with a common frame of reference, the really interesting discussion arises from our differences.

“Most UX people I know are web interaction designers like me, but the book club drew developers, software UI designers, business strategists, visual designers, and various flavors of agency and in-house IAs and IxDs.”
- Sarah Mitchell, UX Book Club Los Angeles

In saying all that it’s also important to recognise that no two UX Book Clubs will be the same. The books will be different. Some groups will meet monthly; others every alternate month. Some will be small affairs with half a dozen folks and others will be big (30+); and some will be more book reviews than book discussion. And that’s OK. What’s important is that we learn something, meet some people, and enjoy ourselves in the process.

”...And that sort of set the tone for the rest of the event: high-energy, engaged conversation, a fertile middle ground between events where there is a single speaker with everyone else semi-passively engaged, and free-for-all cocktail hours, which are fun and great for networking, but lighter on substance.”
- “Anders Ramsay”:http://www.andersramsay.com/2009/01/17/taking-the-ux-book-club-to-the-edge/, UX Book Club NYC

Getting Involved In UX Book Club

There are two ways to get involved in UX Book Club. The first is to sign up to the group in your local area. A list of existing UX Book Clubs is available on the wiki at “uxbookclub.org”:http://uxbookclub.org. There are around 50 groups already listed – including some groups that are just forming. If you’re working in UX or would like to learn more about the field to help with whatever work you are doing, add your name so that you can be kept informed.

The second way to get involved is to start your own UX Book Club in your area. We’ve found that the best thing to do add your city or town to the wiki list, then post a message to the IxDA.org or IAI mailing lists (or both) letting other people know. We’ll send an announcement out via ”@uxbookclub”:http://twitter.com/uxbookclub on Twitter to help spread the word. If you have a local IAI, UPA, or IxDA chapter, tell them about it at your next meeting.

I’ll leave with you a quote from Whitney Hess (UX Book Club, NYC) that echoes the sentiments of so many UX Book Club attendees:

“These books really aren’t meant to be read alone — they’re references as well as jumping off points for exploration of the practice. It was great to hear what others thought of both the content and its context in the greater body of work, book-form and otherwise, that our community has produced.

I’m really looking forward to the next event.”

Control and Community: A Case Study of Enterprise Wiki Usage

Matthew C. Clarke — Mon, 04 May 2009 07:51:14 GMT

The Balance of Power

There are a wide variety of uses for Wikis and a level of interest in using them that’s matched by an extensive range of Wiki software. Wikis introduce to the Internet a collaborative model that not only allows, but explicitly encourages, broad and open participation. The idea that anyone can contribute reflects an assumption that both content quantity and quality will arise out of the ‘wisdom of the crowd.’

There are, however, negative effects of this extreme openness. One problem is the deliberate vandalism of Wiki pages. Another is that even those with no destructive intent may yet degrade the quality of a Wiki’s content through lack of knowledge or skill. Anyone can write nonsense as though it were fact. Anyone can accidentally delete useful information. Someone with half-baked knowledge of grammar may change all the “its” to “it’s.” Of course, someone more knowledgeable may notice the problem and fix it … but then again maybe they won’t.

Wikis can impose various forms of control to protect against these risks, including user registration, moderation, enforced stylistic rules, and imposing prescribed topic structures and page layouts. These types of control, however, are typically seen as contrary to the basic Wiki concept.

Consequently, one of the central tensions when managing a Wiki is between centralized control and anarchy. In the public arena, the balance of power tends towards anarchy, but in a corporate environment a more centralized approach is often required.

In this article I describe one application of the Wiki way to a common corporate process and extract some guidelines for the effective use of Wikis in that context. In particular, I am seeking insight from this case study into the “balance of power” tension.

The example on which these reflections are based is a project within the software company CorVu [1] to improve the technical knowledge base related to the products we sell. Like many companies, CorVu has extensive knowledge of its own products and a desire to make that knowledge available to customers. A major block to achieving that desire has been a lack of people with the time to either record the internal knowledge or to fashion the knowledge into a customer-ready format. We needed to spread the load so that a broad range of developers, tech writers, professional service consultants and others could all contribute what time and knowledge they had to a shared goal. Our hope was that a process built around several Wiki sites would facilitate this collaborative approach.

There’s no guarantee, of course, that lessons learned in that context will transfer to others. But without documented cases such as this one, any theorizing about the balance of power issue is just speculation.

Three contexts for a Wiki

To start with, it is important to clarify the key differences between three contexts in which Wikis are used: public, team and enterprise Wikis. [2].

Public Wikis

By a “public Wiki,” I mean one where any Internet user can read and contribute to the collaborative effort. It may be that editing content is restricted to a registered user group (as is the case with Wikipedia), but anyone can register. Consequently, the size of the contributing community is potentially huge, there is a high level of anonymity, and the contributors do not typically relate to each other outside the confines of the Wiki.

In this context, very little centralized control is evident. You typically find some explicit guidelines for contributors, either formulated by the founders/hosts, or as an evolving page edited by the contributors themselves. There is also an implicit understanding of etiquette and an implied social contract that comes with joining the “community.” But in the end, anyone can edit anything … and anyone else can un-edit it. This is the essence of anarchy: not that anything goes, but that what goes depends on peer acceptance. In an anarchy, it is not the case that there is no control; rather, the control is exerted by peers (around the edges) rather than by an authority (in the centre).

Requiring registration prior to participation does not alter the anarchistic nature of the process. Registration has numerous benefits, not least of which is that contributors can be recognized and gain respect for their contributions. Registration may also increase the sense of belonging because it reflects each contributor’s conscious choice to join the community. That sense of belonging is essential to any viable anarchy.[3]

Moderation, on the other hand, inevitably moves the balance of power towards the centre. Moderation invests some users with the power to limit the contributions of other users. While moderation is sometimes seen as necessary in order to combat vandalism and dissension, this imposition of authority denies the libertarian aspirations of most public Wikis.

Team Wikis

A “team Wiki” is one where the people who read and contribute all belong to the same team or work-group. Perhaps the R&D team uses the Wiki to record evolving product specifications; or the members of a local church collaboratively documents its history; or a class of students collates the results of a research project. Membership of the team predates and takes precedence over membership of the Wiki community. A person joins the team and as a by-product may be requested or required to use the Wiki. The number of people participating tends to be small and the contributors are likely to relate to each other outside the context of the Wiki.

In contrast to public Wikis, where self-selection guarantees that the vast majority of users are technically savvy and keen to be involved, the people contributing to a team Wiki may not be doing so voluntarily or with much enthusiasm. It may well be a required part of their work that they would prefer to avoid. The need to make the Wiki as easy as possible to use becomes even more important in this context. This includes clear navigation and an effective search function, but more than anything else it means a simple, familiar user interface for editing text. Many team Wikis fail simply because the potential contributors refuse to learn Wiki markup or to use a non-wysiwyg editor.

In this context, registration is essential, but moderation is not. The restrictions on who can contribute protect against vandalism and, because the collaborators have pre-existing relationships and a common commitment to a higher cause, the community operates with a trust model. In fact, apart from the restrictions on membership, a team Wiki is unlikely to impose much control at all over contributions. Standards, structures, and conflicts will be resolved using the organization’s normal processes outside the Wiki. The collaborators will discuss and vote, or demand and threaten, or just do what the boss says, without that process being explicitly controlled by mechanisms within the Wiki.

Enterprise Wikis [4]

When it comes to implementing Wikis across a large enterprise such as a global corporation, a new set of concerns affect the balance of power. Management wisdom is required to maximize participation while keeping business objectives clearly in sight.

In my experience, it is rare that a single Wiki site within an enterprise is open to contributions by any employee. Where this is the case, moderation is likely to be required because of the large numbers of contributors who have no direct accountability to each other. The concerns at the enterprise level relate to how numerous organizational Wikis within the enterprise can be integrated into the IT infrastructure and how the use of Wikis can most effectively support corporate goals.

Rather than allow the proliferation of diverse Wiki projects throughout the enterprise, IT management is more likely to select the Wiki software that everyone is to use and perhaps host all instances centrally. It may be that some IT managers are “control freaks,” but there are good reasons for standardizing on Wiki software:

Risk. If many work groups host their own Wiki using their own choice of software, there is a significant risk of knowledge loss. It is hard to guarantee that each work group will secure the Wiki adequately or ensure appropriate disaster recovery. What happens if the work group’s server dies? Will they have an adequate backup procedure? What happens if the work group’s IT expertise leaves the company? Will the knowledge of how to run the Wiki be passed on to the remaining team? What happens if the Wiki software no longer operates when the server’s operating system is upgraded? Centralized Wiki management can avoid such problems.
Support. Most Wiki software is easy to learn (at least to us!), but some are certainly easier to learn than others. In a context where many employees participate in multiple Wikis within the enterprise, training and user frustration can be reduced by using the same software for all the Wikis.
Cost. Centralized IT management can also reduce the total cost of ownership of Wiki projects. That may be counter-intuitive given that most Wiki software is free. But the costs of running a Wiki include the cost of the hardware that hosts the Wiki, the time it takes to manage the Wiki (installation, user admin and support, backup, etc.) and the time it takes to teach people how to use the system. Although these costs may be small for each work group, the total across the enterprise can be substantial, and can be reduced by standardization and centralization.

In this context, the balance of power swings inevitably towards centralized control. The challenge is how to do so without stifling the free and creative contributions that are essential to a Wiki’s success.

The CorVu case study

The company I work for, CorVu, started using Wikis within its R&D group back in 2000 using the original WikiWikiWeb software. The project described below was based on MoinMoin, but we have also used DoKuWiki and have since standardized on Confluence.

CorVu produces software that assists other enterprises to implement their strategy and to track their performance against that strategy over time. CorVu has a variety of channels for making its internal product knowledge available to its customers, but the product functionality grows at a faster rate than the Tech Writers can keep up with. Apart from the fundamental description of each feature, a complex assortment of configuration details need to be documented – performance optimization, best-practice implementation techniques, interactions with third-party software, etc. A lot of knowledge at that level resides with the Professional Services team rather than the Product Development team. Often, the people with the knowledge do not have the time nor the writing skills to record it, and the people with the responsibility to deliver documentation to the customers do not have the knowledge. There’s nothing uncommon about that problem!

Since the goal of capturing and disseminating quality technical documentation requires collaboration, I thought that a Wiki might help. So we set up two independent Wikis to capture knowledge from two different groups of employees, and a third so that customers could access a sanitized version of that knowledge.

I’m not putting my own case forward as the paradigm of success. In fact, although the project yielded a significant improvement in capturing internal knowledge, we have not yet achieved the final goal of effectively disseminating that knowledge to our customers.

Figure 1. Knowledge capture and dissemination using three Wikis

R&D Wiki

This Team Wiki is the home of internal coding standards, design documents, etc. Anyone on the product development team can contribute, while employees in other departments can only view.

Professional
Services Wiki

The Professional Services Wiki (actually called the ‘Internal Technical Knowledge Base’) is a Team Wiki for recording how the product is used in practice, for instance: internal discussion about bugs, compatibility with third-party software, implementation tips and techniques, performance optimization, etc.

Anyone in the organization can edit this Wiki, but the primary contributors are Professional Service staff (consultants and help desk). This Wiki has two intentions: to be the primary location for recording and accessing internal product knowledge, and to be the staging ground for knowledge that can later be released to customers.

We centrally imposed the top level of structure and navigation here, based on product modules. This makes it easier for contributors to know where new content should be added. Specific pages enable FAQs to be built over time. Where it is relevant, information from the R&D Wiki is incorporated into this Wiki.

We scrapped a commonly used set of email distribution lists in favor of a process whereby questions and answers are posted to this Wiki site. This means that problem solving previously lost in email trails is now captured and searchable.

Customer Wiki

The Customer Wiki has the same basic structure as the Professional Services Wiki. That is, nearly all of the pages in the Professional Services Wiki have a matching page in the Customer Wiki. The difference is that the content in the Customer Wiki is edited by professional technical writers.

Each page of the Professional Services Wiki includes a status block indicating who the primary author was, who has checked the accuracy of the technical content, and who has checked spelling, grammar and adherence to the corporate documentation style. Only when those steps have been completed can the page be copied over to the Customer Wiki. An important part of that process is to make judgments about what information should be kept internal and what the company wants to reveal to its customers.

The Documentation Department is the only group who can edit the Customer Wiki. Although customers can leave comments, they cannot modify the published content.

In this project, there was a clear business goal and a centrally-driven process to attain that goal. The Professional Services and Customer Wikis were seeded with pages that provided a structure for delivering accurate and accessible content to customers. While the ability to contribute was widespread, there were explicit “rules of engagement” around user registration, topic naming, page layout templates, content categorization, and navigation.

Although there was a degree of central control, we tried to balance that with encouragement for broad-based collaboration–otherwise, why use a Wiki? The distinction that guides this balance is between structure and content. Although the structure is imposed centrally, content is generated by a diverse range of people in a way that promotes openness, the recognition of contributors, editing of any content without fear of criticism, and shared responsibility for quality.

Since the quality of the documentation exposed to our customers is crucial, the process includes a QA step that is uncommon for Wikis. We did not want to constrain all contributors to adhere to strict grammar, spelling and style rules. Instead we left the knowledge capture stage free from those restrictions and used technical writers to edit the content before its dissemination to customers.

It may seem strange that we would use a Wiki to publish non-editable information, but this is a testament to the versatility of the software. Wikis provide a very fast means of building a web site, whether collaboration is the intention or not. In our case, we use one Wiki site to capture knowledge from one group of people and another Wiki site to disseminate the information to a different group of people. With regard to my categorization of Public, Team and Enterprise Wikis, the “Customer Wiki” is a hybrid: it is built by a specific team and hosted within an enterprise infrastructure in order to publish in the public arena. A more traditional approach to software documentation would have been to repackage the knowledge into some other HTML or PDF format for customer consumption. But the maintenance of that dichotomy would have been far more onerous than copying between two parallel Wikis.

Managing an Enterprise Wiki project

Embedding Wiki tools across an enterprise is an organizational change project and as such requires appropriate planning and project management, along both technical and cultural dimensions. I won’t go over those generic processes, nor repeat suggestions for Wiki adoption that are documented in places like WikiPatterns. But drawing from CorVu’s experience, I will highlight some advice for project managers in the enterprise Wiki context.

People

Seek patronage at the highest possible level. That is, find a person with as much power within the enterprise as possible who will sponsor the project. The sponsor may do no more than ‘give the nod’ to your work, but that invests you with the authority to draw on other people’s time. In CorVu’s case, the CEO himself was a key supporter.
Enthuse a champion. This needs to be a person who is well respected, who will lead by example, and in doing so enthuse others. The champion will need to be able to put a lot of time into the project and will often be the primary contributor to the Wiki, especially at the beginning. In our case, that turned out to be myself.
Identify the group of people who can be expected to generate the majority of the Wiki content. These are typically subject matter experts. Discuss with them the value of writing down what they know or Wiki-izing what they have already written.
Identify anyone whose participation is mandatory. Is there a key political player or subject matter expert who absence from the project will cause others to think, “Well, if she’s not involved, I’m certainly not going to waste my time?”
Since our goal was to create a knowledge base for external consumption, it was important that the content generated by subject matter experts was checked for both accuracy and readability in the same way as other customer documentation. Consequently, the people involved in the project needed to include professional technical writers.

Tools

There are many different Wiki software tools in the market (Wiki Matrix lists over 100) but most are not adequate for an enterprise rollout. CorVu’s experience suggests that an enterprise Wiki requires at least the following:

Administration tools to manage a large number of users, with integration to enterprise security mechanisms (e.g. LDAP and single sign-on).
Separately secured spaces for different knowledge areas.
Effective management of attachments that includes versioning and a built-in search function that indexes the attachments.
Integration with other enterprise software such as portals, business intelligence, and content management systems.
Many contributors in an enterprise context will be non-technical. This makes it essential that the Wiki has a familiar, WYSIWYG editing mode rather than forcing users to learn some Wiki markup language.
An assortment of non-functional requirements such as good reputation, reference sites, some assurance of product longevity, and the availability of support.

Generating participation

All Wikis stand or fall based on whether an active community is formed. You can’t achieve the ‘wisdom of the crowd’ unless you have an active crowd. The means of achieving that across an enterprise are somewhat different from public Wikis.

Build a critical mass of contributors. Since the contributors are employed by the enterprise, it is possible to make the Wiki part of people’s responsibilities. At CorVu we found this to be imperative. Unlike a public Wiki (where there are many people who contribute huge amounts of time as a hobby), in a work context (where everyone is probably too busy already), this isn’t going to happen. So write it into job descriptions. Get managers to send emails to their staff saying that one hour a week should be spent writing up their knowledge on the Wiki. Arrange a seminar on how to use the system. Use the company newsletter to promote the value of the project.
Build a critical mass of topics. To be used, the site must be useful. To generate traffic to the site, make the most frequently required information available on the Wiki first, and make the Wiki the only source for that information. In CorVu’s case, for example, one significant page stored the latest product release information. When any software version was moved from internal QA to Beta, or from Beta to General Release, this page was updated. Once people learn that the Wiki contains a lot of useful information they will look there for answers to start with rather than wasting someone else’s time by phoning or emailing questions.
Send links rather than information. Set an expectation that when anyone is asked for some detailed information, the response should be a link to a Wiki page. If the information has not yet been Wiki-ized, don’t type a lengthy answer in an email; instead, spend an extra minute typing it into a Wiki page.
Provide recognition and rewards. As with most Wikis, the best way to encourage participation in the long term is to ensure that the efforts of the contributors are valued. This is easier in team and enterprise Wikis than in public Wikis because the contributors are known. Wiki pages can indicate explicitly who the primary authors were. There can also be rewards within the enterprise beyond the boundaries of the Wiki. For instance, some employees may have components of their annual review linked to their involvement in Wikis.

The future of enterprise Wikis

Our experience with Wikis at CorVu has been very positive and gives encouraging signs about the future potential of this approach to shared document workspaces. There are multiple offerings that meet enterprise IT standards, and the tools currently available are robust, simple to administer, simple to use, and inexpensive. The CorVu case also shows that enterprise Wikis can be used not only for internal purposes, but also as a means of publishing information to external stakeholders.

By putting minimal central control in place an enterprise can gain significant benefit from this simple technology, including improved knowledge capture, reduced time to build complex knowledge-based web sites, and increased collaboration. Although enterprise Wiki use requires a greater degree of centralized control than public Wikis, this need not impinge on the freedom to contribute that is the hallmark of a Wiki approach. The balance of power is different in an enterprise context, but fear of anarchy should not prohibit Wiki adoption.

Nevertheless, I predict that Wikis will disappear over the next 5 to 10 years. This is not because they will fail but precisely because they will succeed. The best technologies disappear from view because they become so common-place that nobody notices them. Wiki-style functionality will become embedded within other software – within portals, web design tools, word processors, and content management systems. Our children may not learn the word “Wiki,” but they will be surprised when we tell them that there was a time when you couldn’t just edit a web page to build the content collaboratively.

[1] CorVu is now a subsidiary of Rocket Software, but this case study pre-dates that acquisition.

[2] There is another form of Wiki that I have ignored here – the personal Wiki – but in that case, questions about the balance of control do not arise.

[3] In an editorial comment, Christina Wodtke offered the insight that if identity is essentially disposable, then registration does very little. Perhaps it is only when the link between registration and identity is persistent that protecting one’s reputation becomes an important motivation towards good behavior.

[4] What I call an ‘Enterprise Wiki’ others have called a ‘Corporate Wiki’. I prefer the former because it is not restricted to corporations in the business world, but also applies to government agencies, churches, and large not-for-profit organizations.

Interaction 09 Follow-up

Whitney Hess — Mon, 04 May 2009 07:51:03 GMT

From February 5-8, 2009, IxDA hosted their second annual conference, Interaction 09, in Vancouver, BC. Last year’s inaugural conference in Savannah had a powerful and lasting impact on the community, filled with encouraging messages and the realization that for many of us that we had “found our tribe.” The challenge for 2009 was to see if that energy could be recaptured a year later—in a new place and during undeniably pressing times.

The Setting

The Four Seasons in Vancouver felt much less intimate than the refuge and privacy we shared in Savannah, and the impact of Simon Fraser University was invisible compared to that of Savannah College of Art and Design (SCAD). Still, one important aspect remained quite evident—this community of interaction designers truly adores one another.

Finding people with whom you share similar passions, challenges, and perspectives both comforts and uplifts the community. Even with the different feel this year, Interaction fulfilled a critical mission. Disenfranchised, overwrought interaction designers looking for a way forward found renewal that can last us the whole year. We encountered inspiration around every corner, ringing with the clear message that our time has come and our mandate as designers continues to grow.

Instead of practical advice on which interface elements to employ in particular situations or new techniques for prototyping, the overall emphasis at Interaction 09 was much more about the role that interaction designers need to play in their organizations and throughout the world. Even IxDA’s manifesto noted the aim to “improve the human condition”—a far loftier goal than simply making useful and engaging digital interfaces.

Day 1, February 6

After a day and a half of workshops, the Interaction 09 conference started on Friday afternoon with a lineup of impressive keynote speeches from John Thackara and Fiona Raby, along with a heated panel discussion moderated by Jared Spool.

Thackara, in his talk titled “Experiencing Sustainability” (description | video) demanded that interaction designers do our part to combat climate change, resource depletion, and economic crisis by shifting our focus and skills towards designing promising new solutions for repair and growth. As interaction designers, we have the ability to devise innovative systems to combat common, everyday problems, and Thackara urged us to consider our impact far beyond the computer screen.

Though A/V system problems mired her talk, Raby shared several projects from her design students at the Royal College of Art that challenge many constraints we artificially place on how people interact with technology, and more importantly how people interact with and relate to one another when facilitated (and controlled) by technology.

Spool kicked off his panel by noting that as of today, 10,000 new interaction designers are needed to support the growing challenges of even just the most major companies; he asked his panelists, both educators and managers of design teams, how they plan to meet the demand. Matthew Holloway of SAP, Josh Seiden of Liquidnet and outgoing president of IxDA, and Andrei Herasimchuk of Involution Studios discussed the perfect balance of skills, education, and experience that they seek from designers they bring into their teams. Liz Danzico, chair of the new MFA Interaction Design program at the School of Visual Arts, and Jon Kolko, who founded the interaction design minor at SCAD, discussed how to best prepare interaction designers to recognize and address everyday business obstacles, becoming all the more valuable to their organizations.

The panel was getting at some critical obstacles in growing the interaction design practice before it disappointingly devolved into a “define the damn thing” debate about the distinction between interaction design and user experience. Groans from the audience and fierce statements from the panelists revealed just how divisive and counterproductive this argument can be. Still, it was great to see the community alive with fervor, as many hallway and hotel room conversations on the topic followed.

Day 2, February 7

While everyone was still nursing their wounds, Saturday started off on a much more uplifting note. We had talked about the state of the world, laid out our differences, and recognized just how much we’re all desperately needed; now it was time to talk about how to get this stuff done.

In his keynote titled “Irrational Behavior” (description | video), Robert Fabricant showed us some concrete ways that his team at frog design is addressing pervasive public health issues in South Africa with Project Masiluleke. He shared inspiring examples of great interaction design and reminded us that “technology is not our medium; behavior is our medium.” Fabricant differentiated among the outputs, outcomes, and impacts of our designs, noting that just because people are buying a product doesn’t necessarily mean that their behavior is changing. Our goal, clearly, should be the latter.

Dan Saffer revved us up at the end of the day with an impassioned keynote (description | video). He called for an end to the “religious wars” and obsession with defining our practice and instead urged us to be flexible and determine what is best for each project. “There are no best practices,” he said. “Best practices should be a place to begin, not where it ends,” reminding us that our responsibility is to invent new systems. He echoed other speakers in focusing our attention on health care, education, government, energy, and other domains where our ability to recognize and solve ongoing problems is sorely needed. “Where are the interaction design rockstars?” Saffer asked, citing our need to be as visible as the Frank Gehrys and Philippe Starcks of the world.

Ultimately the message was that being poised to tackle these issues simply isn’t enough if we aren’t capable of selling ourselves. As revitalizing as it is for our community to come together and learn from one another, it’s more important that we get out of the echo chamber and make ourselves known to those outside of the practice who can put us in a position to create change.

Day 3, February 8

By day three, we were ready to step out of the shadows and no one better to show us the way than Marc Rettig, a very humble and discreet member of our community who exposed us to the ways in which he and his company are choosing to make a stand.

He reiterated many of the previous day’s themes in his keynote, “How to Change Complicated Stuff (e.g., the World),” declaring that the relationships we create through products are far more important than the products themselves. If our goal as interaction designers is to create positive change, then we can no longer just be satisfied with shipping the product or launching the site. “You must establish the change,” Rettig said, “and put in place the necessary conditions for it to be come the new Normal.” Ultimately, our success isn’t measured with metrics but instead by the personal stories that illustrate how lives have been improved by our design solutions.

Then in her closing keynote, Kim Goodwin noted that the sustainability and cultivation of our practice can be ensured by one very important activity: Mentorship. Goodwin noted that if everyone in the audience mentored just one or two people, our community would grow exponentially and we would all become better at our craft. Both the mentor and the mentee have much to learn from one another, and that passing of the torch symbolizes, and ensures, the longevity of our profession.

Indelible Marks

A single theme emerged throughout the three days of the conference: The time has come to expand the definition of what interaction design comprises. In an ever-changing, interconnected, and in many ways injured world, we need to apply our skill sets, techniques, methodologies, and critical problem-solving capabilities to much larger-scale systems far beyond the reaches of technology.

As Doug Lemoine of Cooper nicely stated in a blog post recap, “Like other disciplines, interaction design is wrestling with the ways in which we, as a profession and as individuals, can do more than simply design more disposable crap. How can we design stuff that lasts, stuff that helps, stuff that addresses real problems?”

Phillip Hunter was particularly intrigued by the greater number of touchpoints across which we can design. Reflecting on the conference two months later, he wrote, “It was really exciting to hear and see emerging design tools and interaction mediums. NUI & gestural interfaces, mobile, MS Surface, Axure, Catalyst (someday soon we hope), etc., along with continuing extensions of browser-type experiences with Silverlight and Flex.”

Our community is growing, and with new people come new approaches, perspectives, and methodologies. As Matthew Nish-Lapidus wrote on the nForm blog, “Our practice is still in relative infancy, but there is amazing momentum and a great sense of importance driving us forward.” The challenge now is to unify the practice and turn our attention to the profound problems that truly need our help.

Several other sessions deserve note for garnering much discussion. Leisa Reichelt’s “Design by Community—The Drupal.org redesign” examined how to use the community to grow the design, while Christina Wodtke’s “Designing the Viral App” examined how to use the design to grow the community.

Also of note were those talks providing insight into the full-body interactions required for touch screen interfaces—Nathan Moody’s “Designing Natural Interfaces” and Bjorn Hartman’s “Enlightened Trial and Error – Gaining Design Insight Through New Prototyping Tools.”

Looking Forward

One of the most interesting things about the IxDA conferences are the sheer number of sessions presented over the course of just a few days. While “Lightning Round” slots allow for a wider variety of topics, 25 minutes is much too short to get anything of value out of a session. By the time everyone arrived, got settled in their seats and pulled out their notebooks or laptops, almost half the session had passed. There were several sessions that left me wanting more, feeling as though I would have gotten greater depth out of reading a blog post or article on the topic. I hope in the future that the organizers schedule more in-depth 45-minute-to-one-hour sessions and reduce the number of these shorter sessions.

In the end, the best thing about Interaction 09 was the opportunity to spend three days with so many brilliant, passionate practitioners, educators, and thought-leaders from all around the world. It is an honor to be among them, and no matter where we are or how we gather, these events and the community’s support energize me to do more, try harder, think smarter, and reach farther. Here’s to next year back in Savannah!

Note: Videos have been indicated here where available. More videos will be posted by the IxDA on Vimeo. Feel free to check there for updates. -Ed.

IA Summit 09 - Day 3

Jeff Parks — Fri, 24 Apr 2009 08:10:40 GMT

IA Summit 2009 Podcasts

Main Conference Sessions, Day 3 – Sunday, March 22

These sessions were recorded on the first day of the conference. Download them individually here, or get them all with the Boxes and Arrows iTunes feed.

Links to the presentations and slidecasts will be updated continuously. See the Slideshare IA Summit 2009 page for up-to-the-minute lists of available presentations.

Thanks to the speakers for their hard work and for sharing their knowledge with the community.

Gaming the Design: Using Game Design Techniques in the Realm of Investing – Dominic La Cava and Kellie Rae Carter

Games have a central goal in their design: to keep people playing. Games use a variety of interactive and immersive techniques to create a play space, techniques that are useful to designers of more work-oriented or transaction-based interactions. These other interactive spaces, in fact, have the exact opposite goal: to reduce the time users spend on the task or interaction.

In this presentation, Dominic La Cava, Senior Information Architect at Vanguard, and Kellie Rae CarterUX researcher at Comcast Interactive Media, demonstrate how one design team incorporated game techniques into a redesign project.

Download

Leading with Insight – Matthew Milan

Insight is one of the most widely used and poorly understood concepts in the creative process. Insight is what drives the big idea, validates the crazy hunch, and frames both problem and solution in one fell swoop. Without the right perspective, knowledge, and grounding, generating insight can be unpredictable, wildly unreliable, and completely inconsistent in application.

Matthew Milan, Principal and Design Director with Normative, helps us understand how to generate, identify, frame and use insight effectively. This poorly understood practice is an increasingly a critical skill to have when working on solving complex problems. As an information architect, insight is one of the best tools you can use to unpack difficult challenges and turn them into effective solutions.

Download

Lessons from Slime Mold: How to Survive and Thrive in Ever-Changing Organizational Environments – Kate Rutter

How can we stay effective, be engaged and create great work in an environment that is ever changing and in constant flux?

Say hello to slime mold, an organism that has spent the last few million years evolving a powerful set of survival techniques that are wonderfully relevant for people grappling in shifting organizational environments.

Kate Rutter, Experience Designer at Adaptive Path, describes how this fascinating life form holds intriguing lessons for today’s knowledge worker—from sensing and responding to environments that become hostile to using the power of signals to create alignment and collective action. In this romp through the kingdom of myxomycetes, we learn a set of practical tips and tools for surviving, thriving and doing our best work in even the toughest of environments.

Download

The Art and Science of Seductive Interactions – Stephen Anderson

To be good information architects, we need to crack open some psych 101 textbooks, learn what motivates people, and then bake these ideas into our designs. We’ve spent the last decade perfecting how to create applications that serve our users needs. Now it’s time learn a bit about the art and science of seductive interactions.

Stephen P. Anderson has been gathering and analyzing specific examples of sites who’ve designed serendipity, arousal, rewards and other seductive elements into their applications.

By understanding basic psychological principles we can raise the bar on our projects!

Download

The Courage to Quit: Starting, Growing and Maintaining Your Own UX Business – Sarah Rice, Whitney Hess, Jenn Anderson, & Christopher Fahey

In this panel discussion, freelance IAs Sarah Rice, Whitney Hess, Jenn Anderson, and Christopher Fahey argue that Information Architects have an opportunity to structure and evolve their own work environment. There is potential to influence where they work, who they work with, the type of work they do, and for whom they do work.

This panel discusses what it is like to create ones own work environment – the motivation for taking this entrepreneurial path, what it has been like, what we’ve learned, and the ups and downs of such a work life.

Download

UX Health Check: A Measure A Day Keeps the Redesign Away – Livia Labate & Austin Govella

The UX Health Check allows IA/UX professionals and their collaborators to introduce metrics of success and benchmarks to their product and service design decision-making, from the most strategic to the most tactical aspects.

Measures of success that qualify and quantify user experience efforts are scarce and not widely adopted. Livia Labate, Principal of Information Architecture and User Experience for Comcast Interactive Media, and Austin Govella, author and Independent Consultant, demonstrate the UX Health Check. This approach introduces a common language for UX professionals to measure how investments in improving the user experience result in concrete outcomes.

Download

Professional IA/UX Organizations – How to Start and Run a Successful Local Group or Chapter – Kyle Soucy, Nasir Barday

The growth of the IA/UX industry has seen the birth of numerous organizations with local chapters and groups around the globe, but there is more work that needs to be done. Existing chapters and groups need support and guidance to ensure continued growth and there are still vast regions that are in need of their own chapters and groups.

During this session, Kyle Soucy, Founder of Usable Interface, and Nasir Barday, Senior User Experience Architect at FactSet Research Systems Inc, share how to keep the momentum of a group going strong, including:

* Good meeting ideas * How to find venues, sponsors, and speakers * How to promote your events * Pitfalls to avoid in running your group * How to deal with limited volunteer help

Download

An Internet Watered Down (or, How to Save the Mobile Web) – John Pettengill

Mobile sites are not an afterthought to be appended on the end of a development cycle. Smart phones have something that desktop computers do not. Context. We need to rebuild the mobile web from the ground up, capitalizing on the fact that we can know where our users are, and consequently we can know their intentions.

John Pettengill, Information Architect with Razorfish, believes mobile websites should address the needs of users who are “out and about”, and any site that doesn’t shouldn’t be considered part of the mobile web. The Starbucks iTunes Store is a great example of how we can change, and improve, the way we live. iPhone users are presented with a special application when they are at a Starbucks café, an app that displays songs played at the café and gives users a way to purchase them.

Download

Evangelizing Yourself: You can’t change the world if no one knows your name – Whitney Hess

We devote our careers to advocating for our users, but who’s advocating for us? No one is going to carry you through your career. If you want to make a major impact in this field, you’re going to have to work at getting recognized. Moreover, your name has to be synonymous with quality.

In this session, Whitney Hess, User Experience Design consultant, helps timid and unassertive practitioners come out of their shells and become leaders in the user experience community. Her advice is based on her own experience taking control of her career and developing an authentic and positive reputation.

Whitney talks about the value of starting a personal blog, actively using Twitter and LinkedIn to build and maintain a network, staying up-to-date with trends and standards, how to get the most out of conferences, and ultimately how to gain confidence in your skills and successes.

Download

Five Minute Madness – IA Summit Community

This open mic session traditionally closes the IA Summit. Any conference attendee can approach the microphone five minutes to make their mark on the IA Summit. As in years past, a variety of people take advantage of this open forum.

Boxes and Arrows

Using Wikis to Document UI Specifications

Introduction

Description of the Problem

Wiki Overview

Benefits

Collaboration

Speed

Flexibility

Reversible

Archives

Centralized Image Updates

Informal Approval Process

Challenges and Solutions

Installing the Wiki

Syntax

Portability

Simplicity

Printing

Trust

Conclusion

References

UI Pattern Documentation Review

Introduction

The problem

The solution

Integrating UI patterns

Why standardize UI patterns?

Problems with the solution: UI pattern Classification Approaches

Martin Welie’s patterns

Classification Analysis

Documentation Approach

Jennifer Tidwell’s patterns

Sari Laakso’s patterns

The Design of Sites’ patterns

Summarizing the classification types

Another Classification type – Level

A proposed classification system

Why have a classification hierarchy — aren’t filters or tags more useful?

UI pattern Documentation Proposal

UX Book Clubs

The What and the Why

How It Works

Getting Involved In UX Book Club

Control and Community: A Case Study of Enterprise Wiki Usage

The Balance of Power

Three contexts for a Wiki

Public Wikis

Team Wikis

Enterprise Wikis [4]

The CorVu case study

Managing an Enterprise Wiki project

People

Tools

Generating participation

The future of enterprise Wikis

Interaction 09 Follow-up

The Setting

Day 1, February 6

Day 2, February 7

Day 3, February 8

Indelible Marks

Looking Forward

IA Summit 09 - Day 3

IA Summit 2009 Podcasts

Main Conference Sessions, Day 3 – Sunday, March 22

These podcasts are sponsored by:

IA Summit 09 - Day 2

IA Summit 2009 Podcasts

Main Conference Sessions, Day 2 – Saturday, March 21

These podcasts are sponsored by:

IA Summit 09 - Day 1

IA Summit 2009 Podcasts

Main Conference Sessions, Day 1 – Friday, March 20

These podcasts are sponsored by:

IA Summit 09 - Keynote

IA Summit 2009 Podcasts

The IA Summit Opening Keynote

Contrast Reveals Mediation

Inspiration Trumps