I Am Finley

Mobile Web

Core Development Principles


Development shops are relying on the communications team at a finance agency to know that they should request their code be optimized for performance or accessibility. I’m going to go out on a limb here and say that shouldn’t be the client’s job. We’re the experts; we understand web strategy and best practices—and it’s time we act like it. It’s time for us to stop talking about each of these principles in a blue-sky way and start implementing them as our core practices. Every time. By default.

A List Apart

I’ve been in the web industry for 15 years, grew into my own during the web standards revolution, and have a huge heart for a11y issues. Seeing our industry revert to, in many ways, the methods and practices from before the standards movement is disheartening at best. We need, now and always, to insist on core development principles.


Virtual Hosts and Mobile Development


Virtual hosts are such a great tool for web developers to test locally without losing their mind, but web development in 2015 involves testing on far more than a single machine. If your mobile iOS devices are on the same network, here is a simple trick.

  1. Go to System Preferences on your Mac.
  2. Go to the Network panel.
  3. You should see your IP address in here. Mine right now is
  4. Go to Settings on your iOS device.
  5. Go to the Wi-Fi section.
  6. Tap the info icon on your current Wi-Fi network.
  7. Scroll down to the HTTP Proxy and tap Manual.
  8. Enter the IP address you found above into the Server field.
  9. Enter 80 into the Port field.
  10. Go to your browser of choice on the iOS device and go to your virtual host.

Simple enough for quickly testing your websites.


The Web is not Poor Man’s Native


Of course, the web development model also has its own set of challenges. In particular, there is a huge over-indulgence in trackers today, and this can wildly impact responsiveness. If you run a plugin like Ghostery for a while, you’ll quickly learn just HOW prevalent add-ins like this are. In a quick tour around common news sites, for example, I found the AVERAGE number of external tracking libraries being loaded to be more than twenty.

In Progress

Yup. When I worked at Abt Electronics, I was abhorred by the requests to add a new “tracking pixel” every few weeks. We had dozens of them on our site. A simple look under the hood showed quite clearly that the performance was hurt severely by these tracking scripts. Bringing this to the attention of an apathetic employer made me realize how bad the problem is. Marketing wants to track visitors and will not listen to developers that these things hurt the visitors they want to track. This is even more an issue with mobile networks that, even with 4G LTE, are significantly slower and more lossy than broadband.

If we simplified our webpages, stopped trying to emulate native, and stopped bloating them up with unneeded network requests, we’d have a much faster web experience than native (when considering finding and downloading of a native app).


Accessibility and Flipboard


When you build a website with traditional standard DOM techniques, you get accessibility “for free” more or less, and this is without question a good thing. I’ve been a proponent of accessibility for as long as I can remember. It does not follow, however, that what Flipboard chose to do is wrong.

It is true that Flipboard’s engineering decisions prioritize animation and scrolling performance above accessibility. That’s no secret — the title of their how-we-build-this post was “60 FPS on the Mobile Web”. It does not mean they don’t care about accessibility. My understanding is that accessibility is coming — they’re working on it, but it isn’t ready yet.

When titans clash. I love that we are, as a web community, getting back to writing instead of quick messages on Twitter. The thought that both Faruk Ateş and John Gruber have put down in words is great and the conversation is what makes the web such a great platform.

Last week, I shared a blog post from Flipboard’s engineering team about their new, mind-blowing website. Not only did they create a great desktop version of their service, but they built a stunning, Canvas-driven mobile version. Their whole reason for not using the DOM (HTML and CSS) was for the sake of visual performance and user experience. 60 frames per second. In iOS, we call this butter. It isn’t something iOS developers sacrifice. It’s the expected norm. In fact, it is by and large why HTML5-driven, app-wrapped apps are so bad. With the web stack, smooth animation doesn’t happen. When a scroll view doesn’t scroll like butter, it looks jumpy. Jumpy looks cheap. Facebook suffered from this. So they went native. Basecamp suffered from this, so they are slowly going native. My bank suffers from this but they continue using Phone Gap and it is the worst app that I am forced to use.

As Gruber points out:

Blinded by ideology, oblivious to the practical concerns of 60-FPS-or-bust-minded developers and designers, the W3C has allowed standard DOM development to fall into seemingly permanent second-class status.

The DOM was never built for what we are doing with the web today. But Faruk is right about the DOM:

[The DOM makes] content easily accessible to anyone, anywhere, anytime, using any device

This is what is difficult. If you want to build a great product, some sacrifices must be made. Gruber says so perfectly that “shipping is a feature.” Ship early, ship frequently is oft the motto of web companies, and one I agree with. Flipboard chose to use new technology that fits their product and by doing so increased the amount of effort needed to pull it off. If Gruber is right, that Flipboard is working hard on accessibility for their new web service, then I don’t see much of a problem here. Before last week, Flipboard was only available as an app. Last week that changed. Those that need accessibility will have to wait a bit longer.

But like Gruber and Faruk, I care highly for accessibility. This is why I took the opportunity with Ashes a couple years ago to involve a blind man in testing the app. With his help, most of the app is fully accessible through VoiceOver. Subsequently, Ashes was featured on a number of podcasts because of it’s accessibility. Making it accessible was an afterthought. Design and, as Faruk says, flashiness were crucial to making the app what it was. The design sold it. But accessibility came soon too.

I think in a year we’ll look back at the amazing, open-source library that Flipboard will have released for making Canvas accessible and forget that for a few months we had a beautiful, cool app that was inaccessible. But in the meantime, the conversation will continue.


Mind-Blowing Web Engineering from Flipboard


In order to optimize scrolling performance, we knew that we needed to keep paint times below 16ms and limit reflows and repaints. This is especially important during animations. To avoid painting during animations there are two properties you can safely animate: CSS transform and opacity. But that really limits your options.

60 fps on the mobile web

As an iOS developer and a web developer, the biggest difference I’ve seen is in the handling of performance. The average web developer doesn’t think for a second about optimizing rendering for mobile, preventing reflows and repaints, and far less garbage collection. If an iOS developer acted the same, their app would never run.

The engineering that went into producing Flipboard for the mobile web is absolutely stunning. The easy route would have been to make it with HTML and CSS, but the performance would have been very poor. To make it with Canvas required a lot more thought, but produced something magical.