When you start working on a website or application, what is your goal? In the current state of the web, there are many ways you can carry your user but, in the end, you must choose web inclusive or web exclusive. Sites with rich APIs which interact with the world around them are web inclusive. Sites which focus internally, drawing little content from the outside web and, ultimately, giving nothing back are web exclusive.
The web is moving away from exclusivity. When the web started, documents were shared, whole, and people had to visit a particular site to view their content. It rarely came to you, typically requiring you went to it. This was the face of the web in the 1990’s. Autonomous operating sites maintained individually for the sake of the content maintained within.
The modern web, as I discussed last week, is constructed with a blend of autonomous content and content-objects from across the web. This kind of shared content structure is a natural development beginning with sites maintained as interfaces interacting with content sources like databases.
By creating an exclusive web application you gain certain benefits. You control your environment. You get to set the rules and everyone who uses your system must obey. You maintain the images. You store the copy. You define the network. Everything you do lives within the ecosystem you create.
For as good as it sounds to have supreme power over a web ecosystem, there are drawbacks. You are solely responsible for maintaining the system. When things break, it is your job to fix them. When enhancements are made, you are the one on the hook to build them. The onerous is on you and you alone.
There is another issue that comes with maintaining a partially or fully closed ecosystem. You can lose trust. People get wise when others start watching everything they are doing. This kind of realization hurts companies. Facebook appears to be suffering from just this kind of loss of trust right now. As they get more aggressive with sharing user data, they lose user trust. Since Facebook is a closed ecosystem, an exclusive web application, and users are aware they are being watched, trust in the system wanes.
Inclusive web applications, on the other hand, lend a feeling of freedom and sharing due to the transparent sharing of information across the wire. The inclusive web draws information in from APIs and RSS feeds across the web. Just as information flows in, the local API allows information back out again.
When the inclusive web also allows people to manage their own privacy, users feel more secure. They know they can collect the information they want and share it with whomever they like without feeling the burden of filtering or censoring their preferences in order to please people they neither know nor are aware even exist.
The benefit you gain from running an inclusive web application is the ease of production. You maintain the code base for a hub and your unique function while allowing other services to manage the content they specialize in. This community development process leads to many different groups acting in a specialized way and supporting a subset of the total code that builds the end user experience.
For the gains available in the inclusive web, there are pitfalls as well. Privacy management becomes a more complicated task for the user. Instead of managing the privacy controls at a single dashboard, they are required to manage their privacy as it applies to each system they touch. This can become a burden if a user suddenly decides to overhaul the privacy settings across their personal social ecosystem.
Another concern to weigh against is control. The more inclusive your application is the less control you have over the experience your user has when they interact with the ecosystem in its entirety. Within the scope of your application, users can, and should, have a consistent experience.
All APIs, however, are not made equal, so preparing and presenting an interface for your user does not mean you will be able to give them the same rich experience they would have when interacting with the primary service. On the other hand, this may be preferable as you can offer a subset of functions which relate directly to your service without directly mirroring the function of the service you are interacting with.
With these control issues in mind it is likely still a greater benefit to be inclusive rather than exclusive. Through acting in an open, inclusive way your site becomes a boon to the user, enhancing their experience and making the web a friendlier place to be.
In the end, however, the inclusive web is where users truly live. No user interacts solely with any specific web application forsaking all others. They look to constantly enhance their experience on the web through richer interactions. These interactions, however, are not just with a machine. They are interactions with people. People don’t all live in once place.
Instead of trying to fight the inevitable rise of the inclusive web as an expectation of the user, embrace it. Think about the sites and services your users prefer. Engage your users with new ways of acting with and upon the web around them. Provide your users an open, inclusive experience. Make the web a better place.