I’ve recently become the owner of an Android tablet (Galaxy Tab 8.9) and having spent some time browsing the web with it I’ve identified a couple of areas where work by us, as developers, can make a real difference.
The first is the easiest: use appropriate HTML5 input elements. It’s quite frustrating typing an email address into a text input field when the
@ symbol is on a different interface view to the
_ symbol, or when predictive text is enabled, and there’s really no need for it when HTML5 input types are well supported and — crucially — fully backwards compatible. So if you’re asking the user to input an email address, use:
The same goes for other form fields.
The second area for improvement is slightly more complex: stop browser sniffing if you can, or stop making presumptions if you can’t. On a number of sites I get redirected to a mobile-optimised view, as I’m guessing that the browser detection script finds ‘Android’ in the UA string and presumes it’s a phone.
By far the worst culprit is Yahoo, whose UA sniffing either misidentifies or fails to identify the browser on my tablet, and serves me the most basic mobile interface. I’m using a brand new tablet with a very capable browser over a solid Wifi connection, and I’m served what is essentially a WAP site.
To add to the frustration, no link to an alternative or full site is provided, so I have no choice at all. If use about:debug and change my browser’s UA string to ‘iPad’, there’s a tablet-optimised version of Yahoo Mail that works (almost) perfectly with my device; but otherwise the UA sniffing is actively working against me.
Capability detection should always be preferable to browser UA sniffing, but if you must use UA sniffing at least keep it updated, don’t make presumptions, and provide an opt-out link to the desktop site as a basic option.
That’s it: two changes, making a much nicer experience for everyone.
As you’re no doubt aware, HTML5 video is this year’s big thing — but there’s a dispute going on about which should become the default standard video codec. The current nascent de facto standard is H.264, but recently the new WebM format is gaining traction.
I’ve no idea how the web video format war will end. My preference is that a free, non-patent encumbered, high-quality video codec will become the standard, and WebM is the best fit for that description. Despite the recent announcement by the MPEG LA, the patent pool which controls licensing of H.264, that it will always be free for ‘video delivered to the internet without charge’, that still doesn’t make it free-as-in-speech, and still not free-as-in-beer for anyone wanting to build a business around video encoding/decoding (which includes, if I’m not mistaken, bundling it with a browser). All that said, my preference is meaningless in the face of so many vested business interests.
In my previous post, Making HTML5 Video work on Android phones, I said that you have to encode your videos as
.m4v in order for them to work in Android. This isn’t actually correct. The suffix can be either
.m4v, what matters is the way the video is encoded.
Now, there are loads of blog and forum posts which give differing advice on presets and parameters, and I’m no expert — so what I’ll do is just show you two quick ways that worked for me (I have a Samsung Galaxy S).
I recently became the owner of an Android phone* and found that, despite it being listed as a feature of the browser, the HTML5
video element didn’t work for almost all of the examples I tried. I’ve just done some experimentation with this and think I’ve found a solution, so this post is offered in the hope that it helps anyone who may be tearing their hair out over the same problem.
As Firefox 3.5 brings open video to the web, the W3C decide to drop codec requirements from the HTML 5 spec, citing disagreement between browser makers and concern over patents. Luckily, there’s a way to make video for everybody, which means encoding each clip only twice.
To much fanfare (the blowing of their own trumpets), Opera today announced Unite, a new service which lets you use the browser as a personal file server and social space. I haven’t had more than a passing glance at it yet — my URL is home.stopsatgreen.operaunite.com, if you’d like to see if I’m available — but it certainly looks interesting. Useful? I’m not sure yet.