Don’t Settle for a Mediocre HTML5 App Experience

Posted on by

Since Facebook announced their decision to ditch their HTML-centric app experience for a native one, I’ve been doing a lot of thinking about what that means for the HTML5 versus native debate. Unfortunately we’re at a point in the circle of tech where it’s easier to build a great native experience than it is to build a great HTML experience. I’d argue it’s not impossible to build a great HTML experience on mobile devices, just more difficult (I think Untappd is a great example, photo bugs not withstanding). The problem is that runs directly counter to why most people choose to go the HTML route and that causes a host of issues.

Today, when someone decides to build a mobile app from HTML, it’s primarily a developer-focused decision and not a user-focused decision. What I mean by that is that often times HTML makes it easier/faster/cheaper for someone to deploy a mobile app. Maybe they have a bunch of web developers and want to quickly crank out an app. Maybe they want to target multiple devices and they see HTML as a way to reuse code. Those aren’t bad reasons to chose HTML5 necessarily, but they do drastically change the goals of a project from “make this as awesome as possible” to “make this as good as we can with our constraints”.

So it’s no wonder that a lot of the HTML mobile app experiences are subpar. They started with the very premise of wanting to do it cheaper/faster/easier. That’s not a path to software greatness. Facebook again provides an example here. They had a ton of HTML content they wanted to reuse and an HTML-centric app was a fast, easy way to repurpose that content for mobile apps. Plus they could deploy it to lots of different kinds of devices with minimal code changes. They didn’t start from a place of wanting to make a great mobile experience, and the results spoke for themselves. When pressure finally got to a breaking point and they had to create a great mobile experience, they went with the clearest path to that route – native. This tweet by Josh Clark implies as much. It wasn’t that the HTML app was fundamentally unfixable, it was that (I assume) they looked at what it would take to make it as good as the native app and decided it wasn’t worth the effort.

I don’t blame people for making that judgement call. The PR boost that people used to get from throwing HTML5 into their marketing has started to subside and at the end of the day your users aren’t going to forgive a crappy mobile experience because you got 5 in a row on buzzword bingo.

HTML developers are in a rough spot right now because once you take out the faster/easier/cheaper argument, it’s tough to provide reasons why HTML is better than native apps. I see three main reasons. One, the web is a fantastic medium for designers and allows very unique experiences. Two, the ecosystem around web technologies has never been stronger and the number of cool frameworks, tools, and libraries that are available to web developers could have a significant impact on the kind of app you can build. Three, it never pays to bet against the web.

The first two I’ll cover in later posts and the third is the most subjective anyway so I want to talk briefly about that. For most apps, the future isn’t going to matter, so this isn’t a “future proof your code” argument. It speaks deeper than that. Do you want to be the kind of company who makes the future, or do you want to be the kind of company who follows along? HTML is the future. Just like native fell out of favor on the desktop, native is going to fall out of favor on mobile devices. The APIs are getting better for device access. Core graphical capabilities are being added that will make for nicer components, better experiences, and faster UIs. And the web is bigger than one company. The web is the great equalizer in tech. That leads to its own sets of drama about how we add features, but at the end of the day, no one will own or control the web. I see the web as a glacier. It tends to move very slowly, which can be a drawback. But when it moves, it brings everything with it and it carves a deep, permanent path that completely changes the landscape. That’s a tough thing to try and stop or stand in front of.

When you see an HTML mobile app that’s not as fast or snappy as it should be, think about what problem they were trying to solve. If the answer isn’t “build the best app possible” then don’t take that as a good example of what HTML is capable of. And if you’re building an HTML app put the same amount of effort, thought, and design into it as you would a native app. With the breadth of design possibilities, the HTML/JS/CSS ecosystem, and some forward-looking vision, you can build something that helps turn the conversation back to why the web is such an awesome medium for applications.

Related posts:

  1. UcompOS Rich Experience Framework
  2. Does Experience Really Matter?
  3. A Response to Benjamin Sandofsky’s Shell Apps
  4. Salesforce.com Looking to Give Customers a Better Experience
  5. Pandora Nails it: Pay a Premium for the Experience
  • dazweeja

    I’m not sure Facebook is a good example. It’s just a poorly written HTML app. Despite the resources they potentially could have thrown at it, Facebook obviously didn’t or they just had poor developers. That might seem improbable given the importance of mobile to Facebook’s strategy but it’s true. These sorts of HTML vs Native comparisons would make more sense if you were comparing a well-written HTML5 app with a Native equivalent. Of course, it doesn’t help on iOS that UIWebView is considerably slower than Safari either which impacts all HTML apps. Apple cites security concerns for this situation but these are clearly not insurmountable – they just lack the will to fix it. HTML apps on iOS would be much faster and snappier if Apple wanted them to be.

  • TommyBoy

    I disagree that html is faster/easier/cheaper option. It looks like it in the beginning but it always ends up the other way around and all companies/digital agencies are starting to realise that. PR on HTML5 was phenomenal, but that was just PR. It turns out it takes ages to get apps/ websites finished, it turns out some features are not available in certain browsers, oses, etc and you end up with this unmaintainable file of crap code with billions of exceptions that has cost you way more than anything else. HTML5 is just a buzz word that many people turned into the coolest thing on the web without actually being able to write apps and websites in anything else than html javascript and css. All those stunning examples you see on the web take ages to build and to be honest I could write them in Flash in a quarter of the time. 

  • Adobe Evangelist

    “HTML is the future.” Perhaps you should update the statements about the Flash Platform on the ‘About Ryan’ page.

  • Julian Lawton

    One thing to remember is that native apps are often still web apps – they are making heavy use of HTTP, RESTful web services, JSON and XML – without that architectural layering a lot of native apps would have been impossible to develop.

  • Shawn Blais

    TommyBoy hit the nail on the head.

    There’s nothing wrong with easier/faster/cheaper, this is what Unity3D enabled, Unreal Engine 3, .NET, etc etc, it helps maximize profits and allow you to quickly move on to new projects.

    The problem is that HTML was never in a position to provide that. It was never the right tech for the job.

    It will never win over native apps cause the DOM is a pile of crap, and renders inconsistently on every device, which will always always always skyrocket your costs over native or a proper middleware solution which compiles to native.

  • http://blog.digitalbackcountry.com Ryan Stewart

    I agree, and think that’s the problem. People choose HTML because it’s *supposed* to be faster/cheaper/better but it doesn’t turn out that way for a variety of reasons. 

  • http://blog.digitalbackcountry.com Ryan Stewart

    I think games are a much different beast because they’re not as dependent on UI components as most HTML apps are. When you’re building something that’s completely branded, like a game, it’s easier to reuse code than something where you have to drastically change UI elements to be cross platform.  

  • http://blog.digitalbackcountry.com Ryan Stewart

    Hah, done, thanks. 

  • http://blog.digitalbackcountry.com Ryan Stewart

    It’s always interesting to me that these native apps are built on the web infrastructure. I think in some ways that only helps the case for the wider use of web technologies on mobile. 

  • http://blog.digitalbackcountry.com Ryan Stewart

    The UIWebView on Safari is a huge, huge deal, and you’re right. Hopefully it’s something that will be addressed down the road. But the problem with HTML vs Native comparisons right now is that I don’t think we have a lot of spectacular HTML examples. 

    And that’s the premise of the article. Even big companies like Facebook that *could* do it start from a place of “lets do this because it’s faster/cheaper/better”. Then when it comes time to actually build something polished, they go native because it’s easier to build a great looking native app than a comprable HTML one right now. 

  • Shawn Blais

    This is a false assertion though. UI of the top tier of applications is not really OS specific, for example SnapSeed, Clear, Adobe PhotoShop, PicShop, none of these are using traditional UI elements. Likewise for Android applications, the best ones are the ones that have ditched native UI completely (though this has changed with Android 4)

    In fact. it seems to be a staple of AAA native apps that they go out of their way to create custom UI.

    PicShop is my app, it works on Android, iOS, Blackberry, off a single swf. It has a 4.5 star rating on Android and Playbook, and 5 star rating on iOS. It ranks 12th on iPad and 30th on iPhone in Photography.

    The problem isn’t using middleware. It’s that HTML is a lousy (read: expensive and time consuming) middleware to use.

  • http://blog.digitalbackcountry.com Ryan Stewart

    That app looks awesome. And I agree that a custom UI is critical and often preferred, I just think it’s tough for a lot of developers to do. And for a Photo app like yours, I’m not sure HTML would even be a good option because it wouldn’t have the power to do a lot of the filters/effects it looks like you’re doing. 

    But I don’t think that means you can make a blanket statement that HTML is lousy. It looks like it would have been lousy for your app but I think it could have been a good choice for Facebook if they’d optimized, tweaked, and stuck to it. 

  • Shawn Blais

    Ya, I mean it’s suited to some things. My main issue with it is just an inherent thing though. Because there’s no reference implementation of the DOM, the implementations are inconsistent.

    This makes HTML a unique platform in that it’s core display layer is completely unreliable. 

    It’s hard to really imagine this every going away as new OS’s and browsers versions are created constantly.

  • http://twitter.com/matthewfabb matthewfabb

    When writing an mobile web app from scratch, it can be very time consuming. However, it’s not the case when a developer or team uses one of the many JavaScript frameworks like jQuery Mobile or Sencha Touch. A huge amount of resources continues to poor into these and other frameworks and they continue to get better and better.

    On the flip side, I still see companies making simple apps for one mobile platform or another, when they could have gone cross platform. Like most recently, the Toronto International Film Festival making an app for iOS and Blackberry (the later is a sponsor), while ignoring Android. The festival itself is only a week and half long, the app has the film schedule, descriptions of the films, a map of theatres and links to social media. They could have easily made an cross platform app and reached a wider audience. It wouldn’t have been native, but in this use-case, I don’t think it really needed to be native.

  • http://blog.digitalbackcountry.com Ryan Stewart

    That’s a good and interesting point. I’d argue that jQuery Mobile and Sencha Touch, while getting better, don’t come anywhere close to competing with native frameworks on speed and performance. Is that part of the problem? That when you go native, you get access to fantastic frameworks/UI components that make building an app better? Whereas on the HTML/hybrid side, the frameworks are a lot slower and to get good performance you either have to build from scratch or really, really tweak the frameworks. 

  • http://profile.yahoo.com/M5CHRLTGSTKXWN6HXAHR5G7X7M p

    “Just like native fell out of favor on the desktop, native is going to fall out of favor on mobile devices”Wanna bet ?

  • http://googma.blogspot.com/ Googma Sansar

    thank you for your nice post. i got many ideas from this post and it is really helpful to improve my blogging.