Archive for the 'mobile' Category

Reading List

HTML5 etc

Responsive Web Design

Mobile

Misc

Reading List

Industry

Misc

Reading List

NEWT

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.

Industry

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.

misc

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

Standards

  • 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

Misc

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:

Mobile

HTML, CSS

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.

Opera

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.