Tag Archives: Novarra
Nokia's Beta Labs introduced a Beta of the Ovi Browser Wednesday. It's based on the Vision browser from Novarra, which Nokia acquired five months ago. The Ovi browser is a proxy based browser, similar to Opera Mini. It renders and transcodes web pages on a server before sending them to the phone client in a highly compressed format. Nokia claims that the compression reduces web traffic by up to 90%.
The Ovi browser supports the Nokia 2700 Classic, Nokia 2730 Classic, Nokia 3120 Classic, Nokia 3600 Slide, Nokia 5130 XpressMusic, Nokia 5220 Xpressmusic, Nokia 5310 XpressMusic, Nokia 5330 Mobile TV Edition, Nokia 5330 Xpressmusic, Nokia 5610, Nokia 6300i, Nokia 6303, Nokia 6500 Slide, Nokia 6500 Classic, Nokia 6600 Slide, Nokia 6700 Classic, Nokia 7210 Supernova, Nokia 7900 Prism and Nokia X3. If you have one of those devices you can download the browser from browser.ovi.com
I don't have a supported device but wanted to see what the Ovi browser was like. Visiting browser.ovi.com with an N95, I got a "Sorry your device is not supported..." message. But by impersonating a Nokia 5130 with Firefox's User Agent Switcher Add On I was able to grab the jad and jar files and Bluetooth them to the N95. The Ovi Browser installed and started up only to display, "Ovi Browser does not run on this device." I finally had success with MicroEmulator, a PC Java ME emulator.
If you want to try running the Ovi Browser on an unsupported device, here are links to copies of the jad and jar files.
Running on MicroEmulator, the Ovi Browser was actually quite impressive. Like Opera Mini, the browser has two modes. With "Column View" off, it's a "keyhole browser", like Symbian Webkit, where page is displayed with original formatting intact but highly reduced in size (image above, right) and you can zoom in on a small area (image below, left). In the other mode with "Column View" On, the page is simplified and reformatted into a single column (image below, right). Both modes worked well on the sites I tried. Fonts were attractive and readable and there was no overlapping of text and images.
Fans of column view will be happy to know that it actually seems to works on all sites, unlike with Opera Mini where Mobile View is disabled and horizontal scrolling occurs on Blogger hosted blogs and many mobile sites. On the other hand the Ovi browser forces some desktop sites into Column View and disables the option to turn it off! This happens with the full version of Google News and with those pesky Blogger blogs.
One of the selling points of Novara's Vision browser was that it transcoded Flash videos on the server into a format that the client could play. It doesn't look like that feature made it into the Ovi Browser Beta. When I tried to watch a Flash video on the YouTube desktop site I got the dreaded prompt to download the Flash plugin.
The Ovi Browser's user interface is intuitive but a bit cumbersome. With Column View on the 2, 8, 4 and 6 keys scroll one screen up, down, left and right respectively. Those are the only keyboard shortcuts that I could find, all other actions are accomplished through a hierarchical menu. Consequently, it takes multiple key presses or taps to access common actions like bookmarking a site, opening a bookmark or toggling column view on or off. With column view on the 2, 8, 4, 6 shortcuts do not work making scrolling to the bottom of a long page a bit tedious. On the plus side the numeric access key shortcuts that are used by some mobile sites do work in column view.
For a first Beta, the Ovi browser is remarkably stable and usable. I'm hoping that Nokia will continue to develop this browser and bundle it with all their S40 phones. There is a real need for good proxy based browsers on low end phones and the in developing world where resource constraints, high data costs and the lack of 3G limit the browsing experience. In my experience, the browsing with Opera Mini on a feature phone actually rivals that that of any smartphone. The only thing holding back mass adoption of mobile browsing is the cost of data. Hopefully network operators will make lower cost data bundles available to users of basic phones with highly efficient browsers like this Opera Mini or the Ovi Browser.
The largest US mobile carrier, Verizon Wireless has started funneling traffic between Verizon feature phones and the web through a transcoder from Novarra. Verizon calls the service "Optimized View" and has added promotional information and a FAQ to their customer website There is also a page on the carrier's developer site which has links to a opt-out form and to a PDF document detailing the rules that the transcoder uses to determine which sites to transcode.
Given the disastrous effects that VodaFone's UK roll-out of Novarra had on mobile sites and services, I'm rather apprehensive about this. In the PDF, Verizon/Novarra say that they won't change the User Agent header or transcode sites that have submitted an opt-out request or have a URL corresponding to one of these patterns:
*.mobi, m.*, mobile.*, avantango.*, wap.*, iphone.*, <domain>/m/*, <domain>/mobile/*, pda.*, wireless.*, wml.*, xhtml.*, <domain>/m/, <domain>/gmm/, <domain>/portable
For sites that have not opted out or do not use one of the mobile URL patterns, the transcoder will change the User Agent and a number of other headers to ones mimicking a desktop browser. However the site will not be transcoded if it meets any of the following conditions:
- It uses one of the following mobile specific DTDs:
- <!DOCTYPE html PUBLIC "-//OMA//DTD XHTML Mobile 1.2//EN" "http://www.openmobilealliance.org/tech/DTD/xhtml-mobile12.dtd">
- <!DOCTYPE html PUBLIC "-//WAPFORUM//DTD XHTML Mobile 1.1//EN"
- <!DOCTYPE html PUBLIC "-//WAPFORUM//DTD XHTML Mobile 1.0//EN"
- <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.1//EN" "http://www.w3.org/TR/xhtml-basic/xhtml-basic11.dtd">
- <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
- It uses one the following MIME types:
- It has a self referencing link rel tag:
- <link rel=”alternate” media = “handheld” href=mymobilesite.com/>
- It sends a "Cache-Control: no-transform" header.
I don't have a Verizon account but I did do some limited testing in a Verizon store. I used a Motorola V950 which runs the Openwave 6 browser. I mostly tested my own sites. The transcoder seems to follow the rules in the PDF. None of my sites that use a mobile URL pattern, Doctype or no-transform were transcoded. A couple of test pages I created as copies of mobile pages but with none of the Novarra trigger conditions where transcoded even though they were under 10KB.
I didn't really test the quality of the transcoded pages but noticed that a two line navigation bar is added to the top and bottom of the page and pagination is used. I thought the transcoded version of howardforums.com was reasonably usable, but my test sites, which were under 10KB, were needlessly split into two pages.
According to Verizon, the transcoder does offer users the ability to view the original version of any transcoded page by clicking a "Turn off Optimization" link in the bottom navigation footer. As a user, I consider this a very desirable feature which all transcoders should implement.
Secure HTTPS sites are transcoded, except for "banking sites". I wonder how Novarra identifies banks? Users are warned that their security may be compromised when visiting a non-banking secure site through the transcoder. I didn't try any secure sites so I don't know what this warning looks like.
Transcoders are the bane of mobile web developers. This one will probably not be as disruptive has the Vodafone UK one was because Novarra has learned some lessons from that debacle and is doing a better job of detecting mobile sites and also because the development community is more aware of the transcoding problem and how to work around it. There should be no impact on m. and .mobi sites and others with a recognized mobile URL pattern. Sites that use a mobile doctype and don't do browser detection will also be unaffected. However, sites on .com domains that rely on the User Agent or other headers to optimize for specific handsets need to either get on the white-list or start checking the "X-Device" headers where the transcoder is putting the original values of the headers it's modified as follows:
|Original Header||Renamed Header|
The Verizon transcoder can be identified by the Via: header which it sends, "1.1 Novarra (Vision/7.3)
X-Mobile-Gateway: Novarra-Vision/7.3 (VZW; Server-Only)"
The Vodafone transcoder broke many content (ring tones, game, application) download sites. I don't see that happening with this one because Verizon already blocks almost all off-portal downloads.
The problem with transcoders changing headers is that it forces millions of mobile sites around the world to change their code in order to keep the same functionality. It's an annoyance for capable mobile web developers who somehow find out that another transcoder has been deployed somewhere in the world. The real problem is with sites that aren't actively maintained or whose developers don't actively follow the doings of the W3C or monitor the mobile development mailing lists, forums and blogs. Which, I suspect, is the majority of sites worldwide.
Verizon and Novarra claim that their transcoder partially follows the recommendations of the W3C Content Transformation Guidelines. However those guidelines are still a work in progress and the issue of whether transcoders should alter the User-Agent except in a very limited number of cases such as when a site returns no content when presented with a mobile browser User-Agent is still under discussion. It would be far better for the health of the mobile web if transcoders did not alter the User-Agent and other headers as recommended by the Rules for Responsible Reformatting: A Developer Manifesto a document that evolved from discussions on the wmlprograming Yahoo Group and which has been signed and adopted by several transcoder vendors, but not by Novarra.
Remember the furor that erupted on the web and the wmlprogramming Yahoo group over transcoders? Specifically, the ones that Vodafone UK and other carriers implemented with the goal of making non-mobile web pages more usable on mobile handsets? The issue was that these services had the (hopefully unintended) consequence of degrading or completely breaking numerous mobile web sites and services. Ring tone and game downloads no longer worked, some mobile web sites didn't load or displayed malformed content. Sites that relied on being able to detect mobile browsers and deliver optimized content no longer worked as designed because the transcoders removed or changed the HTTP headers that identified the browser, user's language settings or preferred content types.
Developers and content providers upset with the disruptions to their sites and business models rallied around Luca Passani, co-creator of the WURFL mobile device repository to formulate a document, "Rules for Responsible Reformatting: A Developer Manifesto" which suggested guidelines that transcoders should follow to avoid disrupting existing mobile sites and services. The "Manifesto" was generally well received in the mobile web development community and was also endorsed by three of the major transcoder vendors InfoGin, Volantis and Openwave. Openwave provides the OpenWeb transcoder used by Sprint.
The furor had died down, but now it's been rekindled by the W3C's release of a draft of its "Content Transformation Guidelines" recommendations, which like the Manifesto, describes best practices for mobile transcoders. The Guidelines are open for public comment until Sept 16. Anyone can comment by sending an e-mail to [email protected] (note that your e-mail address will be published on the web - I recommend that you use a disposable e-mail address!). All comments can be viewed at lists.w3.org/Archives/Public/public-bpwg-comments
Their are some clear differences between the two documents. The W3C Guidelines doesn't go as far as the Manifesto in limiting what is acceptable behavior by transcoders, particularly with regard to changing HTTP headers. The Guidelines also place a larger part of the responsibility for interoperability on mobile web developers and publishers rather than transcoder vendors. All of which understandable given that the members of the W3C, including the Mobile Web Best Practices Working Group, are primarily representatives of commercial organizations including mobile carriers, transcoder vendors and large web publishers while the Manifesto comes out of the mobile web developer community.
There are lively discussions about the W3C Guidelines going on both through the comment process and on the wmlprogramming Yahoo group. Luca and others have proposed changes to the Guidelines that would bring it closer to the Manifesto. It remains to be seen if these suggestions will make it into the final document.
In reading both the Guidelines and the Manifesto, I noticed that neither said anything about allowing end-users to opt out of transcoding. I think it is essential that all transcoders offer ordinary users a way to disable the transcoder, either temporarily for the current site or page, or globally for all sites.
In spite of everyone's best intentions, transcoders will sometimes break sites that would otherwise be usable on a given handset. If you have ever used Skweezer, Mowser or the transcoders that Google, Yahoo, AOL and Microsoft Live use to reformat web content returned from search queries, I'm sure you've noticed that some sites come up blank, broken into one line pages or missing essential parts and functionality when transcoded. Fortunately those services are opt-in, no one is forced to use them, and except for Yahoo and AOL, they offer links to the original version. With the carrier transcoders there is often no way to opt out, leaving users no alternative if the transcoded version of one of their favorite sites is broken.
Secure sites pose a special problem for transcoders as they can not be transcoded without decrypting the the secure content, potentially exposing users to "man in the middle" attacks. Users need to be able to opt out of transcoding when doing online banking or shopping when account information or credit car numbers are being passed.
I've left a comment with the W3C arguing for making user opt-out a requirement for all transcoding proxies, I won't bore you by reprinting it here as it essentially restates the above. You can read it in the W3G BPWG archives.
The issue of transcoding, is a very important one for the future of the web on mobile devices. Take a few minutes to skim the Guidelines and the discussions at the W3C and wmlprogramming and if sufficiently motivated, email comments on the W3C Guidelines to [email protected] by the Sept. 16th deadline.
Transcoders, web services that convert full websites to a mobile friendly format, can be great. If you are trying to use a site like The Economist's that doesn't have a mobile edition on a phone with an, ahem, limited browser like a RAZR V3, a transcoder is the only way. You can bring up Google on your RAZR, search for "The Economist", click the first result and get something that will load on your phone and is readable if not pretty. Yahoo has a similar service, although in my experience it doesn't work nearly as well. In fact right now, Yahoo's Novarra transcoder is failing on economist.com with the helpful message; "TR- if you see this message isCompatible is failing incorrectly."
But what if you are using Opera Mobile, Palm Blazer, the Smartphone version of Netfront or even Opera Mini on your RAZR. All of these browsers can render economist.com without any help and they retain more of the original's look, feel and features than any transcoder. Wouldn't it be great if you could search the web with Google or Yahoo and load the targets of your search in your full web mobile browser without transcoding? Well you can, there are actually several ways.
1. In Google, when you are viewing a transcoded page, scroll to the bottom and click the "View in HTML" link. Not very convenient but better than nothing. There's no such option on Yahoo's transcoded pages, unfortunately.
2. Use a special URL to force Google or Yahoo Search to send the full web version to any browser. For Google the URL is: google.com/webhp?hl=en&output=html
For Yahoo, it's search.yahoo.com/?rs=1
These URLs send Google or Yahoo's full search interface to any device whether it can handle it or not and search results will not be transcoded. Google and Yahho's simple search pages work pretty well in Opera Mini and other full-web browsers. As you can see in the top two images showing regular Google in Opera Mini's "Mobile View", the search form fits on one page and the first result is above the fold.
Incidentally, I almost always set Opera Mini to use "Mobile View". This mode reformats content into a single column eliminating horizontal scrolling. I find Opera's other ("desktop") mode, which gives a tiny "map" of the a large page where you are supposed to find the part you are interested in and then zoom in to read it, inefficient and a waste of time for most sites. Fortunately Opera offers a great "Fit to Screen" mode in Opera Mobile 8.65 and a usable, but slightly buggy, "Mobile View" in Opera Mini 4.1. Netfront, the Blackberry Browser and Mobile Internet Explorer also have fit to width modes although none of them work quite as well as the ones in either Opera browser. Nokia's otherwise great S60 browser doesn't have any fit to width capabilities.
3. Suppose you want to use Google or Yahoo's mobile search interface which returns more results on a single mobile page and includes results from both the mobile and full Webs but still want to avoid the transcoder. There are a couple of ways to do this. You can log into Google Mobile and set the "Format web pages for your phone" option to "Off" on the settings page. But suppose you don't want to login? Well if you are using Opera Mini, you can just use the Google search box on the Mini start page - or if you are using different browser you can impersonate Opera Mini with:
For Yahoo, try entering:
to access Mobile One Search without the transcoder. I find this is hit or miss with Yahoo though. It seems to work with Opera Mobile and Mini but not the Teleca full web browser on the LG Voyager, for example.
I hate it when web sites make assumptions about mobile browsers and force their users to a subset of inferior content with no way out. Thankfully, Google and Yahoo, for the most part, offer alternatives. Unfortuanately they don't publize these workarounds or make them easy to find.