It’s not about what we have, it’s about what we share… Part Two.
Here’s the second instalment from Planky on Social Media tools – enjoy 
P.S. If you missed the first article, you can find it here.
It’s not about what we have, it’s about what we share… Part Two.
In part one I gave an overview of what was possible and started down the journey of the various bits of setup that had to be done, either by you, or setup that has already been done by the Windows Live team. In this article I show how the OAuthWRAP protocol works with Messenger Connect.
Windows Live ID wants to share some secrets
Windows Live ID is the Authorization Server. It implicitly trusts the Live IDs in its database because it created and issued them. But when it gets down to your site, it needs to have some assurances that the site that comes to it purporting to be your site is in fact your site. To this end it will create and share a couple of secrets with you. In OAuth WRAP terms, your site is known as the client application, hence the secrets are termed the client ID and the client secret. It’s important that you keep these secrets, well, secret.
To obtain these secrets you must go through a registration process with Windows Live ID (the Authorization Server). You’ll be asked for the site’s domain name and the URL of a callback handler (covered later). The secrets will be stored against the domain and URL. Whenever your site communicates with Windows Live ID, all the parameters must match up; the URL, the domain, the client ID and the client secret. Security and authorization error messages invariably end up with one or more of these parameters not matching up correctly.
While the product is in Beta, you can’t register a domain unless you have also applied to join the Beta and been accepted on to the program. You are informed by email of your successful registration. This process can take a few days, so make sure you allow for it in your schedule. You’ll be asked questions about the number of users that hit your site and the scenarios you want to try. As a general rule, if you fill in all the fields accurately, the scenario you want to deploy is supported and the site is a genuine site, you will be accepted on to the Beta program. You’ll need a Live ID to register.
To register, go to http://dev.live.com and click the “Join the Beta” button.
Once you are registered, you can add additional URLs and manage their secrets. You can also upload logos that will be used in authentication challenges and so on. This is done at http://manage.dev.live.com.
Figure 2: Client application management at http://manage.dev.live.com
Protocol Exchanges
Once all this basic setup (certificates, client ID, secret, callback URL, domain name) has been completed, you can create/modify the pages in your site with the aid of the Windows Live SDK.
In this section, you’ll see how the browser, Windows Live ID, the Windows Live API Service, your site and so on all communicate with each other. In later sections we’ll talk about how most of this is wrapped up in the OAuthWRAPCallback assembly plus some javascript libraries. It’s useful to understand how the elements communicate with each other before understanding what the libraries and Windows Live tags do. Even though this means you’ll have to live with a degree of ambiguity until you understand more – but stick with it, it is better this way.
First, a protocol diagram:
Figure 3: OAuthWRAP protocol exchanges in Messenger Connect
Each element is numbered 1 – 17. At the end of this, the browser will have cookies that represent security tokens. Your web site will take these cookies, convert them to tokens and use them to access, for example, Windows Live profile information, or contact information.
- The web browser connects to your site.
- The web browser loads a page that contains a “Connect” button. Embedded in to this button is the client ID you obtained when you registered your application, the callbackURL you registered, a thing called the client scope (basically a permission type that will be covered later) and optionally, client state information.
- Clicking the button causes the browser to see if it has already gone through a consent process by checking for a consent cookie. In this case we assume no consent cookie is present.
- This causes the browser to go to a special page on Windows Live called the “Windows Live Consent page”.
- The consent page prompts the user for credentials, but also, importantly asks the user “are you happy to be providing this site, with the following information”. The consent page looks like this:
Figure 4: Windows Live Consent Page
…clicking the “what will I share” link, shows something similar to the following:
Figure 5: What you will share
- At the same time, the consent page gathers up the client ID, scope, callbackURL and state, and makes a call to the Windows Live ID Authentication URL.
- Windows Live ID is what is asking for the Live ID and password.
- Because the user typed the credentials in to the consent page and they were accurate…
- …Windows Live ID validates the password against the Windows Live ID and sees a genuine user. It now generates a short lived verification code and records this fact against the specified Windows Live ID in the back-end database.
- Windows Live ID generates an HTTP 302 redirect to the callbackURL (which it obtained in step 6)
- The verification ID, client ID and client state are passed to the callbackURL.
- It’s the callbackURL that has access to the client secret (the one that was generated by http://manage.dev.live.com when you registered your site. Remember the screenshot in figure 2?). The code for the callbackURL is provided in an assembly as part of the Live SDK. The assembly checks in web.config to retrieve the secret which must match exactly the secret stored at manage.dev.live.com. Although it might appear to be a security risk to store sensitive information like this in a file on a web server, by default IIS request filtering protects this file. Of course though, if someone manages to find an exploit – there is your client secret for all to see. I’ll talk about a solution to this problem later.
- The client secret is checked to make sure it matches the one stored against the specified client ID. The short-lived verification code is checked to see if it has expired yet. This is a simple protection against replay attacks. 2 tokens are now generated: the refresh token, which is long lived – 8 hours – and the access token, which has a short life. The names of the tokens are something of a give-away. You use the refresh token to get new access tokens when they expire. There is no need to re-trace every step, including authentication, to renew an access token. Simply supplying a refresh token returns a fresh access token. Say if the access token has a life of 10 minutes, it means if a Windows Live user makes a more restrictive edit to their profile, it will only be a maximum of 10 minutes before requests are no longer honoured. Of course, if the client application already has a copy of the data, then there is nothing Messenger Connect, the OAuthWRAP protocol or indeed the original owner of the data can do about that. Once past initial disclosure, it is not possible to destroy data that is now in somebody else’s hands. These tokens are stored in Simple Web Token format. Recall the description in the Part One post which shows how the tokens are additionally protected by encryption and signing, and remember this requires the creator and consumer of the tokens to go through a certificate exchange which involves the exchange of public keys.
- The access and refresh tokens are returned to the callbackURL along with expiry information.
- The callbackURL forwards the tokens to your web site.
- Your website uses a process to copy the token contents in to a collection of cookies.
- The cookies are returned to the browser. Although you might expect the site to keep copies of the tokens and maintain state between the browser and the tokens, in this case, the tokens are effectively stored in cookies on the client. They are session cookies, not long-lived cookies, so when the browser is closed, the cookies are destroyed. This means to get them back again, the process has to be re-traced in its entirety. The reason for doing this is because the code that runs on your site is a very clever javascript library. Storing cookies in the browser like this makes it possible to perform apparently complex state operations entirely in client-side code.
In Part 3, we’ll have a look at how the tokens are passed to the Windows Live API Service and the data retrieved. Then in subsequent parts we’ll look at some code and show how the various pages and services link together. I’ll cross reference the code that runs with the protocol diagram so you should be able to work out what’s going on.
Stay tuned, Planky
_______________________________________________________________
Thanks Planky! You can check out Planky’s blog here.
It’s not about what we have, it’s about what we share… Part One.
Steve Plank (Planky) is an Architect Evangelist on the Microsoft DPE team (Developer Platform Evangelists). Planky, in his own words, is ‘unusually intrigued by things like encryption and that kind of caper. Very interested in protocols and all the malarkey that surrounds them’. If you want to know more, take a look at his blog.
It’s not about what we have, it’s about what we share…
Facebook, MySpace, Twitter, Messenger, Spaces, Linkedin, Bebo and so the list goes on: places we share different aspects of our lives. We see something on the net that we like and we put it on our wall, we tweet it, we promote it, we chat about it, we allow others to share in the pleasure we get from it.
Each of these services is an Island. We go to the first one and register, create a profile, log out, log in, add to our profile, add friends, add photos, share photos, share the things we like. Then we go to the next service and guess what we do? We register, create a profile, log out, log in, add to our profile, add friends, add photos, share photos, share the things we like. As they say in the Rock and Roll world – repeat till fade.
Windows Messenger Connect is a way for us to connect these experiences and services together. For some of the features – such as creating a single login or sharing profiles, contacts and friends across different sites it does require the co-operation of the site concerned. Your site.
But many things can be shared in a natural way, because of the APIs and services exposed by these sites in any case.
We’ve all seen this sort of thing on various web-sites:
…a way of sharing that page through email, with our Facebook friends, or through Twitter. We can now add a new sharing icon – the Messenger Connect Sharing Badge:
When you see this icon on a site, it means you can share it with your Messenger friends just by clicking it. This is the simplest Messenger Connect feature to implement on your site because it just requires a few lines of HTML – Messenger at the back-end takes care of everything else for you.
Why would you do this on your site? The more people who share your pages with their Messenger friends, the more visitors you will have to your site.
Messenger Connect Capabilities
There’s more than just sharing a page. This list gives you an idea of the sorts of things you can build right in to your site:
- Lower the friction of getting users to register at your site. We’ve all done it – hit yet another page that asks for personal information like Last Name, Home Address, Home Telephone Number. We often find the process too onerous for the benefit we feel we might receive from the site and so we bail out. Depending on which study you read, between 80% and 99% of users who go to the registration page of a site, abandon the process.
- ASP.Net has built-in mechanisms for authenticating users. Or you can build a home-grown authentication system or use libraries from a 3rd party. The advantage of using Windows LiveID on your site is that it’s a ready-made market of about half a billion people in the world who have already registered.
- There’s a Windows Live Signin Control where you can integrate the authentication and consent process into your site using little or no JavaScript code
- There are JavaScript and .Net libraries that allow you to sign users in, monitor their authentication state and, with user permission, get access to their Windows Live profile information so they don’t have to go through the process of re-keying all that information yet again.
- Real-time chat within your site:
- A small bar at the bottom of the page; the Messenger Web Bar is a single UI Control that contains a full Windows Live Messenger experience. It allows users to manage contacts and interact with them, shows all active conversations, allows users to update and display presence and most interestingly – enables the user to stay signed in to Windows Live Messenger while they navigate from page to page within your website. Conversations that start on one page can continue on another.
- The Chat Control can be embedded right in to your web pages: users can view a Messenger chat session and users who have a Live ID can use Messenger chat to send their own messages.
- Contacts: Users spend more time on a site when they know their friends are there. Make it easy for them to discover their Windows Live contacts on your site.
- Share your activities: Let your friends and contacts know what you are doing – it’s a way to remain connected on a personal as well as a network to those close to you.
- Share your Calendar and Photos: Isn’t this really about sharing some of the minutiae of your life with the people you care about. Whether you can make it to a dinner party on a certain date, or a picture of you and your partner on a beautiful beach somewhere is not interesting to anybody unless they know you. The level of interest and engagements goes up exponentially when you know the people you share these things with. Messenger Connect just makes that process easy to do in an ad-hoc way when using the Internet.
The mechanics
Almost all of this is possible because of a web based protocol which is used for authorizing API access across sites: OAuthWRAP or Open Authorization Web Resource Authorization Profile. WRAP is a profile within OAuth. In the cases we are interested in, it uses browser redirects, HTTP headers and HTTP Post messages to transfer control and tokens between web sites, Live ID and the web browser. The tokens contain authorization information that determines what site can get access to what information. The protocol has built-in features such as timeouts, security, encryption, secrecy and so on. There are 4 parties in an exchange:
- The Client Application (your website)
- The Authorization Server (Windows Live)
- The Protected Resource (Windows Live): for example your profile or your contacts
- The web browser (and attached to the screen, keyboard and mouse of the browser – the user)
In the case of Windows Live – it performs roles as both an Authorization Server and a Protected Resource. It authorizes or denies authorization to resources such as a user’s profile, contacts, calendar or photos.
Setup
Before any exchanges can take place, some things need to be set up. This section talks about that.
Windows Live APIs trust Windows Live ID
Firstly, there needs to be a trust relationship between the Protected Resource (Live profiles, Live API service etc) and the Authorization Server (Live ID). The trust involves a certificate exchange which essentially results in the 2 services swopping public keys with each other. This ensures that tokens can be encrypted and signed – just a precaution to ensure tokens aren’t cracked open and inspected, faked or modified. The diagram below shows the way this is achieved.
- The Windows Live Authorization Server has a certificate (as does the Windows Live API Service). It contains a…
- Public Key.
- The related private key is held separately to protect it.
- A certificate exchange takes place, which essentially means the Windows Live Authorization Server and the Windows Live API Service swop public keys.
- When a Refresh Token or Access Token is generated by the Authorization Server, to assure its authenticity, it is signed by the Authorization Server’s private key.
- Because the Windows Live Authorization Server has a copy of the Windows Live API Service’s public key, it uses this to encrypt the Refresh/Access Token.
- The encrypted, signed token is passed to the Windows Live API Service.
- Because the Windows Live API Service has a copy of the Windows Live Authorization Server’s public key, it can use this to validate the signature and therefore be assured that the token was indeed generated by the Windows Live Authorization Server, and not modified by an imposter while in transit.
- The Access/Refresh Token was generated by the Authorization Server, which used the Windows Live API Service’s public key to encrypt the token. It therefore uses its own private key to decrypt the token. In this way the security and authenticity of the tokens transported between the 2 servers is maintained.
The reality is that this all happens entirely under the covers. It’s merely included in this description for the sake of completeness. But it does mean as a developer you can be assured any time authorization information is passed via a user’s browser, it is all safe.
I’ll continue the story in future instalments. Stay Tuned!
Stuffing your data under the mattress…?
Andrew Fryer (aka Deep Fat) is an IT Pro Evangelist on the DPE team (Developer & Platform Evangelism). Andrew ‘covers the wider issues facing IT professionals in the UK, such as cloud computing, infrastructure optimisation against uncertainties about the economy and the environment’.
Stuffing your data under the mattress…?
You would think in this cloud era that keeping your own data and running applications on a PC is the high tech equivalent of stuffing your money under a mattress rather than trusting a bank with it. But in this country, despite the previous conservative governments effort to boost wider share ownership, many of us see property ownership as more secure and over time this has consistently out performed shares. The only way this would change is if there was some significant change to taxation, as a growing population’s demand for housing will always be at a premium.
Getting back to PC’s. If I could rely on cheap and ‘always on’ communications, would I need to store any local data or cache any applications? Possibly, but if I did, I would use more than one provider/ location much in the same way as I wouldn’t invest in just one bank in case it went to the wall.
So why do I have a PC of my own? Ownership and control.
I can use my PC to control where I put my stuff:
- Stream it to from my TV/ games console
- Dump my music to MP3 players whichever one I choose
- Move stove to interim storage like USB drives and SD cards
- Transfer my legacy analogue assets to the digital world using record players and scanners for my negatives
- Upload and backup to the various digital vault sites like SkyDrive
- Share content on any Social Media sites e.g. Flickr/ Facebook /Slideshare as they come along
- Get in to eBooks when those devices match my success criteria for a good eBook reader
- Store secure credentials for online banking etc.
If some gadget comes out that can do all of this stuff and connect to all the stuff I have now (or will have), then I might reconsider. However we don’t even have the communications yet and certainly not where I live (~1Mbs). Moreover, I have to pay excessive charges in hotels and airports for the most basic of connectivity while I am out and about.
I realise this has probably got nothing to do with Ray Ozzie’s article in the LA Times, but I think he may well have a point, the PC has an even bigger role to play in a cloudy world than in an unconnected one.
A gentle plea for organization
James O’Neill follows up his article ‘IE6 must die’ with wise words about the importance of keeping pictures and their description together to make sure treasured memories are preserved.
A gentle plea for organization
I flinch when I use the word “Metadata”. I sense people rolling their eyes and thinking “here we go: another trip down jargon alley”. Meta- is used to indicate “higher level or second order kind” meta-data is data ABOUT the data – in simple terms file properties.
I doubt if librarians say “metadata” but they understand it. A book has 3 natural properties: Author, Title and Publisher; consider, for a moment, the usability of a reference library where shelves are arranged by any one of these and you’ll understand need for the Dewey Decimal Classification system – which tags books by what they are broadly about. Some people call such tagging classifications “taxonomies” another word which makes me flinch – it just means something tabulated, (“taxi” and “taxes” come from the same root – they relate to tables of charges).
Disk file systems have a few core properties for every file – a name (which usually had an extension part identifying the format of the data), the date when the data changed, and a location in the file system’s hierarchy. Classification implies location and vice versa – as with library books. Unfortunately, where the Dewey system works in many libraries from one year to the next, the folder structure created by someone else (or even your past self) can be a mystery: any decent size library needs a catalogue and so does a modern hard drive. Cue search.
Search relies on indexing text – but not all text is equal. HTML has a <META> tag which tells search engines “this is the description”, “these are keywords” and so on. Office documents have had Author, Title, Keyword-Tags, Description and other properties since the early 1990s. Non-textual files can have textual metadata: MP3 and WMA files both have the ability to store Track Title, Album, Performer and Writer information (and more). Enter a musician’s name in the search box on Windows 7 or Vista and you find their songs in your music collection. Pictures, in TIFF, JPG and some RAW file formats store technical and descriptive information, (known as EXIF data) which Windows can index and search.
But things go wrong with pictures. At a recent event I heard a speaker complaining that he had catalogued his photos with iPhoto, and then realised the drawback of having the information in a proprietary database. He looked for an alternative but only Adobe Lightroom and one open source program used EXIF. The reference to iPhoto suggested using Windows Explorer was not an option for him. But there are many cataloguing programs for Windows which do the job less well than Explorer: quite a few are supplied with cameras.
Windows 7 Explorer – Top right: searching by free text and in specific meta-data fields
Middle left: found items with hit highlighting and live icons
Middle right: preview, and bottom details pane viewing and setting information for multiple items
Windows XP gave explorer the ability to show and set properties of photos and other files. It was improved in Windows Vista and again with Windows 7; both make it easier to view and set properties, search through them and create virtual folders using them: with properties catalogued, files don’t need to be arranged by their location, any more than a library catalogue would be arranged by the Dewey numbers which determine shelf position.
Indexing gives immediate rewards for entering EXIF tags. The speaker I mentioned was interested in the long term, and it has concerned me too. Photographic prints, negatives and slides often come with pieces of additional contextual information: the note scribbled on the back, the letter wrapped round a precious family photo and so on – they are meta-data. Valued pictures are preserved and handed down – studio pictures from Victorian times are useful to family historians today and even with family snapshots from the 20th century there is a good chance that pictures come with something informative (even something like “Holiday, Norfolk 1971” on the packet) . Will people bother to preserve Digital photos? And will there be information for their children and grandchildren to refer to? I’m quite optimistic on the first part – we share digital photos and tend to keep all our old data as we upgrade computers, hard disks keep getting bigger making room for it. But I’m sure that information about the picture will only survive if it stays with the picture. With cataloguing programs – however good they seem – I’d test setting a title and keyword tag and prefer a program which stores data in the photo over one which doesn’t. If a program stores picture data only in its own database it means:
1. You can only search for pictures from the program itself, not from a Windows Search
2. When you share pictures they will lose their data
3. You can’t change software unless the new software reads the database (which is unlikely)
4. If the database stays with the images, will a future generation be able to read it?
If prints are rarer than in days of film, they may be cherished (rather than files), never underestimate the power of the note written on the back!
Car Porn – Part I
As the Geneva Motor Show kicks off today (and I’ve already fallen madly in love with the Porsche 918 Spyder), and as our very own Daniel Sumner is a self confessed car lover, we thought it would be rude not to share Part I of his ‘Car Porn’ post with you.
Car Porn – Part 1
Talking to someone who works within the car sales industry recently, he dropped the term “Car Porn” mid-sentence. Obviously the use of such words in generic technological discussion pricked my ears (so to speak). He explained that in their site statistics they have to filter out the high end luxury brand vehicles from their reports, as although they may only have a few hundred of these cars on their site, the number of users actively searching for these cars is x100 higher.
Now either there are a lot of people with very good saving plans in place, or people are having that “if I did win the lottery tonight, then I would buy…” moment. This moment of fantasy is usually born out of the fact that maybe, just maybe tonight I will win £85 million… what follows is that brief but delicious fantasy of how you would then spend the dosh, and how long you would keep on going to work for, just to keep a measured life style (I think I might manage about 3 days).
What is interesting is how many people love to window or fantasy shop and how that manifests itself in the online world. A tire kicker coming into a showroom in a car dealership is of absolutely no value at all to the seller. But online there is still value to be had; simply looking generates advertising revenue for the publisher. So while it may well be a reporting task to filter out the fantasists, it’s still a job worth doing because of the value it generates.
But is there a way we can better service the lovers of Car Porn? Or any other interest group for that matter? And by ‘service’ I mean both 1) giving the lovers of all things V12 a rewarding experience, and 2) giving the publisher a quality click steam, and improved advertising revenues?
Better still is there some way we could link together all the automotive fantasists into such a cornucopia of automotive eroticism that had not been seen since the days of Sodom and Gomorrah?
I think there is….
Photograph reproduced courtesy of CNET UK
IE6 Must Die
James O’Neill is a IT Pro Evangelist on the DPE team (Developer & Platform Evangelism). What does that mean? Well to steal a line from his blog, his focus is on ‘Windows Platform for starters, Virtualization, Real Time Collaboration and Photography to follow, served with a side order of philosophical attitude’. Need I say more?
IE 6 Must Die
I’m not quite sure where the “IE 6 Must die” meme started, perhaps it was on Mashable, or perhaps it was a tag on twitter. Although it has taken hold in a lot of places (Bing finds 76,000,000 references to it) there is still a need to spread the message. I don’t think I’m giving away any secrets when I say that we watch our share of the web browser market, and we’d like to see IE8 get as much share as possible. But this takes more than persuading people that IE8 meets their needs. A lot of organizations are stuck on IE6 and won’t move, despite things like the following:
- It’s been widely reported that Google have announced they are pulling support for IE6 (and versions of chrome and Firefox which are rather less ancient)
- In a post marking IE8’s new found position as the world’s most popular browser Microsoft’s own Brandon Le Blanc said as an aside:
“You may have recently heard about organizations including Google recommending that people update their browsers and move off older versions, such as the nearly decade-old Internet Explorer 6. Think about what technology and the Internet were like in the year 2000 – and consider how they’ve evolved since then. In 2000, “phishing” was something that happened at the lake, not online. There was no social networking, no RSS feeds, and no real blogs. It was a different time – and people’s browsing needs were different. Today’s Internet calls for more.
We support this recommendation to move off Internet Explorer 6. Modern browsers such as Internet Explorer 8 bring benefits for customers and developers alike.”
- There is a petition on the 10 Downing Street Web site, asking Government to stop ignoring its own advice and shift – over 5000 signatures so far
- The department of health has already moved on this
- This guardian article “iPhone is the new IE6” , which used IE6 as a byword for all that is bad about developing for a specific browser
Brandon’s point about phishing is a key one. The weakest part of any browser is located, as the saying goes, “between chair and keyboard”. Bodies like NSS labs do tests on how well different browsers block different kinds of Malware – their most recent test is here – and IE8 won. IE6 has no blocking. It’s like a car without seatbelts – which isn’t as far-fetched as you might think.
According to WikiPedia, Mosaic, which is the ancestor of all modern browsers, was released on 22nd April 1993, and IE6 released in 27th August 2001, 3049 days later. So, what date comes 3049 days after that? By a staggering co-incidence it is 1st January 2010. IE6 is closer to the first real browser than it is to today. Would you fly in a plane which is closer to the Sopwith Camel than an Airbus, or drive a car which is closer to the Model-T Ford of 1908 than today (that would be 1959, the year Saab introduced the first model to have seat belts as standard)?
When I came across a story about “IE6 no more”, I did wonder if they had some Axe to grind, but their home page says:
”Microsoft Internet Explorer 6 was released in late 2001. For its time, it was a decent browser, but in 2009, it is still in use by a significant portion of the web population, and its time is now up.”
Apart from the need to update the year, that’s a correct statement and about as neutral as I think it can be worded; this is simply a campaign to get people to browse the web with something more modern. They don’t care if people replace IE6 with IE8, Firefox, Safari or Chrome – and they provide a little code snippet for site owners to put into their pages to create a “please upgrade” banner. As it happens I have XP mode set up for demo purposes so I can fire up IE 6 alongside IE 8, and I wanted to see that looked like. Is it me or does IE6 look horrible?
Remember IE6 only runs on XP. Mainstream support of XP and IE6 came to an end in April 2009; it is now in extended support until 2014 – from July you’ll need to be on Service pack 3. I’m going to be talking a fair amount about deploying new software and anyone pinned on XP by IE6 isn’t going to be doing much of that.
Now: you might say “But we have a crummy line of business application that is essential to the continued operation of the business – it is unmaintained because (a) no one is entirely sure how it works and (b) it was built on old technology and uses components from vendors that have long since gone out of business” [That’s a précis of the start of an article on XP mode from Ars Technica]. I have two answers to that – one technology advice: MEDV (or XP mode for small companies) will allow you to run those applications in an XP Virtual machine. Don’t think that this is “free” MEDV is part of MDOP which has a license cost, but even the “free” XP , mode costs resources. And the other answer? Your organisation has had four years to come up with a plan to get off IE6. Yes, it involves spending money, but that is investing to make people more productive. When others were getting the benefits of new technology, your technology was frozen in 2001. Are you sure you want to work for a company like this? (And if you work in one those poorly run parts of the UK Government don’t even think telling me the taxpayer’s money isn’t there before you’ve read this).
P.S. Brad Colbow’s cartoon is a great contribution to the discussion.
Is your website sociable?
Daniel Sumner is a Platform Strategy Advisor on the DPE team (Developer & Platform Evangelism). Yep, his job title doesn’t make it clear exactly what he does! In his own words, “I focus on helping customers in Retail, Manufacturing and Services sectors innovate with using our latest technologies.” He’s also into cars and girls, but that’s another story. Daniel’s done us the honour of being our first guest blogger (he may get his own regular slot at this rate – anyone who fancies rising to the dizzy heights of guest blogger can contact us any time).
Is your website sociable?
In the UK I don’t think we’ve quite got to grips with how you can link your social audience to your website. Growth in social networks is mind numbing and the amount of data the sites are able to capture about you, your friends and your interests is significant. Despite the huge opportunity, to date the comment from the average web site owner has been “so what?”
The problem is, it’s not that easy to link social networking sites to content or retail sites, from a technical perspective or the commercial justification. Yet consumers have an increasing desire to share their online experiences and activities with their social groups. You just have to look at the rise in Facebook applications to see that trend.
Microsoft made a huge investment early on in social networking with Instant Messenger, an application that is used by almost half of the internet population in the UK. Messenger friends – unlike your Facebook friends – are likely to be much closer “real” friends to you. Most of us have around 15 people that we are will to share our presence with and allow them to interrupt us or communicate with us on an ad-hoc basis.
These friends also have opinions you value and share experiences you are interested in. The only way that these friends can actually share details via Facebook and/or Twitter is by retyping their experience into the update or status.
But all that is changing. If you are a user of LinkedIn, or Facebook, or TripIt for example you may have noticed the ability to link your status updates automatically when you have an update in another application. A service called Facebook connect does this. But we also have the same function appearing in the Windows Live platform, enabling you to link messenger to various social networking sites and perhaps more importantly allowing you to link a retail or content site to your messenger status.
So, for example:
1) You log into messenger and your status says; “So happy to be at work on Monday morning!”
2) During lunch you head over to retail site to check out a pair of trainers. You end up being unable to decide between some old school green flash Dunlop’s and some techno miracle shoe from Kobe Bryant. If the site supports messenger integration you could pull up a messenger widow inside the site, ping your buddies and ask them to evaluate your sartorial elegance in casual footwear, where they then send you to Puma by Alexander McQueen and urge you to rethink.
3) Having made your purchase, a site could immediately push a status update out saying “I just bought these very cool trainers at Puma by Alexander McQueen” with whatever links you wish. The site now has the ability to update you and your friends about your sneaker habit.
The mechanics of actually connecting up can be found on dev.live.com using the Web Messenger toolkit and the latest consumer versions of live on get.live.com. Enjoy!
