Ripping mobility from the clutches of telecom
Skyfire Launch – Proper Mobile Browser Behavior
For the last few weeks I’ve been helping out the folks at Skyfire with some bits and pieces of projects they needed some backup on. They have a new browser for mobile devices, initial release is for Windows Mobile devices, but they plan to add additional platforms before too long. See their blog for the official story. As Rafe reports the browser is proxy based with most of the logic living on the server side. The result is that the browser is as standards compliant as the base it’s built on (which is Mozilla), so all the normal settling time about corner cases of CSS support and Javascript pretty much go away. Hopefully folks won’t have to deal with the “how will my page render on this additional platform” question as web property owners.
However there are some questions from the mobile side they would like to answer but haven’t sufficiently worked through yet. For instance what information do you send up to the server to make sure you get back “the right page” for a user. We’ve gone through these kinds of discussions before around belligerent or hostile proxy activity.
But say you have the ability to render a desktop page on a mobile device in a way that was never possible before, and to do it across platforms. Do you identify yourself as a desktop browser and display the full version? Or do you mix in some info about the device and possibly get the mobile version instead? Sometimes content or downloads meant for your device are based on reading out the user agent associated with your device. If we send that along the original phone user agent (using something like the unfortunately named X-OperaMini-Phone-UA header) then site owners have to pick up an additional header to act on. And at times it’s hard to pick up the original user agent unless you can sniff it out during an over the air download.
In the proxy world the accepted proper behavior is to pick up the handheld version header and redirect directly to that. One possibility is to provide some UI elements that indicate there’s a handheld version available and give the user the option to switch to that.
It would be great if there was a way to pull together some of this different stuff (pickup up additional headers from proxies and browsers and proxy based browsers) so that developers don’t have to add new logic every time a new browser or service comes out. Until the overall questions are settled it’s hard to standardize, but then again code speaks pretty loud. I wonder if just making a set of rules and an implementation would be the best way to handle the proliferation of techniques. The specs and standards don’t really seem to address the root issue here. For instance the content transformation landscape doc from the W3C is aimed at a much different level – once you have some content how do you handle it. Where this is more of an identification issue, how do you properly represent what you are so that you can get the “right” content?
| Print article | This entry was posted by miker on January 28, 2008 at 2:28 pm, and is filed under Software, Technology, ThisIsMobility. Follow any responses to this post through RSS 2.0. You can leave a response or trackback from your own site. |

about 2 years ago
I think the issue here is the need to identify not only the browser, but also the device. UAProf’s have this ability, (especially with the diff header), but haven’t seen very good adoption.
Most user agents in the web world already indicate both the browser and the OS.
What is to stop the User-Agent being an extended form of something like:
Mozilla/5.0 (SonyEricssonK800i/R1JC)
This, along with suitable accept headers indicating supported content types that would be passed through directly to the native browser (Like OMA mime types) would be a clean solution? It identifies the browser to allow the site to select an appropriate rendering, but also indicates the device keeping people needing to target content at specific handsets happy.
Some of the earlier Opera Mini releases I saw presented the underlying device as part of the user-agent, but this seemed to be phased out later on, which is a pity in my opinion.
The disadvantage of using headers other than the user-agent and other common ones (accept header for example) to tailor the presentation, is that most proxies are very flaky with properly handling the vary header for caching except when used with common headers.
Steve
about 2 years ago
Steve, the problem we saw with including the device identifier in the UA was that some sites would give us WAP 1.0 content e.g. when they spotted the word “Nokia”.