Outsource your features!

A new trend is rising: applications which are not designed to fulfill some user’s needs but, rather, to provide some service to other web apps.

Until some time ago, if you were to design your own web app, you had to write the same code, with little to none variations, to deal with pretty common issues (i.e. login, user profiles, messaging and so on) every time. You had no choice but to reinvent the wheel each time. Over and over.

Now you have one more possibility: delegate your recurring, non-core (albeit relevant) functionalities to third party web applications, which are built to integrate easily with your own one.

This leaves you with a lot more time to focus on your core features, maximizing your effort. Think of it as code reuse, for web apps.

I’m writing this post a few hours after adding support for user avatar images on Novlet, and I’m still surprised about how painless the process turned out to be.

Although I consider avatars a great addition to most account-enabled applications, we chose not to support them at the beginning because we considered them not to be that relevant for a web app centered upon creative writing. At least, not relevant enough with respect to the effort they required.

So, what made me change my mind?

The answer is, in just one word, Gravatar.

In short, Gravatar allows users to associate email addresses with avatar images, and allows application developers to access that images using the email address users registered with. Users have to set up their images just once, and any gravatar-enabled application will transparently use them.

Stop. Gravatar does just this. But it does it well: it took me a ridiculously small number of lines of code to set everything up, and it works like charm. (You should see the new avatars on Novlet.com when we finish polishing the details. )

Another example: BitLet’s feedback forum.

Originally, we used to gather feedback and suggestions from our users through email or via the blog. But the forum we created with UserVoice allows us to collect suggestions and manage them in an orderly and efficent way, and it took us just a few clicks to set it up.

Now you should understand why Bitlet’s blog is created with Blogger. And that’s why we plan to leverage Google Account Authentication and, eventually, all OpenID providers for our upcoming Secret Project™.

It’s a trade which benefits both users and developers: why not to take advantage from that?

In one of my previous posts I wrote about the potential of Facebook as an application platform. But with a family of interoperable and pluggable application services (or service applications ) which can be used as building blocks for our web apps, the Internet itself can become an even more powerful, open, platform, pushing the concept of mashup to a new frontier.

Web application platforms?

The everyday life of the average Internet citizen is filled with dozens of impressive web applications, which help to perform any sort of task.
Ranging from planning your next trip to Holland to sharing the photos of the last party you had, a lot of activities can be effectively made easier or more efficient by using some brilliant web site.

Although it’s becoming increasingly hard to find something you can’t do from within your browser, there are still some activities which won’t probably deserve their own shiny web app, being relevant just to a tiny niche of users.

But, think a few seconds about that: the concept of the “long tail“, often cited as one of the key points of Web 2.0 (whatever it means), is all about niches. In particular, even if the big players are fighting to satisfy the most popular needs for the vast majority of users, there may still be enough room for anyone else to deliver solutions to the needs of the niches (i.e. the “tail”).
And the good news is that it might be a sound strategy, too.

Get to the niches

Quoting Wikipedia, from their page about the long tail,

Where inventory storage and distribution costs are insignificant, it becomes economically viable to sell relatively unpopular products; however, when storage and distribution costs are high, only the most popular products can be sold.

The same principle can be generalized to web application development, as well.

Suppose we are about do create a web application which addresses a simple, non-essential, need: probably we are not aiming to the mass market, and maybe we are focusing on something that is relevant to a small amount of users, or for a limited duration (just the timeframe in which they need your app).

If we are able to focus on the core of your application, without having to deal with the burden of non-essential aspects, then it becomes viable to develop new services that will be useful for relatively smaller sets of users.

Now, there are several ways to handle this point. Most of them are technical, such as choosing a specific platform/technology/framework, while some others are merely economical (unless you’re creating something just for the fun of it). All of them are well documented and widely discussed.

But I’m afraid we might still be missing one, fundamental, point.

It’s not all about costs

Even if we manage to complete our project successfully, we still have a major barrier to cross: a new web site to use can be a significant complication to some users. It means, at least, a new web address to keep in mind (or in the bookmarks), and a new set of credentials to remember.

There is, always, a small resistance we have to win in order to make users adopt a new application. A resistance that is more relevant if we are addressing a non-essential need for a niche target.

In order to win that resistance, the first option we have is to build an outstanding web app, so that users will be so willing to use it that they will easily overcome that barrier. There is another possibility, though.

Consider this. Facebook offers us the possibility to leverage their entire user database (over 100 million users, November 2008), and, most of all, a window which stays open all day long on the browsers of a lot of people, to which we can post notifications.

In addition, as you will certainly have noted, the resistance of users towards adding new Facebook applications is significantly lower than the resistance towards new web applications. Outrageously lower.

After all, they already have registered.

Many web applications that would never make it as stand-alone web sites, might earn their place as Facebook applications. (Or, maybe, LinkedIn applications, or Google App Engine applications, or something else).

Then, that said, why do we continuously get bugged with dozens of invitations from pointless quizzes and useless tests on Facebook? Why there are so few useful applications on Facebook? It may just be the sign of some huge potential that lies unfulfilled.