Offline First

In temple architecture, the main room stands at a considerable distance from the garden; so dilute is the light there that no matter what the season, on fair days or cloudy, morning, midday, or evening, the pale, white glow scarcely varies. And the shadows at the interstices of the ribs seem strangely immobile, as if dust collected in the corners had become a part of the paper itself […] where dark and light are indistinguishable

Jun'ichirō Tanizaki, In Praise of Shadows, 1977

Hoodie.io, an awesome web app framework, started the “Offline First” initiative.

It struck me for two reasons: First, it’s the right way to go and I have been looking into Meteor or Rendr/Backbone for some time. In a world, where services converge across technologies, platforms and ecosystems, technology needs to go a similar way (see my W-Jax talk). Seconds, I was quite surprised the let’s-code-all-startups-in-javascript-scene is realizing that! I’ve had my troubles following all the JavaScript developments of recent years (with the exception of Node) because their use cases simply didn’t make too much sense for me, it all seemed to be exclusively fitted for kinda-social-cloud-powered-minimalistic-apps. Seeing this attitude changing makes me feel optimistic and encouraged.

Until recently, the web app world was like “The West” in Tanizaki’s book: Always perfect, brightly lit, accepting no natural error, resilience was only required in certain places like hardware. Tanizaki praises the shadow, and more the diffuse actually, as a juxtaposition to the always-bright, the efficient and the productive. In building resilient, adaptive, “Offline first” systems we now embrace the shadows, the connection problems, the version conflicts, the deadlocks. And more, we embrace the diffuse, the not-so-clear situations to be identified, auto-corrected or escalated to the user. This means we value adaptability over usability in some areas, giving the user control (if she wants or not) over the process. This means we have work closer with users, design better services, fail gracefully.

As an enterprise guy, where mobile applications have been in place for some time, my projects have always been “offline first”, i.e. “complex” rather than “complicated”. It’s the reason I looked into CouchDB for mobile sync. Even when I built applications mixed with WebViews and native views, this very distinction was made taking into consideration the connectivity context. Connectivity is a part of responsive, or adaptive, or reactive, design. And therefore a part of flow-oriented, resilient service systems that can adapt dynamically*. 

Or, as Ethan puts it, with a nice reference to How Buildings Learn and the aging process: “Shearing Layers”, which means acknowledging the gaps, designing for change where the system is exposed to natural forces and “invite our users into some of these problems” i.e. move conflict resolution to the user, and make visible the complexity - with a suggestion system at work.

Or, in Tanizaki’s words:

The quality that we call beauty […] must always grow from the realities of life, and our ancestors, forced to live in dark rooms, presently came to discover beauty in shadows

*) If you read my blog regularly you know I am not a fan of cybernetics the way Sussna is proposing it as an automated solution to cope with complexity. I like to quote Steve Jobs: “people don't know what they want until you show it to them”. However, I was happy Sussna did the JAX keynote, agreeing with him almost entirely, I fully agree to his Manifesto.