• On Treating the Web as a “Platform”.

    Published in: Web Development.

    I haven’t previously weighed in on the native apps versus web debate. In fact, I feel that the debate is largely over. It’s not that either has won, but rather that we are using each for its strengths. Today, though, I believe I’ve gained new clarity on the functional delineation between native and web, and what the web needs in order to achieve “native-like” experiences.

    The Strength of Ubiquity

    The Web has a great advantage: it’s everywhere. Building for the web is to embrace fragmented clients and, in response, progressive enhancement. The fundamental function for the web is universal access. Once you start trading access for animations, access for modularity and encapsulation, or access for clientside functionality, you’re trading away the biggest strength the web offers.

    If you build a native app, you know that only those on your target platform will have access. And that’s okay, you’ve made that tradeoff decision up front.

    There seems to be a common idea (or maybe it’s just loud) in the web community that we can treat the JavaScript-enabled browser as a platform and build something native-like that hits anything that has a browser. Well, anything that has a modern, JavaScript-enabled browser. And by “modern,” we mean “meets all the requirements for my framework.”

    The Problem of Web as Platform

    I don’t have a fundamental problem with building for target audiences that are smaller than “anyone with a web browser.” I do think that trying to achieve larger reach by publishing to the web and then limiting that reach by requiring a certain level of browser functionality is confusing, but that’s not the real problem. The real problem is that we know so little about the environment in which our product will be used.

    Right now, today, we cannot reliably implement gestures in websites. The risk for colliding with native gestures in the mobile browser is just too great.

    The Web, and web apps by extension, exist as an app inside an app. The browser is not an OS, it’s an app: it has its own gestures, interface, and controls. And our websites exist inside of them. It’s not just a needed-functionality problem; it’s a UI problem. Are we placing our UI controls right next to the browser controls? Are our gestural power-features conflicting with the browser’s gestures?

    Building for the web requires a certain amount of letting go, a level of agnosticism towards platform and environment. We cannot treat the browser (or webview) as a clean environment; it has its own opinions.

    “Native-Like”: A Brief Sidebar

    I’ve come to believe that web apps will never truly rival native apps, for a single, simple reason: user interface conventions. iOS and Android have conflicting UI conventions. Take tab bars as an example: iOS guides you to put them at the bottom of the view, within easy access of the user’s thumb; Android guides you to put them at the top, so as to not conflict with the ever-present Back, Home, and Recents OS/hardware controls. When we first began building sites for mobile after the iPhone, the web, at mobile sizes, was designed to look like iOS. Now, though, mobile web design has largely embraced the same conclusion that we reached on the desktop: the website can contain its own design conventions and shouldn’t mimic the OS. This is a good place to be. Web apps shouldn’t attempt OS-level cohesiveness.

    What We Need for True “Web Apps”

    To truly achieve a native-like experience with web technologies, we need an opinion-less environment, and we need to know when our web app is being run in such an environment versus a browser or another app’s webview. This may be met by the HTML5 Web Application Manifest, or something similar, I don’t know. I do know that it’s not being met currently.

    If we know that our website is being run as such, we can make assumptions about our environment and treat our session as a native app that happens to be built with web technologies, otherwise we can default to an ubiquitous, environment-agnostic site.

    And there’s a lot of power in ubiquitous, environment-agnostic sites.

    A Plan From Here

    My current strategy doesn’t change. Build for the web because of its reach. Build for the web for everyone. Build for the web first; it’s reach is too large to ignore. Build for native for what native can provide: hardware access, gesture support, and an experience coherent with the OS.

    Perhaps soon we’ll be able to take advantage of more and more of these native functionalities with web technologies that run as first-class apps. But we’re not there yet.


    1. Implementing Responsive Images on Goizueta.emory.edu.

      Published in: Web Development.

      A couple of months ago, we implemented responsive images for Goizueta Business School’s website. I want to give a summary of how we did it. Our site is quite large; content and assets are edited by multiple people, managed and overseen by a Marketing and Communications team. A responsive images solution needed to be dead […]

    2. Tonx Coffee Review.

      Published in: Reviews.
      Tonx Quilanga Macchiato

      Tonx is a coffee subscription service, delivering freshly roasted coffee right to your door. I was aware of Tonx through various mentions on Twitter, but was able to give them a try through their Starbucks gift card exchange program, as I had received a Starbucks gift card from Christmas. Overview The service is pretty straightforward; […]

    3. Notes on Luke Wroblewski’s “Mobile Design Now” Workshop.

      Published in: Web Development.

      Luke Wroblewski takes and shares great notes from talks that he attends. They’re big shoes, and I don’t expect to fill them, but here are my notes from Luke’s “Mobile Design Now” talk. The Mobile Opportunity Arguing for Mobile With the growth in mobile, it’s difficult to argue that we shouldn’t address mobile The Mobile […]

    4. A Reflection on Day Two of An Event Apart Atlanta.

      Published in: Web Development.

      The second day of An Event Apart has wrapped up. I would say that only one new theme emerged, a couple of talks tied in with one of yesterday’s themes, and a couple of talks stood on their own ground. Test Everything The dominant theme in today’s talks was the importance of testing. As builders […]

    5. A Reflection on Day One of An Event Apart Atlanta.

      Published in: Web Development.

      Having finished the first day of An Event Apart Atlanta, I’ve come away with a lot of good information. My notes are much more extensive than this post, but these are the common themes I felt emerge from the various talks. The Web is Complicated The largest theme of the day was that the web […]

    6. In Defense of Southern Snow.

      Published in: Life.

      When snow hits the South, it is often accompanied by condescending remarks about the South’s seeming overreaction to “just a little bit of snow.” I don’t argue that we don’t see much snow in the South, or that we take conservative measures with it, but I do think the patronizing commentary on our plight is […]

      Tags: ,
    7. On the Pursuit of Home Espresso.

      Published in: Food & Drink.

      For a while now, I’ve known that the biggest factor limiting my home espresso was my grinder: it just couldn’t grind finely or consistently enough. My shots were weak and watery. I compensated by using dark roasted beans and increasing the overall volume, but I knew that’s all I was doing: compensating. I even began […]

    8. Recommended Reading, Volume 5.

      Design Hey, Designers: Stop Trying To Be So Damned Clever (via @necolas) What Screens Want (via @jonathanstegall) Life Welcome to Dinovember (via @seriouspony) You and Your Research (via @blankenship) Face-o-mat Travels the World – 2013 (via @chriscoyier) In The Stanley Parable, Finding The Story Is The Game Web Development The Pastry Box Project: November 12, […]