Content Blocking is How the Internet is Meant To Be

Content Blocking killed the ad supported business model and even though it gets some companies in trouble. It will spur innovation and business model reinvention for content publishers. If your visitors can block whatever they want (or better phrased: whatever they don’t want), what is the thing you have to offer that is worth their time and money. Hint: it is not just better content.

Content Blocking was released in iOS9 and was presented by Apple as the following:

Use the Content Blocking extension point to give Safari a block list describing the content that you want to block while your users are browsing the web.

Which means that you can install an application on your iOS device which will block certain content in any webpage in Safari. Content only will be blocked in Safari not in other web windows that appear in other apps.

To make things clear before moving ahead:

What Content Blocking is Not

Content blocking is not new. There was a long list of ad blocking extensions available which let you block ads in your browser on your desktop. There are extensions such as Ghostery that allow you to be very specific in what you or what you don’t block. Also you could install a specific profile on your iOS device or setup a specific DNS or VPN connection to filter out content from sources you don’t like. It always has been there, the big change is that it moved out the nerd section (profiles, DNS, VPN, proxies or extensions) and got easy with just installing an app.

Second of all content blocking is not stealing. It is not taking money away from people whose content you read. It is deciding not to download certain elements on pages of publishers on your device. Office proxy servers often block already such elements (ads, tracking or platforms as a whole such as Facebook). The publisher is free to force you to have everything downloaded before reading, though you are free to not do so (and also to not consume the content).

Why this is what the Internet needed

Content blocking is what the Internet needed first of all since page size is increasing each year in almost exponential fashion. At the same time traffic is moving more and more to mobile and even though our bandwidth in general increases, it doesn’t always catch up and therefore load times increase.  Big pages consume more battery on your mobile device, big pages cannot be loaded in some cases and if you are on a bandwidth limited mobile plan you burn through your data quickly.

A content blocker makes sure that the page is being downloaded significantly faster on your mobile device. which is the key feature for me. It is not about blocking content per se, it is about speeding up the loading times and making sure content gets there faster. In this lengthy review of Ben Brooks you can see that pages are being loaded up to almost 62% faster. In this review about Crystal (one of the content blockers for iOS) on betanews it shows that bandwidth savings can be over 50% depending on the websites you are visiting. Also some of the blockers just keep you sane and block everything about the Kardashians.

Publishers should leverage Content Blockers

These numbers are not just in the interest of the user. It should be in the interest of the publisher as well. Page abandonment increase linearily in the first 4 seconds of a page visit. Which means that the longer somebody has to wait the more likely he or she drops of. After 4 seconds of waiting 25% of the people left. When shopping 40% of the people leave a website that takes more than 3 seconds to load. Why as a publisher wouldn’t you be supporting content blockers at all since it could increase your direct conversion.

Source: Kissmetrics

Source: Kissmetrics

If people prefer to use a content blocker to speed things up or to block ads you could say they are wrong. However if many people are telling you they have a problem that your platform is to slow and solved the poor experience by content blocking and you decide to ignore this, you are either stubborn or visionary. I would say most likely the first though the long term will learn me if it is the second.

Your issue is distribution, not destination

During one of the many meetings with smart people I had last year one of them drafted the issue most organisations have to be one of distribution not destination around content. Content Blocking provides a solution for distribution (getting things faster on your own terms). There are several ways to tackle this issue, especially going outside the bounds of your original destination. For example companies such as the Washington Post are using Facebook Instant articles and Wired chooses to have some exclusivity with Apple News. The companies are publishing on a platform they don’t own, but deliver maximal distribution and a very smooth and integrated content delivery integrated in the platforms.

If in the end it is wise to publish on platforms you don’t own is a whole other question. Though mixing the content across platform could be a very effective way of getting your content in front of the right audiences without having to worry about Content Blockers.  Since those won’t work in Facebook’s native application or in the Apple News app. However which content is served (such as ads or trackers) next to the content of the article is not the ultimate decision of the publisher, it is done by the platform owner.

Solve distribution, don’t block the blockers

Content blocking is something that is still relatively small now, though it is a clear signal from users that there is a demand. If users have an easy way to turn of ads and trackers and speed up the page they will do it and in some cases they are even willing to pay for an app that help them to do so. Even if they don’t pay, they are willing to go to the process of downloading an additional app to improve their overall experience. For publishers this is an important lesson to learn: it is not just about creating high quality content that people are willing to consume and / or pay for. It is about the whole experience around the content as well. If users are now optimising their own experience, it means that as a publisher you are not trying hard enough for your users.

On the long run, good content won’t be enough. A seamless, fast and non intrusive content experience will become the norm either facilitated by third party solution such as content blockers, third party platforms such as Facebook Instant Articles and Apple News or by publishers themselves after they have cleaned up their platforms and make things less bloated and privacy invasive. The content experience will improve nevertheless since the bar has been raised and content blockers have shown how great the experience can be, it is up to the publishers to accept this new reality and either be actively part of it to make the change happen or to see how they are being changed from the outside (or bypassed…).

Responsive Design: There is More in Life than just Screen Size to Respond to

What we learn often with Responsive Web Design that it is all about the view port. However that is just one of the many contexts to respond to. Of course we need to make sure that content is fitting the window you use to view. Though there is more in life than the piece of glass you are looking through to view the web, the app or any other media you are viewing. For the sake of simplicity let’s focus on the Web in general for the rest of this article and let me provide with an overview of contexts you could be taking into account when building your solution.

Know the screen

responsive-design-heroYou should make sure your website is viewable in a proper way on devices. So don’t make people zoom in and zoom out, set appropriate break points and scale content to the appropriate site and reorder the elements on the page where necessary. Furthermore there is more than page size to worry about. With the rise of retina screens you should take into account the pixel ratio as well. Since if you don’t you might end up with graphics that give an unintended 8-bit experience.

Know the source

It is delusion to think that everybody goes to your website directly as it is their only goal. Most likely people will go elsewhere first and then find a way to your website. However “elsewhere” is an important guidance on what people want to do. If people come to your website via a career focused website most likely they are looking for a job, why not personalise you site on the fly to showcase career focused elements instead of your latest and greatest white paper.

Also do you know if the visitors is coming via one of your others channels to your website? If so, why even think to reset the user journey, continue the user journey from your other channel. Your user is not thinking about you as a collection of channels, he is seeing one logo and expects one experience.

Is this the first time your visitor is coming to you, or the second, third or twentieth time? Use this data to modify your site to your visitors needs. A good example is this plugin available for WordPress.

Know the connection

Serving retina images on a GPRS connection might not be the best use of time and bandwidth. Though your retina screen is great, if you don’t have the bandwidth to feed it, why even bother trying. First and foremost it is about serving the content request in a minimal acceptable way. Anticipate the bandwidth of the receiver is a good way to make sure people will really visit your webpage and don’t drop off after a few seconds.

8636543831_e54b299c0a_oThe special case is of course the case of no connection (it is rare though it happens still), can you give people an offline reading experience after they visited your website for the first time? Your offline experience should be better than the standard no connection available message of the browser. Please keep in mind that if your site cannot be reached, people will blame it on you, since the rest of the items on their device is still working.

Know the activity

A simple way to validate what people are doing at the moment is to check where they are coming from. Not only a geographic basis, but also on a hostname and network basis. This information will often disclose if they are at an office, a public space, at home or anywhere else. Based on this context you can give them an appropriate call to action or present content in a different way. For example somebody who is from the competition and he is visiting your careers section during work hours on its company network could be offered with a less aggressive page so he can still browse around and apply while his colleagues might be thinking he is doing competitive research.

Combining this data with time of day you should be able to determine if a prospect is doing research from his desk during work hours, or still late at night at home. The latter could give you the impression that urgency is high and therefore a conversion is more likely than normal.


We even didn’t not touch on the topic of sensors, since it now easier than ever to ask somebody’s location and customise the display based on this information. And if you know somebody’s location you can also determine if somebody is moving or not, on what speed somebody he is moving and also have a best guess on what mode of transport he is using during his move from A to B. This is something you can use to customise the experience since if you have the best guess that somebody is on a train (based on high-speed and the current location) you might want to consider giving him a lower bandwidth version of your website to make sure it still loads, since reception and wi-fi are often pretty poor in trains.

Know your visitor

All the previous items were really passive data collection from a user perspective. The user didn’t had to take any action to get a more responsive web experience. However why remain passive. You could ask a user to login to personalise a website. Why couldn’t you be using this authorisation to go further than just the interests of a user. Imagine you could integrate with somebody’s calendar and adjust the content based on the calendar of your user. If you notice he has a steering committee the next morning on topic X and the individual is doing research on your website, why not offer him topic X prominently. Use the data that the user is willing to provide you to create a better context and respond better to his needs.

Know the device

IMG_0723If most visitors are using an iPhone to visit your website, why not give them a more native look and feel. They are used to do it in apps, so why not extend it to your website. Also validate how they are accessing your website, are they using Safari directly or are they using an in-app version of Safari? For example if you discover that your users are using the in app Safari version of the LinkedIn App, why not remove your sharing buttons on your website. The LinkedIn in app Safari browser offers sharing buttons already and having people to click on a sharing button would most likely break their flow / user journey and take them outside the eco system they would like to be part of.

Know when you can do better

There is no such thing as “the best” channel. There is the best way to do things for somebody at a certain time in a certain context. So why not offer people a better experience when you can and when you know it will be ten times better. The challenge is on how to make this channel switch a part of the user journey without breaking it and making people leave.

If you know your check out experience is better in your app than on your mobile website. Direct people to the app, explain them they can keep a credit card on file in the app and maybe lure them there with a small discount. Especially when you know that people having the app installed will buy more frequently than people using the mobile site. It is always worth paying the acquisition fee on a short notice to benefit on the long run.

You know

All the topics I touched upon in the above article are not new and not even close to rocket science. You could be starting to do this right now. All the data is available publicly for each of the topics I have listed examples. So why only respond on screen-size, respond on context, make things personal, not just from a content angle though for a complete experience point of view.

Your Users Hate Your Navigation

Navigation is a skill that involves the determination of position and direction. However as easy the navigation in your car might be to determine your position and your direction, as difficult is the navigation on most websites.

Those navigations are just space wasters on websites, they don’t have a real function, or better phrased: they have a function, but they are simply ignored by its users. That is of course not a mistake of the user, they have just found a better way to navigate your site than clicking through endless drop down menus, navigating mega menus or filling out forms to get somewhere they don’t know if they want to be there.

You could even consider that having the need for a navigation on your site shows something is already broken and the navigation is just trying to fix it.

Will it be good?

That question is exactly the issue that many navigations do not answer. The navigation could bring people from a point A (where they are) to an uncertain point B (something that could be their destination). As long as point B is an uncertain destination for your visitors, they will try to find a different route that gives them a higher level of certainty. There is nothing worst than getting lost or ending up somewhere you don’t want to be.

It is not about getting somewhere, it never was

Don’t think that the main purpose of your visitor to navigate as many pages as they can on your website. Do not think it is about visiting as little pages as possible. It is not about navigating at all. It is about task completion: to let people do something they want to do. It is about removing the uncertainty whether or not they can get to their task completion as quickly as possible. Not by showing a vague direction, but by showing the clear path to their goal.

Here comes the user journey

What is the purpose of your navigation? It is not about getting people from A to B, it is about helping the visitor to complete his journey. The visitor has a certain goal (“I would like to know more about X”). He has a starting point of his journey (let’s assume you are so well-known that he directly goes to your homepage, which is unlikely for most brands though) and you have a certain goal as well (“I want to have the contact details of this individual to make a sale in the end”). These three items combined form a very simplified user journey.

If you start thinking in a different way about your website and focus more on user journeys. You’ll notice that there is not a single entrance point (again: your analytics would have told you so already), which means that having a single one-size-fits-all navigation might fail you instantly. Since if the journey starts on the homepage you might need a different navigation than when the journey starts directly at the relevant page (since the user got there through Google). On the latter your might even want to consider to not display any navigation to prevent any distraction for the user.

So kill your navigation now

Seriously, don’t start killing your navigation right now. Start analysing the impact of your navigation right now. Then you will know if you have to ditch your current navigation on your website. Learn from the data what the existing user journeys look like and how you can modify your navigation, or even your website as a whole, to create a better experience throughout the user journey.

The navigation is just something that you might need to provide to help in  determination of position and direction during the user journey. It is not a mandatory item for your website all the time, since a user has not  a burning desire to be navigating all the time. Most often he just want to have task-completion.

60% of the visitors of your Website are not human, now what?

Humans account for less than 40% of all web traffic. Which means that there are more robot ‘eyes’ watching your website than humans are browsing it, clicking it and touching the web interface you have created.

Why bother about robots and semantic markup?

Practical example: if Google (or any other search engine) cannot read your website correctly it won’t be able to display it in its search results. When Facebook cannot find the correct image to show next to your link on Facebook it will just take the first alternative it can find.

So if you want to be 100% sure how things are being displayed (or are displayed at all), make sure to use the correct (semantic) mark up.

You got visual

Of course you are surfing the trend of the visual web and you are making sure your website is an absolute visual tastemaker. You are working your h1 tags for SEO, however what about the rest of your markup? Have you considered that the average non human visitor on your website won’t notice that something is an address because of the lack of semantic markup? The bot might see the term ‘address’ caught within h2 tags, though it doesn’t know what in the next couple of lines is the address. So how do you make sure your non-human visitors will find the address you want them to find.

Don’t start worrying now, you don’t have choose between your nice visual style and semantic markup. It is about how you can use semantic markup together with your visual style to give your web page the right structure for robots to understand.

Pick your semantic markup

To right type of semantic depends on the robots visiting your site. So besides your human audiences, which of your robot audiences do you like to serve, since there are many different types of self-proclaimed standards (, microformats, opencyc etc) for in page optimisation of semantic mark up.

Besides that there are also some channel specific markup for the non human visitors from a specific channel such as Facebook (for its so-called open graph) and Twitter (for Twitter Cards) is the one that is supported by Google, Microsoft, Yahoo! and Yandex, which could therefore be your semantic mark up basis of choice if you mainly target search engines and want to use their unique functionalities to display and list certain content.

The big benefit doing it right

If you do your semantics right you are not only controlling how your website is being displayed in general, but also how and what is displayed by other services that use a robot to visit your site and digest your content.

Create a Zen of Flow

I have removed almost everything from my site, my wife warned me that I would end up with a plain text file if I would push it any further. Maybe that is even a better idea: no distraction. Though I would miss the structure that font-sizes are offering in headers. The reason for removing almost everything is because every click is a distraction. Scrolling doesn’t interfere with what you are doing, a click is deliberate friction, it is a moment for somebody to get distracted.

Driven to distraction

Even though we assume we are great multi-taskers: we aren’t. We cannot read one thing and at the same time process something else with our brains. We can do only one thing well, therefore I removed everything that was distraction so you only can do one thing: reading the article. I don’t need you to read something about me, see the latest articles or start with sharing before you finished the article. To be honest, I don’t want you to do anything else than just reading the article an experience the serenity of scrolling instead of the aggression of clicks.

Each click is a dilemma, scroll is flow

A click is  deliberate action and therefore a distraction. At the moment you are on the page, you have to move your cursor on top of the link and press or tap a button. It is breaking your flow, since it forces you to do many things which creates this single dilemma: will I continue reading the article, will I go somewhere else, shall I preload something else for later reading, or will go and play Angry Birds. With scrolling there is none of this friction. Basically you are reading the article and to keep reading you have to move your screen, just like you need to turn a page. You don’t decide if you want to do the action, you decide if you want to read on. The decision you have to make is more subconscious than clicking to go somewhere else.

Flow through content

So flow through content and remove any clicks. The easier you can make the consumption of the content, the more it will be consumed.

Remove the aggression of clicks and introduce the Zen of Flow.

API, why, how and where is the money

API is short for Application Programming Interface, it is a way to communicate with something without having to use the website or tool of the specific service. Often is about the exchange and manipulation of data (such as  most apps for twitter on iOS and Android use the Twitter API). Basically APIs are (becoming) the Ducttape of the Web and a vital part for its success.

There are many reasons for people to start with an API some of these are more business related and some of these are more technology related . Business related drivers to start with an API:

  • Increase Brand awareness
  • Allow people to use their own data
  • Build goodwill with developers (starting a community)

Technology related drivers to start with an API:

  • Solve programming problems with an API in mind can improve code quality
  • Simplify internal reuse of data
  • Allow others to extend the functionality of your application
  • Allow alternate input mechanisms
  • Unanticipated applications of your data
  • Turn your service into a platform.

Things to keep in mind while maintaining an API

From a technology perspective there are several approaches on can choose to move forward with an API. However one of the most important things is that when an API is released the API is used by the service provider themselves internally (drink your own champagne) to make sure that the platform and your solutions keep in sync with regards to functionality. Also don’t change the API in a way that it breaks, which means that people who build on your API all of a sudden have solutions that don’t work anymore. Versioning therefore is very important.

Also important is to build for scalability, to keep an on eye on the metrics for the API (how often is it used, which methods are used most often, what is the fail rate, is there any peak usage), to keep in touch with the development community and to take part actively in this community. Also be conscious about paying or not paying developers for the work they do building on your API. Most often it is better to not pay the developers since they will build things out of passion and if somebody is building something on your API for free then you know your API is useful. Also consider an API never as finished and since you are working with developers on your API be sure to include or experiment with the latest developments since this audience expects you to do so.

For building an API there are four stages that impact the time to integration:

  • Vanilla API: starting point of every API with just the functionality, not necessarily specifically written for a certain programming language (often SOAP or REST APIs).
  • API wrapper: Wrapper in a specific language (ruby, PHP, .Net, C#) around your API so people can start using it in their favorite development language without having to write the complete wrapper by themselves. (Improves time to integration with around 50%)
  • Documentation: documentation next to the Vanilla API and the API wrapper will decrease the time to integration even further especially when the documentation has several examples which can be reused. (Improves time to integration with around 20%)
  • Share kit: an easy way to share certain functionality from the API often on a copy-paste basis (such as the embed functionality that YouTube is offering). Offers less (or in some cases even no) room for customization though it offers the shortest time to integration (sometimes even just minutes)

APIs should be free, or at least free for a certain level of usage. APIs often extend a core service which is already being monetized and API extends this and enables the core service to be used more and most likely also to be able to earn more money. Monetization via the API is often done just to cover costs, not make additional money. So the main business model is often just to make sure costs are covered and in some cases it could happen that there is money to be earned with an API.

Common business models for APIs:

Artificial Scarcity

Rate limiting

The API itself is free; however when you go beyond a certain number of transactions a fee is imposed. This fee is the way to cover the costs for the increasing usage (and required scalability) of the API though it can also be used as a way to discourage sloppy programming and make sure people are using the API efficiently also. Also it can be a way to make a divide into people who are using the API just as a hobby and people who are using the API for something they might earn money with and are willing to invest in.

Data limiting

Next to rate limiting there is also data limiting the core for some business models. Developers can only get a certain amount of data per API call or in a certain period of team. Again this could be a way to cover costs for increasing usage of the API, or it can be a way to divide people in two groups: the ones that are likely to make money based on your API and are willing to invest in it and the ones who are using it is a hobby.

Functionality limiting

Another way to create artificial scarcity for supporting your business model is by limiting functionality. Often basic functionality is provided for free (such as read access to data) and more advanced functionality (such as update and insert actions) are only available for paid users. This is again a model that helps finance growth and helps to differentiate types of users as well as make it easy to scale for different types of uses.


SLA / quality

Instead of creating artificial scarcity another way to support your business models can be done via differentiating in service level agreements or quality in general. When developers pay more they get a better service (short support window, increased uptime, faster response times etc), when developers are not paying they get the basic API which is often maintained on a best effort basis (which shouldn’t mean that is should have very high response times and downtimes without an end though).

Transaction free / revenue sharing

Another way to earn money via the API is a shared revenue model. Based on the success the developer has with the API (for example a payments API) he has to pay a small fee per transaction (similar to what Amazon and Apple are doing on their platforms). This way you have a shared interest in making sure the API is successful.

The Next Web in 2011 and Beyond

The next web is not about semantics, it is about removing the gap between desktop and mobile and between installed software and SaaS. It is the post-OS era, people are using a device that is (nearly) always on and always connected, the OS and the browser are becoming commodities. It is the era in which markup is going to lead again in favor of proprietary technologies.


HTML5 is bridging the gap between the devices and the application experience, especially since all major browsers (Chrome, Firefox, Internet Explorer, Opera, Safari) are supporting HTML5 by default. Also HTML5 offers an alternative for proprietary/vendor-specific technology such as Adobe Flash, Google Gears, Microsoft Silverlight and Java FX.

Functionalities such as native video and audio, native local storage, native content editing are removing the barrier between the experience of offline installed applications and online applications.  However not every user  has the choice or the opportunity to upgrade to the latest version of their browser of choice, a fallback is required for most HTML5 functionality and therefore there still will be a gap between desktop and mobile and between installed software and SaaS for some users.

Markup back in the game

HTML5 is bringing markup back in the game, in favor of proprietary/vendor specific plug-in, introducing the foundation for solid cross device, cross platform, online or offline user experience and making the first efforts to bridge the gap between desktop and mobile and between installed software and SaaS.

Infinite monkey theorem – the key of the Generative Web?

The infinite monkey theore states that a monkey hitting keys at random on a typewriter keyboard for an infinite amount of time, will almost surely type a given text, such as the complete works of William Shakespeare. With 24 hours of video uploaded every minute on YouTube, there are a lot of ‘monkeys’ who are hitting their ‘typewriters’ in creating their next master piece. So actually it isn’t surprising that the there is a really great video on YouTube every now and then which is considered a masterpiece (just a matter of enough ‘monkeys’).

Providing a typewriter

Google now offers the search stories video creator (you may name it a typewriter) to its audience (nearly infinite ‘monkeys’) to create search stories (ads?) such as Google did for their Super Bowl Search ad. With an audience that is nearly infinite (and since the number of Internet connections is growing it seems infinite) and with an easy tool, we shouldn’t be that surprised if the next ad for Google on the Super Bowl is created by a ‘monkey’ on their search stories typewriter. Just a matter of time.

If you have the time and the tools to make sure you help infinite monkeys hitting random keys on a keyboard, than you’ll have a good result in the end. However, that can take a long time. Therefore a company such as Threadless is limiting the randomness and have a set of rules to which the designs of the ‘monkeys’ should comply. And since the ‘monkeys’ that are creating designs for Threadless are not just merely hitting random keys, (or in this case moving their paintbrush randomly in Photoshop) a lot of designes that would be declined aren’t created and therefore a great design will be popping up a lot faster.

Monkey business

So is the web just monkey business? It might be, if you let things flow unstructuredly. However, Threadless turned the monkey business in something valuable (Threadless’s revenue is $30 million) by helping their ‘monkeys with a set of rules’. Google is helping their ‘monkeys’ as well  by providing them a typewriter with limited keys. So if you can reach out to enough ‘monkeys’ that have a ‘typewriter’ and enough time to hit keys at random, you too might get value from them. Just make sure that you either have enough time or that you set a clear playing field for the ‘monkeys’.

The only good thing you can do with e-mail

Although we predicted at the Technology Blog of Capgemini that e-mail would die this year it seems it is rather persistent. However besides overloading people with e-mails and setup a competition “Who is the person who could CC the most people”, there is one good thing you can do with it: use it with Posterous.

Meet Posterous

Posterous is a service that distributes its content in a way that seems to be uncool at first sight. Simple: sending e-mail is not something the cool kids do, everybody is sending e-mail on a daily basis. Therefore my first feelings about Posterous were that it was totally not cool or useful. We are struggling with an immense amount of e-mails (with only a small percentage that is really useful) and then there is Posterous, a new service that seems to be e-mail centric.

By using such an uncool medium as e-mail, Posterous is quite cool. It is a really easy way to send your content to a lot of networks. It is an easy method to get people to start a blog or to share their photos and videos on several sites. Often senior management does not get what a blog is, or how sites like YouTube, Flickr or Twitter work, however they are masters of their inbox and understand e-mail very well. Now these people can also blog, they do not have to learn a new trick, they only have to e-mail to a certain e-mail address. The only thing they have to be aware of, is the results of sending a simple e-mail to Posterous

For the digital illiterated

Besides an easy introduction to social media for the digital illiterated, e-mail is also a service that is not blocked in most offices or countries (while something like Facebook or YouTube is often blocked). E-mail to certain domains is hardly ever blocked, and at almost every device that has an internet connection you will have the possibility to send an email to Posterous and distribute your content.

But still: it’s e-mail. So it’s a bit uncool.

Web3.0 is not about Web

The next web (call it what you want, you can call it Web3.0 if you like versioning) is not about the Web. It is about removing the gap between the desktop (offline at a device (laptop, PC etc)  installed software such MS Office) and the Web. Currently the web is more and more present on the desktop, due to tools like Prism but also due to the immense growth in web application development.  However desktop presence is still key, it is a typical kind of intimacy if you are able to be present on someone’s desktop.

Post-OS era

A trend which is emerging is something like a post-OS era, people use a device, and what the device is running does not matter. It might even go a bit further: the OS has become something like a commodity, people assume that it is part of an ecosystem without realizing that it is something you can choose to install. The next step will be to become more browser agnostic. Browsers are not a yet a commodity, people know there is difference between them, and they are still a separate application which you have to launch to get to your favorite web application. Besides that, broadband wireless internet connections aren’t a commodity either.

However the gap is closing thanks to frameworks which make it possible to create cross browser (or should it be mentioned browser agnostic) solutions. Also Google Gears is a real improvement to have the ability to use your web application both online and offline (which will be more standardized when HTML5 and ARIA is implemented by most vendors). The fact that we all get faster CPUs, but also that JavaScript interpreters such as Squirrelfish have gained a lot of speed on the client side is something that closes the gap.

There used to be a really big difference between performance on the desktop and performance on the web, this gap is also closing. It is just a matter of time before you cannot tell the difference between a client application and a web application (or mixtures). The user experience of both will be exactly the same and it becomes less important if you are running Windows and IE8 or Ubuntu and Firefox3. The only thing you really need is a screen and a broadband connection.

Web3.0 will not be there

Many identify the Semantic Web as Web3.0, however if it would be really Web3.0, it would have probably already occurred. Especially since we are already talking quite a while about the Semantic Web (the Semantic Web roadmap is from 1998 (PDF)). Perhaps the Semantic Web will even never happen since nobody really thinks it is important, or not important enough (if it was really important it would have already been there, wouldn’t it). What surely will happen is closing the gap between desktop and web, it is happening already.