Boosting internet in mobile: the return of the browser proxies (mobile megatrend series)
- 5 comments
- 4 pings
- view license
(browser proxies are back in fashion.. guest blogger Fredrik Ademar looks at the limitations of today’s mobile web and how browser proxies have resurfaced to bring the internet to the masses. Part of our Mobile Megatrends 2008 series).
Struggling with the limitations of the mobile web
Numerous attempts, more or less successful and well-known, have been made over the past years to replicate the browsing experience provided on a desktop device also in the mobile context. Latency, low bandwidth, limited input capabilities and small screens have typically been main hurdles to overcome to really get something remotely close to the original web experience. A quite interesting trend in the mobile browsing space that now has gone through an exciting renaissance, is the concept of bringing in network proxies to intercept the web-to-mobile traffic and optimize. The most well-known example is probably Opera Mini, which truly has made a significant impact on how mobile web is perceived by the masses. But Opera is only one of many contenders in this space, and there is a set of different initiatives providing similar functionality and benefits (although in slightly different packages) such as Bitstream ThunderHawk, InfoGin, Flash Networks, Novarra, WiderWeb, Google Wireless Transcoder etc. The trend seems clear going forward - this could indeed be the answer to the quest for a truly pervasive web experience across mobile and desktop. Or maybe we are hoping for too much?
Ways to address the problem
To begin with one should note that the solutions provided are not by any means new concepts. The ideas can be found already back in the early WAP days, and many of the issues that now attract attention, were in fact exactly the same that WAP attempted to address with the original WAP gateways etc. In retrospect one of the major problems with WAP was that the ambitions were stretching too far. For instance using SMS and USSD as transport mechanisms was a bad idea from the very beginning, and this seriously harmed the priorities and technology trade-offs made. However, one important assumption was right, the insight that simply applying the classical W3C standards to the mobile space was not going to do the job and that is still the case today.
Standards like HTTP and HTML (with Javascript, CSS etc.) are simple and straightforward, but also pretty verbose formats quite unfit for a mobile environment. Applying these on top of standard TCP as transport does not really match the need for a responsive and user friendly mobile web service. To some extent it is really a no-brainer to identify potential solutions, and the most straightforward and natural approach is to introduce an intermediate proxy, which translates and optimizes the traffic over the air interface, still maintaining the legacy structure and protocols on the server side. Typical functionalities included in the available solutions are things like page pre-rendering and reformatting, image and data compression, intelligent proxy caching, image size reduction, session tracking etc.
These functionalities can be basically be categorized in the following three technology segments (based on the excellent taxonomy of browser proxies at the S60 browser blog):
- Speed proxies
Purpose: image compression, efficient page contents caching, HTTP & content pipelining.
Examples: Bytemobile, NSN, Flash Networks (NettGain), Venturi VServer, Novarra
- Adaptation (transcoding) proxies
Purpose: page reformatting, image reduction, menu simplification, session tracking, SSL session handling, XHTML/MP adaptation
Examples: ByteMobile, InfoGin IMP, Google Wireless Transcoder (ex Req Wireless), Novarra nweb, Volantis Transcoder, WiderWeb, Greenlight Wireless Skweezer, Clicksheet
- Server based (pre-rendering) proxies
Purpose: pre-renders page before sending and improves navigation
Examples: Opera Mini, Bitstream ThunderHawk
A speed proxy typically makes the mobile browsing faster and reduces data to a certain extent, while it still preserves a full page. Adaptation and server-based browser proxies on the other hand will drastically reduce the amount of data sent over the air, but at a significant cost since the page will no longer be the original web experience. Often the page is re-formatted into one long narrow column (like e.g. Opera SSR), and dynamic effects like pop-down menus and pop-up windows will not work.
Bringing in the proxies, pros and cons
When benchmarking these products in terms of performance, the improvements are indeed often significant. Content size is reduced to 10-50% of the original size, and the downloading of typical sites can be done in half the normal browser download time (ballpark figures from Opera Mini). Since much of the heavy lifting is done in the network, an interesting side effect is also that the CPU, memory etc. requirements for the device are much lower. It is even possible to deploy solutions to devices post sales that will mobile web enable them, even if they did not have that kind of support from the beginning (using e.g. java based approaches like with Opera Mini)
Ok, this sounds great - are there really no weaknesses with the browser proxy approach? Yes there are. A common problem highlighted is the lack of true end-to-end security, as well as the problem of ensuring integrity of the transferred data. These problems are difficult to get around given the nature of the architectural setup.
Another very relevant problem is the fact that when applying different automatic intelligent conversion algorithms on content, you do indeed tend to violate the original intent of the content author. You can never replicate 100% of the experience on the desktop web, and in many cases content gets optimized away completely (like e.g. flash content).
Another typical comment is that networks and device hardware are getting more capable each year, and solutions including anything other than standard web browser technology, will quickly become obsolete. I think this assumption is completely wrong, there will always be a gap between mobile and desktop web - the mobile device will always be more limited and therefore needs to be treated differently.
Building a business case
As always, the technology roll-out also needs to be coupled with a sustainable business model. Where is the money in all this? Besides the services of providing the core browser experience, there are lots of value added services like billing, content filtering etc. that can be applied, but the true value lies in the fact that companies in this space are right in the middle of a giant flow of very targeted user data going back and forth. Carefully catered this asset can prove to be far more valuable than what can be made from the original service - with that said it is really no surprise to find Google (Google Wireless Transcoder) as one of the contenders in this segment.
A megatrend going forward?
As a future outlook for 2008, the mobile browser proxies will continue to provide an increasingly important contribution to the mobile web experiences, especially important harnessing the value of the long tail. This time, there is no doubt the proxy based browser model is here to stay, but it will typically not be perceived as a ground breaking revolutionary step, more as a natural and obvious evolution. We will also likely see a consolidation of technical solutions, as some players in the space today are to some extent not providing scalable and competitive enough solutions.
Comments?
Fredrik
(Browser proxies is trend 11 in our Mobile Megatrends 2008 series. Full presentation below.)
Boosting the Internet in Mobile cannot be solved via a server based solution.
The real problem centers around three things:
1: Device capabilities
2: Terminal capabilities
3: Operating system capabilities
If the server knew each of the above capabilities in real time as each request was made you could then make sensible and appropriate decisions on what to serve back to the customer. The absence of this information leads to a predictable and bad mobile experience.
Solving the above 3 items leads to a predictable business model for web service operators as they are now able to offer their customers a better mobile experience and instead of bombarding them with ineffective advertising - instead they can offer contextual based information.
Please review our web site to see how our solution tackles and solves the mobile internet browsing problem. At the bottom of the home page are several business use cases illustrating how our approach delivers real business results.
Cheers,
Peter Cranstone
CEO 5o9 Inc
http://www.5o9inc.com
Hi. Firstly I’m a Volantis employee, so obviously this comes from an interested (but hopefully informed) position.
Automated PC to mobile transcoding is a relatively complex business and can also be extremely CPU intensive. There’s a variety of approaches out there, usually involving relatively simplistic rearrangements of blocks of data on the page and some attempts to either strip or convert styling information. Our own approach involves attempting to additionally annotate the page so that configurable rules can be applied to the various types of area (this also allows for additional approaches - our Mobilizer web service, now available via http://www.ubik.com, uses the Volantis transcoder to convert pages for subsequent editing into a genuine mobile site, and also allows for ongoing transcoding of pages, or parts of pages, where the backend is genuinely dynamic.
We’re increasingly seeing transcoders being procured in conjunction with speed proxies. You should probably add Fujintech to the list of speed proxies, and Opera to the list of server side transcoders, since their technology is OEM’d by some of the speed proxy vendors you mention. WiderWeb is of course now owned by Openwave.
As for this being a megatrend. All the figures we’ve seen show “made for mobile” traffic growing far faster than transcoded traffic (which is also, however, growing, just more slowly). Our approach with Volantis transcoder has been to translate the originating site into a “made for mobile” representation which is then processed by the Volantis Mobility Server (now available as a free download from http://community.volantis.com). Volantis Mobility Server can also be used to design, construct and run new “made for mobile” services, which might include different content and capabilities more appropriate for mobile users.
In terms of contextual information, Volantis Mobility Server includes a regularly updated database of over 4500 devices, which tracks around 650 different attributes. Each one of these (plus any custom attributes the developer may care to add) can be used for contextual decisions - we implement the W3C DIAL draft standards (http://www.w3.org/TR/dial/) and notably the candidate recommendations for content selection based on device attributes (http://www.w3.org/TR/cselection/) - this combination of a standards based approach, device knowledge and proven scalability is the core reason why so many customers already use the software - in fact more than 200m users worldwide consume their mobile web services through Volantis software.
Sorry if the above sounds like something of an advertisement, but the software is at least free! You’re welcome to come to our community site, download it and try it out.
Best wishes and happy holidays
Mark
Hi I am working for Flash Networks, at Flash Networks we believe that open mobile browsing is an essential for mobile internet proliferation, users are expecting diverse content experience which is not available on operators portal. For open mobile browsing to be embraced by end users, quality of experience should improve. The key ingredients for improving mobile internet QoE are:
• Fast browsing: speed up browsing time by applying the right mix of optimization technologies (pending browser type, network type and content)
• Adaptive browsing: Smart adaptation of web pages and video content to the mobile environment
• Safe browsing: Content control (filtering) for protecting youth and other segments from accessing in appropriate content
• Single, network based platform providing a holistic view of mobile internet QoE is essential for activating only the relevant services to ensure best QoE at the lower operating cost (for example not activating web to mobile adaptation for mobile aware content or preventing access to adult content stored at the optimization cache server for opt in users and more)
Moving forward we believe that the importance of fast browsing will grow as smartphones equipped with sophisticated browser will enable downloading full HTML pages, on the other hand, the importance of HTML adaptation to mobile will ultimately decrease as the percentage of mobile aware content will grow and the percentage of smart phones which do not require adaptation will grow as well.
In addition, our customers are expecting significant growth in video streaming traffic, such traffic will require streaming shaping (rate adaptation) to reduce buffering and maximize available bandwidth.
Best regards,
Eli Mahal
VP Marketing
Flash Networks
Interesting post, but I think your conclusion misses the point:
Another typical comment is that networks and device hardware are getting more capable each year, and solutions including anything other than standard web browser technology, will quickly become obsolete. I think this assumption is completely wrong, there will always be a gap between mobile and desktop web - the mobile device will always be more limited and therefore needs to be treated differently.
Of course there will always be a gap between handheld and full-size computers, with different needs. But within a decade the web will certainly be accessed far more from mobile devices than any other. The US will be the last place this happens, since most Americans can afford both a mobile and a laptop or desktop device, plus we spend a lot of our mobile time in cars. But in developing nations, where your mobile device is your only computer, mobile will dominate the web in traffic volumes, and that will then become true everywhere.
I believe all new web development in 2015 will be designed to work on both big and small screens. There will be exciting new technologies used on big screens that don’t translate well to mobile — but if it’s a service or content that is potentially useful on mobile, it will also be developed with a mobile-optimized version.
So what content would still need server adaptation? Full browsers on mobile devices are already capable of dealing with the majority of legacy HTML, which will continue to improve with device and network evolution. It’s just the new stuff that’s hard: today that is sophisticated Ajax, Flash, etc. But bleeding-edge content is built only on sophisticated web sites, and those designers and developers will respond as the volume of mobile browsing begins to dominate.
Think of the switch from landlines to cell phones.
Surely there will be content that is mainly used on big screens. I don’t expect to ever do in-depth comparisons of mortgages on my small screen, and there are plenty of other cases where the big screen’s efficiency and power are preferable. But portability trumps power for most day-to-day information and communication needs, and that implies that there won’t be much web content that isn’t designed to work well on mobile.
Which implies that server-based adaptation (at least at today’s level that grossly compromises the web experience) will only be important for a limited transition period.
–Franklin, from Nokia browsing
As for the role of browser proxies going forward don’t get me wrong. I am not claiming browser proxies to be the silver bullet to solve all potential problems with the mobile web experience now and in the future. My view is rather that browser proxies in different forms is and will be an important piece of the puzzle bridging the gap for a set of web standards quite poorly suited for direct use in a constrained mobile context. Proxies are an efficient way of enabling the long tail of web sites developed for desktop, to be efficiently consumed by mobile users (also in low-end devices). One might argue that this is not a big problem, since (especially on high-end devices) we see full browsers already capable of handling most legacy ‚Äústreet HTML‚Äù sites, and sites with fairly complex use of scripts etc. out there. However, to be honest most of those browsing experiences are still quite painful (in many cases due to poorly written sites more or less abusing the standards)
At the same time I do very much agree with Franklin’s view that going forward the web will be accessed far more from mobile devices than others, which in turn will promote the evolution and development of web sites natively written for mobile (with or without a desktop version running in parallell). In essence this is the only way to create a truly optimal mobile web user experience, and I’m actually surprised the market has not come further already - after all, mobile access to the web has been possible and available in various forms for over ten years. Maybe it is just a sign of how inert this movement is and how difficult it has been to justify investments of upgrading legacy solutions. Also a problem creating a ‚Äúmobile version‚Äù of a web service is that unlike desktop it encompasses literally hundreds of formfactors, interaction paradigms, contexts etc. you need to address as a content author. Moving forward it might be that harnessing contextual information about the device, and the type of solution that Mark talks about in the Volantis Mobility Server (with W3C DIAL etc.) is the most/only valuable contribution a browser proxy will have.
In addition, as Franklin points out, on some markets mobile presents the only way of accessing the web and for these markets the web is already adapted for mobile by default. Quite interesting in this context is the fact that on emerging markets surprisingly many devices actually supports J2ME/MIDP2 and many services are deployed not as traditional web services but as java based solutions (i.e like flavors of Yahoo Go and the likes).
When talking about the mobile web experience for the future I think it is also important to point out that this will not be restricted to the browser context, i.e. as a quite monolithic experience. Instead it will be a pervasive experience across the whole user journey in the device. We have seen initial parts of that trend with some ODP:s, different approaches for connected active idle screens, calling it widgets/gadgets or whatever. The essence is that we will see elements of UI, data and resources originating from the web troughout the whole user interface in the device - where it is seemlessly mixed with the native UI, enhancing the experience. In 2015, I think that will be what we refer to as web in mobile, not only simple usage of the browser.
Cheers,
Fredrik



visionmobile 2005-2008