Recently I’ve given presentations on Social Networking in Drupal. In my mind, status updates are a central tenet of any successful social networking platform, which is why I built the Facebook-style Statuses module for Drupal. There’s more to social networking than status updates though. In this post I’m going to go through some of the standard features of social networks to identify some of the places I hope Drupal will grow.

The features I cover here are mostly ones which are not quite perfected yet in Drupal. Many things I didn’t cover, like forums, multi-user blogs, comprehensive user profiles, groups, wikis, events, and some fun modules that add game mechanics (User Badges, Userpoints) are already in great shape. And I haven’t identified anything that is entirely missing or impossible to do in Drupal.

So don’t be fooled; there are some things that aren’t quite complete yet, but in my mind Drupal is far and away the best platform on which to build a customized social network.

Why Social Networking is Important

2 of 3 Twitter followers and 1 of 2 Facebook fans are more likely to buy a product from a brand they follow. 80% of Twitter followers and 60% of Facebook fans are more likely to recommend a product they follow to friends. This is no fluke; people are influenced by their friends on social networks, and brands can leverage this to spread the word about their product. In fact, each Facebook fan or Twitter follower is worth an average of $136.38 per year to a company. When you consider that many companies (even small ones) have hundreds or thousands of fans, that number adds up quickly.

This graph is taken from a HubSpot study from February 2010. The orange bars represent social advertising – advertising designed to encourage others to generate links to companies’ websites. The orange bars represent advertising, in fact, that many would not recognize as advertising. Hubspot labels these methods “Inbound marketing” because they are designed to generate discussion that drives people to the company out of interest.

The blue bars represent traditional marketing, which Hubspot labels “Outbound.” This type of marketing consists of targeting “the audience” by sending them unsolicited messages promoting your company. You can tell from the graph that this is far less effective in generating new customer leads.

Inbound marketing convinces people to share the news about your company with their friends. Those friends are then getting tipped off about your company from a source that they trust, rather than getting one more “spam” email in their inbox. As a result, those friends convert into many more leads than traditional marketing can generate.

This graph (from another HubSpot study) astounds me every time I look at it. Companies that use Twitter regularly generate twice as many leads as companies that don’t. Wow. Now imagine how much more valuable that would be if that social networking activity that happens on Twitter happened on your site instead.

And social networking is not just valuable to business – it’s valuable to communities, too. People like to connect – both to build business relationships, to meet intellectually stimulating peers, and to build genuine friendships.

We tend to think of the world as having a few powerful influencers who convince everyone else to follow them. One goal of every company is to become an influencer in its field. However the reality based on research from Google is that hubs are actually focus points; influencers are themselves influenced by many sources, and they channel what they have learned to many other people. You should design your social features to work with this reality. Status updates and tweets are good examples of ways to do this. Where press releases and email marketing tends to be one-sided, social networking allows influencers to aggregate lots of information from sources they like, and then easily share it with their followers and friends.

But the bottom line is that social networking is not just something cool any more. It’s now something that users expect on every website. Web 2.0 is not the cool future; we are already there. The cool future is the Semantic web and HTML5. People are spending almost a quarter of their time on the internet on social networks already, and that number is rising by almost 70% per year. That is a chunk of time that could be spent on your website. 1 in 4 Facebook and Twitter users follow a brand in order to be part of a community. Those are your dedicated power users, your most valued customers who you want to foster. They are your evangelists. Help them help you.

Friends

The basic premise of most stand-alone social networks is the concept of user relationships. Drupal has a strong showing here, with two solid solutions: Flag Friend and User Relationships. I recently wrote another blog post comparing them, so I won’t go into that here, but suffice it to say that if you want users to be “friends” on your website, Drupal has great options.

As with many parts of Drupal though, both modules tend to be somewhat less effective when it comes to working together with other parts of Drupal. Both Flag Friend and User Relationships have Views integration, which (if you know what you’re doing) allows showing lists of content created by your friends. But these things are tricky, and occasionally you just can’t quite build what you want. More often though, you’ll realize that while you may be able to create listings of friends’ content, it’s harder to keep people from seeing other content if they go to that content’s URL directly. Both modules do provide a measure of access control, but there are so many contributed modules and settings to take into consideration that they couldn’t possibly cover every case. For most uses both modules do quite well; but for some sites that are serious about comprehensive access control, there is room for improvement.

Obviously, “friend” connections are a central part of any “social” website, but friends in name only often means very little. Content gains value when it is restricted to an inner circle, so making access control more comprehensive is a worthwhile goal.

Status Updates

I’ve written and presented extensively on why I think this feature is so important, and I back up my convictions with code. As the author of the Facebook-style Statuses module, I can say conclusively that the module is extremely stable and full of features. There are weak points though: Facebook-style Statuses Comments is an auxiliary module that allows commenting on status updates, and it doesn’t quite degrade gracefully for users without JavaScript. Facebook-style Micropublisher, a module that allows attaching links, images, and video to status updates, is fairly stable but still in development as part of the Google Summer of Code process. And currently, it’s not possible to have a “group wall,” although that’s in heavy development as well. There are tons of very strong points though, including integration with about 25 other modules. You can check out one of the demo sites to see how powerful this is.

Social Streams

Views is a very powerful module that allows listing content on your site, but one thing it cannot do is list different kinds of content together. For example, status updates from the Facebook-style Statuses module are not nodes, and cannot be listed in a node view with (for example) blog posts or forum topics. Luckily there is a way around this in the form of the Activity module.

The Activity module aggregates different kinds of activity and stores messages about users’ actions based on administrator-defined templates. This allows for the kind of “activity feed” seen on Facebook. However, Activity stores literal messages, not tokenized ones. What that means is that if an activity message contains a user’s profile picture and the user changes their picture, the change will not be reflected in any messages that have already been saved.

Also, I recommend the Activity 2.x branch, since it is much more powerful and has better support from other modules. However, there is no stable release for it, and it is still under very active development. There is also no upgrade path between development builds, so make sure you keep up with the changes if you opt for this branch.

Although Activity is by far the most heavily used module of its type, there are alternatives, the most popular being Heartbeat. Heartbeat is much less Drupal-y than Activity but it doesn’t have the restriction of historical saving that Activity does. On the other hand, the additional freedom comes at the price of performance. Activity is my preference.

Real-time Alerts

One of the awesome things about Facebook is the instant gratification – it lets you know right away when other users do things that affect you. Drupal has robust notification frameworks but until recently didn’t have great options for immediate notifications on your site itself. One option was growl-based solutions, which briefly overlaid messages over the site – but there was no way to go back and read those messages later if you missed them, and there never was a stable, supported version for Drupal 6. Now there’s an alternative: I wrote a module called Application Toolbar (or Appbar) which allows nearly real-time alerts in a bar at the bottom of the screen like Facebook used to have. You can also put blocks on the bar (a region is dynamically added to your site) so you can also add navigation or whatever else you want there. Appbar is still in development, but it’s stabilizing rapidly and should have a full point release in 1-2 months.

Applications

There are three kinds of applications we could talk about here. The first are third-party clients for a web service, like TweetDeck for Twitter. These clients can pull users’ activity and information using an external API and push back new content or edits. Drupal does this very well using the Services module, which provides an external (but secure) CRUD API for modules that integrate with it (including nodes and comments). The ability to have third-party applications entices developers and therefore grows your site’s user base, use cases, and relevance.

Another kind of application is a sort of widget that appears on the site itself, like Farmville for Facebook. As far as I know, there is no standard way of achieving the second kind of application in Drupal, although there are probably entirely separate platforms designed to help sites do this.

Embedding widgets from your site into other sites is another way to think of applications. Drupal can do this using the conveniently named Embed Widget module, although development on it has been sporadic. There’s also no point-release, although there is a release candidate.

Individual Privacy

As an open-source software guy, I’m no fan of walled gardens. But I do recognize that sometimes, some measure of privacy is necessary. (Of course I would argue that it’s just an illusion, but that’s another story.) While Drupal has very powerful and extremely granular site-level permissions control, it has limited ability to have individual user-controlled privacy settings. There are some modules that allow users to control access to profile fields (including CCK fields for Content Profiles), so personal information can be protected to an extent, although these modules don’t account for every use case. However, content access is a bigger problem. Lots of modules deal with sitewide content access, but very few deal with content access on the individual user level. Flag Friend and User Relationships both have content access submodules that attempt to restrict viewing nodes to users’ friends, but User Relationships’ implementation is controlled by administrators, and both modules apply only to nodes.

The current situation is good enough for many sites, but it’s certainly far less than ideal. The reason there’s no complete solution right now is that such a solution is very difficult to create.

Take my Facebook-style Statuses module for example. (It does pretty much what you would expect – it gives each user a “wall” or stream where they can post status updates or write messages to other users.) As the maintainer, I could add a “visibility of status updates” setting to users’ profiles with the options “everyone,” “only me,” and “friends.” Great. But first of all, there are two main “friend” modules, Flag Friend and User Relationships. Should I support one, or just both? Which branch should I support? User Relationships allows different two-way relationships – should I have a different setting for each one or should I group them together? And both modules allow one-way relationships – should fans or followers get an opportunity as well? The answers to these questions will vary between sites. It’s hard to figure out a way to let administrators choose the answers, and even harder to implement their choices. That’s because even if we solve those problems and a user chooses to only show status updates to people with whom they have a two-way “family” relationship, we still have to change all the views that list status updates to reflect the new setting. Getting views to reflect individual user settings is difficult in the first place; getting views to reflect individual user settings for multiple different modules which may or may not exist on a site is like convincing stampeding elephants to bake you baklava. The result might be tasty, but grandma wouldn’t approve of the mess in the kitchen.

Long story short, granular individual privacy options sort of exist in Drupal, but they are by no means unified, and unifying them is not easy. Even if someone were somehow to write a useful API to do so, it would still be difficult to convince other modules to adopt that API. I don’t know of any efforts to create any sort of framework like this.

As a result, the current approach is likely to continue – that is, to write modules that solve a specific use case. Taking the example above, someone could write a module that would add that “visibility of status updates” setting to users’ profiles using the single two-way relationship provided by Flag Friend 1.x, and would then use hook_views_default_views_alter() to change the default Facebook-style Statuses views to respect the user’s access control choice using a custom filter. (That still leaves administrators to make sure they respect the access control choice in customized views though – and there’s also the problem of only allowing friends to write messages to each other on their profiles. Facebook-style Statuses has ways to support that, but the same problems as before come up again.) I’m something of a perfectionist – I like fully abstracted, generic solutions where possible – so this specificity doesn’t satisfy me. But it’s a start.

Comprehensive Image Galleries

I hold the Facebook model of image galleries as the gold standard for a social networking site. Users should be able to create images inside or outside of galleries; all galleries should be personal to the user who created them rather than sitewide; and it should be possible to upload many images at once into a gallery. Various parts of this are quite possible in Drupal 6, but there is no complete solution of which I’m aware. There are tons of implementations of image galleries, but most of them are aimed at portfolio type sites. And there are a few multi-upload modules, but most of them involve flash which is complicated to set up and not supported on many mobile devices. Most of them also don’t allow creating separate nodes for each uploaded image, which creates a problem for adding descriptions and adding individual images outside of galleries. Again, the reason is that doing this well is very difficult.

The bottom line is that while Facebook-style image galleries are possible in Drupal 6, it’s not simple. I’m hopeful that this situation will dramatically improve in Drupal 7, which has much better native media handling (especially via the Media module).

Conclusion

The term “social network” means different things to different people, and for the vast majority of cases Drupal covers all needs very well. There are clearly some areas in which we could improve though, and I hope that there will be more focus on these issues moving forward. As you’ve probably noticed, most of those areas are not related to specific modules, but rather to the imperfect ways in which modules integrate.

My ultimate goal as a Drupal developer is to build a social network distribution. I want it to be possible to install Drupal on your site and out of the box have it working very similarly to Facebook. I want this not because I think it would be great if there were thousands of Facebook clones floating around the web, but because I think the social model is the best one for building any sort of community. It’s what people know and love (or for some, love to hate). It’s also a great way to grow a business.

Yes, I know about Drupal Commons and no, I don’t consider it a competitor. I’m excited about it. I think it will further the goal of social networking in Drupal. Drupal Commons is aimed at the enterprise, while I’m aiming more at organic communities that exist out of common interest rather than fandom. And Drupal Commons doesn’t really need many of the things I discussed in this article (or at least they chose to believe that real developers ship, and they’ll get to the rest later).

So I have a long-term interest in seeing all of these things happen, and if someone else doesn’t solve them first, I hopefully will eventually. They’re not easy problems, but with Drupal, anything is possible.