Return to the main Infowranglers site.
This Month
January 2010
Sun Mon Tue Wed Thu Fri Sat
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31
Login
User name:
Password:
Remember me 
View Article  Google Wave: Potentially powerful, but it will make normal users’ heads implode.


So. Google Wave. The hype has dispersed, the hubbub has calmed down. Moreover in some quarters there’s already a backlash in progress. “Slow, over-hyped, doesn’t do much new” are opinions I’ve seen aired recently. But I think the backlash is misplaced.

Certainly Wave’s current Preview implementation is flawed and there are good technical reasons for people to dislike it. However, the more I’ve come to understand Wave, the more I believe it is potentially absolutely brilliant - a communication and collaboration … I’m going to use the phrase… game-changer. Sorry about that.

In fact, I believe that he technical problems with the Preview implementation are the least of it. The biggest challenge that Wave faces is going to be getting users to wrap their heads around it: Wave is so flexible that there is no natural metaphor that properly describes its capabilities.

When introducing an Internet-based communications medium to new users, real-world similes have always been the easiest way to go. Ten years ago it was simple: E-mail is like a letter, instant messaging is like a one-to-one chat. A blog - it’s like an online diary. Once those were sorted out you could rely on second-level metaphors that built on some knowledge of the Internet: Wikis - they’re a Web page anyone can edit - and you can see everyone’s edit history.


Wave Guide - the jargon


Some context: Google Wave was developed by its creators, Lars and Jens Rasmussen, as a modern reinvention of email. They were sick of e-mail’s shortcoming as a collaborative tool (the Re:Re:Re:Re: problem). The thing they came up with - Wave describes a platform, a product, and a federated protocol. What it provides is a system for creating a discussion-document mix that can be edited by multiple users in near real-time.

A wave
is the overall container for a threaded conversation, consisting of one or more participants (which may include both human participants and robots). The wave contains state and stores historical information. A wave always contains at least one wavelet…

A wavelet
is the basic container for one or more messages - known as blips - which are often organised into a threaded conversation. The wavelet is the basic unit of access control for data in the wave. All participants on a wavelet have full read/write access to all of the content within the wavelet. Many waves will only contain one wavelet, however whenever you create a new private conversation within a wave you are spawning a new wavelet. Every wavelet contains at least one ‘blip’…

A blip
is the basic unit of conversation and consists of a single message in a wavelet.. Each wavelet always consists of at least one root blip. From a technical point of view the blip’s content is actually stored in an attached XML ‘document’

Not only does Google Wave need to be described with a messy simile melange: (“it’s a mash-up of e-mail, IRC, Wiki, and IM”). But more problematic is that the best metaphor to describe Wave’s use tends to morph from minute to minute. What seems like IM one minute can become akin to a Wiki the next and E-mail the minute afterwards. From what I’ve seen on the Preview this transition from one mode of use to another can cause a mental jolt. Overcoming resistance to those jolts and getting users to embrace the flexibility is going to be a hurdle when unlocking its full potential within a business.

In Use…

Starting off a wave conversation when you are the only person on line can seem like e-mail. But if there are several of you online simultaneously, the experience is more like IM or IRC. One unnerving quirk of Wave is your ability to see other people’s keystrokes, complete with pauses and back-spaces in real-time. Often this means that one person will start typing… and before they have even finished their first line, someone else will have chipped in and started replying. The first person, seeing the reply emerge will sometimes go back and start amending their original thought, leading to the second person deleting their own reply.

It makes for a fast-moving collaborative environment that feels like a meeting where everyone is talking at once. And that is even before someone starts editing the very same blip you are typing, even as you are writing it.

Potential applications

This fluid environment presents some novel applications. One example may be to transform the technical support discussion forums and FAQs that are common on technical Web sites.

The problem with discussion forums is that they are poor when it comes to finding previously answered questions. Consequently, they often contain the same question, asked multiple times in slightly different ways by different people and , answered in a variety of manners. After trawling through a discussion board for a while, the user is often left screaming ‘yes, but which is the right answer? Before deciding to post their new version of the same question. By contrast the FAQs are easy to navigate to find answers but the content can quite often be stale.

Wave offers the way to combine the two (or three, if you include real-time chat support that some companies now offer).

In the Wave-using scenario, a user would visit a company’s support area and begin typing their question into a new wave. If another user or employee was online, this might turn into a real-time chat, if not it would turn into a typical threaded discussion. But once an answer had been found a moderator could edit the discussion thread down to the essential Q and A, adding it to a FAQ list, if appropriate, or deleting it from the discussion board entirely. The result is a fluid evolution from online support t to finished support document.

Why open source matters, why federation is key.

Google has committed itself to releasing Wave code under the permissive Apache open source license, in fact the first tranche is already released. The implications of open source and open protocols is clear enough - anyone will be able to implement their own Wave server, in the same way that anyone can implement their own e-mail server using the SMTP protocol. Moreover since Wave is an open Platform there are already a plethora of Gadgets and Robots that extend the base Wave functions,

Just as important, the Wave protocols will work in a federated manner - again like SMTP, meaning that contributors to a Wave can use their own local Wave servers to communicate.

For a time, the federation aspect puzzled me, since I was locked into the idea of using Wave as a conventional Web-based Internet or intranet-based collaboration medium. Why federation? I wondered. Surely, if I want to use Example Inc.’s Wave-based support forum, I’ll just point my browser at wave.example.com and away I’ll go. But here’s the clever thing about federation - it’s the key to the original Wave aim of replacing e-mail

In the federated Wave world, rather than sending an e-mail, you would create a message (actually the initial blip of a wave) on your local Wave server and then sent it to colleagues in the same way that you would send an e-mail. It would pop up in their Wave in-boxes. Your colleagues would then simply add their reply/edits, which would be seen by all the people who received the initial blip. No more Reply-to-all nightmares. So Wave doesn’t have to be something attached to a Web site for collaboration; federation makes it a peer-to-peer personal communication tool.

Problems Problems

So why do the people who hate Wave, currently hate it so?

  • The need for speed Preview’s Web interface, written in GWT (Google Web ToolKit) which frankly pushes browsers to breaking point. It works reasonably in Chrome, but in Firefox it is sluggish and Safari, which presumably uses some aggressive in-memory caching to keep things fast can see its memory usage balloon to 1.6Gigs after half an hour of intense Waving.

Currently nearly all the usable dedicated Wave clients out there are in effect site-specific browsers, accessing the Web interface. This is akin to only being able to use e-mail via Web mail. What appears to be missing is a usable client-server protocol - the POP/IMAP elements. Google itself doesn’t appear to be prioritising this (not surprisingly, it likes Web interfaces). It has open-sourced a rudimentary text-based client which uses a minimal protocol implementation, but appears happy to rely on community efforts to develop a properly rich protocol. The community efforts are stuttering along at the moment. Now, I know Web interfaces are all the rage, but personally I think that a nice snappy user experience is likely to need on a native client app.

  • Who gave you permission to do that? To force people into really seeing what Wave is all about, Google has left out anything resembling a permissions system. That means I can create a wave to discuss ‘Usablity Issues in Lotus Notes’ and you can come along, delete everything and change the title to ‘Elephant farming in Bromley”. And there is not a thing that I, as originator can do about it. Certainly the other wave participants can see that you have edited my blips, and even see the history of changes, using the Playback function - but that’s not enough. Expect to see roles, permissions and access controls. Locking down permission will also service to make the new medium seem less strange and unfamiliar. However locking down too far will destroy what makes it special.

  • Where is everybody? There’s no point using a collaboration medium, if there is no-one to collaborate with and at the moment activity on the Preview has slowed down, it can feel pretty quiet. Google needs to get the protocols finished and the open source code out of the door before companies can start using it in anger.

  • Bugs bugs bugs Yes, it’s full of them. From the way that search and playback often doesn’t work to the fact that once a wave gets to a certain size it will - without warning - make itself read-only.

In summary: It’s a lovely idea, its open source and federated, it will have a serious impact on any business whose business is collaboration and groupware vendors will need to sit up and take note. However it needs a lot of technical work before it becomes a practical tool, I estimate a couple of years at best before we see Wave in the wild. That will give you long enough to think about exactly how you explain the new working methods to your users and customers.

Update: Clearly there weren't enough wild-eyed visionaries like me about, or perhaps the rest of the population simply got sick of waiting for the user interface to load. But Google has announced that it is pulling the plug on Wave.

View Article  When Web 2.0 concepts collide: The tribal problem with Digg

It is a truth universally acknowledged that a Web site with a large user-base must be in need of some social networking features. After-all turning a Web readership into a community, which can share knowledge and opinion, benefits the Web site and the user-base alike. And hey, social networks are hot, so if you can make your site into one of those, you’re bound to boost its value. Right?

Not always: in Digg.com, we have a site where social networking is positively toxic to its core model. Yet the company continues down the social road.  

For those few who haven’t visited it, Digg is a user-driven news aggregator. That is users submit links to interesting news stories, which get voted up (dugg up) or down (buried) by the rest of the users. The ones that are most rapidly “dugg” make it to the site’s front page (that’s a simplification - the algorithm that dictates whether a story to make it to the front of the site is more complex and obfuscated than that).  Digg’s selling point is that the content that makes it to the top of the pile is dictated entirely by the crowd and the algorithm. There are no editors, moderators or overseers deciding what hot and what’s not.

So Digg is a classic embodiment of the “wisdom of crowds”. It turns out that the model works well when your crowd is amorphous and disconnected. But what happens when it starts to get clumpy? What happens when connections occur between parts of the cloud, when things get tribal? Bad things, that’s what.

Over the last couple of years the Digg team has looked to capitalise on all the information generated by the army of diggers, aiming to improve the algorithm so that each user sees what they are interested in.  One strategy adopted was to add social networking into the mix. The thinking is simple enough: if Alice spots that Bob tends to submit interesting stuff, give her an easy way of following Bob’s activities and give the two of them a way to tip each other off about interesting stuff. Consequently Digg introduced a way to build lists of ‘Friends’ - making it easy to follow what particular users are doing and what content they are digging. It also added the ability to send a message, or ‘Shout’ to Friends.

The result was twofold. Some users began digging stories based on who submitted it, rather than the intrinsic value of the content. Networks of friends have emerged that work to promote the submissions of particular users. Of course, such concerted teamwork could happen anyway through e-mail and IM. However with friends and shouts Digg has specifically created the tools that are detrimental to the site’s core mission.

“But hang on a second”, you may be thinking - “that sounds like a good idea, letting me follow someone smart and interesting improves my experience”. You’re right. But the problem with the Digg model is when a group mutually up-vote each other’s stories, the results are non-local to that group. In other words if a cluster of Bobs and Alices have a deep interest in moth-wrangling and digg each other’s stories, it doesn’t only effect the group’s results: Carol and Dave will also see the story rise through the ranks despite the fact that they are much more interested in the latest earwig-racing news.

The addition of a social element also exacerbates the “power user problem”. These are users who build large networks and therefore manage to drive large numbers of stories to the front page. The bête noir of many users are power users who   spot stories submitted by someone else and re-submit it as their own - usually leaving the original submission in the dust. It’s leads to this kind of pitch-fork rattling story from December - and Digg’s response which you can read here.

So Digg clearly takes the issue seriously and has spent significant time tweaking its design to get around the problem. An early response was to removing the list of ‘top posters’ to reduce competition for the title of “number one Digger”. Breaking the site up into topic sections was another move designed to give users an easy way to filter content.

It has also spent a lot time tweaking its algorithms to reduce the unwanted network effects and to make it harder for network-dugg stories to hit the front page.  But as the algorithm has become more sophisticated, so the conceptually simple link between number of diggs and the likelihood of hitting the front page has been lost. Users now puzzle over why some stories with large numbers of diggs never making it to the front page. The answer of course is that the stories may have been dugg, but not by the right kind of users.

Digg has tied itself in knots because of two fundamental problem with its model:

1. The number of diggs that a story receives is global - everyone sees the same number.
2. Everyone sees the same stories hit the front page (assuming they have all the sections turned on).  

Unfortunately network effects mean that while everyone sees a story as having the same number of diggs, the value of each dig varies for each user:  a digg from a Friend is more valuable to me than a digg by your Friend. An unprompted digg from someone is more valuable than someone who has been prompted by a friend. So the contents of my front page should be different to yours.  This is a fact recognised by Digg’s recommendation engine.

So how can Digg get around this? It can’t easily. Giving everyone their own individual front page would lead to confusion, as would displaying an ‘adjusted’ digg number for each user next to each story.    

Digg could simply remove the Friends and Shouts functionality and leave stories in the Upcoming voting queue anonymous until they had passed some threshold of popularity. But it won’t do that because it wants to increase its value and social networking is by far the easiest path when you have a large user-base.

Are there any major lessons here for other sites? Only this: In the vast majority of cases  giving your user-base the tools to communicate is a Good Thing. The main exceptions are: (a) when your customer service and products are so bad that letting users converse will create a lynch-mob (b) when your core model requires a user to act without being biased by other users’ activity.

Before retrofitting sociality to existing site, pause for a moment. How will is the site's mechanics be affected if a sub-set of the users start acting as a coordinated mass, rather than informed individuals?
View Article  One to watch: Content Circles - a new collaboration tool
Content Circles is an intriguing little company. A nine person outfit founded by a couple of Adobe/Xerox alumni, it has so far stayed under most peoples’ radars. There appear to be few if any blog entries about it and no mainstream news coverage. But the company does have a potentially nifty little tool for small and medium sized businesses to share files and collaborate on authoring them. It's just emerged from beta.

Content Circle’s basic concept is a familiar one. It lets you create multiple closed workspaces (it dubs them circles, of course), into which you can dump any kind of document. You can then invite contacts into the circle, so that they can view, contribute or edit the content depending on the role that you as circle creator assign them. Once in they can choose to be notified when content is added or changes, can add notes to documents, and use an in-circle IM system.

Yes, its another approach to doing away with the old e-mail attachment shuffle and there is no shortage of cheap and cheerful approaches; DropBox, Google Docs… or Sharepoint, if cheap doesn’t really appeal.

However Content Circles is unusual in it takes a peer-to-peer approach to the data and is written as a desktop Java application. So there is no central repository for the files, instead each member of the circle holds copy of the files locally in the application. Drag a file or folder into a circle window and the data is copied into the application and then synced across the network to the rest of the membership. If they are offline, then the data is synced as soon as they reappear, from whichever members are online. If everyone is offline, well it is possible to set up a machine as a dedicated store-and-forward server.

The application also hosts a real-time chat pane for circle participants as well as the ability to tag and add comments to files. Here's an annotated screen-shot from the company:



There are some nice touches - you’ll notice above that I said dragging a file on to the application copies it into the circle - so the existing file sits untouched on your machine. But what happens when the version held within CC is altered? First the application makes a new revision and keeps it with previous versions. Secondly it flags up that the version inside the application now differs from the original sitting on your machine and lets you update the original with a couple of mouse clicks.

Another nice touch is the application’s ability to link to Google Docs and Sharepoint servers, so that documents can be pulled in from those sources, edited collaboratively within Content Circles and the Synced back out.

Annoyances and questions

The 1.0.1 release has a few niggles in it: The Google Docs function won’t work for anyone in the UK or Germany simply because the application automatically appends @gmail.com to the end of username credentials. Fine, except that in the UK and Germany, Google is forced to use googlemail, not gmail. Content Circles says that this bug would be fixed in the next release.

Will it work in a corporate enterprise environment? If Content Circles reminds me of anything at all, it is of a stripped down Groove. Groove was the brainchild of Lotus Notes creator Ray Ozzie and used a peer-to-peer approach to sync files, discussions, all kinds of data between clients. Now I haven’t used Groove since both it and Ozzie were snapped up by Microsoft in, so I don’t know how Microsoft Groove has evolved 2007 . But the original free app combined a lovely idea with a somewhat flawed implementation - it was bloated and syncing often worked, but sometimes didn’t, resulting in a lot of ‘could you re-sync at your end?’ IM conversations.

I wouldn’t want to paint CC with the Groove brush, but it naturally makes me cautious. Particularly since I haven’t tested it in a proper business environment so I don’t know how it copes with traversing firewalls or how it scales or how much network traffic a large installation dumps into the corporate LAN. These are all issues that can make peer-to-peer a pig in the enterprise and can cripple an apparently good idea. On the sync'ing side at least things look hopeful. Whereas the early Groove was purely peer-to-peer, Content Circle's
firewall-traversing abilities are mediated by a "rendevous service" running on the company's own servers according to CEO Sri Chilukuri.

Another thing that will add confidence is the ability to see how others are fairing in the field. Content Circles doesn’t currently have a support forum for users to swap experiences, so you can't get an intuitive feel for how deployments are going. The company says that is set to change.

Subscription based pricing

Lastly, pricing. Content Circles is using a subscription model to sell its product. Passive “circle members” - users who merely want to partake in a circle - can use a free copy, but users who want the ability to set up new circles (be a “circle owner”) and use a few of the more sophisticated abilities such as Sharepoint integration will need to pay - $24.95 per month or $249.50 per year. New users get a 30 day trial period during which they can use all the facilites including circle creation.

Personally, I don’t mind the subscription model when I’m paying for a service, but here the subscription felt artificial when I first tested the app - my personal preference would have been for a standard software license. However
Sri Chilukuri argues that there is a substantial service element, with the important directory service (for authentication and security), as well as firewall traversal being dependent on Content Circle's servers.

You may be wondering what happens if you set up some circles, use them and then let the owners' subscription lapse. The answer - the circles are frozen; the content may be accessed, but no new content, tags, notes etc. may be added. Renewing the subscription, 'defrosts' the owner's circles once more. It's an interesting model and one that at least means that, should something befall this small company your content is at least retrievable.

This is definitely a company and a product worth watching.



View Article  Google Friend Connect v Facebook Connect = chalk v cheese - at the moment
I’ve been helping a couple of people sort out their customer-facing sites recent and the same question has popped up: Google Friend Connect or FaceBook Connect? When Myspace weighed in with MySpaceID and promised to interoperate with Google Friend Connect, the questions multiplied. So as Christmas approaches, let me lean back against this mahogany fireplace, place my sherry carefully upon it and and expound for a moment.

Most of the initial debates that I’ve seen on suggest that this is an immediate battle and that Google/Facebook  are going head-to-head with comparable systems. Not so, in my opinion. While they both broadly aim to make Web sites more social, the offerings are in many respects very, very different. That may change in the future, but here’s the summary of where we are now:

Google Friend Connect

A Quick and dirty addition of social widgets to a Web site. Doesn’t really integrate into the existing site. Currently lacks an API, but expect that to change one day.

Pros

* Good for Non-coders with smaller sites who just want to cut and paste a widget in.
* Good for creating broad, loose networks.
* Expect to see wide availability of wide selection of apps (gadgets) as existing OpenSocial authors tweak their offerings.
* Open-ish - based upon OAuth, OpenSocial and OpenID.
* Support from Myspace, but limited details on integration at the moment.


Cons

* No API, so very limited ability to integrate social information into the mainstream site.
* Log-in is not integrated into the main site at the moment. So expect dual log-ins if your site already has user accounts.
* Not all OpenSocial apps work unmodified.

Facebook Connect

A more powerful system that allows integrated log-on and integration into an existing site thanks to its API. Implementation is more complex than Google Friend Connect.

Pros
* Proper single-sign-in tying site and social aspects together.
* Activity on your site can show up in users’ Facebook feeds - a nice viral way to promote the site.
* A full API giving site designers flexibility.
* Facebook users have to use their real names on your site. (Added veracity)

Cons
* More complex to implement.
* Tightly tied to the fortunes of Facebook.
* Facebook users have to use their real names on your site. (They might not want to)

The main advantages of Google Friend Connect is that a quick cut’n paste of some code is all that’s needed to integrate an open OpenSocial application (Google calls them gadgets) into your site. At the moment only a subset of OpenSocial applications worth in the Friend Connect environment Users can interact with these widgets using their existing Google, Yahoo, AOL, or OpenID credentials.

The relative simplicity of using the Google offering  is already garnering benefits for  the company. Twitter’s recent announcement of support for Google Friend Connect (A user can log in to a GFC-enabled site using their Twitter credentials) was initially this was seen as rejection of Facebook. But “not so” says Twitter in its blog. It’s just that integration with Facebook Connect and MySpaceID are still works in progress that “will require some development effort on our part.”

In the future expect to see Google make its offering more powerful (I would expect an API) and Facebook to help make its more simple. Already it has  added a directory of plug-ins that allow popular blog and Wiki packages to work with Connect.

And what of MySpaceID? To be honest it still appears something of a closed book to me since it really hasn’t launched properly yet. It is holding out the  promise of synchronization of social activity back to a user’s Myspace page, but isn’t there yet. It's not even absolutely clear how the promised interaction between MySpaceID and Google Friend Connect will work in practice. I’d hold fire until more details emerge.

I'll be revisiting this topic in the future to look at exactly how much knowledge you lose about your userbase by implementing something like Facebook Connect.

In the meantime - have a very Merry Christmas and a Happy New Year.
View Article  Collaborative blogging tool Skribit readying new 'Pro' features.
Writer's block is a perennial problem - the average corporate blogger has  lots of interesting information tied up in their noggin. But how do they navigate the boundless seas of half-formed blog ideas and steer themselves towards the safe port of.... splosh... oops, my metaphor seems to have sunk. Never mind.

Anyway,  Skribit is a handy, free widget that can be integrated into any blog with the minimum of fuss. It lets readers propose topics for the blogger to write about, and it lets other readers vote on these ideas.

At first glance, you might think "so what - topics are often suggested in post comments anyway?" This is true. However the typically blogging set-up  reinforces an author-reader divide,. The blogger gets the big headline and large type-face text, the readers get the little comments tucked away.  The use of something like Skribit helps break down the barrier and brings the blogger's desire for interaction front-and-centre. And of course the blog author can always 'fly a kite' or two - proposing their own topics and watching how the voting goes.

Currently, the widget is implemented as an IFrame, and as you can see with the sample to the right, the styling it allows is a little rough-and ready. Its Javascript is also rather on the chunky side, which can slow page loading.  However some changes are in the works, first there is a new, lightweight version of the widget in development, which allows it to be styled using a blog's own CSS. Secondly there are moves afoot to try and put a business model for Skribit in place.

 Skribit doesn't look like a company yet, it hasn't apparently taken any VC financing and comprises three people: Student-founder Paul Stamatiou, developer-founder Calvin Yu and Lance Weatherby who is "Venture Catalyst" at Georgia Tech. and who appears to have a mentoring role.

However, it will start beta-testing a Pro version of the tool next month, according to a posting on the Get Satisfaction support site. The team has even started canavassing opinion as to what features should appear in the paid-for version. So far, support for multiple blogs, suggestion moderation, analytics and increased customisation all appear to be likely candidates.  That's good news since a decent revenue stream will increase the chances of a secure future for the the basic, free version.