Monday, October 26, 2009

Content Maganement with the Delegated Features as Services

As a friend of mine pointed out:  there used to be a server and many terminals, currently we have a bit more sophisticated terminals - PCs - and our big server is the Internet, where the apps are "on the cloud". Nice analogy, and for me it makes a lot of sense. Are we really coming back to the terminal-server age but in a more advanced, i.e. distributed version?

Anyway I think that every feature in a Web application should be a service. Not a service in a sense of a mashup or SOA, but in a bit different sense.

Let's take a simple example - Drupal. It's a content management system. The power of it is that it's extensible with new modules that are normally contributed by the community. These modules implement different features, such as rate the content, comment, spam filter. One of the nice ones that I really like is made by the Drupal inventor Dries Buytaert, called Mollom. In fact it's a gluing module for the Mollom service, the service does spam filtering for your site. Specifically, when a person presses the "Save" button, the post first travels to the Mollom service, and then is checked if it's spam, in case it looks suspicious the user has to fill in a CAPTCHA in order to save the post.

Now consider that all the modules in Drupal had the Mollom nature. That is the module would just be the glue for the service which lives somewhere on the cloud.

A simple content driven site based on Drupal could be quite easily implemented with what's available out there. Consider a site for video sharing, kind of YouTube but maybe not so generic. At the core is Node - the most primitive content type made of title and body. And now let's add features as services:

  • Comment the node - Disquss.

  • Control the spam - Mollom.

  • Let users send the feedback about your video sharing service - Zendesk.

  • Rate the content - Outbrain.

  • Share the content - AddThis.

  • Video upload and related features - Kaltura.

What else? Well there is one more piece that I think is very important:

  • Social graph management. There are many services available out there starting with Facebook and finishing with QQ. These services expose APIs so there are also gluing modules for Drupal available. There is one caveat with social graph management. What features one wants to map, is it only friending or also status updates, picture sharing, etc. The purest approach would probably be to have a gluing module in Drupal that only uses authentication and friending features of the social service.

All in all, I strongly believe that paying for a feature as a service is better than paying for (re)implementing and maintenance of that feature. So it's like SaaS but on a feature level, not the whole application (feature set).

Friday, October 9, 2009

Audiobooks Social Network

I like books.  Recently I got attracted by audiobooks. This looks like cheating a bit, because it's not pure reading, however, I must say it's far from cheating. Listening requires (at least for me) even more attention than reading.

Anyway, I am now keen on audiobooks, and as it usually happens, my experience with the Web comes into play. So I started thinking whether it is a valid idea to build a social site fully dedicated to audiobooks - or more generally reading text aloud and listening to recordings.

Let me analyze the idea of this social site in several axes.

Social object

Clearly the social object would be a piece of read aloud material. For simplicity we can think of a chapter of a book. When all the chapters are available the whole audiobook is there. Interestingly, an audiobook can be assembled into one even if each chapter is read by different people.

Social activities

We've got chapters of audiobooks as downloadable files on the site. There will be two kinds of people visiting the site: those who submit their readings to the site and those who will want to download audiobooks. Besides all the usual features like sharing, bookmarking, chatting, reviewing, flagging, rating etc. audiobookers will need some special tools and features, such as: audioconferencing for real time multicharacter recordings, a friendly avatar that impersonates the reader, rankings of the best (popular) readers, transcription of audio into text for search engine optimization, and so on.


Software-wise everything looks solvable. It's just a Web site maybe with AIR desktop applications for reading aloud, saving, organizing, listening, etc. to books. The greatest challenge is how to ensure that the reader is reading the book the way it was written. And then, how to ensure that the readers will correctly name the pieces they read so that they (semi-)automatically could become one audiobook. Probably this is only achievable by croudsourcing and social filtering.

Business case

All the materials on the site should be available for free because it's community generated content. Still there are plenty of opportunities for paid services. For instance:

  • assemble audiobooks out of separate chapters for those who don't have time to do that by themselves;

  • sell professionally read audiobooks; allow the readers selling their recordings and take a percentage from each transaction;

  • provide additional tools for readers to promote themselves and get statistics;

  • organize paid events where book authors read aloud a chapter or two of their books;

  • use the audiobooking infrastructure for voice recordings management system as a service;

  • etc.