March 2009

I've heard it a number of times: "Our organization wants our own Facebook." After you've gone through the strategic planning, and made sure that, indeed, building your own social network is exactly what you want to do (instead of building on networks already there, which, I think is what should be done 80% of the time), how do you go about doing it? I've been working on this for a while, and here's what I've found.

You have several options:

• Ning. This is, in fact, the option I'd almost never choose, unless this is a very short-term, or throw-away, project. Ning is a Web 2.0 startup in search of a sustainable business plan, and who knows when it will fold, or what will happen to it. The community and data is not your own, and there is some evidence that they might be using that data in social networks on their platform in ways that they shouldn't be.
• Elgg. Elgg is an open source social networking platform that had a previous life as an e-learning platform. It's meant for developers - although it does provide an out-of-the-box social network, it takes a fair bit of work to get it looking and working like you'd want it to. And, it's a young project, so that adding custom functionality is going to be harder than with established projects like Drupal or Joomla. I've installed and played with it a fair bit, and there is a lot to like about it, but the lack of a solid developer ecosystem, and the dearth of add-on modules and themes makes it a hard choice.
  
• Drupal. Drupal has a module called Organic Groups, which is incredbily popular, and there are lots of other modules that add functionality to it. Building a social network on Drupal will take more work, but since you are starting from a really solid grounding of Drupal, and can extend this site in all sorts of ways, this might be the best option. It's the option I've chosen for two ongoing projects that are creating social networks.
  
• Joomla. Joomla has a number of components that provide social networking functionality, including Community Builder and Group Jive. I haven't had a chance to play with these yet, but they are worth a look, and there are some great Joomla web shops out there that can help with this.
  
• Proprietary platforms. There are quite a number of proprietary platforms that can also provide a social network site for your organization. In general, these are going to be fairly pricey, and not as customizable as the open source platforms are.
  

Final work: look before you jump into creating a new social networking site. Careful planning and investment are necessary for success.

I am a strong advocate for spending the time directly with software vendor sales and technical support to explore software tools. Most software offers many more features than you expect, and have unique approaches to solving data management challenges. Often its largely on the basis of the demonstration that many of us will make a final selection of software for our needs.

For the last 4 months, I have managed to either sit through demonstrations or demonstrate myself approximately 30 software packages for various nonprofit technology projects, including a number of donor database systems. Some were quite informative while others did not go so well. Here are a few of my discoveries on what makes for a great software demonstration that we as demonstration facilitators and participants can incorporate:

• Educate the vendor: Most software tools are built to solve a wide array of business problems, even when they are narrowly focused to, say, donor management tools. Vendors lead much better demonstrations when they know their audience goals and requirements so they can focus on what is most important.
• Educate the audience: Many participants in demonstrations do not know what to expect, and how to participate. Provide information up front about the software and the areas to cover, and invite feedback and questions before the event as well as throughout the demonstration to make sure the audience understands and is engaged.
  
• Develop a script: Its very easy for both the facilitator and audience to go off track on an aspect of the system, and lose time to see more important areas. Before engaging a demonstration, prepare a script with areas to cover and questions to resolve, and keep track of time to make sure you cover those areas. Share this will all folks reviewing the tool so everyone is on the same page.
• Phrase questions as "scenarios": Instead of asking, "how do I merge the last name of my donor to a letter", ask "how do I personalize my messages to my donors to build stronger relationships?". This is a broader question that includes the reason why you want to send personalized messages. The vendor is then invited to show the process of developing and personalizing letters, emails and other tools besides strictly mail merge, and will likely answer several additional questions in the process.
• Get your technology ready! Software demonstrations typically require computers with internet access, ability to run web demonstration software, a working phone line, and the software to demonstrate. Most vendors will set up a system for running a web demonstration - definitely test it prior to the demo to make sure it works ok. Some demonstrations used software that was not well prepared for answering my questions, or that did not work at all initially - this is definitely not a great way to start!
• Debrief immediately: Software demonstrations generally will not answer every question. Be sure to debrief soon after the demonstration to identify learnings, pros, cons and questions for further exploration. If engaging demonstrations of more than one software system, be sure to debrief each before demonstrating the next, as it gets very confusing to remember what each system offered otherwise.

In general, its best to approach the demonstration in the spirit of partnership, rather than as a competitive venture. Share more information rather than less to get the most out of the exchange, and to manage expectations properly.

Google Reader gets a good mention in my RSS article, Using RSS Tools to Feed your Information Needs, but deserves an even deeper dive. This is a follow-up to that article, along with my recent posts on Integrating content with websites, and Managing Content with Pipes. We've established that an RSS Reader helps you manage internet information far more efficiently than a web browser can; and we've talked in the last few posts about publishing feeds to your web site. This post focuses on using tools like Google Reader to share research .

Out of the box, GReader (as it's affectionately known) is a powerful, web-based reader that lets you subscribe, mark and share items in two significant ways. Shared Items are items that get published to a public page that you can point your friends and co-workers to. Further, this page can be subscribed to via RSS as well, so it can be republished to your web site, or integrated into a Facebook feed. Using (fake) bill 221b as an example, if you monitor for and selectively share articles related to the bill, you can easily point co-wokers and constituents to your shared page, and or republish those items in places where your audience will see them.

Shared Items are also made available to other GReader users who choose to share with you. This offers a greater level of convenience for teams working with shared research; it can also afford a level of confidentiality if you don't want to publicize a public page. Not only can you share the items you find; you can also tag them, much like you would with Delicious or Flickr, and add a note, if you have thoughts or context-setting notes to share. A function recently added GReader takes this even further - shared items can be commented on, much as a blog post can.

The last bit to add to this arsenal is a very powerful, but not terribly obvious GReader feature. The Note in GReader bookmarklet (which you can drag to your web browser's quick links or bookmarks toolbar from the GReader "Notes" page) lets you share, with comments and tags, pages that you find on the web as GReader shared items. So if you run across something that isn't in your feeds (and there's plenty of web content that can't be subscribed to), this lets you add it to your shared items.

What I've found is that, as much as I admire social bookmarking sites like Delicious, they become a lot less useful when I can store all of the pages that I find via RSS or browsing, with tags and an option to share them, in the same convenient place.

It's important to note that, as powerful as all of this is, it still lacks some functionality that similar tools have. One great advantage of using Delicious as a link-sharing tool is that you can share links specific to any tag (or set of tags). Google Reader doesn't offer multiple shared pages based on filtering criteria. And while you can add notes to your feed (without adding links), it's not as flexible a repository as a tool like Evernote, which lets you save web pages, ODFs and all sorts of documents to a single web-based folder.

Also, Google Reader isn't the only game in town. The Newsgator family of RSS readers offer similar sharing functions; some of which overcome the limitations above, as do other readers out there (please share your favorite in the comments).

What it boils down to, though, is that we now have powerful, integrated options for online research, as individuals, as teams, and as information agents for our constituents. The convenience of publishing as you discover is a significant advancement over earlier schemes, which usually involved either sending a lot of easily-lost links by email, or submitting your finds to a webmaster, who would then add them to a page on your site. This is a publish as you find approach that incorporates sharing and communication into the research process.

Next week, I'll finish up the "More RSS Tools" series with a post about OPML, the way that you make your collection of feeds portable.

I'm continuing with follow-up topics from my RSS article, Using RSS Tools to Feed your Information Needs. Last week, I discussed integrating content with websites, and this week I'm going to dive into one of the more advanced ways to work with RSS content. This gets a little geeky, but it really shows off some of the sophistication of this technology.

The article provides numerous examples of RSS sources, but all in the form of web sites, blogs and web services that offer you one or more streams of information. If you want to narrow your view beyond the feeds available on a site, say, because you are only interested in Idealware posts about CRM tools or the ones written by Steve Backman, then you need a tool that will refine your search. Alternatively, you might want to put a section containing news stories relevant to a particular issue on your site, but want some control over the sources, as well as the subject matter. For this amount of control over the content you retrieve, you want to use something like Yahoo! Pipes.

Pipes is an RSS mashup editor. It's a tool that looks a bit like Microsoft's Visio, where you drag boxes onto a grid and draw relationships between them. But it's not a layout or flowcharting tool; instead, it's a visual mapping and filtering tool that lets you identify sources and then apply rules to those sources before merging them into an aggregated feed. To break that down, let's say that your goal is to either monitor talk about a bill, or, maybe, to publish a section on your web site titled "What they're saying about bill 221b" (I made that bill up). You have identified eight blogs that have good posts on the subject, and these are blogs that you trust to properly represent the issues and not, in any way, malign or confuse your efforts.

In Pipes, you can select all eight as sources, and then set up a filter to block any posts that don't reference "221b". The resulting RSS feed -- which you can then subscribe to our republish -- will isolate the posts that are relevant to the bill from your selected sources.

For example, here's that pipe that will allow you to skip Michelle, Heather, Paul, Laura, Eric and my posts and just see Steve's:



Another, more advanced example: You have an organizational Twitter feed that you want to republish to your site But you only want to publish your posts, not your individual replies. In Twitter, a reply is always identifiable by the very first character, which will be an "@" sign. Twitter RSS items arrive in the format "yourtwitterid: tweet", so any reply will start with "yourtwitterid: @". Setting up a Yahoo Pipe filter to block any result with ": @" in the text will isolate your posts from the replies. You can add a "Regex" (e.g. Search/Replace) command to replace "yourtwittername:" with nothing in order to publish just the tweet. The pipe will look like this:



If you play with Pipes (Yahoo! ID required, otherwise free), I highly recommend starting with an example like mine or this one by Gina Trapani to get the feel of it. Save your pipe, and you can subscribe to it -- it updates automatically, and you don't have to make it public for it to work.

Google has it's competing Google Mashups tool in private beta, and similar tools are popping up all over the web. I talk a lot about how RSS is the technology that allows us to manage the information on the web. Pipes let us refine it. It's great stuff.

Look for more RSS talk on OPML files and Google Reader in my upcoming posts.