Uh oh. If you can see this, something has gone wrong with the CSS. Bugger.

Normal service will resume shortly. Feel free to read on, things may just look a bit odd. It's probably related to a sudden change in Blogger's features, requiring some strange back end migration trickery.

syndication needs to get social

Social networking discussion seems to focus on which service will kill another, which ones are going to be the winners or losers. But as far as I'm concerned, I don't want them to kill each other; I just want them to let me publish once and syndicate wherever I choose.

is that a crowded market i see before me?

Social networking sites and services continue appearing thick and fast. Every service wants to be the one that people use; and every new service is evaluated to see what it's supposed to be killing - right now Google has 19,800 results for the query pownce "twitter killer".

But do users really think this way? Do users want one service to rule them all? Do superior services win? MySpace suggests not. Personally I think people just go where their friends are - it has nothing to do with technical merit or clever hooks. There's no point sitting on a technically superior service with nobody to talk to. So you sign up wherever your friends are.

But the thing is your friends don't actually move in neat ranks and dutifully sign up to one social network. They join up all over the place, wherever they saw a concentration of early adopting friends. Since your friends are on these other services, you either sign up to those too or you miss out on the interaction .

Sure, some people are fiercely loyal and attempt to convert their friends; but they are competing with both the force of habit and human nature - they're screwed, in other words. Once people are comfortable with a service, they'd kind of like to stay put. It becomes their primary service for that kind of data. They might sign up for some others, but they're secondary to their chosen service.

the joy of repetition

After signing up for a few services even the most casual observer will notice the similarities. In fact what they'll really notice is that the more social networks you sign up for, the more they subject you to dull, repetitive work. We start thinking "hang on, weren't machines meant to be doing the work?".

People have long since wished that social networks could share contact details so you don't have to grind through finding your friends on the next service. I've long since wished for the next step: syndication of similar information:

  • I don't want to write a LiveJournal, I just want it to syndicate my Blogger posts.
  • I don't want to create status updates in FaceBook, I want it to import my Twitter statuses and use those.
  • I don't want to sign up to Zoomr, but I'd let it import my Flickr stream.
  • I'd like del.ico.us to mirror my ma.gnolia bookmarks since most of my friends use del.ico.us.

I have primary services for most of the information social networks are sharing. If something new pops up, say I decide to get into Cork'd or Last.fm, I'll happily add that to the pool. But if something is asking me to do the same thing I'm already doing elsewhere... well, I've already done that. I don't want to do it again. If I have to do it manually, eventually I'll stop doing it in at least one place.

pattern recognition

There are some distinct patterns in the type of personal data people create:

  • Notifications - system alerts/updates, action required, action recorded
  • Messages - short, long, statuses, chat, comments
  • Files - photos, videos, music, documents, etc
  • Data - URLs/bookmarks, events, contacts

Most network communications are variations and combinations of these basics. Yet the networks don't let users share the same stuff between services. Why not? Well filthy lucre of course. Each service attempts to create a walled garden, so they can make some money in some way.

But by creating walled gardens, the services are insisting that someone has to fail. At the very best, they all bleed. It's a war of attrition and users are the pawns. Realistically all of my status updates should be "updating fifteen social network sites, can't sleep, friend requests will eat me..".

they've shared before

Email and chat have both survived competition. Consider all the options for chat and email - there are far too many to list. Despite the direct competition, all the services survive. How? By sharing or allowing users to combine services.

Email doesn't have to be manually resent to every friend on a different ISP or email provider. The system just handles the transfers regardless; and any provider can survive so long as they can reliably send and receive email.

With chat, users can now run multi-protocol clients which take care of all the options. They have multiple accounts but they only run one bit of software to manage them all. No specific chat service had to beat all the others - they all just accepted their fate and let the multi-clients access their APIs.

Wouldn't it be awesome if status updates worked the same way? Write one Twitter status and friends get that status whether they're on Twitter, Jaiku, Pownce or FaceBook.... sweet!

comments

Then there's the next step... comment aggregation. If we can syndicate information, we'll want to be able to collate comments across all these services. No sweat, in your XML feed include a reference to a definitive source for each message - remember how we have primary sources? Services can share comments and display them according to timestamps.

can't we all just get along?

Surely all of this is possible. It's not that long ago people couldn't imagine networking everyone's computer in any meaningful way! Probably the biggest challenge would be to convince all the services to share data openly. They don't want to share, they want to recruit page impression monkeys (that's the humans, you at the back) so they can make money.

But if services were open, users could choose whichever service they wanted and still get updates from all their friends. No particular service would have to live or die. Users wouldn't have to choose, nor would they have to miss out on what their friends are up to in yet another walled garden.

It seems social networks are anything but social with each other. The people running them seem to hope that their competitors can be beaten. But consider MySpace vs. FaceBook - even if that war can be won, at what cost the victory? Isn't it more likely that the whole thing could force a migration to some other service entirely?

By sharing data instead, services could decrease churn rates. Why shift to another service if you get those updates anyway? People could actually choose the service they like the most, not the service their friends liked the most. Surely that would make them more likely to just relax and actually write new updates. More usage, more data, more hits. Then everyone wins.

Update: if your Twitter stream is public, you can now synch it with Facebook - Integration between Twitter and Facebook Status | TwitterSweet. Of course if your Twitter feed is protected, you're still no better off.

Labels: , , , , , , , , , , , , , , ,

wd06: Jeremy Keith - is AJAX hot or not?

[Liveblog - liveblogging may continue depending on batteries and wrists ;)]

Jeremy Keith is running through 'am I AJAX or not'. Good points about the definition of AJAX - it's such an abused term; people tend to equate it directly with 'Web 2.0' (another abused term!).

I guess ultimately from the point of view of the user, they simply don't care. It's not about whether something is AJAX or not, so much as 'does it work'; and AJAX techniques (used for good and not evil) can create that sensation. Users can get small bits of information back quickly without waiting - people like the feeling of speed and the page hasn't triggered boredom responses.

Jeremy goes on to suggest that the way to choose when to use AJAX is to get into pattern recognition - what user behaviour and expectation will benefit from AJAX? For example adding a product to an online shopping cart - the user doesn't want the whole page to go away and reload just because they added something to the cart. When you don't need to update the entire page, then it's a good time to use AJAX.

But, a bad time to use AJAX might be to have entire pages of search results - you're keeping less than you're changing. Traditional paradigms hold true and the user's experience isn't disrupted.

A great way to illustrate the principle of 'keep the user informed': Jeremy (like me, as it happens) likes the window seat on planes so he knows when the plane is about to actually land. The moment of impact is scary if you can't prepare, but really not too bad when you know it's about to happen.

Jeremy echoes somehing that Derek discussed yesterday in the Accessibility 2.0 workshop: if you emulate an interface feature, you must emulate it completely. Which is a great argument to support being a bit more choosey about when to use certain UI features. Do you really need to have drag and drop in a web app? Will your users expect it? Have you emulated every possible outcome of the drag/drop motion? You need to be aware of all the implications of what you're doing.

A big reminder: if it's not accessible, it's still no good! Things must still be accessible and usable. You don't get to dodge the accessibility requirements just because AJAX is 'new and shiny'. The good news is that AJAX does not preclude accessibility, but you have to be really aware of what you're doing and what will happen in screen readers.

In closing, Jeremy once again quoted Tim Berners-Lee: The power of the web is in its universality... In my opinion, I don't care if it is cliched to use that quote. For me it never gets old. It is and will remain an incredibly important statement about what the web should be.

I think it's a great thing for our industry that a talk on AJAX finished with a discussion of accessibility.

Labels: , , , ,

about

Web development and standards, as seen by Ben Buchanan.

subscribe

elsewhere

[More bookmarks]

No Clean Feed - Stop Internet Censorship in Australia