How Flipboard Chose Form Over Function For Their Web Version
Flipboard, the iOS & Web magazine-slash-pinterest-slash-something-else content exploration platform, just released its new Web version.
I use that term loosely, because to call what Flipboard unleashed onto the world a “Web” version is akin to calling a collection of tires, AA batteries and spare car parts a Tesla.
Before I get serious, I want to commend the Flipboard engineering team for the huge amount of effort they clearly put into this project. While I am critical of their work, I do not wish to diminish how hard they worked to achieve what is, in some ways, an impressive technical accomplishment.
Flipboard, from a design point of view, has always struck me as fantastic while simultaneously disappointing. From the very earliest days the app has relied too much on designing for a certain flashiness and, as far as my personal tastes are concerned, too little on designing for utility, for function. Its success proved that it was just me who had no real use for it, and their design team is entirely worthy of the praise it’s gotten.
Similarly, Flipboard’s original iOS engineering work was phenomenal. The flashy animations were smooth as silk, never janky or even laggy. That the engineering team worked hard to attain the same level of visual splendor and performance in their web version is a testament to their commitment and attention to detail.
But again, I’m remiss to call it a Web version, as this product is an inaccessible flyer that is as ghosts in your iPhone. If you navigate by VoiceOver, don’t bother: VoiceOver doesn’t recognize any content to exist on the page.
Flipboard is a product focused heavily around text-based content, which is why it’s so deeply regretting that Accessibility was thrown completely out the window by the engineering team. The entire “Web” version was written in a pseudo-DOM (Document Object Model) inside an HTML5 Canvas element, because, as Michael Johnston wrote on the Flipboard Engineering blog:
If you touch the DOM in any way during an animation you’ve already blown through your 16ms frame budget.
Well if we can’t get 60fps for our flashy animations using semantic, accessible markup and CSS, let’s just build a Flash™HTML5 Canvas website instead!
Let it be clear: it is absolutely possible, technically, to build an accessible website in HTML5 Canvas.
It’s just really, really, really friggin’ hard!
I know the engineering team did not mean to make an inaccessible mess of a site that, despite herculean efforts, still stutters through animations on my iPhone 6 like an equally-beautiful Colin Firth midway through The King’s Speech. (Please excuse me for a moment while I check whether mine is the latest model iPhone with the fastest processor… Yes, yes it is.)
I’m also hopeful that Accessibility is the next big project to tackle for the engineering team. A 2.0 release, if you will.
But more than anything, I am dismayed.
I am dismayed that Accessibility was treated not even as a mere afterthought, but as something worth sacrificing completely for the sake of flashiness.
I am dismayed that Flipboard’s leadership chose fancy but ultimately irrelevant animations over function, over purpose.
And I am dismayed that people like John Gruber now think this solution by Flipboard is somehow “a scathing condemnation of the DOM/CSS web standards stack.”
The DOM isn’t perfect, but it also isn’t the worst
The core complaint seems to that the DOM and CSS animations cannot reliably or adequately deliver 60 frames per second rendering times. But here are some things the DOM can do just fine:
- Make content easily accessible to anyone, anywhere, anytime, using any device;
- Help the blind and the vision-impaired enjoy your content without requiring you, as author, to do anything for it;
- Render complex websites or layouts without having to invoke the full power of your device’s graphics card, thus consuming considerably less energy (i.e. battery life);
- Cater to the most diverse technology stack ever seen while remaining the most accessible of all environments to learn code and programming in;
- Not have to recompile all (or even just parts of) your code when you make changes and want to test them.
The list goes on, really, but the point is this: the DOM was never designed or architected to be something like OS X’s Core Graphics Frameworks. The DOM was meant to make information both widely accessible and easily authored, something it accomplished with such tremendous success that it was honored in one of the most prominent, powerful, and beautiful moments in Olympics Ceremony history.
Use your tools and technologies for what they’re great for. If you must use them in ways they weren’t designed for, at least try to make use of what benefits it offers. To get rid of the DOM entirely for a website ostensibly about content is simply creating a mountain of trouble for yourself where there was none.
There is certainly plenty of room for improvement in the performance of the DOM and animations, and I want us to have a technical future wherein such flashy animations can be applied to user interfaces without so much as a shrug. But sacrificing the DOM’s greatest virtues is something that cannot and should not ever be a requirement to get us there.
Update: John Gruber defended his “scathing condemnation” remarks in a very reasonable follow-up. I then responded with some short-form thoughts on Twitter, but may write more if there is a need. See also: Chris Heilmann’s thoughts on this matter.
I think our differences simply boil down to what we value and prioritize. Animation fidelity is increasingly important, but I would never advise a client with a content-focused website to sacrifice accessibility so completely (not even temporarily) just for animations. And I will always be disappointed in websites that do.
If you liked this, you should follow me on Twitter!
