Flipboard and the “mobile web” dream…
Sunday, February 15th, 2015 at 12:33 pmAccording to the luminaries of the web design world, the “mobile web” doesn’t exist. Stephen Hay said it, Smashing Magazine said so and Jeremy Keith amongst many others.
Except, it does. Not as a technical reality, but as a dream of marketing and overly excited managers who believe in magical powers of their engineers. And it is nothing new. We’ve been there before, and we probably will get there again. Every few years a new form factor or technology comes out that promises a web that is catering perfectly to a very niche need whilst being open and available to all. Or – in other words – water that is almost, but not totally wet.
Flipboard’s magical journey at 60 fps
Last week Flipboard engineering released the Kraken with their “60 fps on the mobile web” post, explaining how they managed to give the new “web version” of Flipboard a buttery smooth 60 frames per second on mobile by forfeiting the DOM and rendering the whole thing in Canvas. The general outrage was that it was read as a call to give up on the DOM and use react.js and Canvas instead.
Not surprisingly, this sparked a lot of discussion and annoyance toward them. But let’s step back a bit: first of all, it is a good thing when engineering teams publish their findings and tell us why they made some decisions. It can be a great learning resource and is a courageous thing to do. In a world where people spend most of their time dismembering technical posts on hacker news putting yourself out there means you also need to deal with a lot of polarised feedback. You need to learn fast how to deal with trolls and people using these systems to grandstand. So, thanks are in order – thank you, Flipboard. The post is detailed, it explains what they tried to do and how they achieved it.
The usefulness of such a resource starts getting questionable when hype kicks in and people take it as gospel. Flipboard did not claim that what they do is the perfect way to achieve happiness on mobile. Instead they are very open about their intentions:
In the pursuit of 60fps we sometimes resort to extreme measures. Flipboard for mobile web is a case study in pushing the browser to its limits. While this approach may not be suitable for all applications, for us it’s enabled a level of interaction and performance that rivals native apps.
Right now, mobile is still hot. HTML5 is still hot. A company pushing the boundaries of both is hot. That’s why it is good value for a tech company to write articles like that. And I am 100% sure the Flipboard engineers have the heart in the right place and rightfully are proud of what they have achieved.
Solving the right problem with the wrong approach
That said, the title is terrible as it promises a simple answer to a huge problem. Or, on reflection, not a problem, but a massive misunderstanding.
What this post told me most of all is that it isn’t solving an issue of the web. It is about simulating a native interface for a mobile touch device at 60 fps using web technologies. It’s aim is to run smoothly on the currently hot device that the most affluent people use – let’s say the iPhone 6. They are not beating around the bush about this at all:
Now we’re coming full circle and bringing Flipboard to the web. Much of what we do at Flipboard has value independent of what device it’s consumed on: curating the best stories from all the topics, sources, and people that you care about most. Bringing our service to the web was always a logical extension.
There’s a massive flaw in this: it tries to bring value independent of what device it is consumed on and then it applies assumptions and concepts that are only beneficial to a mobile, touch-enabled device.
This is a porting exercise. This is bringing something to the web. It is not creating a web product. That would be reaching as many people as possible, and making your content available independent of hardware, ability and environment. You can not “go to web”. The web is not another form factor when your starting point is a very restricted environment. That’s how we got text-only versions of Flash movies and “accessible versions” of DHTML monstrosities. Using web technology means you start with the assumption that you have no control over the way your content is consumed. And that’s as far removed as it can from what Flipboard said:
Flipboard launched during the dawn of the smartphone and tablet as a mobile-first experience, allowing us to rethink content layout principles from the web for a more elegant user experience on a variety of touchscreen form factors.
And this is why calling this a web experience is ill-advised from the get-go. As Faruk Ates put it:
…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.
This is not about the technical implementation. The flaw is in the idea of turning a native app that was specifially designed for a certain form factor into a “web version”. The journey explained is full of assumptions.
The first one is the big 60. All our web technology efforts need to match the 60 fps threshold or they are useless, right? Well, looking at my Nexus 5 device with Android Lollipop and anything I could do to be state-of-the-art I can safely say that not a single app works consistently smoothly at 60 fps or doesn’t stutter from time to time. So, I guess, I have no apps.
Of course, we need goals to aspire to and some things to measure against. But defining something like 60fps as a baseline is pretty naive considering the fragmentation of hardware and the amount of abstraction layers an HTML5 app has to go through. Maybe considering less greedy interaction models might be a way forward?
Which brings me to the second assumption: endless scrolling is what the web is about. And from there, the article tries to make that work. True, a lot of solutions have endless scrolling. Also true, many a time that is more annoying than a pagination would have been.
What Flipboard did here is to build a native-feel solution in an environment that has no native paradigms. There are no form-factor standards on the web. They change constantly. The parallax scrolling page today is the multi-level DHTML drop-down of tomorrow.
Stretching the canvas
It is a daring and seemingly clever solution to go for canvas to reach good performance in an endless scrolling interface. But that’s all it is – a currently clever solution with a very short shelf-life. As Rachel Nabors put it:
Re: recreating the DOM in canvas and accessibility: we will look back on this as a hack. Browsers will catch up, will render the DOM faster.
When working on Firefox OS and low-end devices, the main issue just a few months ago was that canvas was too slow and people used the DOM instead and complained that it is the wrong API for games. The push was towards canvas to become hardware accelerated or – even better – mobile browsers to support WebGL. Now we have this and many a DOM solution using all kind of 3D transform tricks in CSS to force hardware accelerated layers look silly. Much like this might look silly very soon.
The honest approach to this would be to give the article the title “How we created endless scrolling at 60 fps on high-end mobile devices by replacing the DOM with Canvas”. But that’s not as quotable and it doesn’t make you sound like a trailblazer solving a “real and very common” problem.
Access denied
Flipboard already admits that in terms of accessibility, this is a horrible solution. Screenreader availability aside, my warning bells went off when I saw elements with not only fixed positions on the screen but also fixed dimensions. And when you use a tool that supports text but means you need to calculate line breaks, I’d get a queasy feeling in my stomach. There goes resizing the font. There goes copying and pasting. There goes translating a text. All things the web is great at. And it is nothing new.
Every single time we replaced text with graphics to gain more control we had to re-invent these basic features of a text-based web. Remember image replacement techniques of headlines before we had web fonts? Remember how Flash had to bend over backwards to seed the browser history and to make text highlight-able? Remember how it was impossible on mobile devices to copy and paste at all?
When reading the section of the post about accessibility I get flashbacks to horrible times:
This area needs further exploration. Using fallback content (the canvas DOM sub-tree) should allow screen readers such as VoiceOver to interact with the content. We’ve seen mixed results with the devices we’ve tested. Additionally there is a standard for focus management that is not supported by browsers yet.One approach that was raised by Bespin in 2009 is to keep a parallel DOM in sync with the elements rendered in canvas. We are continuing to investigate the right approach to accessibility.
Wait a second. Re-read this, please, and tell me if I am crazy when I think this sounds like a lot of duct-tape around a leaking faucet.
We have a perfectly accessible way of achieving all of this: we call it HTML and we have the DOM and the accessibility API. That way we’d have a perfectly working web site that gets found, indexed, is accessible to a lot of people. We can then convert into a fast performing canvas solution on mobile devices that are touch-enabled. We can test for that – web technology is good at that. Think about it: a data source that comes with lots of accessibility benefits and already has an API to read it in part? Sign me up.
Instead we consider adding a lot of HTML content inside the canvas element as a fallback and hope browsers and assistive technology will do something with that.
Content inside canvas becomes interesting when canvas isn’t supported. Today, that’s an almost non-existent use case. Browsers support canvas. It is a blank, stateless placeholder in the page that we paint on and wipe. It is an etch-a-sketch in the page. It isn’t even vector based – it is a dumb collection of pixels. That’s why canvas is fast – the Flipboard article does a good job explaining that.
Canvas is to HTML5 what DIV and SPAN are to HTML4 - it has no semantic meaning. It is a placeholder for generated, visual content. Not text, not interactive elements. When canvas came to be, the first comments were that it is the new applet. And that is still quite a sensible way of describing it from a markup/semantic meaning angle. It is as much a black box in the page as Flash was to the rest of the markup.
Replace the DOM, but not its virtues
The problem with Flipboard’s solution to the mobile performance issue is that it wants to use canvas because of its stateless and high-performance nature and get all the benefits of HTML and the DOM at the same time. This is asking too much.
We could, however, get quite a long way by creating our canvas content from HTML that is in the document. And that is what it means to build a web product – you build a sensible HTML solution first, and then use CSS and JavaScript to enhance it. That way you don’t need to worry about covering the basics after you fine-tuned the final product. That approach will always result in disappointing fallbacks that are hardly ever maintained.
The “mobile web” thing
The whole goal of this exercise was to match native performance by using web technology and applying ideas of native environments. And this is a thing we should be aware of. The mobile web.
The issue is that according to this post and many others of the same ilk, the mobile web exists. The mobile web is not a technical thing – it is a misconception and one that is hard to match. Companies nowadays start with a native experience. This is where the short-term gain is. This is where the short-term high user numbers lie. This is the beautiful technology – the shiny devices, the backing from OS vendors and the exciting interaction models that come with the OS. It feels good, it feels that there is something to work with.
Then these people hear about the benefits of web technologies: cross-platform support, lower cost of engineering as you don’t need to pay experts of red-hot new technologies, re-use across different form factors and so on. A lot of times this happens when the honeymoon period of the native solution is over and there is new growth to be unearthed.
Then, they want both. Hence, “the mobile web”.
We have two issues to battle with this: a technical problem and an image problem.
Let’s talk technical first: matching the performance of a native app with a web app is a game the web can currently not win. At least not if all you count as performance is its fps speed and how well it integrates with the OS. The reason is that the cards are stacked against us. Unless the browser becomes the most important thing in a mobile OS, we will always have a hacky experience.
To the OS vendor, the browser is a necessary thing to offer – another app much like the calculator or the phone app. From a marketing and monetary point of view, having people build exclusively for your platform with your tools and in your languages is a win-win. You have a captive audience and you can show their numbers in huge figures during your keynotes to your stakeholders. Making the browser amazing means you have to share.
Add to this the ridiculous browser fragmentation and the amount of zombie browsers on older systems that will never get an update again and you will find that matching the newest and coolest of the native offering is really hard.
The image problem is that the web seems stale. Our market thrives on hype and short term gains. All our messaging about the web is praising its longevity. What you do now means you will benefit in years to come, even if it means some extra work. Your products will be easy to maintain for years to come. Future technology will already support what you do now and it will be easy to extend if you use progressive enhancement. This is our messaging, and it is great messaging.
Except when all you care about is the next month’s user and download numbers and how many people posted selfies and sent stickers to each other that you sold them. Then this message is just noise and sounds like arrogant “in my days” speeches.
If we love the web and want it to work out, we need to pick our battles. And the real battle lies with operating systems not having a browser we can rely on. And with lack of support of very basic features we need to give an app experience across browsers and platforms. And with a lack of standards that really get to fruition and are implemented instead of being replaced by a library that is open source, but never leaves beta.
The mobile web is real – and it isn’t. It is a dream of people who don’t get the nature of the web trying to harvest its benefits. And right now, these people get all the VC money and get the tech press excited as they promise something new. The hype as it is now is not sustainable. It killed these people once in the dotcom boom and will again – very soon.
We can stomp our foot about that and get angry and we can repeat tiring old messages. Or we can bide our time and fix what is broken and keeps us from performing the way we want to. Let those who need the quick short-term win pretend they found the solution. Our time can be used differently. The amount of devices, form factors and user needs is not decreasing any time soon. The web can cover all of them. Let’s make that happen once the fever dream of the one true app form factor is over. Much like there is not one mode of transport to cover all needs, there is no such thing as a perfect app or interaction model.