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.
