Archive for the 'mobile' Category

Reading List


Sublime Text 2

I haven’t actually enjoyed using an editor since VAX EDT in my old programming days, but Sublime Text 2 is an excellent program that not only doesn’t get in the way but has lots of utilities and features.


Dell Extends Ubuntu Retail into India – Unreported, of course, because it’s about FOREIGNERS, but Dell have been featuring Ubuntu on a wide range of Dell computers in China, starting at 220 stores and expanding to 350. They’re also expanding in to 850 stores across India.


Specifying which camera in getUserMedia

getUserMedia started life as a nice little API that allowed the developer to grab video and/ or audio from a device.

navigator.getUserMedia({audio: true, video: true}, success, error);

It’s shipping for camera access in Opera 12 desktop and Opera Mobile 12 and implemented in Chrome nightlies.

The spec has ballooned since I last looked at it in detail. There is a new “constraints API” which adds significant complexity, while the language of the spec isn’t rigorous (yet). This is likely to delay standardisation yet the simplest use-cases that it originally met are the core features.

Originally, it had a method for authors to hint to the user agent which camera to use – you could suggest “user” for the camera that faces you, or “environment” for the camera that faces outwards. This has disappeared from the spec, to be dealt with later, once the complex capabilities & constraints API is fleshed out.

Should the author be able to specify which camera should be used? It seems to me that this would be a good idea. For example, my mobile phone camera is usually set to use the rear-facing “environment” camera, but if I were to start up a video-conferencing app (or any of the fun “Photo booth” apps on Shiny Demos) I’d like the app to switch to using the forward-facing “user” camera without my having to manually switch camera. (Some devices don’t have hardware switches, so would require me to go to a system preference to change which camera to use, which would be a major pain in the arse.)

I strongly feel that the Working Group should allow authors to choose which camera to use before fleshing out advanced capabilities & constraints APIs which are beyond the use-cases of many authors.

However, although most phones will continue to have two cameras, some devices like the Mito 611 have more than two. How do we write a specification for hinting which camera to use with multiple cameras?

Why HTML5 urgently needs an HTML adaptive images mechanism

After the recent kerfuffle about the draft HTML specification for a mechanism for adaptive images, and an excellent compromise suggestion by Florian Rivoal (Opera’s CSS WG rep), the mailing lists have gone quiet again.

(If you don’t know why we need such a mechanism, read Matt “Grrr” Wilcox‘s article Responsive images: what’s the problem, and how do we fix it?.)

We’ve needed such a mechanism for a while, but it’s particularly urgent now. Webkit has implemented a new non-standard CSS function called -webkit-image-set:

selector {
background: image-set(url(foo-lowres.png) 1x,
                      url(foo-highres.png) 2x) center;}

The changeset describes it:

The idea behind the feature is to allow authors to provide multiple variants of the same image at differing resolutions, and to allow the User Agent to choose the resource that is most appropriate at the time. This patch will choose the most appropriate image based on device scale factor.

(Read the email/ specification for -webkit-image-set.)

As far as I can tell, it will be in Safari 6 (OS X 10.8, shipping in July) and Mobile Safari for iOS 6, so we’ll be able to do adaptive background images but not adaptve content images.

Once that happens, I bet it’s 0.03 nanoseconds before developers convert <img src=”foo.blah” alt=”useful alternate text”> into an empty <div>s with adaptive background images using -webkit-image-set and (please!) a fallback background images for non-webkit browsers.

Why wouldn’t they? Retina screens will download massive but beautiful images, while users of lower-res phones save bandwidth by downloading smaller images instead of huge images and then reducing them down. Problem solved.

And, unfortunately, people who don’t download images, or can’t perceive images won’t get any alternate text, as there is no content <img> element any more. Those guys have always been last in the pecking order and there’s no reason to assume they’ll get a better deal this time.

And that’s why some agreement on <picture>, <pic>, <img srcset=”…”> (whatever it is; I don’t much care) needs to happen, and fast.

Update 22 June 2012: WHATWG conversation mysteriously dried, so Matthew Marquis wrote to W3C HTML WG and proposed Florian’s suggestion.

Review: Build Mobile Websites by Castledine, Eftos, Wheeler

I got this book free in lieu of payment for my Sitepoint article Notes on Designing Websites for the Asian Market. When it arrived, I looked in the index for “Opera” and found no entry at all. As this is a book is called “Build Mobile Websites and Apps for Smart Devices” and is about designing mobile websites (not just apps), I decided that the book would be another iOS wankathon, and put it immediately in my recycling pile. (“iOS wankathon” is the technical term employed by medical professionals to describe articles/ books/ conference talks that stupidly assume all mobile users have iPhones or other webkit-based browsers.)

Luckily, I decided to give it a go and picked it up just before getting a flight. It’s actually a really good book, with only one webkit wank (a very low number when “apps for smart devices” is in the title).

There’s good information on responsive web design, although it doesn’t replace Ethan Marcotte’s book, it summarises well. The second edition should add information on CSS Device Adaptation (“CSS viewport”) now that IE10 and Opera support it.

I found the chapter on design for mobile very useful with its different patterns for organising information. The chapter “markup for mobile” was less so, probably because I know more about markup than design.

One slight niggle – in an example app, the use of ellipsis is shown by including the name of a person “I am a celebrity with an incredibly long name for some unfathomable reason”. Long names seem quite common in Thailand, Sri Lanka, Russia, Greece etc; it’s only “unfathomable” if you think in the context of English names.

The only example of webkit wanking comes in the “Mobile web apps” chapter. In order to navigate from page to page, -webkit-animation is used with no other vendor prefixes. The authors have ensured that a simplified page swap is available on other browsers, but that tests WebKitTransitionEvent in JavaScript. Why not just use all the vendor prefixes and the non-prefixed version, and only then fallback to a “simplified” page swap? It’s particularly remiss when Firefox supported Animations from May 2011, while the book was published in June 2011.

Better still would be to ensure that vital functionality like navigation is available everywhere and only then progressively enhanced.

In conclusion, this is a decent book. Client-pleasing stuff such as touch, accelerometer, geolocation is covered. But while it was languishing on my shelf more cutting-edge features have become available. You can still learn from this book now, especially if you’re interested in sites that work well on mobile rather than all-singing all-dancing applications, but it would be good to see a second edition that addresses getUserMedia and proper cross-browser vendor prefixing.

Responsive Web Design: preserving images’ aspect ratio

Probably too obvious, but I thought I’d post it anyway.

One of the fundamental building blocks of responsive web design is ensuring images sit within their containers by a simple CSS rule img {max-width:100%;}.

Generally, this works splendidly. But if you’re “reponsifying” an old site, you might find that the authors included the images’ heights and widths as attributes in the HTML.

In this case, the img {max-width:100%;} can wreck the aspect ratio when the image is squeezed, as the width is forced by the CSS to shrink, but the height is still set in the HTML. See my photo of the most overloaded truck in the world and narrow the browser window.

This is easily cured without trawling through the markup and removing HTML height attributes. Simply extend your img CSS so it reads img {max-width:100%; height:auto;} and aspect ratio is preserved.

Reading List


  • Once again, discussion of installable/ packaged web app thingies. Major points:
    • Mozilla doesn’t want to reuse the W3C Widget spec because they want hosted, not installable apps. And the name “widget” is rubbish.
    • Hosted web apps are .. er .. web sites. But wrapped up, with a manifest, they can be monetized in a synergy of micropayment leverage.
    • “Installing” packaged apps can give them greater permissions than web sites. Hixie responded

      The “installation” security model of asking the user up-front to grant trust just doesn’t work because users don’t understand the question, and the “installation” security model of curating apps and trying to determine by empirical examination whether an application is trustworthy or not just doesn’t scale.

  • Two New Proposals to Solve the CSS3 Vendor Prefix Crisis
  • Last week I linked to an article that claimed adherence to WCAG didn’t magically solve all blind users’ problems. Here’s a rebuttal Methodological flaws put question mark on study of the impact of WCAG on user problems. It seems to me obvious that, while WCAG is very useful, it doesn’t replace brain, or testing.

Mobile and devices

Web Biz


Web Standards Song

“Like A Rounded Corner”, by Bruce and The Standardettes

Reading List

Vendor bloody prefixes

As you may have noticed, Opera announced an experimental Labs build supporting a handful of -webkit- vendor prefixes, based on an idea originally suggested by Daniel Glazman, CSS Working Group co-chair:

The rule should be this one: if the CSS parser encounters a prefixed property for another browser, honour that property as if it were prefixed for us UNLESS an unprefixed or prefixed for us valid declaration for that property was already set. That would drastically reduce the problems on the Web.

Here are some of the most useful commentaries (both for and against). Mostly I haven’t commented, except for Andy Clark’s piece which contained factual inaccuracies which could mislead readers.

My favourite commentary has been Daniel Davis‘ interview with Dr Stanley Dards, wise old man of the web:



Spot the difference!

An exciting competition for readers. Can you spot the difference between these two articles?

Two years ago, Dean Hachamovitch, General Manager of Internet Explorer wrote:

Today, intellectual property rights for H.264 are broadly available through a well-defined program managed by MPEG LA. The rights to other codecs are often less clear, as has been described in the press. Of course, developers can rely on the H.264 codec and hardware acceleration support of the underlying operating system, like Windows 7, without paying any additional royalty.

This week, the BBC reports Motorola wins Xbox and Windows 7 ban in Germany – also Windows 7 system software, Internet Explorer and Windows Media Player:

It follows a ruling that Microsoft had infringed two patents necessary to offer H.264 video coding and playback.


For the sake of open-ness, here’s a link to Opera’s 2011 annual report (Giant PDF!).

There is no truth in alleged “leaked emails” that our business plan reads 1) Publish photos of loads of multi-ethnic hipsters in glossy report 2) alias -webkit- prefixes 3) profit!

What Users Want from Mobile, and what we can re-learn from them

From Stephanie Rieger’s excellent piece The Best Browser is the One You Have with You, I came upon a report called What Users Want from Mobile (PDF, 3.6 MB), “A study of consumers’ mobile web and application expectations and experiences conducted by Equation Research on behalf of Compuware”, dated July 2011.

There are a couple of key nuggets in there (although the full report is worth a read). First, let’s remind ourselves that the internet contributed £121 billion (not million) to the UK last year, which is more that £2000 per person, making it 8.3% of the economy. Let’s also agree that mobile is an important and rapidly-growing part of that.

A bad experience on a mobile website leaves mobile web users much less likely to return to, or recommend, a particular website. Nearly half of mobile web users are unlikely to return to a website that they had trouble accessing from their phone and 57% are unlikely to recommend the site.

It’s pretty likely that visitors are coming to your website from non-webkit browsers: Opera is huge. It’s becoming more likely as Internet Explorer on Windows Phone 7 hits the market and when Firefox Fennec is released.

If you don’t make sure that your website works in those browsers (this means testing), 50% of those customers won’t come back. And, unless you are selling something completely unique, they’re quite likely to buy from your competitors instead:

Mobile users do not have much patience for retrying a website or application that is not functioning initially — a third will go to a competitor’s site instead.

Another interesting finding is likely to annoy some developers. When asked “What is the most common problem you’ve encountered accessing websites or applications on your mobile phone?”, respondants answered “Slow to load” (38%), “Crashed/froze received an error” (18%), “Formatting made it difficult to read and use” (15%).

This tells us that speed is more important than aesthetics. So perhaps some of the time and effort put into media queries, viewports, avoiding scrolling, line length would actually be better employed reducing HTTP requests and optimising so that websites are perceived to render faster.

Certainly, if you’re using gigantic libraries and frameworks to speed up your development, you might pause to wonder whether trading off faster development for slower loading is a trade-off you want to make, given that most users find speed to be the main problem – and problems drive consumers away and potentially into the arms of competitors.

It seems to me that old-fashioned, oh-so-dull techniques might not be ready for retirement yet. You know: well-crafted HTML, keeping JavaScript for progressive enhancement rather than a pre-requisite for the page even displaying, and testing across browsers.

They might not be cool. But it’s what users want. And if your business doesn’t provide it, your competitors will.

Added 17 April: in a survey conducted in Brazil, 62% agreed that speed was the most important feature for them while browsing the mobile web.

Reading List: mobile development approaches

Just three links for this reading list, because they show a profound schism in the way people are thinking about building applications that have previously been desktop only and take them to mobile.

The schism is the same as we’ve long had on desktop. It’s simply: do you make your target audience as wide as possible, or do you only design for people who use the same technology as you do?

The nations’s favourite social-media based conference organiser thingy, Lanyrd, launched its mobile version two days ago. I don’t own an iThing, but I assume it’s great there, and it looks and works excellently on Opera Mini and Opera Mobile on Android.

Jake Archibald, JavaScript developer at Lanyrd, said

“Although we’re employing some ‘new and shiny’ browser features, we’ve taken the righteous path of progressive enhancement and been liberal with our testing and support. While most mobile offerings are targeted at particular devices or WebKit, our support includes quirky devices like the old Blackberry 9000 (yes, it still haunts people’s pockets), the Kindle, and even basic feature-phones if they can run Opera Mini. The site works as expected without JavaScript.

Compare this with the 37Signals’ blogpost yesterday, provocatively entitled Developing for old browsers is (almost) a thing of the past:

It used to be one of the biggest pains of web development. Juggling different browser versions and wasting endless hours coming up with workarounds and hacks. Thankfully, those troubles are now largely optional for many developers of the web.

What is this fabulous remedy that 37signals have found? Simply, ignoring users of browsers that you don’t want to support. “Supporting your browser is hard – let’s go shopping”, as Barbie says, or Regressive Ken-hancement in strict Computer Science terminology.

Compare this with Jake Archibald’s comment:

All it took was *not* doing everything wildly different to how you should develop a standard website.

Summarising this dichotomy is an excellent article Did we lose track of the big picture?:

It seems to me that we are slowly switching from publishing content for the Web, to making content accessible to Screen-Readers (SR) – from targeting users, to focusing on devices and modern browsers.

We write about new techniques without considering fall back mechanisms, we use ARIA “hacks” that look like anti-patterns and we use frameworks that have chosen to ignore oldIE.

If you read no other high-level articles this month, read that one.

Reading List – Vendor prefixes, mobile, monoculture

The first reading list of 2012 is themed, rather than the usual miscellany. It’s about the Open Web and the dangers it faces.

I’ve nailed my colours to the mast – most lately in The Pastry Box:

The Web is about communication. It connects many people who previously were isolated such as those with disabilities or those in oppressive regimes. It’s a World-Wide Web, not a Wealthy Western Web. If your super-clever site only works with a mouse and monitor, on the latest $2000 super-spec laptop, with a fat broadband connection, you’re missing the point.

The ideal of universality is fundamental to the Web. Some bloke called Tim said

The principles of universality of access irrespective of hardware or software platform, network infrastructure, language, culture, geographical location, or physical or mental impairment are core values in Web design.

One of the most worrying trends we see at the moment is the erosion of this idea. In a survey, Peter-Paul Koch asked "Do you hope that WebKit will become the only rendering engine, and that the others will gradually disappear?". Shockingly, 32% have replied “yes” (at time of writing). You read that correctly! 32% actively wish for a monoculture. Because, y’know, cross-browser development is hard – so let’s go shopping! Who cares about the users? Who cares about the future? We’ve been here before with IE6- the darling of developers at the time – and look how well that went.

It’s pretty obvious that this is a case of a group of developers that believes that everyone should be just like them and should use the same devices and browsers. After all, despite all their genuflecting to Safari on their iPhones, it appears from December’s mobile statisitics (as written up by PPK) that

Opera once more overtakes Safari. It’s clear now that Android’s untrammeled growth has ended, and that the race for first position will continue to be between Opera and Safari.

(If you’d like to start testing your sites in the number one mobile browser, there are plenty of Opera testing tools available. Note: Opera is my employer, but this is my personal opinion.)

Stephanie Rieger writes in A plea for progressive enhancement

we have to start building sites using solid, future friendly principles such as progressive enhancement…not just when it’s handy or simple, but all the time.

and goes on to show a Barack Obama re-election site in which it was impossible to navigate in many devices, even some new high-spec devices. In a news report about this, the journalist quotes my three incredibly ground-breaking, never-before-heard rules:

  • Code to standards, not to browsers
  • use progressive enhancement
  • remember that you are not your user.

Yes, I know! Utterly new concepts.

However, we’re approaching a monoculture on mobile. This is not the work of an evil organisation, but it’s developer-constructed. Few people are stupid enough to use Olde-Skool browser sniffing and blocking, but we’re seeing lots of people breaking cross-browser compatibility by neglect rather than design.

One way this happens is developers using only one vendor’s CSS vendor prefix even when other vendors support the same properties. Of course, for experimental things only implemented by one rendering engine, that’s fine. That’s what vendor prefixes are for.

The trouble comes about when people do something like -webkit-transition for widely-supported properties, without the corresponding -o- for Opera, -ms- for Microsoft and -moz- for Mozilla.

Last week, Mozilla developer Boris Zbarsky wrote

People never aim to create content that’s cross-browser compatible per se, with a tiny minority of exceptions. People aim to create content that reaches users. What that means is that right now people are busy authoring webkit-only websites on the open web because they think that webkit is the only UA that will ever matter on mobile. And if you point out this assumption to these people, they will tell you right to your face that it’s a perfectly justified assumption. The problem is bad enough that both Trident and Gecko have seriously considered implementing support for some subset of -webkit CSS properties.[my emphasis]

Three years ago, David Baron (also of Mozilla) wrote Should implementors copy vendor prefixes from each other?, and in 2010 Microsoft announced that it would support -webkit- prefixes, but eventually decided against it.

Since then, we’ve had many more debates about the merits of vendor prefixes (see previous reading list), and even the co-chair of the CSS Working Group, Daniel Glazman, wrote

The rule should be this one: if the CSS parser encounters a prefixed property for another browser, honour that property as if it were prefixed for us UNLESS an unprefixed or prefixed for us valid declaration for that property was already set. That would drastically reduce the problems on the Web.

I believe vendor prefixes were a good idea, and remain so if used in a cross-browser, future-proof way. But because so many people only use the -webkit- one, I’m starting to wonder too if vendor prefixes should be considered harmful