Category: Mobile Web 2.0

I am a huge fan of OperaMini and about a year ago, I reported on the usage statistics published by Opera over at their website. While they report their usage statistics once per month, I haven't been over in a while and I was quite possitively surprised when I compare their current report to that I have reported on a year ago. Here are the points I've taken away from the comparison:

• Compared to a year ago, the active user base has increased from 11.9 million users worldwide to 20 million users. So it's almost doubled in a year.

• Number of transcoded pages: 7.5 billion, up from 2.4 billion a year ago. so while the user base has doubled, consumption has trippled. Looks like the per person appetite is rising.

• The amount of data sent to users: 122.00.000 MB during the month, that's almost 4x more than a year ago. So not only do users view more pages but the content per page is also growing. A year ago, I calculated their outgoing average data rate at around 100 MBit/s. At the current usage, their average outgoing data rate must now be close to 400 MBit/s. In addition, there's the traffic for fetching the full web page in the first place and then compressing it to those average 400 MBit/s output. It's difficult to say how much bandwidth that requires due to caching but I'd say its very significant as well.

From what I've heard, Opera has a number of regional data centers now in the US and China, so the overall load is split now. Still, the number is staggering.

For this post, let's do another rough guess: With 7.5 billion pages served a month, that's 250 million pages a day, or almost 2900 pages a second.

All very impressive!

As an avid user of Opera Mini I was very happy to see that the version v4.2 is now available for Android. Alphas and betas have been available since last October/November so announcing a non beta version probably means it's quite stable by now. Good news for G-Phone users and mobile Internet access in general. Kudos to Opera, looking forward to see it on the G-Phone in Barcelona at the MWC!

Regular readers of this blog probably know that I am a glowing Opera Mini fan. I am amazed at how versatile this piece of software is for mobile web browsing. Here are two tips of how to extend the functionality which have come in pretty handy recently:

• Delicous bookmarklet: Opera Mini fans also using the Opera desktop browser are probably pretty happy with the mobile/desktop bookmark synchronization feature. Since I use Firefox and Delicious, I'd like to have a similar feature, as sending links I have found by eMail is a bit too complicated to be efficient. Almost as easy said as done. Denis over from Wap Review has found out how to add a Delicious bookmarklet to the Opera Mini bookmarks. He actually posted the tip over one and a half years ago. Thanks Goolge for pointing me there. Works great, thanks Denis!

• Google Reader: I used to read my feeds via Thunderbird which had the big disadvantage that more often than not, I failed to keep up to the flow of information as I just did not have time to attend my blog roll in front of a computer. I usually have a couple of minutes to spare when I am mobile though. So I switched to Google Reader, which has both a superb desktop and mobile interface. First, I tried the iPhone mobile interface in the S60 browser. It works great, but the missing up/down page scroll functionality of the S60 browser makes it too awkward to use. Nokia, how much longer do we have to wait for this simple functionality? In the meantime, I use the standard mobile interface, which works well with Opera Mini. It doesn't look as nice as the iPhone web interface, but it does its job superbly.

Ever since discovering Opera Mini I am a glowing fan and have rarely touched another mobile web browser since. I've reported some statistics after the MWC in February and it looks like the user adoption continues to grow rapidly. Today, I discovered a report on the Opera web site which gives a number of interesting details as of the first quarter in 2008. Here are some highlights:

• Current number of downloads: 44 million
• Number of users in March 2008: 11.9 million, 26% more than in the previous quarter
• Number of transcoded pages in March: A staggering 2.4 billion, 57% more over the last quarter
• 11.9 million users generated 33 million MB of data in one month. That's about 2.7 MB per person. Let's do some maths: 33 million MB that's 33.000 GB or 33 Terabyte [corrected from PB, 2/2009]. Now if you take that number, divide it by 30 days, 24 hours, 60 minutes and 60 seconds and multiply it by 8 (bits), that requires a bandwidth of 100 MBit/s. In practice the number is probably even higher since usage distribution is probably not the same throughout the day, despite OperaMini being used globally.
• The required bandwidth above is only to the user side and does not include loading the full page to the opera servers first and then compressing it. It's difficult to say how much extra bandwidth this takes since pages are compressed by 90% but a lot of content is probably cached and is thus not retrieved from the web site every time it is requested.

With that growth I wonder how they can keep upgrading their data center for the transcoding, increase their internet bandwidth and still keep the service free!? I am using OperaMini a lot and the transcoding is always fast so they seem to be able to keep up with the task.Thanks Opera, your OperaMini is my application no. 1 on my N95.

Found via: MoMo Indonesia

Here is an interesting blog entry on the Nokia Beta Labs Blog: Tommi reports about the recent coverage of Nokia SportsTracker (which I like very much by the way) in Newsweek and about a YouTube advertising video that came out of the blue. Looks like it was not being done by Nokia!? Is the web 2.0 community now also coming up with the advertising for products they like? Incredible!

I get a lot of web links lately on my mobile phone either in web pages, Twitter, Jaiku or via eMail. Sometimes I would like to take a look at these pages right away on the mobile instead of with a computer later-on. What usually keeps me from doing that is that the links point to full web pages which often overload my mobile web browser. Some people are nice and send their links via esyURL, which detects if the link is accessed from a mobile browser and then transcodes the page accordingly. But that’s the exception rather than the norm. So what I would need is a way to control it myself. Mobile browsers could offer a menu when clicking on a link with a special button (thing right mouse button on a PC) with a list of transcoders such as Mowser, Google and Mippin that return a mobile friendly version of the page behind the link.

Not difficult to do at all. Who will be the first one?

This blog enty is part 2 of my thoughts on offline web applications on mobile devices. In case you haven’t seen part 1 and are interested in this topic, you might want to read part 1 first before continuing here.

When allowing web applications to store data offline and to access locally available information a number of issues arise that require special attention:

Data Synchronization

When storing data both in a local database in the network, the databases have to be synchronized once the mobile device regains network connection. Even for single user applications local and remote database synchronization is not straight forward since the user could have first used the application on the mobile device while it was offline to change some data and later on via the desktop that modified that data in the network. This means that when the mobile devices goes online it can not assume the data base in the network was not modified. Thus, the application needs an algorithm to compare the changes made in the database on the mobile device with the changes made in the database on the network and then modify the local and the network database accordingly. The same applies to multi user applications such as shared calendars.

Access to Local Information Outside the Browser Cache

A big advantage of mobile devices is the ability to support the user’s creativity at the point of inspiration. When pictures, videos, podcasts, blog entries etc. are created on the mobile device they can automatically be enriched with other information such as GPS location before being instantly sent to a picture and video sharing site, blogs, etc. Current web applications, however, do not have access to files and other local data beyond what they can write into the local web database themselves while the device is not connected to the web. In the future it is thus necessary to create an interface for web applications to enable them to access user created content and additional information such as location information. Access to local information needs to be dealt with carefully as it presents a security and privacy issue as will be further discussed below. From the technical point of view the big question is how web applications could gain local access in a generic way to make them interoperable over a wide variety of devices. Some devices might have more sources of information than others. As using proprietary APIs to access such information would make web applications device specific, a standard set of functions must be designed which are then translated on each device into proprietary operating system commands.

Security and Privacy Considerations

Allowing a web application to store data locally or to even access local information beyond the browser cache has a number of security and privacy implications which have to be considered when implementing such functionality.

The main issue with having a local application and data cache in the web browser is that JavaScript applications can use the local cache for user tracking. Advertisement platforms could use the local interface to write a JavaScript program that is included in all web pages of their advertising partners and that records from which page it has been invoked in the local cache. When the same JavaScript application is executed again from a different page it reports the last page back to the advertisement server which can then generate a user profile. As most users are unlikely to agree with such methods the user has to be informed that an application wants to store information locally and what kind of privacy issues this could bring with it. The user should then have the choice to allow or deny the use of local storage either temporarily or, in case the JavaScript application is trusted, permanently.
Access to local device information outside the browser cache is even more sensitive as malicious JavaScript applications could read private data of the user and send it to a server in the network. Therefore, the user has to be informed about the JavaScript application trying to access local data and give the user the possibility to allow or deny the request. It is then for the user to decide whether he trusts the application and thus allows access to local resources. Again, the user should have the choice to allow access temporarily or permanently as trusted applications should be able to access local data without further queries to the user once agreement has been given. Otherwise, usability of the application would suffer.

As always, comments are welcome!

I am currently doing some research in which directions applications on mobile devices will develop in the future. The following post on offline web applications on mobile devices has been inspired by a blog entry on Ajit Jaokars OpenGardens blog.

On the desktop, many web browser based JavaScript applications exist today with well designed user interfaces and connectivity to services and databases on the web. Web based applications such as GMail (email reader), Bloglines (blog reader), Writley (text processor), etc. are now even taking over some of the functionality of locally installed programs.  On mobile devices, this trend is not yet wide spread. In my opinion, there are a number of reasons for this:

• Web browsers on mobile devices need to become AJAX capable. This is well underway and in the mid-term its likely that most mobile devices will include such a browser. As JavaScript and the functions for asynchronous communication with the web server are standardized, developers can design applications which will work over a wide variety of mobile devices. This is an important key to success as services which only work on a limited number of mobile devices are unlikely to be successful as they will be unable to attract a sufficiently large user base.

• Web applications need to work even if the network is not available. This is crucial for applications such as calendars, address books, etc., which have to be accessible at any time and any place.

• Some applications should also be able to get access to the resources of the device which is important for applications used for uploading information such as pictures to the web or use the device’s built in GPS device to get the current position to be able to deliver information relevant to the user’s current location.

With the traditional server/browser approach these things are not possible. If the connection to the network is lost, web applications can not be loaded onto the device from the web server and user input can not be sent back to the web. A number of different initiatives have thus started to address these shortcomings.

Google Gears

Google’s approach is based on a web browser plugin which offers JavaScript applications on web pages an API to store pages locally. Furthermore, the plugin allows applications to store data locally. When the page is accessed when the device is not connected to the network, the local copy of the web page including the JavaScript program is used instead. The Gears plugin extends a web browser with the following functionality:

• A local server which feeds the web browser with web pages which have been stored in the local cache in case the device is used in offline mode.

• A relational database in which JavaScript applications on web pages can store information. To stay with the example above, a calendar application could hold a copy of the user’s calendar entries which are synchronized with the calendar entries in the web when the device is online and the application is used.

• As synchronizing the local and remote data depository after going online could take considerable time it is important that such activities do not block the execution of the JavaScript application on the web page. Thus, the Gears API contains a ‘WorkerPool’ which allows executing JavaScript code in the background.

At the beginning of 2008, Google Gears is only available for desktop based browsers as it depends on a web browser plugin interface which is not yet available in any mobile browser. As the software is available as open source under a BSD license the way is free for mobile browser developers to include it in future versions of their products. While Google Gears enables web applications to run offline, there is not yet an extension which also allows web applications to use local resources (e.g. access to the file system, getting network information, GPS information, etc.).

Nokia S60 Web Widgets

Nokia’s vision for local web applications on mobile devices are widgets. Unlike Google Gear’s approach a widget is not executed inside the web browser. Instead, it just uses the web browser’s core as a runtime environment and otherwise looks like a native application. Widgets can even have their own icon that appears along local applications in application menus of the device. Not running in the user interface of the web browser but instead having the full screen available has a number of advantages. From the user’s point of view the program can be started and controlled just like local applications. When the widget is started by clicking on the icon in the program list, the web browser core is loaded and the JavaScript and HTML page which the JavaScript application can modify is shown on the screen just as a local application.

The first version of the web widgets packet does not offer local storage to applications which limits its use to times when the device is connected to the network in case data needs to be stored between invocations of the widget. Also, there are no interfaces at the moment to get other data from the device such as calendar entries, address book access, etc. Widgets do have access, however, to system information such as the current battery power level, network properties such as signal strength and network name, display light control, vibration control, speaker control, memory properties, etc.

HTML-5

For version 5 of the Hypertext Markup Language (HTML) the World Wide Web Consortium (W3C) is specifying tools to make web pages and embedded JavaScript applications available offline. The approach taken by the W3C is very similar to Google Gears and also features offline caching of web pages and a data repository for JavaScript applications to store data locally. There are two ways of storing data locally. For simple data structures, data can be stored in name/value pairs. For more complex data, JavaScript applications can use a SQL database with standardized functions to query, insert, change and delete data. The advantage over Google Gears is that once the standardization of HTML-5 is finalized, browsers can natively support offline web applications and a plugin like for Google Gears is no longer required.

That’s it for a first overview. In a future post I’ll take a look at data synchronization between the network database and the local cache, why and how some applications should be able to access local data beyond the cache and the security and privacy implications of local web applications.

As always, comments are welcome.

Mobile network operators are always pointing to the fact that they don’t want to be mere bitpipes but would rather prefer to remain a network + service provider as they are with voice telephony today. Most have recognized some time ago that this is a rather unrealistic goal and are opening their walled gardens. But maybe this bitpipe disgust could be remedied with a different perspective on things!?

Apart from the few killer apps born out of web 2.0 (Google search, maps, Flickr, Amazon, eBay, Facebook, …) most people today use quite a number of services in the Long Tail of the web. In case you are not familiar with Long Tail economics, take a look the original article by Chris Anderson published on Wired magazine which focused on goods on the long tail but is in my opinion applicable to services as well. It is these startup or niche segment services that might give the final incentive for users to consider going online from their mobile. The "problem" for network operators is that they can’t be the provider of the killer apps, since they are already out there and they also can’t be the provider of those niche apps, since there is not a lot of money to be made in the long tail as this article by Alex Isold on ReadWriteWeb aptly points out.

What Alex also points out, however, that while you can not make a lot of money in the Long Tail but you can actually make a lot of money WITH the Long Tail as aptly demonstrated by Amazon or eBay. So now look at mobile operators: Selling bandwidth is nothing but making money with the Long Tail of the web. Sounds a lot better than ‘bitpipe’, no?

Comments as always welcome!

I’ve been thinking a bit about the recent history of mobile Internet access lately because I was wondering why it had such a teribble start. In the mobile world, the web had a much more difficult start compared to the fixed line world for a number of reasons. First attempts by mobile phone manufacturers to mobilize the web were a big disappointment for quite a number of reasons. In the fixed line world the web got an incubation time of at least a decade to grow, to be refined and to be fostered by researchers and students at universities before being used by the public who already had sufficiently capable notebooks, PCs and a reasonably priced connection to the Internet. In the mobile world, things were a lot different when first web browsers appeared on mobile phones around the year 2001:

• Mobile Internet access was intended straight for the public instead of first attracting researchers and students to use and refine the services. Unlike at universities where the web was free for users, companies wanted to monetize the service from day one.

• It was believed the web could be mobilized by only adapting successful services to the limitations of mobile devices rather than looking at the benefits of mobility. To put it into the words of Tomi Ahonen, that is like taking a radio play, bringing the actors and their microphones, and showing them when they read a radio play on TV.

• Few if any appealing content for the targeted audience was available in an adapted version for mobile phones.

• Mobile access to the Internet was very expensive so only few were willing to use it.

• Circuit switched bearers were used at the beginning which were slow and not suitable for packet switched traffic.

• The mobile phone hardware was not yet powerful enough for mobile web browsers. Display sizes were small, screen resolutions not suited for graphics, no color, not enough processing power and not enough memory for rendering pages.

• Use of a dedicated protocol stack (the Wireless Application Protocol, WAP) instead of HTML required special tools for web page creation and at the same time limited the possibilities to design mobile and user friendly web pages.

Each of the points mentioned above would have been enough on its own to stop the mobile web in its tracks. Consequently many roadblocks needed to be overcome before the Internet on mobile devices started to become interesting to a wider audience. This fortunately coincided with the emergence of the web 2.0 and its evolution into the mobile domain. But that’s another story.

As always, comments are welcome!