Improving Offline Posting

The best technology is invisible and reliable. You almost forget it’s there, because things just work. Bad technology never disappears into the background — it’s always visible, and worse, it gets in your way. We rarely stop to think “My, what good Wifi!” But we sure notice when the Wifi is iffy.

Good technology in an app requires solid offline support. A WordPress app should give you a seamless, reliable posting experience, and you shouldn’t have to worry whether you’re online or offline while using WordPress Mobile. And if we’ve done our jobs right, you won’t any more.

Getting Started

Our first step was a review of the current offline posting experience, done by a cross functional team composed of designers, QA engineers, and developers.

The process was pretty straightforward: we went offline, started testing, and taking notes. We also took into account support requests and existing bug reports.

We shared our findings, discussed them and came up with a set of offline principles to ensure the consistency needed to make things better for our users.

Consistent Messaging

One of the first issues we noticed was that we were constantly interrupting the user’s workflow with blocking alerts. We also noticed the messaging was inconsistent at best.

The blocking alerts were particularly harmful because they got in the way of the user’s activity without adding much value. They directly clashed with the idea that the best technology should not get in your way.

We removed alerts that weren’t offering any useful choices, replaced the ones that were useful with better contextual messages that display inline within the UI, without blocking the user’s workflow, and standardized all our messaging to be more consistent and clear.

Automatic Uploading

More significantly, the offline posting flow was broken. Users were unable to save modifications to posts while offline.

Additionally, some of the blocking alerts were directly tied to the app’s inability to save or publish while offline. They existed because we needed to prevent the users from performing actions that weren’t supported while offline.

To resolve this, we implemented logic to queue upload operations, and replaced the blocking alerts with contextual messaging. Now, the upload queue executes when specific triggers are activated, as shown in the image below.

Playing it Safe

But queueing upload operations can be problematic.

Consider a case where the user makes more changes to a post after publishing it. We needed to make sure that we wouldn’t publish changes that happened after the user tapped “Publish”.

We could have stored a local immutable copy of the post each time it was saved, but the complexity of this solution and its unclear added value made us look for alternatives.

The solution ended up being relatively simple: we generated a hash code based on all of the post fields, and associated that hash with the queued publish operation. When executing the publish operation, the hash has to match the post for it to be published.

But even if the hash doesn’t match and the publish operation is cancelled, the app will auto-save the post so it’s available from other devices.

Additionally, we didn’t want devices that were offline for an extended period to remember offline save operations forever. The solution here was to make sure queued upload operations time-out after a while. This safety mechanism helps us ensure a device that’s offline for a week doesn’t trigger any uploads when going back online.

Final thoughts

This process forced us to put ourselves in our user’s shoes. By making our user’s struggles our own, we came out with a better understanding of what makes for a good offline posting experience.

But that’s not enough!

It’s easy to forget about the offline experience as we’re working on new features. Our most important takeaway is the importance of remaining aware of what happens when the device goes offline and considering the implications for our users.

Because once users stop noticing they’re offline, we’ll know we did a great job.