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.