Apologies to any names I’ve misspelled, product names I’ve left out, etc.

Interesting stats:

• 21 web services analyzed
• 10 (48%) are using OAuth (including YouTube)
• 5 (24%) are using AuthSub (also including YouTube)
• Dopplr is the only non-Google property using AuthSub
• Tumblr is the only property using plaintext passwords, although Posterous is using HTTP Basic, which is basically plaintext

Looks like OAuth is gaining some real traction, and in fact if Google switched over to using it, it’d have a real hold on the authentication space. That would probably be a good thing. Next up in my adventure will be seeing how truly conformant/compatible all these OAuth implementations are, and how portable my code be able to be in accessing them all.

If you’d like to add any others that you know about, please throw them in the comments and I’ll add them to the table above so everyone can find them.

In the “old days” (or in a lot of big corporates today), those support cases would have been handled behind a corporate “veil of secrecy”, tucked in a back end system somewhere, responded to by anonymous “Customer Service Representatives” via a generic email account like “support@intensedebate.com”. While we’re also making use of a generic email address, the similarities between our approach and that of big corporates ends there. End to end, the differences are pretty stark.

Plugin Release

Previously, companies may have tried to encode their plugins, or released them as some sort of binary so that they could control access to them and avoid people modifying them. When we released the 2.1 version of our plugin, we “checked it in” to a public-readable Subversion repository which then publishes to the WordPress Plugin Directory. That code (and all other code in the Plugin Directory) is GPL licensed and available for re-use/hacking/modification. People are welcome to read the code and see what we’re doing, point out where we could do things better, and ideally improve upon it themselves.

After we’ve uploaded the code, people will start getting notifications in their WordPress admin panel that there’s a new version available. To help explain what’s going on, we published a blog post announcing the new version, the new features etc.

Comment Support

Not that it’s a recommended channel for receiving support, but this is where we start really differing. People have posted a number of issues and questions about the plugin right there on the announcement post. We could moderate and remove those comments (or not allow them in the first place); instead, we work with our customers and try to address their problems right there an then. Michael and I have been bouncing around on that post answering questions and finding out more information from people so that we could fix some problems and get to 2.1.1. With email notifications coming in every time someone commented on that post, we’re able to quickly respond to people and help work out any issues they’re having.

Seeking Satisfaction

If people aren’t commenting on that post directly, they’re often over at the Intense Debate Get Satisfaction forum, a community-powered support system where a number of people are contributing. Again, this is a very public way of supporting users, and puts us out there in the limelight, warts n’ all. We answer what we can, assure people that we’re still working on things and that we’re making progress (which we are, a lot of it) and that we’ll get back to them as soon as there’s something to report. When there are updates, or when we need more information for troubleshooting, we post another message and get a stack of responses from eager users, hoping to have their problems solved. This is very real and very connected, and I truly believe that being open and transparent about problems that people are having and the way that we’re working with them helps not just that user, but others who may have similar problems.

Late-night Tweeting

For real-time feedback and almost-instant-messaging-immediacy, there’s Twitter. I know, with Oprah getting in on it now Twitter will probably implode soon, but in the meantime, I’ve found myself providing support direct to people via Twitter as well. One user wanted to use IntenseDebate, but found the comment importer wasn’t working. I replied that we were about to release a fix, and that user was then able to get up and running. This all happened, asynchronously, within about 4 hours of his first tweet.

In Your Facebook

Then for one that I really wasn’t expecting, someone contacted me through Facebook to try to sort out a problem. A user spotted me providing support via Get Satisfaction and other methods, and tracked me down on Facebook. In this case, it was someone that we were already working on a fix for, but it demonstrates just another way that people have been able to get in touch with us.

Better for Customers, Better for Us?

I guess the big question (or 2 questions really) this all poses is: Is this new way of providing support better for our customers? Is it better for us (as the company providing support)? Could it be better for everyone still?

The biggest problem I have (as someone providing support) is just trying to keep track of all these different “vectors”. I’ve identified 4 different support vectors above, and that’s not even including our normal support email/form, official Facebook group or VIP support channels. That makes at least 7 different vectors through which we might be providing support. It can get messy trying to keep up to date with them all and ensuring that you’ve replied to people where they’ve contacted you and in a timely fashion. Perhaps there’s an argument for traditional, centralized systems after all

1. It’s Open: I’m a fan of the idea of “open” (as in open source, portable data, etc etc). Facebook is not. Twitter is. Putting my status updates through Twitter means that I can do fun things like load them into my sidebar (on the right of my blog) easily (via an RSS feed). If I updated in Facebook, those updates become useless because I can’t get them back out.
2. Client Apps: I don’t want to have to go to the Facebook site all the time to update my status. I can run a Twitter client (currently DestroyTwitter or TweetDeck) on my computer and update my status in a couple of key-presses. I also have options (there’s that “open” thing coming in handy again) as far as clients go, so I can pick and choose something that I like.
3. Be Part of Something Bigger: Facebook is great and all, but it’s owned and controlled by Facebook. It’s a world unto itself with an established set of protocols and expectations. Twitter is something new. It’s a new type of “web” as we know it. It’s “live” in a way that not much else is yet. I’d like to be a part of that, so that I can see what’s really going on, which brings me to…
4. Search: Twitter’s search system is a whole new ball-game. It allows you to see what’s going on and what people are thinking/doing/asking now.
5. Community: Twitter’s omni-directional “follow” system means that the community/network is fundamentally to Facebook’s bi-directional system. I don’t “allow” people to follow me. If they want to, they do. If they don’t, they don’t. I can reach a whole different group of people on Twitter that I am not connected to on Facebook.
6. Laziness: Last but not least, I have a Facebook app installed that loads my Twitter status into FB anyway, saving me the hassle of updating both

So why do you use Twitter (or Facebook Status)? Chime in on the comments and I’ll add any good ones to the list!

This blog (and literally millions of others) are powered by WordPress. I write my content here and then potentially tweet about it, my feed gets published to FriendFeed, etc. I consider my blog the “central hub” of my online content production. My content gets distributed out into the wider web and ends up all over the place. Conversations occur at many of those locations, so why not aggregate those conversations back to my blog? As far as I’m concerned my blog is and should be the canonical version of my content. This system could leverage the various APIs and feeds provided by other systems, pulling back conversation related to one of my posts and storing it locally using WordPress’s comment system. Upon presentation on my blog, I would then include an icon or text message against each comment declaring where it happened (“on Twitter”, “via FriendFeed”, etc).

Off the top of my head, I’d suggest that part of this system would require you to automatically generate a shortened version of the permalink for your post on as many of the TinyURL type services as possible, then store those URLs against each post. These become your keys for identifying comments/conversations relating to that post. Now you go out to each service (where you don’t already have some sort of programmatic relationship that’s more reliable/simple) and locate all conversations mentioning any of your URLs. Those conversations would then be aggregated back to your blog, and published on that specific post as a comment. With some voodoo, you could even theoretically maintain threading if it was supported on the other systems. This part might require the addition of a wp_commentmeta table though (which has been discussed repeatedly in the WordPress developer community).

I took a quick look around at some of the more popular “conversation-generating” services/platforms to see how possible this would be. This means I’m looking for an API or a feed of some sort which can be access and parsed to locate relevant conversations. Here’s what I came up with:

• Twitter: Search API should allow you to easily locate all tweets containing a URL. You could also quite easily add the ability to reply to a user on your blog and simultaneously post your reply as an @reply on Twitter (the first 140 characters anyway). TweetSuite adds some of this functionality to WordPress already.
• Facebook: Walled Garden! Their APIs do not currently allow you to pull comments back from their system. There has been a lot of talk about Facebook opening up more though, so hopefully this will change soon.
• FriendFeed: Their API is extensive, and seems to allow everything needed. There’s even a WordPress plugin that already does something similar.

There’s even the potential on some of these platforms to reply to the comments left (for example) on FriendFeed, via my blog, but cross-posting that reply back over to FriendFeed to keep the conversation alive.

What do you think about this idea? Which other services would you like to be able to aggregate conversations back from? Drop me some ideas in the comments below.

2008-12-26: Fixed a bug that caused the JS to overwrite details on a non-FB Connect comment as well. Also changed the fake email address that’s stored to include the user’s FB user ID.

In case you’ve been living under a no-technology-news rock for the last few weeks, you’ll know that Facebook Connect was released recently. I had been seeing/hearing a lot about it, including this video at Mashable, showing how to implement FB Connect in 8 minutes. So when my friend Morgan from BlownMortgage asked me if I’d be able to help him implement it on his new resume-editing site ResumeDonkey.com, I figured “how hard could it be” and said yes. Although it definitely didn’t take 8 minutes, I got it done, so I thought I’d post some details on the specific approach I used for ResumeDonkey.com.

Before I rolled my own solution, I took a good look at a few of the existing WordPress options including:

• The WP-FBConnect plugin, made by Facebook,
• Another WordPress plugin made by Sociable, and
• The Community Facebook Connect Plugin, by Jesse Stay

None of these worked quite how Morgan and I had discussed, so I decided to make my own, lightweight solution. Before editing any actual theme files, there’s some prep-work to be done, so:

1. Log into Facebook and then go and add the Facebook Developers Application
2. Click the big button at the top right to Set Up a New Application
3. Enter a name and agree to the terms (you read them all, right?)
4. On the next page, enter the base URL of your website in the “Callback URL” field. MAKE SURE you use the correct preference for your website as far as www. or no www. is concerned, and preferably enforce that on your website using a plugin or something. If you enter http://www.domain.com here, and someone accesses your site as http://domain.com, then your FB Connect integration will break and throw a warning about being on the wrong URL.
5. You can also set some sexy icons/logos to appear in the News Feed of people who comment on your blog, but I’ll let you handle that.
6. Get a copy of the “API Key” at the top of this page, you’ll need that later.

OK, now we need to register a “template bundle”, which will be used to post updates to the News Feed of people who comment on your blog.

1. Go to the list of your Facebook Apps and click on the app we just created on the left
2. Click “Create Feed Template” in the list of links on the right
3. Make sure your correct App is selected in the box, then click Next
4. In the “One Line Template” box, paste this exact text

   {*actor*} commented on the {*blog*} post {*post*}.

5. In the “Sample Template Data” box, paste this (make sure quote marks are still  quotes and not fancy curly-quotes)

   {"blog":"<a href='http://test.domain.com'>My Blog Name</a>", "post":"<a href='http://test.domain.com/post-url/'>Test Post Title</a>"}

6. Click Update Preview and make sure that you’re happy with the News Feed format (if not, change the One Line Template string)
7. Click Next
8. Now click Skip (and ignore/Okay any errors) until you get to the final page and then click “Register Template Bundle”
9. It will give you a Template Bundle ID, and you’ll want to get a copy of that, because we’ll need it later as well.

OK. Now you’ve got a registered and configured (roughly) App on Facebook, time to get dirty on your own blog. Create a file in the root of your domain and call it “xd_receiver.htm”, then copy the following code into it:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Cross-Domain Receiver Page</title>
</head>
<body>
<script src="http://static.ak.facebook.com/js/api_lib/v0.4/XdCommReceiver.js" type="text/javascript"></script>
</body>
</html>

Add the “fb” XML namespace to the header.php file in your theme. Mine ended up looking like this (in PHP):

<html xmlns="http://www.w3.org/1999/xhtml" xmlns:fb="http://www.facebook.com/2008/fbml" <?php language_attributes(); ?>>

And also drop in a reference to jQuery if you don’t already use it in your theme. It’s bundled with WordPress so you can reference it like this (anywhere before the call to “wp_head()” in your header.php):

<?php wp_enqueue_script('jquery'); ?>

Then you’ll want to edit comments.php (assuming you’re using a relatively normal theme), and make some changes to add the FB Connect button. Find the part where a user would normally enter their name/email/URL and change it to look something like this:

<div id="comment-user-details">
<fb:login-button length="long" onlogin="update_user_details();"></fb:login-button>

<p style="clear:left;"><strong>Or enter your details below:</strong></p>

<p><label for="name">Name <?php if ($req) echo "(required)"; ?></label><br />
<input type="text" name="author" id="name" value="<?php echo $comment_author; ?>" size="50" tabindex="1" /></p>

<p><label for="email">Email Address <?php if ($req) echo "(required)"; ?></label><br />
<input type="text" name="email" id="email" value="<?php echo $comment_author_email; ?>" size="50" tabindex="2" /></p>

<p><label for="url">Website</label><br />
<input type="text" name="url" id="url" value="<?php echo $comment_author_url; ?>" size="50" tabindex="3" /></p>
</div>

Just above this block, you should also find the start of the <form> tag for posting a comment, you want to add the “onsubmit” attribute to it so that it looks something like this:

<form action="<?php echo get_option('siteurl'); ?>/wp-comments-post.php" method="post" id="commentform" onsubmit="update_form_values();">

The important parts there are that it’s all wrapped in a DIV or SPAN with id=”comment-user-details” and then obviously the <fb:login-button> stuff. Now further down (I went right down to the bottom of the comments.php file actually), add this code:

<script src="http://static.ak.connect.facebook.com/js/api_lib/v0.4/FeatureLoader.js.php" type="text/javascript"></script>
<style type="text/css">
#fb-user { border: 1px dotted #C0C0C0; padding: 5px; display: block; height: 48px; }
#fb-msg { float:left; }
.fb_profile_pic_rendered { margin-right: 5px; }
a.FB_Link img { float: left; }
</style>

<script type="text/javascript">
var fb_connect_user = false;
function update_user_details() {
fb_connect_user = true;
// Show their FB details
if (!jQuery('#fb-user').length) {
jQuery('#comment-user-details').hide().after("<span id='fb-user'>" +
"<fb:profile-pic uid='loggedinuser' facebook-logo='true'></fb:profile-pic>" +
"<span id='fb-msg'><strong>Hi <fb:name uid='loggedinuser' useyou='false'></fb:name>!</strong><br />You are logged in with your Facebook account. " +
"<a href='#' onclick='FB.Connect.logoutAndRedirect(\"<?php the_permalink() ?>\"); return false;'>Logout</a>" +
"</span></span>");
}

// Refresh the DOM
FB.XFBML.Host.parseDomTree();
}

function update_form_values() {
if (fb_connect_user) {
profile = jQuery('#fb-user').find('.FB_ElementReady .FB_Link')[1]['href'];
user_id = profile.substring(profile.indexOf('?id=')+4);
jQuery('#url').val(profile); // FB profile URL
jQuery('#email').val(user_id+'@facebook.com'); // Can't get a real one from FB unfortunately. This saves their user id @facebook.com
jQuery('#fb-user').find('.FB_ElementReady .FB_Link').each(function(i){ if (i==1) { jQuery('#name').val(jQuery(this).text()); } }); // Gets their name from the DOM
setCookie('fb_connect', 'yes');
}
}

function setCookie(c_name,value,expiredays) {
var exdate=new Date();
exdate.setDate(exdate.getDate()+expiredays);
document.cookie=c_name+ "=" +escape(value)+((expiredays==null) ? "" : ";expires="+exdate.toGMTString());
}

function getCookie(c_name) {
if (document.cookie.length>0) {
c_start=document.cookie.indexOf(c_name + "=");
if (c_start!=-1) {
c_start=c_start + c_name.length+1;
c_end=document.cookie.indexOf(";",c_start);
if (c_end==-1) c_end=document.cookie.length;
return unescape(document.cookie.substring(c_start,c_end));
}
}
return "";
}

FB.init("YOUR-FACEBOOK-API-KEY", "/xd_receiver.htm");
FB.Connect.ifUserConnected(update_user_details);
if (getCookie('fb_connect') == 'yes') {
setCookie('fb_connect', null);
FB.Connect.showFeedDialog(YOUR-TEMPLATE-BUNDLE-ID, {'blog':'<a href="<?php bloginfo('home') ?>"><?php addslashes(bloginfo('name')) ?></a>', 'post':'<a href="<?php the_permalink() ?>"><?php addslashes(the_title()) ?></a>'}, null, null, null, FB.RequireConnect.promptConnect);
}
</script>

For those of you paying any attention to what you’re copy-pasting, you would have noticed that there are 2 important things you need to replace in that last block of code. Go back now and replace “YOUR-FACEBOOK-API-KEY” and “YOUR-TEMPLATE-BUNDLE-ID” with the appropriate values from the beginning of this process. YOUR-FACEBOOK-API-KEY should be replaced with the 32-character string from the Facebook App config, and should include double-quotes around it in the code above. The YOUR-TEMPLATE-BUNDLE-ID should not have quotes around it.

Save everything and upload it (if you were working offline). If all has gone well, you should now get a FB Connect button on your comments (you need to log out of WordPress to see it), and when you click it, you should connect to FB, then be able to post a comment.

When a Facebook user comments on your blog now, their name will be loaded from Facebook, their profile URL will be used as their URL, and the email address will be recorded as “user@facebook.com” (their API doesn’t allow you to actually get it, to avoid spam I assume).

Enjoy.