Offline/Low-bandwidth UX Design Patterns

Steve Trevathan
Offline Camp
Published in
4 min readJul 8, 2016

Design Patterns make expectations, intentions, and contexts understandable. Things you can’t ignore, but especially when creating an offline experience.

In our UX Design Patterns session held at Offline Camp, the team huddled together and brainstormed on what patterns existed (surprise, not too many!), discussed where and why design patterns could help us, and spent some time crystallizing what our barriers to defining those patterns are.

Most documented offline states appear to simply notify a user of their isolation.

Sure, there are a litany of apps that wall up their product and explain to the user that they’re currently offline, but that’s not a useful model for the offline enabled application. Instead, having a root design pattern for saving, loading, merging conflicts for multi-user offline editing, and certainly a wide variety more would help. Especially when there is some versioning or variety of instances of such patterns that reflect the unique environments they’re experienced within. To state plainly:

  • We need varieties of offline scenarios to help us define better reusable patterns.
  • From those we need a way to discuss, challenge, and fork the patterns for our own unique cases.

There are many more challenges than the non-existence of UX design patterns for offline, however.

Offline is the negative space

Well discussed was the fact that, regardless of being a maker or a consumer of tech, people of today’s world don’t expect offline to work. Decades of requiring constant internet connection — and with improvements being experienced only as incremental speed increases — have set us up to be somewhat blind to offline. Because of this, we don’t really see the opportunity in the negative spaces.

Some fantastic people and influential organizations have, however, and with their help we should be seeing a sea-change in expectations of apps. For the average customer, it will feel like the fabric of the app has gotten significantly stronger. Though, as we discussed in the session, this will not happen all by itself.

Community and contribution

To promote awareness of offline capabilities and their more-than-supplemental benefit to products in design communities, we’re going to also want to have a plan for how designers can get involved. Plenty of questions arose from this:

  • Can we work with an open design community? How has this been done elsewhere and can we get a level of teamwork from the design community in the same way we do for development?
  • How do designers contribute back? What tools could we use or create for designers to better do this within their communities?
  • Given that GitHub is a rather unnatural/uncomfortable place for designers, where would we plan to hold our discussions? In places like Discourse, Slack, or perhaps something more suited for documentation level discussion like Hackpad or Dropbox Paper?
  • How do we manage what the ideal solutions are? We’ll want discussion in the community, but having a release team for the solutions might be a good idea.
  • Consider versioned/forked patterns, as many patterns in software are useful to a point before having to be adjusted for their app context. A physical world example: a bench using standard bench form patterns may be followed, but perhaps context calls for adding a center divider to keep people from sleeping there for long durations.

Resources

Some resources were discussed, though it appears we’ve got some work ahead of us in discovering and/or making our own.

All in all, I think the session helped bold, italicize, and _underscore_ a glaring lack of design examples and open collaborative resources available. I’m looking forward to spiking on a concept for community tooling, as well as on creating an initial list of example offline product scenarios we can use as a guide for shaping our offline design principles and patterns.

If you’d like to collaborate, have resources you’d like to share for this post, or have suggested paths for solving the challenges we’re facing here, please comment in this post, join the #design channel in the Offline First Slack community, or email me directly at steven@offlinefirst.org.

Editor’s Note: This article is part of series of unconference session recaps submitted by the awesome folks who participated in our first ever Offline Camp, a unique tech retreat that brings together the Offline First community. You can find more coverage of our initial discussions in our Medium publication. To continue the conversation, 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.

--

--

Steve Trevathan
Offline Camp

Designer, developer, musician, photographer, and artist. Running@makemodelco | Co-org @ux_camps +@offlinecamp