Aanand Prasad

Offline Support is Valuable, and You Can’t Add it Later

2011-08-13T22:11:00Z

Non-trivial offline functionality in a web application is more valuable than you might have initially assumed, if you care about the user experience on mobile devices. It’s also not a feature you can easily add after you’ve already built a working product. It has a profound effect on how your app should be designed, and you have to plan for it from the outset if you don’t want to end up rewriting the bulk of your communication logic.

If you’re designing a web application to run primarily on desktop browsers, you’ve probably already decided against implementing offline functionality. That’s entirely fair: there’s almost always an Internet connection available, and you’ll save yourself a lot of time.

If you’re considering implementing a mobile interface, though, you would do well to seriously consider implementing offline support too, even though mobile users usually have an Internet connection. Let me explain.

Why It’s Valuable

Mobile Internet connectivity is rubbish. I’m a Vodafone user living in London, and seeing the 3G icon in my iPhone’s status bar is as commonplace and pleasurable an event as finding somewhere you can sit down to drink on a Friday. This has profound implications for the assumptions you can make when designing the communication logic of your application, if you value the mobile user experience. To lay it out:

You can’t assume a request will complete in a short time.
You can’t assume a request will even make it to the server.
If it does, you can’t assume the response will make it back.
If the request does fail, you won’t know whether it made it to the server or not.
If the connection is slow, or flaky, it may well stay that way.

For every single type of request your application will make, you will have to deal with these limitations. Consequently, if you’ve come straight from the world of comparatively fast, always-on broadband, many things you’re used to doing are now anti-patterns. Off the top of my head:

When a user initiates an action that requires communication with the server, you can’t expect them to wait, doing nothing, until it’s succeeded—they could be waiting for minutes.
If the action fails due to network error, you can’t simply tell them to try again in a moment—if it failed once, it’ll probably fail again.
If the user wants to perform several such actions in quick succession, you really can’t do either of the above two things. Have you ever used an application that worked that way? You can feel your hair greying.

An application designed along these traditional lines, built on the assumption that an Internet connection is not just available, but reliable and fast, will be incredibly frustrating to use over a poor-quality connection.

What I’m getting at is that offline support isn’t just a way of making your app usable when there’s no Internet connection. It can also be a way of making it usable when the Internet connection is awful, which, depending on the app, could be a much more common occurrence. You simply need to broaden your definition of “offline” to mean not just “there is no connection”, but “there is no good connection”.

Why You Can’t Add it Later

As touched upon earlier, the workflow for processing actions in an application that assumes a fast, always-on Internet connection goes something like this:

User initiates action.
App makes request to server.
If the request succeeds, the UI is updated to reflect the changes to application state.
If the request fails, the user is notified.

The problem with this design is that the assumption of connectivity is fundamental. In the absence of a good Internet connection, it’s merely annoying. In the absence of any Internet connection at all, it fails at step 2.

The good news is that, in my limited experience, getting into the offline mindset requires only one key realisation: when you leave the world of timely, reliable communication, the local database, not the server’s, must be the gateway for all persistent changes in application state.

When I say “the local database”, I really mean HTML5 Local Storage, and when I say it must “be the gateway”, I mean the workflow must change to something resembling this:

User initiates action.
Changes to application state are persisted locally.
The UI is updated.
At some point—now or later—the local database and the server are synchronised.

Which, you might realise, is how native smartphone apps are designed. The good ones, anyway.

When your application is designed this way, its “offline” usability skyrockets. Many common user actions—checking off a todo, archiving an email, composing a blog post, reading something previously downloaded—can be performed with no latency and little to no loss in immediate utility. Indeed, Backbone.js’ example todo app is a functional and useful application that never even needs to talk to a server.

The not-so-hidden cost of this approach, of course, is that you have a new responsibility: you must ensure every update makes it home. That means retrying requests when they fail. That means ensuring actions are never processed twice, so my blog post doesn’t appear multiple times just because it got through the first time but the response never made it back. It might also mean preserving the order of actions performed.

In short, it means you have to carefully design your application for eventual consistency—given enough time, the server and the client will agree. Because the client is no longer a dumb terminal—it’s a node in a distributed system, with its own opinion of the current state of the application.

Indeed, “the current state of the application” no longer has a canonical meaning. What if the user has the application installed on two devices, and has made updates on both of them? Proceed far enough down this rabbit-hole and it becomes necessary to leave behind the Newtonian universe.

If this sounds like more trouble than it’s worth… well, it might be. Your call. But I hope I’ve made the value of offline support clearer, and if you’re planning on implementing it, I hope you’re really planning it.

Better Tap Behaviour with jquery.tappable.js

2011-07-05T20:13:00Z

The behaviour of tappable elements in Mobile Safari is unacceptably ugly. Unfortunately, taking control of it is more involved than it perhaps ought to be. jquery.tappable.js does (most of) the hard work for you.

I hope we can all agree that mobile web apps shouldn’t pretend to be native apps, but I don’t like the thought of having to accept the current state of most mobile apps as the hand we’ve been dealt. The whole business feels somewhat 2000-era, which is frankly weird—we’ve spent a good decade improving the look and feel of apps in the browser, but the majority of mobile web apps seem content with a half-hearted grey-boxes-and-lines style and a rigid, transitionless interactivity.

Does the responsibility lie with the vendors of mobile browsers? Partially. Apple are only now getting round to adding native support for scrollable elements: so far, we’ve been stuck with a range of lovingly crafted fakeries that range from ‘pathetic’ to ‘uncanny valley’. The problem goes beyond the slow pace of change, though—even when the functionality required to implement higher-quality interaction is in place, it’s often in such a way as to leave an inordinate amount of work to the app developer. A perfect example of this is the default behaviour of ‘clickable’ (or, rather, tappable) elements in Mobile Safari.

Tap a link, a button or indeed any element with a click event defined, and two unpleasant things happen. First, nothing, for around 300 milliseconds. Then, an ugly dark-grey overlay—you know the one I’m talking about. Compared to the responsiveness of tappable UI elements in native apps, using a mobile app where every element behaves this way feels like operating your iPhone with someone else’s finger.

In developing nnnnext, I quickly came to the decision that this wasn’t good enough, and set about trying to fix it. While removing the overlay was easy enough, it quickly became obvious that iOS’ touch behaviour is more complicated than I intitially suspected, primarily in that it treats a “long tap” differently from a “short tap”.

Perform a short tap (i.e. literally just tap the screen), and the element is immediately highlighted and the appropriate action executed. Perform a long tap (keeping your finger down for a moment), and the element is highlighted after a short delay (around 150ms) and the action executed when you lift your finger—unless you move your finger first, in which case the highlight is immediately removed and the action cancelled.

The reason for the long-tap highlight delay became apparent after I’d coded my initial implementation: if the element is immediately highlighted when you put your finger down, then every time you scroll you’ll get a flash-of-highlight if you happen to start your scroll by putting your finger on that element. This is, I believe, why the delay is only in place on large, column-spanning elements of the type you can’t avoid touching when you scroll, while buttons and other small widgets react the moment you touch them.

I realised some of this only after implementing an incorrect solution, releasing it and blogging my ignorance. Another fact I overlooked is that Mobile Safari’s behaviour only deviates from the rest of the OS on short taps. Long-tap behaviour is the same, but with short taps, both highlighting and action are delayed, and for around twice as long as the long-tap highlight delay! The reason for this (though I failed to perceive this blindingly obvious fact at the time) is Safari’s double-tap-to-zoom feature—if there were no delay, or if it were much shorter, double-tapping would be impossible.

In most mobile-optimised web apps, however, zooming isn’t even enabled, rendering any short-tap delay worse than useless. Here, then, is our desired behaviour, expressed in terms of browser events:

Event order	Desired effect
touchstart, timeout, touchend	Highlight on timeout, fire callback on touchend (long tap)
touchstart, touchend, timeout	Highlight and fire callback on touchend (short tap)
touchstart, timeout, touchmove, touchend	Highlight, then de-highlight on touchmove (long tap cancelled by scrolling)
touchstart, touchmove, timeout, touchend	None (scroll)
touchstart, touchmove, touchend, timeout	None (scroll)

I promised up there in the first paragraph that I’d done the hard work for you, and here you go: jquery.tappable.js implements this behaviour, and falls back to click events in desktop browsers for good measure.

It deviates from the above table in one respect, however—the highlight class is removed (or, in the case of a short tap, not added) before firing the callback. This is a matter of code aesthetics for me: I don’t want a library or plugin I’m using to add a transient class to an element without cleaning up after itself. When I need the highlight class to stick around longer (which in the nnnnext codebase is the exception, not the rule), I add it again in the callback function.

Anyway, examples:

// Basic usage
$(element).tappable(function() { console.log("Hello World!") })

// Add a delay
$(element).tappable({
  callback:   function() { console.log("Hello World!") },
  touchDelay: 150
})

// Don't cancel taps when the user moves their finger
$(element).tappable({
  callback:     function() { console.log("Hello World!") },
  cancelOnMove: false
})

// Don't highlight the element OR fire the callback unless a
// specified condition is met
$(element).tappable({
  callback: function()   { console.log("Hello World!")      },
  onlyIf:   function(el) { return $(el).hasClass('enabled') }
})

Have fun!

Prototype Chains and CoffeeScript Subclasses

2011-05-20T13:16:00Z

In developing nnnnext.com, I tackled a surprising number of problems I’d not faced before in my web development career. Here’s one of the more interesting ones, with what I think is a pretty cute solution.

Context, briefly: nnnnext is a todo list for your music. It’s a single-page JavaScript app written in CoffeeScript and utilising Backbone.js for lightweight MVC. Importantly, it has two similar-but-separate user interfaces: one for desktop web browsers, and another for multitouch devices.

Both interfaces are implemented as a set of classes (provided by CoffeeScript’s simple classes implementation) that represent the different UI views. Each UI requires slightly different behaviour for some views. For example, an element might contain a button that (in the desktop UI) appears when the element is hovered, and (in the touch UI) appears/disappears when the element is tapped. Consequently, some view classes are subclassed in one or both UIs in order to implement these differences. The class structure might look like this (implementation code omitted):

Views   = {}
Desktop = {}
Touch   = {}

class Views.Widget   extends Backbone.View
class Views.Thinger  extends Backbone.View
class Views.Sprocket extends Backbone.View

class Desktop.Widget extends Views.Widget

class Touch.Widget   extends Views.Widget
class Touch.Thinger  extends Views.Thinger

(Whatever you think of classical object-orientation and inheritance, it’s an undeniably good fit for MVC-style UI code—subclasses and the super keyword make augmentation of behaviour very straightforward¹.)

So how, at runtime, might we instantiate the appropriate class? Running all instantiations through a helper method would certainly work:

# assume the existence of a `Mobile` boolean variable

makeViewObject: -> (name, args...)
  UI    = if Mobile then Touch else Desktop
  klass = UI[name] || Views[name]

  new klass(args...)

makeViewObject("Widget")   # => new Desktop.Widget OR new Touch.Widget
makeViewObject("Thinger")  # => new Desktop.Thinger OR new Views.Thinger
makeViewObject("Sprocket") # => new Views.Sprocket

…and if you’re most people, you’ll stop there. I, on the other hand, had just read Isaac Z. Schlueter’s Evolution of a Prototypal Language User, hadn’t done anything fun with prototype chains in years and didn’t like the idea of this unsightly helper method peppering my code. So I got to work.

Instead of Views, Desktop and Touch being plain objects, we create a ViewShop function, point Views at its prototype and make Desktop and Touch new ViewShops, so that property access falls back to ViewShop.prototype, which we’ve just aliased to Views… look, I’ll just show you:

ViewShop = ->

Views   = ViewShop.prototype
Desktop = new ViewShop
Touch   = new ViewShop

Now, after defining the view classes, access any property of Desktop or Touch, and prototype chaining works its magic:

Desktop.Widget   # => Desktop.Widget
Desktop.Thinger  # => Views.Thinger
Desktop.Sprocket # => Views.Sprocket

Touch.Widget     # => Touch.Widget
Touch.Thinger    # => Touch.Thinger
Touch.Sprocket   # => Views.Sprocket

We need only make a UI variable that points to the right ViewShop, and we’re done:

UI = if Mobile then Touch else Desktop

new UI.Widget   # => new Desktop.Widget OR new Touch.Widget
new UI.Thinger  # => new Desktop.Thinger OR new Views.Thinger
new UI.Sprocket # => new Views.Sprocket

Well anyway, I like it.

I should be careful about using the word “undeniably” though. I’m no expert on object systems. If you feel you can reasonably deny it, I’d love to hear from you!
↩