Offline First Design Patterns : Engineering
Introduction
The following is an amalgamation of discussions and ideas that bounced around the one-hour session about Offline First design patterns in engineering at Offline Camp Catskills in June 2016.
How do we find design patterns ?
Use cases! — common user stories, problems we run into, draw commonality from them and different ways to solve them.
Different levels of connectivity
Different types of network connectivity should be analyzed so that effective ways of syncing data can be done. With mobile devices, there could be a plethora of common connection problems like bad connections with good power, really good connections with limited power, spotty connections (worse than slow connections!), consistently slow connections, saturated or noisy connections.
Dealing with data problems
One of problems discussed was the management of data, such as syncing data, managing data conflicts, amount of data, etc. in an Offline First application. How could buffering or caching solve this problem effectively? What is the right amount of cached data?
- We could store every change to the data but then it may blow up and make it really big.
- Store a small portion of data but then it would require constant connectivity for it to be updated. This leads to a never-ending chicken & egg situation!
Different types of Conflict resolution. Give power of solving to the user?
Do we empower users to manage their own conflicts? Like the way Git does “git merge,” which works for code. One participant professed his love for Git and hoped we can solve problems by just doing what Git does!
There is no general purpose algorithm for all conflict resolution. But if we make tools that reveal more conflicts or history to the users, would they be more comfortable with managing it manually? Solutions may also change in domain specific automated tools. We could get a lot of insight from taking examples with offline shared docs… what do MS Word, Google Docs, or Google Drive do? Should this even be categorized as a user experience problem?
Taking parallels from distributed computing
Distributed systems have a lot of good advice on how to solve lots of problems — but they happen on really good machines with good connections — so can some of their paradigms in some way help solve an Offline First scenario? It would involve identifying the relationship with distributed systems but with much more extreme limitations… instead of the network being potentially unreliable, the network is almost entirely unreliable.
Tools to develop and test Offline First apps
Do we have the ability to recreate a lot of these low connectivity issues in our highly connected workplaces or homes? How do we test these unpredictable environments and circumstances?
How good are Google Chrome’s Developer Tools in testing Offline First scenarios? One idea could be having a tool that cuts off your internet connection at random intervals.
Conclusion
Having a compiled set of design patterns based on various offline scenarios will be a useful project in the future. But there is a huge diversity of hostile situations that we can’t predict unless we get in touch with communities having low connectivity or are on the ground to test these ideas and solve specific problems.
Editor’s Note: This article recaps discussions we had at Offline Camp, a unique tech retreat that brings together the Offline First community. Join us at our next event or sign up for updates and cast your vote on where we should host future editions of Offline Camp.
