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

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

Best regards,

Eli Mahal
VP Marketing
Flash Networks

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

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