Archives for posts with tag: HTML5

There are a lot of great reasons to build a mobile Web app just as there are a lot of great reasons to build any Web app and I’m certainly not here to continue the great Web versus native app debate. It’s not native versus Web, it’s both and it depends on your situation.

But what I’m here to talk about are the pretenders. Pretenders are mobile Web apps that try to replicate the native experience. You’ve no doubt seen Web apps with iPhone-style back buttons, awkward attempts at implementing gestures, laggy scrolling and the like.

Pretenders have problems

They don’t meet user expectations
Users of pretender apps get an experience that falls squarely in the uncanny valley — it looks like a native app, but something isn’t quite right. Perhaps it doesn’t respond as expected or it doesn’t quite follow the conventions of a native app. Often pretender apps have both of these problems and then some. They simply don’t feel “at home”.

They are a huge drain on development resources
Development teams can spend countless hours trying to make the Web act native. How many times have you heard that HTML5 is “almost there” in providing  a native-equivalent experience? But the gap between “almost there” and “all there” is significant and may never be closed. Just imagine how many hours have been spent trying to improve the performance of scrolling lists. It’s fine to tackle these problems as part of an open source project, but if you’re attempting to solve these problems in your product you are consuming valuable time that could be spent making your product better!

Embrace the Web

If you’ve decided to deliver your app via the Web, you should embrace the capabilities and constraints of the Web. Don’t spend time and resources making a pretender app, spend that time making a great app that works on the Web.

Bagcheck offers a good example of a mobile Web app that embraces the Web. Instead of using floating headers and footers in an attempt to replicate a native app, the page scrolls like any other Web page. A simple anchor link is employed to allow users to quickly jump to the bottom of the page where a set of menu options appears. Because Bagcheck doesn’t pretend to be native, performance is great and the app offers up a mobile-optimized UI that meets user expectations. In other words it acts like what it is — a website.

Bagcheck Mobile Web

Bagcheck's Mobile Web app feels right at home in the browser

Stop Pretending

If you’re making a Web app, don’t pretend to be something you’re not. If you do, your users will notice right away and it will turn them off. Besides, it’s a lot of work doing all that pretending. It’s far easier to embrace the Web’s constraints and capabilities and doing so will result in a much better product.

See Also

You’re probably already familiar with Adobe AIR. In case you’re not, here’s how Adobe describes AIR:

The Adobe® AIR® runtime lets developers use proven web technologies to build rich Internet applications that run outside the browser on multiple operating systems

In other words, AIR lets you build desktop apps using Flash. You may be using at least a few of them right now. For example, I currently have TweetDeck and Yammer installed on my Mac.

Unfortunately, there are a few problems with AIR:

  • Like Flash, it’s a resource hog (on Macs, especially)
  • It’s installed software which means it needs frequent updates (both the apps themselves and the AIR runtime)
  • It’s proprietary

The Site-specific Browser as an AIR Alternative

If you’re a Mac user, you may already be familiar with Fluid. Simply provide it with a URL and it will create a site-specific browser.

Fluid settings
Fluid settings

Below you can see how Fluid has created a sort of “headless browser” for running Gmail. It’s the same Gmail I access in my browser, but now it looks like an app. No URL bar, bookmarks, etc. Just an app window and the Web page.

Headless GMail browser
Headless GMail browser

Fluid application tiles even support badges, so I know how many unread messages I have (far too many, in this example).

GMail running in a headless browser

In many cases, a Fluid-style solution may be all the user is looking for; a way to run a Web app as a stand-alone application.  The advantage here is that, once installed, the app is served up just like any other Web app, using standard HTML, JavaScript and CSS (or even Flash). Imagine, no more update dialogs telling your users a new version of the app needs to be downloaded, or worse, that AIR itself needs an update. No uncanny valley problem with an AIR app that looks and acts almost (but not quite) the same as it’s browser counterpart, which can lead to user confusion and frustration.

Of course, there are  big advantages for the app developers themselves. Everyone who downloads their app automatically gets a modern, HTML5 compliant web browser by default. They don’t have to port their traditional Web app to Flash just to get an application on the desktop. And if they’ve built the app in HTML5, they even get the offline functionality that many companies now rely on AIR to deliver.

This solution is obviously not for everyone and it doesn’t provide all of the features you get from AIR apps (e.g. toaster alerts), but it does offer a very lightweight solution for web app developers who don’t want to port their traditional apps to Flash.

Follow

Get every new post delivered to your Inbox.

Join 42 other followers

%d bloggers like this: