People seem to be very excited about the Realtime web at the moment, and all the opportunities that exist. However, for all the potential, everyone seems to be thinking of the same old examples of usage.

What it doesn't have to be

The real time web is not about adding chat on your website. It's not really about having stock tickers. It isn't about providing a page where people can continuously see something happening in real time. It isn't really about little multiplayer games. At least, it doesn't have to be.

Many of the examples of people using the RTW, tend to show these gimmicky, forgettable applications which make people say "ooh that's cool" but don't really provide much stickiness to make someone use your site more.

The mundane but immediate web

People seem to overlook the really exciting part of RTW, by thinking about pure realtime scenarios. However this requires that people start using their web-browsers in completely different ways. They need to stay on a page, patiently waiting for new information to occur.

I believe the most interesting aspect of the realtime web is to be found in augmenting the web that we already know. We can add realtime functionally to our applications as another layer of fidelity.

The web is like an onion (and not because IE makes you cry)

Jeremy Keith was the first person who I heard talking about websites as being layered: we have the raw data, in the form of HTML; on top of this we add design, for which we use CSS; on top of this we add behaviour, to change the design and allow people to interact more smoothly. Each of these consecutively improve the experience for the user of your application.

You are not alone

The RTW can be seen as another layer, which improves the experience of an individual, by linking their experience with everyone else on the site. If I know what other people are doing with an app, it affects the way I might use it.

It is about letting people know that they are not alone in using a service, and making their lives easier in the process.

If I am collaborating on a document, and I see my colleague is engaged in a flurry of activity, I may wait a while for him to finish.

Interruption

We can make the RTW about interrupting users while they go about their normal flow, and stop them wasting their time.

If I am shopping for theatre tickets, and halfway through the checkout process someone buys my seats, I want to be told now, not after failing at the end of the process.

In this example, current systems for booking tickets generally have to jump through hoops to stop these situations occurring. With a sprinkle of RTW, it is not necessary.

A more traditional store might have only certain numbers of a given item of stock, and the same kind of model could be used to avoid frustrating users.

Incremental improvement of our existing and glorious web

The important thing is in providing incremental improvements to the experience. Not trying to make people use services in a completely different way, but rather adding a little bit more convenience for them.

Setting up socket servers etc is a bit of a pain, and people have a tendency not to do so for the incremental improvements. The annoyingness of the process leads people towards an all or nothing approach. If they use RTW, they often use too much of it; if they need a little bit, they usually get by without it.

This is why we created Pusher. We primarily wanted to have a central push system that all our own apps could use. However, it seems like it may be pretty useful to others too, so we are now opening it up to a public beta. Please have a play around and let us know what you think!