Design patterns for orchestrating collaborative groups

What

When people get together and form groups, they often discover a shared desire to accomplish something tangible or complex, frequently something with a real-world (offline) impact (see Figure 1-2).

This pattern is also known as a “Workspace” pattern.

Use when

Use this pattern when you have enabled group formation and wish to host and support group project activities. If you don’t have the bandwidth (literally or figuratively) to support this, consider supporting third-party services.

How

• Support your members’ ability to orchestrate projects by coordinating goals, tasks, and deadlines among multiple participants with varying degrees of commitment and availability.

• Provide a workspace for connecting all the facets of the project (people, tasks, dates, collateral) and, if possible, offer a summarized dashboard view linking to more detailed inventories by facet. This makes asynchronous communication possible across disconnected geographies.

• Provide a mechanism for the creator of the project or a participant to bring in collaborators with Send Invitation, and possibly to assign varying rights by individual or group, as shown in Figure 1-3.

  

• Support task management with the ability to assign tasks, accept tasks, and distribute processes among multiple participants by breaking them down into individual tasks. Optionally support the ability to declare that one task is dependent on another and possibly calculate the critical path to the end goal.

• Provide a calendar on which deadline and milestone dates can be scheduled and then verified.

• Offer the ability to send messages to project participants, as well as reminders and notifications.

• Provide a means for collaborative editing of documents or source code, including version control (Figure 1-4).

  

• Include a way for project participants to make and keep track of decisions.

• Optionally provide an interface for project blogging or statuscasting so that project participants can report on their progress and anyone can see at a glance what has been happening lately on the project. Or, provide a timeline view on the dashboard to roll up all recent events in chronological order.

Why

Giving your community members the tools to work together or comanage their own efforts increases the utility of your service and the culture of the social environment. However, your users can often do this effectively via email and phone and perhaps a filesharing system. Do you have anything more to offer? Do you need to?

What

To make decisions, the members or stakeholders of a group need a way to give their opinions, and project leaders need to know which options have the most support from the participating community, as illustrated in Figure 1-5.

This pattern is also known as “Polls” or “Surveys.”

Use when

Use this pattern to collect the opinion of a group of people around a topic (with facets).

This pattern works best when groups are large enough that only a core subgroup is doing most of the collaboration, to provide a voice to the less fully engaged members of the group.

Voting can be in an enterprise or workgroup context. It also can integrate equally well in a consumer context, in which a group of people freely associating with one another need ways to discern their preferences and make collective decisions.

How

Provide a form by which a group moderator or participant can suggest a question or topic to be voted on, and then facilitate a series of possible votes (anything from “yes” or “no” to a multiple-choice option).

Optionally, provide configuration choices governing such issues as how long the voting will remain open, whether users can change their vote, whether votes are anonymous or open, whether a person is restricted to vote for a single choice or can vote for more than one, or whether a ranking of choices is preferred, as demonstrated in Figure 1-6.

Why

Voting and surveys provide a means of soliciting feedback about specific questions from a wider participating community.

Note that it’s possible for some users to game voting systems, especially if no fixed identity is required or authenticated before voting; voting can provide perverse incentives in much the way that a leaderboard can; and there are many competing voting algorithms out there, each with its own pros and cons.

What

People like to be able to work together on documents, encyclopedias, and software codebases, as depicted in Figure 1-7.

Use when

Use this pattern when you want your members to be able to work together to curate their collective wisdom or document their shared knowledge.

How

• Provide a repository for hosting documents with version control. Give users a way to bring in additional collaborators with an invitation to participate, as in Figure 1-8.

  

• Provide an Edit This Page link (see Edit This Page) directly on the document to be edited, or give users the means to upload incrementally updated versions of a stored document.

• For direct editing, provide an edit box, similar to a blog or comment interface, such as that shown in Figure 1-9.

  

• Optionally, give contributors mechanisms for tracking changes, whether via notifications or with RSS feeds.

Why

Collaborative editing is better suited to the online (web or cloud) contexts than the alternative: sending documents via email to multiple participants and then orchestrating the proliferating multiple, asynchronous updated copies of a document, with aspirational filenames ending in “finalFinalfinal,” as painfully demonstrated in Figure 1-10.

What

People like to be able to ask for help with a document without always wanting to give direct editing control over the content itself. Other people feel more comfortable proposing changes and allowing the owner of document to accept or reject the changes, as shown in Figure 1-11.

This same model applies outside of documents as well—for example, when a Git user makes a pull request, proposing that a change be added to the core.

Use when

Use this pattern when more fine-grained control over editing permissions or review flow will help people be more productive.

How

Define a role or a mode in which edits or comments are not accepted or made public automatically but are instead left in a pending state for review by the document owner, who can choose to accept or implement the suggestion, or reject or ignore it.

There are two forms of this pattern, which can be used individually or mixed together:

• Pending edits (as with the Track Changes feature in Microsoft Word or the suggestion feature offered by Google Docs), in which a proposed edit is entered directly into the document and then either implemented or rejected.

• Pending comments (as with Medium), in which a suggestion is made in the context around the document and not directly in the form of its content. The suggestion is then either made public or left hidden or removed.

Why

A layer of pending or proposed changes around a document makes room for discussion and deliberation and gives the owner of the document clarity about the final result.

What

The more difficult it is to edit a shared document, the fewer will be the number of people who will bother to do so. Even forcing people to switch contexts (to an “editing mode”) will create a barrier to participation for a significant fraction of potential contributors (see Figure 1-12).

This pattern is also known as “Edit This, “Universal Edit Button,” “Inline Editing,” “Read-Write Web,” or “Two-Way Web.”

Use when

Use this pattern in interfaces for editing shared or personal documents. You can use this for contexts in which universal editing, anonymous editing, or registered, authenticated, and privileged editing is permitted.

How

• Provide a button or link on any editable content that links directly to an edit box for the content, preferably without even loading a new page, as illustrated in Figure 1-13.

  

• Optionally, when restricting editing only to privileged groups, hide the button from anyone who has not been authenticated as a contributor.

• Consider providing a WYSIWYG editing environment. This will reduce one of the barriers to participation for the majority of people who are not comfortable using abbreviated markup languages to format and style text.

Special cases

When trying to cultivate a culture of collaborative editing, community moderators might need to make an extra effort to recruit, campaign, and encourage contributions. By default, many people are passive, even when invited to edit content, because they are afraid to break something or give offense to a preceding editor. The interface should be as inviting as possible, but be prepared to challenge incumbent behavioral patterns.

Offer a “sandbox” area for beginners (see Figure 1-14), in which they can practice editing safely without worrying about damaging anything or exposing themselves to criticism.

Why

The great promise of the Web draws in part from its facilitation of two-way communication and collaboration across geographical and other boundaries. An interface element that invites the reader to become an author goes beyond the “second-class” forms of participation, such as giving feedback and ratings. The easier you make it to edit content, the more likely people will take the time to do so, and potentially spur one another on to build knowledge stores and other projects that otherwise might never have come into being.

What

Collaborative editing can become bogged down in conversational mode. Moreover, when contributors become too attached to their own individual contributions, this can impede the development of the collaborative document (see Figure 1-15).

Use when

Use this pattern when providing an interface for collaborative editing.

How

Encourage anonymous editing, use version control, and enable refactoring of document content by contributors.

Here are the original principles Ward Cunningham cited when recalling the design principles that underpinned the first wiki:

Open

Should a page be found to be incomplete or poorly organized, any reader can edit it as he sees fit.

Incremental

Pages can cite other pages, including pages that have not been written yet.

Organic

The structure and text content of the product are open to editing and evolution.

Mundane

A small number of (irregular) text conventions will provide access to the most useful page markup.

Universal

The mechanisms of editing and organizing are the same as those of writing; thus, any writer is automatically an editor and organizer.

Overt

The formatted (and printed) output will suggest the input required to reproduce it.

Unified

Page names will be drawn from a flat space so that no additional context is required to interpret them.

Precise

Pages will be titled with sufficient precision to avoid most name clashes, typically by forming noun phrases.

Tolerant

Interpretable (even if undesirable) behavior is preferred to error messages.

Observable

Activity within the product can be watched and reviewed by any other visitor.

Convergent

Duplication can be discouraged or removed by finding and citing similar or related content.

There are many wiki authors and implementers. Here are some additional principles that guide them, but were not of primary concern to me:

Trust

This is the most important thing in a wiki. Trust the people, trust the process, foster trust-building. Everyone controls and checks the content. Wiki relies on the assumption that most readers have good intentions (but assume that there are limitations to good faith).

Fun

Everybody can contribute, but nobody has to.

Sharing

The dissemination of information, knowledge, experience, ideas, views, and so on is paramount.

Why

The wiki approach has unleashed a torrent of creativity on the Web and seems to have captured in its principles the fundamental grain of digital, electronic, web-enabled collaboration.

What

Some jobs are too big for the immediate group of engaged collaborators to manage on by itself. The community will benefit if the interface provides a way to break a large project into smaller pieces and engage and give incentives to a wider group of people (or “crowd”) to tackle those smaller pieces, as shown in Figure 1-16.

Use when

Use this pattern when you want your active core community members to engage with the wider set of people participating in your social environment and get their help accomplishing ambitious projects that would not be possible with fewer people.

How

• Provide a method for splitting up a project into individual tasks so that each task can be advertised individually. Also, provide a venue for announcing crowdsourced projects.

• Give community members a way to “shop for,” review, and claim individual tasks for the project.

• Provide an upload interface or submission form with which participants can contribute their completed work (assuming the work isn’t accomplished directly in your interface).

• Keep track of tasks that have been claimed but not completed by their deadline so that they can be returned to the general pool and reassigned.

• Ideally, offer a dashboard view for management of the project.

• Where appropriate, incorporate a mechanism for compensation for the participants.

Why

Crowdsourcing breaks large jobs into pieces that can be tackled with a much lower commitment threshold, taking advantage of the loose ties in social networks.