Google recently announced the Ice Cream Sandwich version of Android, along with a new version of the WebKit-based browser. Lets have a look at what is in there that’s of interest for web developers.
User agent switching, or a knock to the mobile specific site?
When I was working with web site compatibility at Opera, one of the biggest complaints we got time and time again was when a popular site switched to giving the mobile version of the site rather than the desktop version. Despite perceived wisdom from developers that users are in the mobile context and want mobile optimised sites, the reality is users screamed blue murder. Especially when the site gave no option to switch back. The reasons were usually two fold. One: many users knew their way around the site and where they had to go (even when they only accessed the web on a mobile device) and two: often they wanted to use a feature that the developers had decided the mobile version didn’t need. Many of these users couldn’t just wait until they were on a desktop PC to use those features as their only way to access the web was through a mobile (think rural China, India or the Philippines for example).
One perfect example was GMail. If you tried to sign up for an account (no one does that on mobile right?) it would say something likesign up for an account on a PC. These users were completely locked out of the site with no way to get an account.
I suspect Google has been getting the same complaints Opera was getting, especially as Android is starting to become popular in developing countries. For the Android 4 browser, they have added a way to switch to the desktop site on a per tab basis:To get the most out of web content, users can now request full desktop versions of web sites, rather than their mobile versions. Users can set their preference for web sites separately for each browser tab.
If I’d hazard a guess about how they do this, then it would be that they switch the user agent string to that of a desktop browser such as Chrome. That way the site developer will think it is a desktop browser and will give the desktop site. If they cloak well enough, there will be no way for the developer to force users into using the mobile site. I think this is a good thing, as it will open up choice to the user, and force developers to think about making their regular sites as friendly as possible. This is exactly what the mobile first brigade have been preaching. I suspect things like Media Queries will still work as expected in desktop mode. It will certainly put a dent in the firearms of those that want to browser sniff to give (or try to give. It always goes wrong. I’ve lost count of the amount of issues I had to deal with related to sever side browser sniffing for mobile browsers going wrong, across almost every major site) a tailored experience to mobile devices.
So to recap, to guarantee a good experience on Android, you will need to make sure both your mobile site and your desktop site is mobile friendly. Or use one site and adapt via things like media queries.
Roboto, a new high DPI optimised font
Times change fast on mobile. Back when Android was first released, Google worked with Ascender Corp to produce the Droid family of fonts. One of the main design goals was to produce a font that worked well at small sizes on the restricted resolutions of mobile devices at the time. Thus, the letterforms were condensed to fit as maximise how much text could fit on screen.
Fast forward to today and mobiles are ever increasing in both DPI and screen real estate (Galaxy Nexus has a 4.65 inch display at 330ppi!), and mobile platforms have expanded to tablets. With these new circumstances, Google has developed a new font in house by Christian Robertson called Roboto.
The font has been created from scratch for high DPI screens. It is a geometric font, somewhat reminiscent of Helvetica. As it is the default font, this is the font your site will be using unless you specify otherwise. You should be able to use it where you use arial or helvetica today without any problems. As it is included in an open source product, it will assumably be available to download freely, just like Google allowed with the Droid family. Be careful if you were planning to use it on desktop platforms however. In a comment in defence of the font, Robertson stated:since Android doesn’t use much of the nastiness that is TrueType hinting, Roboto is not hinted to support older Windows browsers, for example.
He mentions a few of the design choices in that post, and it is will worth a read. It remains to be seen whether the font gets accepted in the design community, and we will have to see it in its native environment, but I personally feel the UI looks much more fresher with it. I’m unsure of the Droid family, or any other fonts are also available for developers. I expect there should be at least one serif font, but you never know.
One of the key things for web developers is the capabilities of the web browser. The Android browser has always lagged its desktop cousin, and was stating to get a bit of a bad reputation with web developers. Although they haven’t switched to Chrome (yet) in Android, we do get a new version of WebKit. The official docs report that this is WebKit 534.30. By comparing UA strings, it looks like this is the same version used by Chrome 12. However, just because the desktop version supports a feature, it doesn’t mean the code path was enabled on the Android branch of WebKit, or any porting work was done to expose a feature to the browsers.
New on phones
While tablets have been running Honeycomb, phones have been stuck on Gingerbread. If you’re developing towards phones, then all the features added to Honeycomb will be available to you for the first time. Highlights include:
- SVG (Finally!)
- CSS3 3D Transforms
- Device Orientation Events (access to compass/direction)
- File API
- HTML5 async and defer attributes for scripts
New since Honeycomb
There are not a huge number of toys to play with, but there are a few including:
- HTML5 Details and summary elements
- Blob URIs from File API
- TypedArrays (Originally from WebGL)
- Navigation Timing (performance spec)
- Updated CSS3 gradients to specced version
Thanks to caniuse.com for the comparison data.
So that WebKit version that corresponds to Chrome 12? How does it really stack up? Well a pretty huge difference actually. Some of the key things still still missing include:
- Server Sent Events
- Drag and Drop
- History API
- HTML5 Forms (would be very useful on mobile)
- Progress and Meter
- File Writer
- SVG Filters
- Web Notifications (these are almost like they were designed for mobile)
- WOFF (although does anyone use WOFF now TTF is well supported?)
This is not to mention the features that have been added since Chrome 12. Our new Chrome overlords can’t come soon enough.
So where are we at?
We have some thinking to do regarding desktop sites on mobile being within easier reach, no matter if we like it or not. We have a new font similar to Helvetica as a new font, and a faster more standards web browser to play with. On the whole it is a competent update, but hardly earth shattering for web developers. The Safari browser on iOS is still ahead in a number of key areas in terms of standards support. With Opera Mobile 11.50 reaching 285 on the HTML5test (not featured on the site yet, nor is Android 4), I expect that still has the best standards support on Android currently.