Prescript: Join the discussion on offlinefirst.org and help collecting information on the Offline First Github Organisation. And see the two follow up articles Offline First and the Circle Of Web and Offline First and the Circle of Web Part II: Breaking the Circle.
(Russian translation by @kouprianov)
The members of Team Hoodie are currently travelling around quite a bit, organising, participating in and attending conferences and workshops in various countries, and through all this we’ve not only made lots of personal experiences with limited network connectivity, but also met many people from all over the world, all with their own related stories and problems.
Frequently not having any data connection in even the wealthiest and most developed cities of the world has led us to conclude that no, the mobile connectivity/bandwidth issue isn’t just going to solve itself on a global level anywhere in the near future.
We’ve generally been rather optimistic about the whole problem, often thinking that coverage and bandwidth are sure to increase continually, but our recent experiences have made this attitude appear increasingly naïve. Capacity problems, varying coverage and zones with zero reception, unreliable connections (both wifi and telco) and problems incurred through travelling will likely persist for quite a while.
Geography is non-negotiable, as is most architecture. Travellers are doubly plagued: not only by their mode of transport often prohibiting any sort of connection (many subways and high-speed trains come to mind, as do most airlines), but also by the extortionate roaming charges imposed by the carriers, making a spy-sized collection of SIM cards a neccessity for anyone without a massive personal telco budget. And this is speaking from a solidly western-europe-centric perspective.
Gregor has spent the last six weeks travelling through Africa on the AfricaHackTrip, and we’ve had the opportunity to speak to people from all over the world at Mozfest in London. Here and in many other instances we’ve encountered a solid interest in and a passionate desire for better offline capability in both web and native applications.
Mobile networks simply don’t provide that same level of quality and consistency, and it’s high time we start adapting to that reality. In the same way it makes sense to build interfaces mobile-first, it’s time to think about designing and building our applications offline-first. With an offline mode that isn’t merely a contingency for an error scenario, but a fundamentally more flexible and fault-tolerant way of application design.
With Hoodie, we’ve created an architecture that allows you to build offline apps with relative ease. There are a few issues, but we’re quite confident about the technical aspects of our syncing engine and how it handles being offline. But now we’ve stumbled on a plethora of new, hitherto unknown and unresearched use cases and UX scenarios, all of which are only now easily within the reach of most developers.
This is quite literally a new frontier, largely unexplored and full of interesting problems and unimagined edge cases. In most other realms of app design we are spoilt with UX/UI patterns we can readily employ, but offline-first is terra incognita, there is practically nothing to go on in terms of patterns and metaphors.
All of a sudden, offline becomes more than error handling. Offline becomes a non-threatening reality in which, yes, some aspects of your app will neccessarily stop working, but many others don’t, because they no longer have to. And this raises many fundamental questions:
Does the app even need to inform the human of the current connection state? Is this information even relevant to the human? If so, how can this best be done?
Can I give the users more trust in the app, leaving them safe in the knowledge that it won’t forget the last state it was in, and that it won’t lose any data, regardless of what the connectivity situation is?
How can I communicate to the human that creating data within the app is still possible offline, and that it will be posted/dispatched/properly dealt with in the future?
How can my interface convey changes that occur in the users’ current view when they reconnect and the server pushes new and changed data? What to do with deleted items, things that can’t be organised in lists, objects that aren’t in themselves immutable (like emails)?
How can I make the inevitable resolution of conflicts by the human as painless and intuitive as possible?
Can the app make any preemptive decisions on the part of the human and pre-load any low-overhead data they might need later?
What metrics (possibly behavioural) are there to base these decisions on?
How can I word all of these scenarios in a way that doesn’t worry the users, that embraces offline as an unproblematic reality?
There’s more, of course, but we have to start somewhere. Our Mozfest session on Offline First Application Design has made this abundantly clear to us. There’s a whole new paradigm rolling our way, and we’re going to roll with it. We want to help users of Hoodie in building robust, always-usable applications, not just on a technical level, but also with patterns, metaphors and methods for higher-level application, user experience and interface design. This will be our research project, and it’s going to live at offlinefirst.org.
If you are interested in joining the conversation, you can start by leaving comments on this post. We are looking forward about what you have to share! :)