Technology Review wrote of their experience “The future of media on mobile devices isn’t with applications but with the Web.” in Why Publishers Don’t Like Apps.”Like almost all publishers, I was badly disappointed. What went wrong? Everything … We sold 353 subscriptions through the iPad. We wasted $124,000 on outsourced software development. We fought amongst ourselves, and people left the company. There was untold expense of spirit. I hated every moment of our experiment with apps, because it tried to impose something closed, old, and printlike on something open, new, and digital.”
Lea Verou on Text masking — The standards way. I have a lot of sympathy with the view expressed by Matt Wilcox – SVG is much harder to write than a line of CSS (and I feel a bit ewww at mixing presentational SVG with my HTML). But at least this works everywhere, which is Lea’s point.
When a browser vendor implements a new css feature, it should support it, from day 1, both prefixed and unprefixed, the two being aliased. If a style sheet contains both prefixed and unprefixed, the last one wins, according to the cascade.
Authors should write their style sheets using the unprefixed property, and only add a prefixed version of the property (below the unprefixed one) if they discover a bug or inconsistency that they need to work around in a particular browser.
If a large amount of content accumulates using the a particular vendor prefix to work around an issue with the early implementation in that browser, the vendor could decide to freeze the behavior of the prefixed property while continuing to improve the unprefixed one.
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.
Opera confirms WebKit prefix usage – the .net magazine article that broke the story, based on a leaked email and catching me unawares as I was heading out for the airport
Why O, why? by David Kaneda. This is more balanced than I expected, as the author works for a only-works-in-webkit-woo! mobile framework/ library thing, although one of his 3 pieces of practical advice is to detect WebKit browsers and block them from Opera’s demos, thereby opening the Web by closing the Web, and helping users by hurting users
and the one that neatly sums up my personal ambivalence, and then acceptance of our move: Opera, -webkit-, and the purpose of browsers: “The secret to reaching “Acceptance” is to simply ask yourself, “What are web browsers for? What is their absolute primary purpose? The answer: A web browser’s primary function is to display web content.”
My favourite commentary has been Daniel Davis‘ interview with Dr Stanley Dards, wise old man of the web:
Mobile
How we use our mobile devices “more people have mobile phone subscriptions than have electricity or safe drinking water”
Reponsive News – a blog by the team making the BBC News website responsive
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.
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!
placezombies.com – a quick and simple service for getting pictures of zombies as placeholders in your designs.
Heartwarming stuff
This is why I love working with Norwegians. The ultra-nationalist terrorist mass-killer Anders Behring Breivik hates the children’s song “Children of the Rainbow” that describes a “World where – every sister and every brother – shall live together – like small children of the rainbow”. So 40,000 Norwegians got together to sing it, just to annoy him.
It’s a great example. The UK and USA are intent on showing how much we value democracy and liberty by clamping down on what people can say, see, think, and clap them in prison without trial. Norwegians, conversely, reaffirm their values of tolerance and open-ness when they’re under attack.
Lyrics of Lillebjørn Nilsen’s Barn av regnbuen (Children of the Rainbow), lifted from theworld.org:
En himmel full av stjerner (A heaven full of stars)
Blått hav så langt du ser (Blue seas as far as you can see)
En jord der blomster gror (A world where flowers grow)
Kan du ønske mer ? (Can you ask for more?)
Sammen skal vi leve (We shall live together)
hver søster og hver bror (Every sister and every brother)
Små barn av regnbuen (Small children of the rainbow)
og en frodig jord. (And a blossoming world.)
Noen tror det ikke nytter (Some don’t think it matters)
Andre kaster tiden bort med prat (Others waste time with small talk)
Noen tror at vi kan leve av (Some thing we can live on…
plast og syntetisk mat. (…plastic and synthetic food.)
Og noen stjeler fra de unge (And some steal from the young)
som blir sendt ut for å sloss (who are sent off for a fight.)
Noen stjeler fra de mange (Some steal from the masses)
som kommer etter oss (who come after us.)
Refrain:
Si det til alle barna! (Tell all the children)
Og si det til hver far og mor: (And tell every father and mother)
Ennå har vi en sjanse (That we still have a chance)
til å dele et håp på jord. (to share hope for the world.)
A subtree of a Document can be marked as inert. When a node or one of its ancestors is inert, then the user agent must act as if the element was absent for the purposes of targetting user interaction events … Note: When a node or one of its ancestors is inert, it also can’t be focused.
An entire Document can be marked as blocked by a modal dialog dialog. While a Document is so marked, every node that is in the Document, with the exception of the dialog element, its ancestors, and its descendants, must be marked inert.
The great thing about a built-in <dialog> element, even with its egregious mis-spelling, is that it will make a lot of websites more accessible. For example, many sites use pseudo-dialogs that they either write themselves or get from JavaScript libraries. Many of these don’t allow modal dialogs and lightboxes to be closed using just the keyboard, for example (see Lightboxes and keyboard accessibility for more). Building accessible dialogs into the language is far better than expecting every developer to bolt it on.
HTML5 Accessibility Chops: ‘real world’ ARIA landmark use – “From an initial analysis the correct use of ARIA landmark roles is surprisingly high. Developers are generally using ARIA landmark roles as intended. Although use is low, there is an major upward trend in use as sites switch to HTML5.”
Why We Shouldn’t Make Separate Mobile Websites – me in Smashing Magazine on why Jakob Nielsen is wrong about mobile usability. (The title isn’t mine. It’s really about why you shouldn’t always assume it’s best to make a separate site.
Mood Changes in UK Twitter Content 2009-2012 – “we analyse a collection of 484 million tweets generated by more than 9.8 million users from the United Kingdom over the past 31 months, a period marked by economic downturn and some social tensions.” With handy animation!
Safety Tat – stick-on QR codes for children in case they get lost.
“There’s no markup or API for dialog boxes, tool palettes, hovering tooltips, the contents of popup widgets, and the like.” says Hixie, and begins collecting examples and code snippets to start a specification.
“I would personally prefer the group to take on the more substantial challenge of being relevant to the world, rather than withdraw to being a de facto documentation team for a couple of companies who could easily do that for themselves.” Chaals reminds the W3C Core Mobile Web Platform Community Group that it’s a World Wide Web, and it’s not owned by Google and Apple.
Take the BlueVia Mobile Developer Attitudes survey. “Every year we fund research into Mobile Developer Attitudes and then we open source the results”
Designers respond to Nielsen on mobile – Jakob Nielsen, Queen of the Blue-Links Brigade, published some silly guidelines about mobile development recommending separate sites, cut-down content for mobile and auto-redirects to mobile sites.
Misc
A Baseline for Front-End Developers: “There’s a new set of baseline skills required in order to be successful as a front-end developer”, which Rebecca Murphey lists, with links.
My finest ever spam phone call troll: a 15 minute audio in which I attempt to seduce “John” who called to do a “survey”, and cajole him into singing his questions to me.
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.
Polyfill for getUserMedia by Addy Osmani, uses Flash as a fallback. Not production ready – more IE testing required, and anyway, the spec is shifting again (events rather than callbacks anyone?)
sendthemyourmoney.com: “The MPAA & RIAA claim that the internet is stealing billions of dollars worth of their property by sharing copies of files. They’re willing to destroy the internet with things like SOPA & PIPA in an attempt to collect that money…Let’s just pay them the money! They’ve made it very clear that they consider digital copies to be just as valuable as the original…Take a picture or scan an image of your money. Send digital copies to the MPAA & RIAA in whatever quantity you feel you can afford.
localstorage
There has been much discussion that localstorage is dead and we should all stop using it because IndexedDB is much better. It’s also 676% harder to learn. I initially wrote “Not sure that localstorage is broken. But “localstorage-for-big-data-eg-images-because-vendors-can’t-agree-on-a-DB-API” is certainly so.”
So localStorage is slower than using an in-memory object. Cars are slower than airplanes. What does that tell us? Not a whole lot. …The reason localStorage is popular is partly due to its simplicity… The proposed alternative, IndexedDB, is perhaps one of the worst API designs I’ve ever seen.
What is HTML5 – surprisingly good, 90 second explanatory video for not-so-geeky. Sadly, it loses 98 Brucie points for starting with the word “So”, which is about as sensible as beginning a talk “Notwithstanding” or “Nevertheless”.
Video, multimedia
Encrypted Media proposal in which reps from Google, Netflix and Microsoft propose a form of DRM for HTML5
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.
“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.
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.
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.
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 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.)
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.
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]
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…
