“Native experience” vs styling select boxes

I mused about this on stage at Fronteers 2013, and was reminded of it when reading Stephanie Reiger’s excellent slidedeck The future of media queries?, specifically slide 42 which I reproduce with Stephanie’s permission.

Stephanie suggests a mechanism of telling a user agent to render a navigation list as a native component, so it looks native across a range of devices, because it is native. (We could bikeshed about the markup and whether it should be in the CSS, but that doesn’t matter.)

I get that developers want their sites to appear native on the host device. Presumably users like native feel, too; there’s a reason why users show a huge preference for native apps over web apps, and one of those reasons is that native apps

allow the user to use device-specific hand gestures. Android and iOS are gradually developing different conventions for interaction, and a native app responds the way its user expects. User Experience Stack Exchange

So Stephanie’s idea makes perfect sense to me.

But what puzzles me is the fact that for ages designers and developers have also desperately tried to style away native controls. For example, recently Nicholas Zakas said

and was retweeted hundreds of times. Nicholas isn’t wrong to want this, and this wish isn’t new; when Safari first came out, designers were close to burning their moleskines because they couldn’t make buttons in corporate orange and heliotrope. When I first started showing HTML5 form controls at conferences, without fail I’d be asked how they can be styled. There are endless articles and scripts that painstakingly take real selects, hide them more or less accessibly, then recreate them so they don’t look native on any device.

But why this urge to re-style page elements that end-users are familiar with? You’ll be shocked to learn that I’m not actually trained as a designer – so what am I failing to understand? Or is it that we love native look and feel, except when we don’t?

UPDATE 21 July 2014: Aaron Gustafson wrote an interesting response to my post: The “Native” vs. “Stylable” Tug of War.

Reading List

Apps For All: Coding Accessible Web Applications – book review

(I was sent a free ebook of this title. That hasn’t influenced my review. This ebook is published by Smashing Magazine and costs €10.95. There’s a sample chapter available. I have no financial connection with the publisher or author.)

When I read about this book I was excited to read it. I don’t need Yet Another Accessibility Book (I co-wrote one a long time ago) but wanted something that delves deeply into WAI-ARIA and how it interacts with HTML5 and assistive technologies. As this book’s blurb says “the underlying theme of this book is about making the interactivity of web applications include keyboard and screen reader users”, it seemed like the book for me. It’s also tech-reviewed by Steve Faulkner who’s my go-to Bogan for practical accessibility information, so I was pretty sure I could trust it.

WAI-ARIA is one of the vital specifications for making the web accessible. There are three problems with using it, though: firstly, the spec is hard to read and understand, even in the context of specs’ inherent indigestibility; secondly, it’s hard to understand how its concepts intertwine with other specs like HTML and, thirdly, most developers don’t use assistive technologies so are unable to understand or test the output of their ARIA pages.

Therefore, I greatly appreciated that author Heydon Pickering is a developer, so keeps the book practical. ARIA is used, in conjunction with markup and script in situations that you’d really encounter. The problem to be solved is elucidated, and the output is clearly explained. It goes deep, too; I learned a great deal and plan to re-read it soon.

It’s a short book (but quite dense) and Heydon’s prose style is clear and occasionally humorous. But don’t let that fool you; this is an important book because it’s the only one that thoroughly explains the technical merits and use of ARIA (and doesn’t browbeat the reader about accessibility).

Without hyperbole: every developer should read this book, and put its techniques into practice. Now.

Reading List

Education for the teenage girl: classic movies

As the proud owner of a teenage girl who’s turning into a fine young woman, I’ve reflected on the various stages of parenthood:

  1. spending 49% of salary on baby food, and 49% on nappies
  2. bedtime stories
  3. grazed knees and reassurance
  4. helping with homework
  5. realising you’re unable to help with homework
  6. pretending not being sad when they say they hate you
  7. making them work for relatively trivial amounts of money so they understand that money is valuable
  8. being polite to spotty herberts with ludicrous hair and unstable voices (Teenage Boys)
  9. “this is a house not a hotel”
  10. “Bye!”

The daughter is pretty well-equipped for adulthood. She already excels in many aspects of the curriculum at Bruce’s Finishing School for Modern Young Ladies® – she can fart outrageously, think deeply, belch loudly, accept differences, kickbox and knock down arse-gropers, play guitar, say “no”, say “fuck off”, spin out a really good joke to entertain both friends and eavesdroppers on a bus, get a paedophile deported, support her friends, swear inventively and hold her vodka down.

So I’m beginning a programme of watching classic movies with her. Not worthy art films, just those that have a different view of life, are surprising, or beautiful, or don’t portray women as idiots or trophies to be won, or simply those you’ll feel embarrassed saying “I haven’t seen that” at a student party.

Here’s a list so far:

Your recommendations (with a line about why) would be highly useful.

Poem: It is a hot evening in July

My university friend Richard was doing some paperwork at his house and found a magazine published in the late 80s with three of my poems in it, each of which I’d written to capture one single moment or emotion. For no other reasons than it’s fun for me to rediscover my younger self, and because right now it actually is a hot evening in July, and also because I want to pretend to be all sensitive’n’shit, here’s one of those poems:

It is a hot evening in July. You and I
lie, naked, on the bed. My cigarette smoke
dances in the sun’s fading rays, and hangs in the air
like angels, waiting. Are you awake?
Yes, it seems that you are.
You run your fingers through your raven-black hair,
slowly. Your eyes are half-closed. Your eyelashes are long.
Your skin is pale, glazed with sweat. Your lips are wet.
Stubble in your armpits. Nipples dark, erect.
One of your legs gently massages the other, so slowly.
Perfect.
I lie back, exhaling slowly, and kiss you.
But you do not kiss me.
I have often noticed this: you will reciprocate,
but not initiate. A clock ticks somewhere.
You retain fragments of a fractured innocence:
You remind me of a fallen angel. There are no words.
A smile comes to your lips and I say, What’s funny?
You do not reply.
It is a hot evening in July.

It is a hot evening in July:
humid; quiet. You sigh.
We breathe heavily, in unison.
The sound of next door’s radio
floats languidly through our window to the world.
You hum along, inaudibly. I light another cigarette as
you shift to your side to face me. I stare at the ceiling
and send a smoke ring drifting
which hangs over your head and dissipates.
Your hand rests on my stomach, your head on my chest.
My free arm around your shoulders.
I can hear your heart beat.
I can feel your heart beat.
Somewhere a clock is ticking.
You look up and smile to me; our eyes are solemn.
And then you kiss me and I could cry.
It is a hot evening in July.

Reading List

Being a compendium of links that I’ve read, or tweeted, gathered together for those who don’t hang around on twitter all day. Inclusion here doesn’t imply endorsement, just that I found it useful or interesting.

Standards ‘n’ Stuff

Misc (no LULZ)

Reading List

Ten years of WHATWG

A little over ten years ago, on 4 June 2004, Opera employee Ian “Hixie” Hickson sent a mail titled WHAT open mailing list announcement announcing

a loose, unofficial, and open collaboration of Web browser manufacturers and interested parties. The group aims to develop specifications based on HTML and related technologies to ease the deployment of interoperable Web Applications

Ten years is a long time, especially so in software, but nevertheless, the achievements of WHATWG have been remarkable. Hixie wrote

The working group intends to ensure that all its specifications address backwards compatibility concerns, clearly provide reasonable transition strategies for authors, and specify error handling behavior to ensure interoperability even in the face of documents that do not comply to the letter of the specifications.

Core aspects of the web platform were never adequately specified. XMLHttpRequest, for example, was shipped in IE5 in March 1999, and reverse-engineered and shipped in Firefox, Opera, Safari and iCab, but never actually documented until Anne van Kesteren co-specified it in WHATWG in a Working Draft of 5 April 2006. Anne’s currently working on the Fetch Standard, which defines something as basic as “requests, responses, and the process that binds them” and the Encoding Standard:

While encodings have been defined to some extent, implementations have not always implemented them in the same way, have not always used the same labels, and often differ in dealing with undefined and former proprietary areas of encodings. This specification attempts to fill those gaps so that new implementations do not have to reverse engineer encoding implementations of the market leaders and existing implementations can converge.

Of course, the poster children of WHATWG are the slew of new APIs that “HTML5″ brings us – Web Workers, Web Sockets, native video and audio etc etc. There have been mistakes along the way (of course there have, in a decade!). Last year, Hixie told me

My biggest mistake…there are so many to choose from! pushState() is my favourite mistake, for the sheer silliness of ending up with an API that has a useless argument and being forced to keep it because the feature was so desired that people used it on major sites before we were ready to call it done, preventing us from changing lest we break it. postMessage()‘s security model is so poorly designed that it’s had academic papers written about how dumb I was, so that’s a pretty big mistake. (It’s possible to use postMessage() safely. It’s just that the easiest thing to do is not the safe way, so people get it wrong all the time.) The appcache API is another big mistake. It’s the best example of not understanding the problem before designing a solution, and I’m still trying to fix that mess.

But to me, the biggest triumph of WHATWG has been error-handling and interoperability (actually, two sides of the same coin). We’ve moved from a vision of the future where everything was supposed to be XML and browsers were to stop parsing if they met malformed markup, to a present where every browser knows how to construct an identical DOM from the most mangled/tangled HTML. We’re moving to a world where interoperability is paramount, and where specifications are made in the open, in constant consultation with developers (for example, Service Workers, Web Components) based on real use-cases.

I think the existence and the work of WHATWG has secured the viability of the web platform. Happy 10th birthday. And thanks.

Reading List

A small reading list this week, due to there having been a bank holiday this week, and my pre-occupation with being a snot factory.