HTML5 offline cache - use swapCache carefully

HTML5 Offline caching is an incredibly useful feature that allows your users to load your website even when they are not connected to the Internet. When they visit your website first, the browser checks if your webpage mentions a cache manifest file in its html tag. If so, the browser downloads the manifest file and then downloads all the resources mentioned in that file. You are supposed to add all the resources that your webpage needs in the manifest file, so that when user is offline the browser can load the webpage from the cached version of those resources. You will find many articles that will help you implement offline caching for your website- like this one. This post isn't about it.

If you are using offline caching, you may want to use advanced features like handling the events that are fired when the browser is updating the cache. If you frequently change your webapp, this is a good idea. I handle these events in 3DTin to let the user know that the browser has found a newer version of the app on server and is now downloading it in background. When the download is complete, I show the user a refresh button which they can use to reload the page so that they can start using the new version.

It was while coding this functionality that I came across the swapCache() API call. It sounded very cool and from some examples that I read I got to believe that when the cache download is finished (i.e. in the onupdateready handler), I can simply call swapCache() and user will start using the new version of my app. He/she won't have to reload the page. If you don't read the documentation of swapCache carefully you will get the same impression from simple examples around the net. It may not be a big issue, if your cache contains passive resources like image files. But my erroneous interpretation of swapCache led to a nasty bug in 3DTin few days ago, because I am caching javascript files too.

The documentation clearly says:

[swapCache] does not cause previously-loaded resources to be reloaded; for example, images do not suddenly get reloaded and style sheets and scripts do not get reparsed or reevaluated. The only change is that subsequent requests for cached resources will obtain the newer copies.

This has huge impact if you are loading javascript or css files from cache. In my case, I use WebWorkers which load a separate javascript file after they are started. When 3DTin cache was updated by the browser and swapCache was called, the javascript file that WebWorker used to load was at a different version than all the other files that were loaded when webpage was opened. This led to failures that left me scratching my head for some time. Eventually when I realized this is what was happeneing, I stopped calling swapCache() and instead showed user a button to reload the app manually.

I hope this post will save you from doing the same mistake that I did.

How Wikipedia and Flattr can together change the World

Wikipedia is one of the best things that could have happened to humanity. That's why it feels awkward to see Wikipedia beg for funds every year, due to their decision to not generate revenue via advertisements. A debate between whether contextual ads are better or worse than page wide banners of Jimmy Wales can go to any length, without result. On the other hand, there is however a middle ground. Why doesn't Wikipedia accept micropayments?

Flattr is a micropayment service, that launched last year. If you have a blog, photo gallery or any "Thing" that has its webpage, you can place a Flattr button on it. Visitors of your page will click on that button, like they drop a dime in a tip jar. This action - called flattring - will gain you some monetary compensation. The way it works is, your visitor has a Flattr account that he/she fills with some money each month. During that month while browsing the web they encounter the Flattr buttons on various sites (like yours). They click on those buttons if they like what they see. At the end of the month Flattr divides their monthly payment by the number of Flattr-clicks they did in that month and pays that amount to the owners of those webpages.

Although Flattr has a very compelling solution for micropayments, I have seen some problems with the model from my own experience. The biggest problem is that, your visitor has to have a Flattr account. Whenever I come across a flattr button while browsing, I wish I had a flattr account so that I could tip this guy. But creating a Flattr account costs at least €2. It is very small amount, but it's not as attractive as €0 (to see how big that difference is, read some books on behavioral economics listed at the end) and it's a monthly expense. It doesn't help that I do not see Flattr buttons all that often while browsing. If I were to see them as frequently as Facebook Like buttons, I would definitely go register with Flattr. In my opinion, this is going to be the biggest hurdle in adoption of Flattr or similar micropayment solutions.

My guess is, the people who register a Flattr account are the ones who also have a creative "Thing" on which they want to place the Flattr button. Take my example. I had Flattr account since it was invite-only, but I never saw any point activating it by putting money into it. I hardly come across 2-4 pages each month that have Flattr button. Only yesterday when it struck me that I can put a Flattr button on 3DTin, did I take the pain of adding 3 euros and activating my Flattr account. So it seems that content creators have a reason to register with Flattr. But they are the minority in the population of the internet. The majority of netizens are consumers. Unless the consumers adopt micropayment, the creators cannot hope to make meaningful living out of Flattr like schemes.

Now imagine: What if Wikipedia places a Flattr button on each wikipedia page?

I read at least 5 Wikipedia articles every day, I am sure if you are reading this post, you have similar appetite for Wikipedia. When we read those articles we thank that Wikipedia exists. But most of us didn't pay $25 when Jimmy Wales asks for it once a year. We get the benefit of wikipedia in micro packets everyday, so when it comes to compare the its benefit with a big monetary sum, we tend to value money more. Therefore micro payments is the ideal model for us to express our gratutide to wikipedia.

If wikipedia adopts Flattr as their micropayment solution, overnight tons of people will open a Flattr account. And that is the exact impetus a service like Flattr needs to get over the critical mass. Once that limit is crossed, Flattr will be everywhere and will become a standard for micropayments. Then every content creator will be able to put Flattr button on their page with a confidence that their visitors will very likely be Flattr users too.

Wikipedia is in a unique position to bring a revolution in online payment. Any micropayment solution they choose will become a standard for the web and it will benefit Wikipedia too, without allowing advertisements on their pages.

So what's stopping this from happening?