The old site was a passive audience experience: traditional article driven content read by the user but the aim of the new site is to encourage discussion and user contribution; discussions are started by a number of key individuals who open out their comments for other users to contribute. User’s contributions are given equal prominence to the article itself and form part of the overall site content.

One of the key features we have implemented enables users to register and subsequently log in with their LinkedIn account: instead of the traditional registration form and then double opt-in email verification process the registration is simply a matter of the user allowing ModernSelling.com permission to access their LinkedIn account, entering in their LinkedIn email and password and Bob’s your uncle we can then authenticate against the LinkedIn user account in the backend (using the OAuth protocol and the LinkedIn API). The beauty of this is four fold:

1. Users with a LinkedIn account don’t have to worry about managing subscriptions / profiles on 2 different sites
2. The registration process is vastly quicker and easier for those choosing to use it
3. We can maintain up-to-date profile information about a user as it is passed from LinkedIn each time a user logs in and don’t have to rely on users updating their profile through a traditional ‘My Account’ section
4. Although we are not currently using all the profile information LinkedIn provides and have only scratched the surface of the many different API’s available we can choose to leverage them at any point in the future without going back to our user base and asking them to fill in more information; we are essentially piggybacking the LinkedIn system

Warning: you might not get what you want

For those wishing to utilise the LinkedIn API for their own web applications / subscriptions sites / profile building there is one word of warning: unlike the Facebook method (‘The Graph API’, part of which was previously known as ‘Facebook Connect’) the LinkedIn profile doesn’t provide you with a user’s email address. This appears to be a strategic business decision by LinkedIn but poses some hurdles for those with existing databases which use the email address as a unique identifier: for obvious reasons, if the email address is the unique identifier then it is a prerequisite to have it in order to set up a user account. Furthermore, even if your database does not require an email address, your businesses sole form of direct communication with one of your users / profiles is likely to be via email – so not much use if you don’t have it!

Personally I think this is a major ‘faux pas’. Some might say it is a security issue but actually, if an individual is already giving a third party web application permission to access their user profile it is just another (important) part of personal data they are happy for the third party to use to enhance their experience.

Our solution to this issue was to create a ‘one off’ step on the first attempt to use our log on with LinkedIn process: this ‘intermediary’ page requests the email address  prior to us creating a user account for them in our database. Secondly, for those who already have a ModernSelling.com account but decided to start using the log in with LinkedIn feature we asked them to link their existing ModerSelling.com account with their LinkedIn account by providing their existing ModernSelling login details (email address and password). Both of these actions were very easy and not required on subsequent use of our log on with LinkedIn process.

Below is a screen shot of this ‘intermediary’ page which hopefully should explain it:

Post Script: I’m subscribed to the LinkedIn Developers network and they have released a few useful development libraries and plugins to make life a bit easier. You can find some useful plugins here and a useful OAuth JScript library has been released here (meaning front-end developers can now leverage the LinkedIn API. Note: as it stands – on 20/04/2011 –  there are some bugs in this library which LinkedIn are working to rectify)

The TweetMeme retweet button is for website and blog publishers who want to encourage their audience to tweet their content on Twitter. The button shows a live count of the number of times your webpage or blog post has been tweeted.

There are a few points worth mentioning about this integration because it is not always as straightforward as you might think and perhaps some of this information will be of use.

Firstly, TweetMeme is quite strict so for anti-spam purposes uses a combination of the Tweet which we send to the API and a custom meta tag containing a match of the tweet:

<meta name="tweetmeme-title" content="The Message of the tweet " />

Additionally, the content / message of the tweet has to be a direct subset of the HTML title tag. For instance, for the example above, “The Message of the tweet” needs to be included in <title>. It doesn’t have to be the only thing in the title tag but it does have to be present.

So if like us you are generating these things on the fly (the site in question is driven by a content management system we built) you may have to make adjustments to your system to accommodate the TweetMeme functionality and also discuss compromises with your client; for instance, in our case, the title tag now includes the original title (which was specifically written for SEO purposes) with the article headline (which we want to be the body of the tweet) appended to the end. There is no way around this; the tweet message cannot contain something that is not contained in the HTML title tag so you need to live with it or not use the TweetMeme API.

Secondly, TweetMeme uses a cache which means that if someone already tweeted your page/s before you implemented the TweetMeme functionality the tweet will already be cached against the url. In these instances, if you wish a retweet to use the a new message as opposed to the old, incorrect message (your old title tag if it was incorrect) you need to clear the TweetMeme cache on a page-by-page basis or, rather than doing a manual update for a large number of URL’s you can automate the process and use the TweetMeme ping api (http://api.tweetmeme.com/ping?url=). Just append the URL that you want to update at the end of it and loop through the list of pages on your site.

Finally, part of the site we implemented this feature on is subscription only so bare in mind that any password protected url is not going to allow the TweetMeme API to make a call back to the page to verify it – TweetMeme will not work in these circumstances.

Happy TweetMeme’ing!