This is an excerpt from Designing Social Interfaces. From the creators of Yahoo!'s Design Pattern Library, Designing Social Interfaces provides you with more than 100 patterns, principles, and best practices, along with salient advice for many of the common challenges you'll face when starting a social website. Christian Crumlish and Erin Malone share hard-won insights into what works, what doesn't, and why. You'll learn how to balance opposing factions and grow healthy online communities by co-creating them with your users.
Instead of authority-based decision-making, we relied on a process we called "rough consensus and running code." Everyone was welcome to propose ideas, and if enough people liked it and used it, the design became a standard.
After all, everyone understood there was a practical value in choosing to do the same task in the same way. For example, if we wanted to move a file from one machine to another, and if you were to design the process one way, and I was to design it another, then anyone who wanted to talk to both of us would have to employ two distinct ways of doing the same thing. So there was plenty of natural pressure to avoid such hassles. It probably helped that in those days we avoided patents and other restrictions; without any financial incentive to control the protocols, it was much easier to reach agreement. This was the ultimate in openness in technical design and that culture of open processes was essential in enabling the Internet to grow and evolve as spectacularly as it has. In fact, we probably wouldn't have the Web without it. When CERN (http://topics.nytimes.com/top/reference/timestopics/organizations/c/cern/index.html?inline=nyt-org) physicists wanted to publish a lot of information in a way that people could easily get to it and add to it, they simply built and tested their ideas. Because of the groundwork we'd laid in the R.F.C.'s, they did not have to ask permission, or make any changes to the core operations of the Internet. Others soon copied them—hundreds of thousands of computer users, then hundreds of millions, creating and sharing content and technology. That's the Web.
A friend of a friend told me that "APIs are the biz dev of Web 2.0," and there's some real truth to that, especially if you mean open APIs. (An API, or application program-ming interface, is a set of protocols for interacting with an application from without.)
Internal APIs are essential to the development of any true platform, but open APIs unlock the potential of a third-party developer community, taking your project into realms far beyond what you could commission or build yourself.
The Internet has always thrived on openness: the open (and social) process by which its fundamental protocols (such as the TCP/IP stack) were developed (on the basis of "rough consensus and running code"), the open source operating systems and programming languages that have fueled and sustained its growth, the open interlinking of netnews nodes to create the anarchic and resilient Usenet, the open linking customs of the World Wide Web, the open editing norms of successfully wikis.... I could do this all day.
Of course, today everybody pays homage and lip service to the concept of openness. Everyone says they're open, or trying to be open, or getting more open, but there are many ways to be open and there are many degrees of openness, and frankly, "open" isn't the ultimate value that inherently trumps all other concerns. As with any software architecture of a user experience design project, there are inevitable trade-offs. Great fortunes have been built on lock-in, by keeping switching costs high, and by not allowing users complete control over their own data.
For the sake of this discussion, let's look at four clusters of open patterns and principles:
Embracing open standards
Sharing data outside of the bounds of your application
Accepting external data within the sphere of your application
To be clear, we're not religious about any of this: if a proprietary protocol or technology or model works best for you, then use it in good health and gain whatever benefits you can get, but be aware of what you may be giving up in exchange. Where possible, though, we've found that the more you can build your app upon the rock of proven, well-implemented, open standards and technologies, the easier it is to participate fully in the social potential of the Web and the always-on digital environment we now live in.
Throughout this book, we've lamented the Password Anti-Pattern and the pain of re-friending the same people on multiple networks. Over the last few years, many community-developed protocols have arisen to facilitate interoperability, building upon each other wherever possible. There are several ways to visualize this stack, and it's still a work in progress (Figure 17.1). But to the extent that you can leverage the solutions that are already out there, you'll be able to focus on the value you're trying to add to the ecosystem: the unique killer service your app provides.
Figure 17.1. One articulation of the "open stack" (also known as the "social stack" to distinguish it from the existing open stack that already powers the Internet).
What can I say about open source technology that hasn't been said before? The Internet thrives on open source, and many of the most successful startups and powerhouses run open source languages on open source operating systems. But even if you're fully convinced to use free software that you can patch yourself instead of expensive, opaque software, you still have choices. Will you contribute your code back to the community or essentially create a forked-off cul-de-sac that you'll end up maintaining single-handedly? Will you pay employees to contribute to open source projects that may benefit your competitors? These decisions aren't easy to make, and there's no single answer for everyone, but take the time to think these puzzles through.
Often the first step in "going open" is to open out to the rest of the Web, to make your content and features available elsewhere. It can be easier to sell the idea of extending the reach of your data than perhaps to permit others to play in your own sandbox. As always, there are trade-offs.
When you enable your content to appear in contexts you don't control, you lose a little bit of mastery over the presentation of your brand. You'll have to weigh the pros and cons to determine what to do, but recent history—as in the great success of RSS as a simple syndication format—tells us that limiting your expanse to the servers and hosts and sites you control directly is a risky proposition when the rest of the Web feels more and more like a free-for-all.
Successfully opening out means providing ways for external applications to consume and add value to your data, either public data or data your users have affirmatively authorized for this additional service.
Badging out is one of the easiest openness patterns. It involves packaging up information, frequently personalized information, in a portable format that can be copied and pasted into the template of another site so that content from your service can cleanly appear elsewhere on the Web (Figure 17.2).
Figure 17.2. Generating a badge is a simple way to make your content available away from your own site.
Perhaps the canonical example of this pattern's success is the way YouTube's simple embedding code enabled it to piggyback on the popularity of MySpace as members of the latter site shared videos with one another (having found it much easier to embed YouTube videos than those from any other service). MySpace briefly considered banning YouTube embeds from its service, but by then it was too late.
Also known as "(External) Module," "Badges," "Badging Out," "Embed Codes," "Codes," and "Widgets."
Use this pattern when the user wants a way of taking his content from your social site and sharing it elsewhere.
Allow your user to collect the data that he wants to share on another site.
Generate a snippet of sanitized code that contains access to the data from your site.
Let the user cut and paste the code from a textbox to paste into the other site.
Later, when another user accesses the other site and the page loads in the browser, the embedded, sanitized code executes and retrieves the personally selected data from your site for display as an embedded module or widget.
Giving your users a simple snippet of code for embedding in another site is one of the easiest ways to facilitate organic awareness of your site. Any user who creates a badge and embeds it on her blog or Facebook page is in effect advertising your site for you. Users provide an invitation for their visitors to explore the data or content being shared from your site by clicking through the badge and visiting.
The section called “Embedding”
Microformats and other established semantic markup and data-structure formats enable third-party developers to write applications that consume and manipulate the data you're generating (Figure 17.3).
Figure 17.3. By the simple virtue of marking up your presented data with microformats, you can enable machine reading and semantic interpretation of that data by third-party developers.
Use when designing templates and parsers for your data feeds, streams, sources, and pages.
Wrap any data you publish on the Web with semantic markup, using the common emerging standards (notably, RDF and microformats), as a ready way of sharing it in a structured format.
Broadcast your public content in a readily consumable format by marking up with commonly accepted semantic formats, including but not limited to RDF, microformats, and POSH.
Another site accesses your site using arbitrary URLs to read your public content.
Wrap the content in a standard, sanitized format so that the other site can blend it with its own data.
Third-party developers will improvise unreliable screen-scraping routines in order to consume, structure, mash up, and distribute your content if it is displayed in public dressed in semantically meaningless markup.
The section called “Authorize”
Incoming interoperability is the mirror image of outgoing. It involves the ways in which you support bringing in and building on data generated externally to your system and either found in public or authorized by your own users.
Just as providing badges enables site users to export content from your site and have it appear elsewhere on the Web, openness is a two-way street, so you can strengthen the appeal of your own environment if you enable your users to import their own data from elsewhere on the Web into your site (see Figure 17.4).
Figure 17.4. An application on Facebook enables status updates from Twitter to be imported systematically, consumed, turned into Facebook status updates (with some rules and exceptions), and displayed on Facebook, giving Facebook users the benefit (or annoyance) of additional information that would otherwise not flow to them.
Much as we may dream of building one site to rule them all, it's much more likely that our site participants will continue to live at least part of their lives elsewhere, creating content and forming relationships outside of our site.
Use this pattern when designing the formats and structures of your social objects. Allow the flexibility of open content and data modules to enhance the overall user experience. Allowing offsite content to intermix (even if only with side-by-side widgets) lets your users truly make the experience their own.
Invite your users to provide credentials (or simply URLs for public data) to retrieve third-party data from a third-party site.
Use the credentials or URL to connect to the third-party site, authenticate and/or authorize if required, and retrieve the third-party data.
Optionally blend the incoming data with your existing data.
Present the data to the user.
Instead of trying to fight or ignore the sad fact that our users have lives outside of our site, we can instead invite them to aggregate their content inside of our site by providing easy ways for them to import content generated elsewhere.
Making your own content and services available "off network" is beneficial, but it's only half the story. Without opening your own environment to third-party modules, you deny your users opportunities for experiences that can be improved by greater inventiveness and competition (Figure 17.5).
Figure 17.5. Hosting a module from an external site on yours can feel risky. It's the reverse of the badging out role, but the experience for the user is the same.
Use this pattern when your core services are strong and healthy, you've given outside developers the ability to build on and enhance all of your incoming and outgoing hooks, and you feel confident enough to permit external developers to create services mixing your sources with others that are hosted on your own site.
Another site creates a module/app that includes access rights to data.
The module is uploaded to your site, scanned for safety, and stored for later use.
As you can see, opening out and opening in involve much of the same thinking, but from the opposite side of the table. To fully embrace the "flow" of the Web (and perhaps avoid being routed around), explore the possibility of being open in and open out.
Don't try to own everything. Create more value than you capture. Don't build an application when a feature will do. (See Figure 17.6.)
Figure 17.6. Fireball, a prototype that mashed up Twitter for its social graph, Upcoming for its calendar of Web 2.0 Expo events, and Fire Eagle for its location-awareness.
You have a suite of interesting solutions and a collection of data. You recognize that others can create new and unforeseen solutions with the data if it is exposed through an API (Figure 17.7).
Figure 17.7. Exposing your APIs to outside developers is a fundamental form of openness that can enable your social service to operate as part of a larger ecosystem, rather than as a backwater unto itself.
Use this pattern when developing your site's architecture, when conceptualizing the ecosystem your service will live in, and when deciding which APIs or which aspects of your existing APIs to expose to the public.
Wherever possible, expose APIs that enable outside developers to extend the value of your core service.
Each case will have its own issues of data security, privacy, what gets shared, authentication, authorization, and so on. Terms of Service provide a legal framework for safe data sharing practices, but a rule-based permission system must be in place to enforce rules mechanically.
Some services must be opened on a read-only basis. This may frustrate your third-party developers, but if it can be justified as better than no access at all to data and connection information, then it may still be worth offering.
What's good for the goose is good for the gander. If your site can be enriched by the import of data from outside sources, your data can also provide value to your users when you allow them to take it into their environments and experience it in convenient contexts.
As seen on
Facebook API (http://maps.google.com/help/maps/getmaps/advanced.html)
Google Maps APIs (http://apiwiki.twitter.com/)
Twitter API (http://wiki.developers.facebook.com/index.php/API)
Yahoo! APIs (http://developer.yahoo.com/everything.html)
Many opportunities for social design experimentation online involve adding incremental new features to existing services, but the effort involved in duplicating those services just to add one more feature is prohibitive or wasteful. (See Figure 17.8.)
Figure 17.8. A trusted middleman can broker data exchanges and profit by understanding the flow of information and social gestures that pass through the utility.
Also known as "Middleman, "Middleware," and "Utility."
Use this pattern when you are designing a system that can enhance existing social behav-iors but you don't see the value in trying to launch your own ecosystem just to support your idea, because it's more of a feature than a complete application.
Build an open, interoperable service with clear opportunities for data input and retrieval, clear privacy and security rules and permission structures, and adequate documentation. Then, support the developer community as if it is your primary customer (because it is).
If you want to be seen as a utility (as Facebook describes itself), then you cannot be perceived as self-dealing. Bakers put that 13th cookie in the bag to prove to you that they don't have their thumb on the scale.
http://www.slideshare.net/marccanter/how-to-build-the-open-mesh-09-1427980 How to Build the Open Mesh (unbook wiki), http://buildtheopenmesh.com/ Joseph Smarr at Web 2.0 on the New "Open Stack,"
http://therealmccrea.com/2008/09/19/joseph-smarr-at-web-20-on-the-new-open-stack/ Microformats.org, http://microformats.org OpenSocial, http://code.google.com/apis/opensocial/ The Open Stack: An Introduction (YDN blog),
http://developer.yahoo.net/blog/archives/2008/12/the_open_stack.html The Open Web Foundation, http://openwebfoundation.org/