mindtangle

Web 2.0 Notes: Social Interface Design Patterns

Workshop Title
Designing Social Interfaces: Principles, Best Practices and Patterns for Designing the Social Web

Presenters
Erin Malone (Tangible UX) and Christian Crumlish (Yahoo!)

This was the first workshop I attended this week, on Tuesday. Malone and Crumlish have done a ton of work assembling a comprehensive set of design patterns that can be applied to social software. In their workshop, they ran through a number of scenarios, each showing how various patterns might be applied.

What’s interesting here is that each pattern codifies not only the justification for its application, but also the pitfalls that can be associated with each. One example of many: Letting users form an identity through your software forces them behave as there is now something at stake. Give them a reputation system that incentivizes too much competition, however, and your networks will break down.

Detailed notes, links, images, and the full slide deck can be found after the jump.

Note: I mention Christina Wodtke’s presentation a number of times in my notes. This was a workshop on the same topic that I attended later that day. Those notes will come my next post.

Intro to Social Design Patterns

Examples will be drawn from eGroups, Flickr, Facebook, Twitter, etc. Patterns include both components and larger, overarching patterns. Designing these interfaces is a holistic exercise that extends from the data architecture to the presentation layer.

A Simple Taxonomy:
Social Interaction Venn Diagram

Behavior patterns vs. Interaction patterns: Related, but not identical. The latter is what we encourage people to do with our experiences and interfaces (the affordances we make available.) The first is what people do, because of or in spite of our designs.

The patterns are open sourced and are being collaboratively developed here. Some patterns are established, but many are still developing.

What is a pattern?

[As with Alexander's Design Patterns or the Gang of Four, these social design patterns are expressed in a standardized format.]

  • An optimal solution to a common problem within a specific context.
  • Not a finished piece of code or design
  • Meant to inform all considerations needed to solve a specific problem
  • Context Matters!
  • The Form:
    1. What: Defines the problem. What does the user want to do? Includes a visual example
    2. When: When to use or not use the solution. Adress context
    3. How: Detailed solution. What decisions need to be made, elements to use, behaviors, etc.
    4. Why: Why this solution is best

A Few Scenarios

This talk is a tour of the patterns developed by Malone and Crumlish. They run through a framework for viewing all patterns, going in depth on a couple. The site is comprehensive; no need to repeat the outline here. The tour takes the form of collections of patterns that might be applied in various scenarios.

The Basic Scenario

First steps: lightweight additions to an existing site.

  1. Talk like a person: Modify your site copy to use a conversational tone; sacrifice strict grammar where necessary. Read things out loud. Speak to the user like you would IRL. See: Flickr and GetSatisfaction (e.g. Flickr’s “Don’t be Creepy. You know that guy. Don’t be that guy.”) Instructables has a “Be Nice” policy that works great, here. We have good examples all over the site where we speak to our users in a personal way. We also have tons of terrible examples. Note that this was Leslie’s first criticism of our UI when we asked her her opinion of the site, last summer.
  2. Sign In: Very basic, allowing user to keep persistent state on your site. ‘Nuff said, here…
  3. Tag an Object: Allow user to attach kewyards to an object of organization and later retrieval. Unstructured data like books, photos, etc. Included here because it is a very easy on-ramp to participation. Flickr is an example, here. Less usefulness to Instructables (unless it would substantially improve our search.)
  4. Ratings: Allow users to quickly evaluate content. Stars, as on Instructables. Also very low commitment for participation. Lower even than tagging, IMHO. Instructables’ rating widget tracks the suggested interaction model pretty much exactly, here, from hover status to various click targets.
  5. Share this Item: First cut on engaging other users/potential users. Fairly standard. The examples here also look much like Instructables’ implementation. See Wodtke’s talk. She has good notes on strategies to avoid the “Wall of Buttons” effect.
  6. Contact Cards: Expandable UI for finding lightweight information about a user. Shown on click or mouseover. A way to hide a lot of reputation/identity-related clutter/relationship reflector UIs but give quick access without interruption when desired. Especially useful to Instructables, since we will likely end up going for a more “holistic” reputation system that won’t e easily condensed into a single UI representation.
  7. Adding Friends Instructables doesn’t have two-way relationship structures, yet. Subscriptions are non-reciprocal. Look over the pattern to see what benefits there are to such a feature, because the case isn’t clear for us.
  8. Password Anti-Pattern: Getting users to type in their usernames and password to another site to retrieve contact info. This is highly recommended against. Instructables uses this in its publish pane. Is this really giving us much benefit? See the Wodtke talk; it does give a lot of benefit, which is why everyone engages in this terrible practice.
  9. Circles of Connections: A more complex pattern, allowing for multiple levels of permissions or differentiate between strong and weak ties. There are tons of pitfalls here, both technically and socially. Instructables doesn’t need this, fortunately.

Invisible Users

“People come and read my content, but they’re invisible to each other”

  1. Presence Indicators: See which other users are online, available, and/or open to contact. Would probably be built into any site-wide chat APIs we end up using.
  2. Peer-to-Peer awards: Formalized method for users to give and receive compliments. “You’re Funny,” “You’re Cool,” etc. Instructables could have a “You’re Helpful” button in the comments UI. Merge with Badges on the Profiles, perhaps.
  3. Nudging: Content-free communication between people. Phatic communication. Minimal interaction. Probably less useful on Instructables, where the focus isn’t currently on socializing, more on group curation (or that’s what we’re telling ourselves, at least)
  4. Public Conversations: Forums, comment threads. This is well-travelled territory for Instructables. They are focusing not on forums, though, and more on these emerging patterns (commenting on friend feed, Twitter, etc.) where a conversation may be personal or between a small number of people, but others look on somehow. Instructables’ Orange Board is a better example.
  5. Followers Badge: Instructables and subscriptions, group members, “They like it” using favorites, etc. There are also User Galleries, which allow readers to see recent readers of a piece of content.

Misbehavior

An active community misbehaves (flamewars, griefing, spam, etc.)

  1. Norms, Model Citizen: How do you present the right ways of acting? These can be written out, but they will seldom be read. Useful still for reference. Founders and community managers can play the role of Model Citizen to demonstrate desirable behavior. We have both a codification of norms and a number of Model Cizens who keep things in check regularly on Instructables. Our community rocks.
  2. Leaderboard Antipattern: Really only recommended in extremely competitve communities. Incentivizes non-collaborative behavior. Reputation systems are long-running topic at Instructables. We would never employ this; a more “holistic” reputation system encompassing many factors will most likely emerge, instead.
  3. Reporting Abuse
  4. Reputation, as above
  5. Ratings, as above

Collaboration

My company wants to be more collaborative across distributed teams. Can’t we just add Facebook or Twitter? Less applicability to Instructables, here. More to various social endeavors of mine.

  1. Group Calendar: Basic. We need our own Doodle-like solution for scheduling…
  2. Wikis: Duh
  3. Manage Project: Task lists, resource allocation, Gantt Charts
  4. Group Conversation: Lists, Forums, etc. Neglected point, here: email is often used because search is the killer feature. There are a lot of good UIs, but not a lot of good search. Without good search, might as well use Gmail.
  5. Corporate Identity: Internal, behind-the-firewall profiles. FP does some of this ad-hoc on our wikis.

Mobile

“We also make apps for mobile phones”

  1. Geo: Determine user’s location (e.g. for recommending nearby services.) This is useful context that can be used to filter down and experience for current relevance that will fit on a small screen. I fail to see how this is social, however.
  2. Gatherings: Inform others where you are, on a map or otherwise. This is personal information that has a direct effect on IRL interactions, so much more care and nuance is required.
  3. “Statuscasting”: Twitter et al work well on mobile. Limited screen real estate isn’t too much of a hurdle. Life streaming vs. Activity streaming is an emerging distinction, the former being the much more mundane form.

Other Notes

Don’t Break Email. When you are notified of a message, include the content of the message! If you’re good, you can also make replies by email meaningful to your system. Important lessons, here. Base camp as case study. Instructables doesn’t do the best job here, yet.

[The exercises in this workshop were mostly a flop, so I didn't post notes, here. The presenters have amassed a large body of useful information online, but the crowd didn't get engaged with sharing ideas publicly after each exercise. Christina Wodtke succeeded, in this respect: see notes on her Workshop, next.]

The Presentation:

Related Posts:

One Response to “Web 2.0 Notes: Social Interface Design Patterns”

  1. Ian Wilker Says:

    Can’t tell you how much I appreciate a such a lucid and concise takeaway from what seems like a great workshop. Was just looking at the 164-slide preso a couple days ago — it’s great, but much better with a schematic like this.

    btw I loved the “serial reader interface” on your personal site!

    • Ian, community mgr @ brighterplanet.com, @iwilker

Leave a Reply

Comments can use Markdown syntax. The toolbar at the top will mark up your text using Markdown, automatically. If you'd like to use XHTML, these tags are available: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>