This is a sample chapter from the Second Edition of the book Designing Social Interfaces: Principles, Patterns, and Practices for Improving the User Experience, by Christian Crumlish and Erin Malone. 2015 O’Reilly Media, Inc.
Chapter 8: Share and Share Alike
“Friendship marks a life even more deeply than love. Love risks degenerating into obsession; friendship is never anything but sharing.”—Elie Wiesel
Sharing means that more than one person can see, have, do, talk about, or otherwise relate to the same thing, possibly at the same time. In the real world, sharing means allowing someone else to have access to or control over an object that you currently own or control. This involves a degree of sacrifice. Electronic things made of bits can be replicated or reflected with almost no friction, as compared with real objects.
This might mean sharing is generally easier in a virtual space (than, say, in kindergarten, when giving up the G.I. Joe meant losing control over his adventures), but therefore also less meaningful (or less likely to teach us to play well together, as when we learned that we could plan what G.I. Joe would do next together.
Tools to Enable Organic Word of Mouth
Count me among those not fully comfortable with the word viral as a way of describing successful runaway distribution. I understand that it’s the common term marketers and entrepreneurs have learned and are comfortable using, and I don’t want to impose a “correct” lingo on things, but I agree with those who suggest that viral growth isn’t the ideal metaphor for healthy, sustainable positive expansion. (It seems one trope away from concepts like metastasis.)
Call it what you will, though, a primary motivation for enabling and encouraging sharing among your users is so that good ideas, compelling objects, and interesting activities can spread like wildfire. At best, this benefits the creators of the objects as well as those who enjoy participating in the spreading phenomenon.
So, how do we encourage sharing, or even simply enable it? Well, there are already a number of well-established interface elements for doing so.
Some conventions have emerged for providing readers with tools for sharing whatever they’re currently experiencing in your product. These tools can be used for several of the patterns in this set, so I’ll describe them here first.
A sharing icon is a small graphical element placed somewhere in the interface with which users can share content and information resources with others, through a variety of communication channels (including social media platforms such as Twitter, Facebook, and LinkedIn, as well as email, SMS, and other newer vectors).
For instance, the Share button in Safari for iOS shown in Figure 8-1 gives the user a way to share content with friends on social networking products Twitter and Facebook, along with other options.
There are numerous ways to add a sharing icon to a flow by including it in the form of a widget, which acts as a bridge between the content of a given product and the backend application platforms supported by the widget, abstracting out the complexity of the application platform from the user application.
Provide a sharing icon in contexts for which the user may want to directly send a pointer, invite someone to view something, or add a copy of, or a reference to, something to a shared or public space he owns or has access to.
For direct sending, a user might just as well opt to copy and paste a link into an ordinary email message. This meets the user’s needs and benefits the community, but the behavior will not be trackable by the system, and thus the system won’t be able to learn from this. It’s important not to hinder the user, but be aware that if the sharing widget doesn’t provide any utility beyond traditional email, there’s little reason for users to adopt it. (With users who aren’t technically savvy, however, saving them from having to manipulate URLs and other computeristic text strings can be value enough to warrant use of the widget.)
By far, the primary form of sharing is direct sending. Secondary forms of sharing (such as IM, SMS/text message, and Facebook), when included, should be secondary within the sharing drop-down.
When users are logged in, you can prepopulate the sharing form with their information and give them contact-list or address-book access with autocomplete in the recipient field of the form.
Provide buttons or icons offering one or more ways to share, send, or bookmark the resource, as illustrated in Figure 8-2.
When the user clicks the button, display an overlay form with sending and sharing options (in the case of a single trigger), or with specific options for the type of sharing selected, as shown in Figure 8-3.
Users have come to expect these sorts of conveniences for grabbing and sharing content. Remember, everyone is overwhelmed by multiple streams of information and constant reminders to revisit or share or respond to more information. If users see that they can send or share content smoothly and with little effort, they are much more likely to engage in sharing the first time, and then expect to be able to do so instantly and effortlessly from that point on
As a designer of social experiences, you have several potential avenues for employing a Share This widget:
You can design and make your own widget, and use it throughout your service and/or encourage others to adopt it, thus driving at least some traffic back to your service.
You can publish icons, methods, and APIs for adding your service to existing or incumbent widgets.
You can embrace someone else’s widget if you simply want to incorporate its functionality and aren’t using sharing to drive direct participation in your own network or application.
Different bookmarking and media-sharing applications are popular or dominant in different regions. You can plan ahead for localization when designing a sharing widget by supporting modular swapping in and out of third-party services.
As the number of platforms for sharing proliferates, the idea of displaying an array of icons for destinations won’t scale. ?Why ?Incorporating a Send/Share widget into the template or the browser’s chrome when presenting content or applications, or providing such a widget for others to incorporate into their own interfaces, can help facilitate sharing and interaction on your network. You also can provide this functionality to your users through third-party bookmarking and media-sharing services.
AS SEEN ON
Most blog and zine sites everywhere
Bookmarklets work well for dedicated users already in the habit of sharing and looking for more convenient ways to do so, but they may also work for recruiting new sharers, if well presented. (Otherwise, first-time use of a bookmarklet tends to be rather nonintuitive.)
The executing script has access to the current page, which it can inspect and change.
A user can carry out installation of a bookmarklet by creating a new bookmark and pasting the code into the URL destination field, but more often, you provide the user with a link and encourage him to drag it onto his bookmarks toolbar.
One problem with bookmarklets is that they can’t be keyboard accessible with shortcuts, but they can be made to run on any browser and can even be self-updating.
Bookmarklets make sharing easier, thus reducing the friction for the user and facilitating more activity on the network.
AS SEEN ON
Most blog software such as WordPress, Blogger
Activity Streams are a third interface for sharing, but in this case they are the passive way a user’s activities—including posting, bookmarking, sharing, and commenting on things—can be displayed in an ongoing Vitality feed.
When information resources or digital assets are shared directly with a single user or a named group of users, it can be referred to as Private Sharing, although it might be a matter of sharing with one of Many Publics.
Although it’s not necessarily a one-to-one relationship (because a user can send the same thing to a list of people), the experience is perceived as direct and point-to-point. This is in contrast with Public Sharing, which feels more akin to hanging something up in a common space, such as a corkboard in a break room at work: it can be seen by others who are included in that specific limited public, but no single person has been explicitly invited to look.
Direct (private) sharing, however, does imply a direct invitation and can feel more personal. It’s important that a social interface have a clear strategy about how to present private sharing versus public sharing. If a user is notified or invited to see or do something as though the invitation were personal and direct when in fact it was a blast to a large, semifiltered list of buddies, this can lead to miscommunication and missed opportunities. If Patton Oswalt really invited me to play a word game with him on Facebook, I’d be flattered and inclined to make some time to do so, but if what really happened is that he (or his intern) accidentally invited everyone on his contact list after installing an application with perhaps a misleading interface, I’m in for a disappointment.
The true common patterns for direct sharing are Send This and Casual Privacy. The former is analogous to an email message containing a link to a public resource with an optional message such as “Check out this article I read in USA Today.” The latter is similar but involves inviting a person to see one’s own posted object or collection, and frequently follows the Public Sharing pattern as a secondary, promotional step.
A user wants to share an object—pointer, media, or application—with one or more people, as illustrated in Figure 8-5. The application is involved in the sharing in order to indicate who is sharing what with whom, and how often.
Use this pattern when you want to display content, resources, or applications in your product or on your site. When the user is logged in, you can provide an easier process by prepopulating her sender information and offering access to her contact list.
Provide a mechanism for people to spontaneously share content or objects they find by sending them to a friend or posting them to a shared, personal, or public space. Provide a consistent Share This widget on each screen or associate one with each granular object (pointers, media, applications).
Sending can be enabled for logged-out users with an encouragement to log in to gain access to contacts, or it can be enabled only for logged-in users, in which case it can be an incentive to sign up or a barrier to participation (see Figure 8-6).
When the user clicks the sharing link, provide—in a pop up or overlay if possible—the minimal interface needed to facilitate rapid sending or posting. Offer autocomplete selection from an address book or a set of contacts if possible.
Consider including a text field for adding a personal note, although most people will skip this, and some might even be slowed down by it. One approach is to include a link that, if invoked, expands the optional text field, as Flickr’s widget does.
Any interface that mimics (or hooks into) email can be misused for spam. If you’re using CAPTCHA, consider supporting audio CAPTCHA to provide better accessibility. Sophisticated users might likewise be reluctant to use a one-off sending method that won’t be tracked or archived in their personal mail system.
A Send This option on a useful and ubiquitous Send/Share widget can provide your users with a convenient and familiar method for sharing more content, objects, and applications with one another. If they opt to execute their direct sharing through your widget, you can learn from the behavioral patterns and optimize your interfaces and offerings.
Don’t Break Email!
One-Way Following (aka, asynchronous following)
AS SEEN ON
The New York Times
When people post content or discover it online, they sometimes like to invite other people to view it (see Figure 8-7). You can do this with a Share or Send interface, but in some cases the resource isn’t inherently viewable to anyone without an explicit invitation.
You want to provide users with an invitation option after they have posted content, uploaded resources, or installed an application.
They aren’t really needed for public resources that can be shared easily with a bookmarklet or Share This widget.
Generate a unique custom link for the content, and give users an option to copy and paste it into an ordinary email message or to send it automatically with a Send This interface.
A custom link that gives limited access to a direct recipient using Casual Privacy facilitates fluid sharing within a system of overlapping publics. This relieves the sender from creating formal groups, configuring privacy settings, and granting explicit privileges.
You want to provide a form of temporary or limited access for the recipient of the custom link.
Optionally, You want to provide boilerplate invitation copy that the user can customize.
If the recipient follows the offered link back to your site, remind him when he gets there that he is a guest and might be seeing content not otherwise viewable, as depicted in Figure 8-8.
Kellan Elliott-McCrea’s “Casual Privacy” talk at Web 2.0 Expo SF 2008
Kellan Elliott-McCrea’s “Casual Privacy” slides from Ignite Web 2.0 Expo
AS SEEN ON
It seems too early to declare that ephemeral sharing is a pattern at this point, or what the actual contours of the pattern will turn out to be as it finds its way, but the concept is already a salient trend. Ephemeral means “of the moment” or “passing.” Ephemeral sharing is sharing designed against impermanence, designed to vanish and leave no coherent map of the past.
This should be distinguished from anonymity or pseudonymity, models of which we see across the digital space, but most of which generally in the past continued to offer a form of persistence of identity (assumed or real).
Some recent products have shot up the charts (Whisper), some have faded over time (Secret), and others to continue to thrive as of this writing (YikYak), but all of them have played with the notion of temporary or passing, assumed identity; a clear extension of the models from other recent popular sharing services, like SnapChat and WhatsApp, in which the content is expected to disappear.
We’ll keep an eye on this one as the shape of the pattern emerges.
Social networks in Asia pioneered economies around virtual goods payments, which can provide an interesting alternative to advertising-based monetization schemes.
Users seem to enjoy opportunities to make friendly gestures to one another, especially when those gifts can appear as a tangible, persistent decoration in personal or shared spaces, as demonstrated in Figure 8-9.
Use this pattern in friendship- and romance-oriented social environments where visual displays of affection are welcome.
Provide an inherent gift-giving feature or make it possible for third-party application developers to do so through APIs for messaging between contacts and the ability to display objects on a profile.
If building an intrinsic gift-giving interface, add a Give Gift command to the list of actions a member can perform when viewing the profile or user card of another member, and/or provide a unique starting point for gift giving on the profile (see Figure 8-10).
Display the gift choices, and optionally give the sender a range of choices about how public the display of the gift and optional accompanying message should be, as shown in Figure 8-11. Who should see them (friends, everybody?), and where (on the profile, in the activity stream, elsewhere?), and who can read the note?
Optionally, charge your users to send a gift. (Weigh the revenue benefit against the degree of frictionlessness you are counting on to establish this behavior.)
Scarcity can provide an incentive, as a way for the gift giver to show extra attention or effort in choosing or finding the right gift. Notify the sender when the gift has been successfully received.
Give the recipient the option of accepting (and thus displaying on his profile) or rejecting the gift. If a gift is rejected, do not explicitly notify the sender. If the gift is accepted, display it on the user’s profile and/ or in his activity stream, according to the rules of your gift system and the choices the sender and receiver made.
Optionally, enable gift giving between strangers, but consider the risk of spam and stalking.
Think about whether you want to charge for virtual gifts and potentially find a revenue source there, promote free gift giving, or explore other forms of scarcity.
Virtual gifts provide at minimum the equivalent of a Phatic Poke, a small positive gesture between two people. If displayed on a profile they may also represent a reminder of the friendship. Micropayments for virtual gifts could represent one of several revenue streams for a social application with a sufficiently engaged community. Services for delivering real gifts would extend the goodwill of a positive interaction beyond the confines of the virtual space and would have straightforward monetization opportunities.
AS SEEN ON
Although we sometimes prefer the phrase Direct Sharing over Private Sharing (partly in recognition of the fact that nothing contributed to an internetworked data system is ultimately private in any meaningful, dependable way), for the sake of clarity, we are trying to be consistent about contrasting private and public facets of many of these social interactions. Still, rather than viewing things through the lens of the age-old public/private dichotomy, it might be more fruitful to think in terms of many overlapping public spaces, some of which are more public than others.
In any given system, there can be a range of sharing possibilities, from objects that any passersby can freely view, to items restricted to viewing only by (logged-in, authenticated) members of the community, to those that only people either included in a formal group or explicitly invited can see.
We consider any kind of sharing that isn’t directed at an individual or a specific, defined list of individuals to be public sharing. This form of sharing can be active, as when a user affirmatively posts content or information for viewing and commenting by friends, followers, fans, family, the general public, or any other such audience. It can also be passive, as when activities are tracked and reported on an ongoing basis, generating update notices to friends or items in activity streams without requiring that the user consciously and deliberately share the activity or object.
As Danah Boyd wrote in her PhD thesis, “Taken Out of Context”:
“Networked publics are publics that are restructured by networked technologies. As such, they are simultaneously (1) the space constructed through networked technologies and (2) the imagined community that emerges as a result of the intersection of people, technology, and practice. Social network sites like MySpace and Facebook are networked publics, just like parks and other outdoor spaces can be understood as publics. Collections of people connected through networked technologies like the blogosphere are publics, just like those connected by geography or identity are…. The concept of networked publics is slippery because the concept of publics is messy. The term public is contested, has multiple meanings, and is used across disciplines to signal different concepts. During my interviews, I found that teens also struggle to define this term and rely on multiple meanings to approach a definition from different angles. When used descriptively, public is often in opposition to the equally slippery concept private to signal potential access.”
When designing a social application of any kind, you must immediately grapple with the perspectives of—at the very least—two publics. One is the whole world that will have some way of glimpsing your product, if only to see the high walls of your private garden. The other is the networked public you hope to cultivate, composed of the body of all of your members and participants. Most likely there will be more than two. The outside world can itself have subpublics that view your product in different ways. More important, as your members meet one another and organize themselves into groups around common interests, there will begin to be multiple networked publics within (or, really, facilitated by) your system.
Thus, when your users engage in Public Sharing through your application, this might mean that they are sharing objects with the whole world (as when someone posts content to an ordinary blog), or with the entire membership of your service, or with some other designated public they relate to through your product.
Any interface for One-Time Sharing or Ongoing Sharing should therefore provide choices to the user about who will be allowed to see the social objects she is sharing.
Alternatively, those choices can be baked into the rules of the system, so, for example, when choosing to share an object at Facebook, one choice is to add it to your profile.
By Andrew Hinton, Information Architect at The Understanding Group and author of Understanding Context, an O’Reilly book
There was a time when we could be fairly certain where we were at any given moment. Just looking at one’s surroundings would let us know if we were in a public park or a quiet library, a dance hall or a funeral parlor. And our actions and conversations could easily adapt to these contexts: in a library, we’d know not to yell “heads up” and toss a football, and we’d know to avoid doing the hustle during someone’s eulogy.
But as more and more of our lives are lived via the Web, and the contexts we inhabit are increasingly made of digits rather than atoms, our long-held assumptions about reality are dissolving under our typing-and-texting fingertips.
A pre-Web example of this problem is something most people have experienced: accidentally emailing with Reply All rather than Reply. Most email applications make it brutally easy to click Reply All by accident. In the physical world in which we evolved, the difference between a private conversation and a public one required more physical effort and provided more sensory clues. But in an email application, there’s almost no difference: the buttons are usually identical and only a few pixels apart.
Reply All in email is a pretty straightforward problem—a binary choice for a single piece of data: one message goes either to one or multiple recipients, and the contexts are relatively transparent. But on many popular social network platforms, the problem becomes exponentially more complicated.
Because of its history, Facebook is an especially good example. Facebook started as a social Web application with a built-in context: undergraduates at Harvard. Soon it expanded to other colleges and universities, but its contextual architecture continued to be based on school affiliation. The power of designing for a shared real-world context allowed Facebook’s structure to assume a lot about its users: they would have a lot in common, including their ages, their college culture, and circles of friends.
Facebook’s context provided a safe haven for college students to express themselves with their peers in all their immature, formative glory; for the first time a generation of late-teens unwittingly documented their transition to adulthood in a published format. But it was OK, because anybody on Facebook with them was there only because they were already there at their college, at that time.
But then, in 2006 when Facebook opened its virtual doors to anyone 13 or over with an email address, everything changed. Graduates who were now starting their careers found their middle-aged coworkers asking to be friends on Facebook. I recall some of my younger office friends reeling at the thought that their cube-mates and managers might see their photos or read their embarrassing teenage rants out of context.
The Facebook example serves a discussion of context well because it’s probably the largest virtual place to have ever so suddenly unhinged itself from its physical place. Its inhabitants, who could previously afford an assumed mental model of “this Web place corresponds to the physical place where I spent my college years,” found themselves in a radically different place. A contextual shift that would have required massive physical effort in the physical world was accomplished with a few lines of code and the flip of a switch.
Not that there wasn’t warning. The folks who run Facebook had announced the change was coming. So why weren’t more people ready? In part because such a reality shift doesn’t have much precedent; few people were used to thinking about the implications of such a change. But also because the platform didn’t provide any tools for managing the context conversion.
This lack of tools for managing multiple contexts is behind some of the biggest complaints about social software platforms. For Facebook, it seems every few months there’s a new story about someone’s life being ruined because they misunderstood the its architecture of privacy; and just as often, there’s a new feature or revamp of the rules and controls for managing private context. On LinkedIn, users have often complained the platform doesn’t allow them to keep legitimate peer connections separate from others such as recruiters. In Google Plus, the search giant rolled an extensive contextual messages and tutorial information to try teaching users where the walls and doors existed in its complex sharing architecture, but since most people have more than one GMail account, it’s a challenge to manage which address should receive a calendar invite versus which should be on social mailing lists, for example.
Not all platforms have made these mistakes. The Flickr photo site has long had a simply nested architecture of Public›Friends›Family›Private—a structure so clear, it’s hard for users to make mistakes. LiveJournal, a pioneering social platform, has provided robust permissions controls to its users for years, allowing creation of many different user-and-group combinations. But Flickr has recently made their controls harder to locate; and in LiveJournal (for those who still use the venerable space) the options are so flexible, it’s not hard for users to create more complexity than they can easily keep track of.
Some mobile-first social platforms, such as Path or SnapChat, the idea has been to constrain the structural possibilities to make these spaces more manageable by nature. But the limitations they’ve built in have become more complex as these platforms have evolved—the market pressure to keep adding features eventually breaks the fundamental simplicity.
This is a general challenge among all platforms that have to keep changing in order to stay interesting to the marketplace: while many have been working more at providing context management tools, the structures keep changing, which makes it hard to establish structural understanding. The more ambitious a platform is, the more complexity it demands that is inhabitants comprehend. Try figuring out all the ways that the Google ecosystem uses the word group (including circles and communities in Google Plus)—it’s instructive for grasping just how daunting the challenge is to stitch so many variant structural rulesets together into a rational, coherent understanding of place.
In the rush to allow everyone to do everything online, designers often forget that some of the limitations of physical life are actually helpful, comforting, and even necessary. We’re a social species, but we’re also a nesting species, given to having our little nook in the tribal cave. Maybe we should take a step back and think of these patterns not unlike their originator, Mr. Alexander, did—how have people lived and interacted successfully over many generations? What can we learn from the best of those structures, even in the structureless clouds of cyberspace? Ideally, the result would be the best of both worlds: architectures that fit our ingrained assumptions about the world, while giving us the magical ability to link across divides that were impossible to cross before.
User wants to share an object—pointer, media, or application—with one or more people. The application wants to be involved in the sharing in order to learn who is sharing what with whom and how often.
Use this pattern when displaying content, resources, or applications in your product or on your site.
Provide the means for people to spontaneously share content or objects they find by sending them to a friend or posting them to a shared, personal, or public space. Provide a consistent Share This widget on each screen or associate one with each granular object (pointers, media, applications).
When the user invokes the sharing link, provide—in a pop-up or overlay if possible—the minimal interface needed to facilitate rapid posting. Optionally include a Send This invitation to explicitly choose recipients to be notified of the posting.
Although the initial gesture of sharing is consistent, there are actually multiple architectures of sharing that you can make available to the user, most notably:
Uploading to the cloud
Providing a one-time Public Sharing option in a ubiquitous Share This widget can provide your users with a convenient and familiar method for sharing more content and objects and applications with one another. If they opt to execute their public sharing through your widget, you can learn from the behavioral patterns and optimize your interfaces and offerings.
One-Way Following (aka, asynchronous following)
AS SEEN ON
The New York Times
Live Real-Time Sharing
We continue see various facets of sharing mixed and matched, with a recent innovation being real-time video sharing. First Vine made it easy to insert a tiny clip into a tweet, and then more recently Meerkat and then Periscope showed up to make live videocasts easy to post and share (and somehow starting to favor portrait layout for video much to the dismay of purists everywhere!), as seen in this little excursion in Figure 8-12 from Twitter through a live Periscope broadcast to some recently archived clips.
In the infectiously snowballing of Tumblr reposts or the incorporation of retweeting into the basic vocabulary of Twitter (see Figure 8-13), we see that one of the most powerful forms of sharing is easy reposting of content that you like, in the same context where it first appeared (but in your own timeline or collection within that context).
Use this pattern as part of the framework for initial posts of content in your product so that viewers of the initial post can easily repost content they like to their own spaces.
Provide a Repost button, often in the style of a recycling button, close to the top and bottom of each granular story or piece of content (Figure 8-14).
As with phatic communication (pokes) and lightweight responses (likes and emoji), reposting is a minimal-effort method of participating for people that lacks the burden of the creation of the original content. Frictionless resharing of content can potentially drive huge audiences to breakout-hit material.
AS SEEN ON
Social bookmarking is a way for a community of users to collectively organize links to resources in a community-managed list. Social bookmarking uses keywords and metadata to organize these resources instead of utilizing a conventional hierarchical folder organization. Retrieval of this information from such systems is based on keyword search.
Social bookmarking is thus a form of One-Time Sharing for gathering pointers, generally in the form of title, link, description (the same canonical form used for early blogging and RSS).
Social bookmarking thrives thanks to the convenience of a bookmarklet, which moves the action of bookmarking socially into the same part of the interface (the browser chrome) where old-school bookmarking was always done, as illustrated in Figure 8-15).
Whether invoked via a bookmarklet or Share This widget, the social bookmarking interface can guide the person posting the pointer toward capturing and reviewing the title and description metadata for the bookmark.
Uploading to the Cloud
Photos, files, videos, documents, and many other kinds of social objects are uploaded, posted to, and hosted by social applications in the cloud. Without getting into the technology of grid computing or service level, uptime, redundancy, security, and backups, we’ll just talk about the cloud in a more intuitive sense, as the place out there where we’re increasingly leaving our email inboxes, our photographs, our financial information, and more.
Whereas social bookmarking deals with sharing pointers to objects, uploading to the cloud means sharing the objects themselves, by contributing digital copies to the product’s repository. The terminology for this from the user point of view might be share, post, add, upload, or even bookmark or send. Flickr talks about uploading photos and, now, videos. Facebook has an Add Photos button and a Photos tab with a button labeled + Create a New Photo Album.
Uploaders typically hook into the user’s system interface for browsing and selecting files (as used by an ordinary Open dialog box) when presented in a browser or application interface. They can also be stand-alone client applications, which you can develop or which you might encourage third-party developers to create by publishing and facilitating the use of your APIs.
Users like to be able to collect and display media objects such as videos, images, and even slideshows, as well as badges and applications on their profiles, blogs, and activity streams, as demonstrated in Figure 8-16.
Use this pattern when you want to give the user a way to display media or other objects that can be distributed freely.
Generate an embed code. An embed code is a snippet of markup that a user can copy and paste directly into a blog entry template, profile screen, or other social space for sharing that the user controls, as shown in Figure 8-17.
You may need to supply unique variations on the code to support variant hosting environments or to make the process simpler. SlideShare, for example, offers a generic embed code for most situations and a different code for embedding slideshows in WordPress.
Consider giving your users the option to customize the size, color palette, and presentation of the embedded object. Both SlideShare and YouTube, for example, enable the user to opt out of the display of related objects—slideshows and videos, respectively.
When possible, gather statistics about the number of times an object has been embedded, where, and how often it’s been viewed or accessed through embeds (see Figure 8-18).
Users like to share and display content. The easier you make it for them to do so, the more likely they will. Embedding also has strong potential for organic spread, because it facilitates rapid duplication and redistribution. It is widely thought that YouTube obtained much of its early phenomenal growth from the fact that its videos could be embedded easily on MySpace pages (what the users back then called “my MySpace”).
AS SEEN ON
Passive sharing can also be described as ongoing sharing. It refers to any process through which participants may initially opt in to enable their activities to be tracked and posted as updates to Activity Streams.
Whenever I log in to Flickr or Vimeo or SlideShare, one of the things I see right away are recent uploads from my contacts, which you can see in Figure 8-19.
Different from directly sharing content with individuals or even actively sharing it with different-sized publics, ongoing sharing is a less conscious but more pervasive form of sharing, discussed at length in “Managing Incoming Updates.”
It’s a good idea to occasionally remind people that they’re sharing information passively in an ongoing manner, to protect them from the inadvertent indiscretions that can follow from forgetting who’s watching.
Buy Designing Social Interfaces: Principles, Patterns, and Practices for Improving the User Experience online from O’Reilly.
1. Kellan Elliott-McCrea’s “Casual Privacy” talk at Web 2.0 Expo SF 2008.
2. Kellan Elliott-McCrea’s “Casual Privacy” slides from Ignite Web 2.0 Expo.
3. Tip a Friend, see negative comments and suggestions that it’s an anti-pattern.
At 7 Cups of Tea, Christian leads product and user experience teams in delivering amazing, cross-channel experiences. He is also a mentor at Code for America and co-chairs the monthly BayCHI program. Previously, he was Director of Product at CloudOn, Director of Messaging Products for AOL, Curator of the Yahoo! Design Pattern Library, and a Director of the Information Architecture Institute. Christian is the author of the bestselling books The Internet for Busy People and The Power of Many and co-author of Designing Social Interfaces, now in its Second Edition. He has spoken at BarCamp, BayCHI, South by Southwest, the IA Summit, Ignite, Web 2.0 Expo, PLoP, IDEA, Interaction, WebVisions, the Web App Masters Tour, the Italian IA Summit, UX Lisbon, UX Israel Live; Web Directions South, in Sydney, and East, in Tokyo; @media, in London; and remotely at MobileCamp Chicago. Read More
Erin has over 20 years of experience leading design teams and developing Web and desktop applications, social experiences, and system-wide solutions. Prior to Tangible, she was at Yahoo! where she led the Platform User Experience Design team and was responsible for building the Yahoo! Design Pattern Library, as well as providing design expertise to the popular YUI (Yahoo! User Interface Library). She was the founding Editor-in-Chief of Boxes and Arrows, a role in which she served for five years. Erin is the co-author of Designing Social Interfaces, the author of articles on design management and the history of interaction design, and was a founding member of the IA Institute. Read More