This week, while traveling, I noticed my smartwatch wasn’t working right. So I launched the app to get it to reconnect, but it insisted on checking for updates. At a restaurant in the middle of nowhere, there wasn’t a strong enough Internet connection, so I got stuck without its working for a few hours. I couldn’t read news while I was waiting for the bill because my favorite news app doesn’t load stories until I launch it.
Later, I went for a trail run at a little park. The main screen of my fitness tracker is largely a map, but in this case. it was totally blank. It hadn’t synced or saved a map while it still had coverage, so when I needed the app, it just complained about there being no coverage at that time.
Champion Advertisement
Continue Reading…
Apps Are Not Web Sites
Often, when I work on mobile apps instead of Web sites, it is for key technical reasons such as connectivity to a Bluetooth IoT device. If your product doesn’t have any such needs and really only shows users data that it loads from remote servers, you might not need to create an app at all. If your app and Web site do exactly the same things, you should think really hard about why you should spend time and money on app development.
But often the key reason to bother with creating an app is even simpler. It’s to allow people to work with your information or use some specific functionality when they are not connected to the Internet.
Offline Is Not a Feature
We neglected to think about this reality for a while and built a few years worth of apps that act too much like Web sites that users must install.
Over the past year, I’ve seen a small, but happy resurgence of offline capabilities. Certain organizations, including some of my clients, are getting used to the fact that not everyone has great connectivity, so we should all offer many of our new mobile tools as apps that work when a device is disconnected from the Internet.
But some have a strange perception of what bad connectivity means. All too often it’s a little like the joke about adding the feature “easy to use.” Instead of building for the reality of networks, airplane mode becomes a line item in an app’s required features.
And, far too often, teams still think too literally when building features. If the project charter says they need to create a download-and-sync feature, you can likely expect to end up with a button labeled Download and Sync rather than the app’s doing this on its own. That’s where we come in, as UX designers, and prove that user experience is not just about picking the color of that button.
Connectivity Is Not On or Off, but On-and-Off
I’m often reminded of a line that someone used in opening a talk at a conference in Eastern Europe: “Not everyone has good 3G service.” Yes, he said 3G. The 4G LTE service I encounter in every big city in the US is something they’ve only heard of.
And they are lucky to have reliable mobile service at all. While mobile is by far the default way in which people get online, connectivity varies in quality from moment to moment and place to place. Low speed, high latency, and frequent loss of connections are common occurrences. Specifying that you need to cover these people by saying things like “provide airplane mode” is poor practice. That sort of terminology expresses connectivity as being either on or off and implies that users can select their network connectivity.
It also means that, for most apps, across most of the world’s surface, we cannot design apps that require constant connections—or even large file transfers. Right now, we build functionality that works in our offices and at the corner coffee shop. Does your app require a weekly 500-MB download?
For much of the world, connectivity is always poor, transient, or simply expensive. Your users may choose to wait for Wi-Fi or better connectivity. They may switch SIM (Subscriber Identity Module) cards to use the cheapest network. But very, very often, they simply have to suffer poor connections.
And, remember, this is not a third-world issue that you need to pay attention to only if your product will launch outside the US. Just drive into the suburbs or between cities to see what mediocre coverage really looks like.
The Traveling-Worker Problem
Say you’re building an app for a remote worker like a repairman, salesman, or installer. While these people may start their day at home or at the office, they drive to the customer’s site based on the live data they receive. If the customer resides in a rural area with no coverage, that’s fine—as long as remote workers can use your app’s synced data and can take notes about their work.
On the way to a second site, they may pass back into an area with mobile connectivity, and their tablet will automatically sync the data they’ve entered to the server and bring in fresh data updates they can use to better deal with their next customer.
But making users press a button to sync their data or having an app retrieve data only while users are looking at the app won’t work. People won’t be using the app while driving.
How do you decide what features you should make work offline? The same way you design your information architecture, your task-flow diagrams, your navigation, and everything else. You analyze the information and functionality, understand the audience, and learn how they will use your app. Often, you’ll want to sync a whole lot of data.
Designing to Sync
To solve users’ problems with poor or transient connectivity, there are a few principles you should follow. This will help ensure systems are useful and usable under all network conditions. Follow these principles:
Never throw away user data. Keep everything users gather or enter on a mobile device, including application states, until the data is synchronized.
You’re providing a service, not an app. Make sure your app can send the data users have gathered back to the company database or cloud-storage provider.
Deal with conflicts. With multiple endpoints, multiple users, and delayed syncing, you can end up with mismatches in the data. Try to avoid these, but if you cannot do so, provide easy systems for users to choose the correct data.
Send as little data at a time as possible. Design data for sync services to be as compact as possible—and ensure sync works well on high-latency mobile networks. Design them to work out in the real world, not for the Wi-Fi in your office.
Indicate when an app is offline. If a disconnected state or the display of stale data might matter, make that obvious to the user. If partial connectivity might cause a remote user to have some data that’s not synced, it could be important to make other users aware of this.
Prioritize the data you send. Ensure that key information or data upon which others are dependent gets loaded first. A lot of apps, including Twitter, burn up my data-syncing time in poor coverage areas by loading their ads before the information I actually requested.
Never require the user to be responsible for saving data or interrupt the user when they can continue working with offline data.
So now you need to add a sync service to your product.
Designing Products
Bolting sync onto your product’s design never works well. This is one of the reasons I talk a lot about designing systems rather than just designing or prototyping user interfaces. You have to think about the entire product holistically—and before you get very far into design. Think about the entire product experience—from the store to email notifications.
Fundamentally, you should store key information in a local database, then sync it with a remote or cloud database. Simple. But when does it sync? Well, you need to figure that out.
Sometimes you can wait until the app is running in the foreground, but the user is often outside Internet coverage by then, so there’s no way to sync data without getting back in the car and driving around. The best approach is to run a service in the background that watches for network connectivity.
You really cannot tack on a background watcher that’s very useful, effective. or reliable. You have to conceive of it as an integral part of an app’s functionality from the very start of a project.
Designing a Sync Service
Regardless of whether an app syncs regularly, it’s good practice to store pretty much all of the information your app displays in a local database. You can create a sync service to periodically update the content, empower multilingual content, and more.
Of course, this is necessary to make a regular sync service work well, too. For modern, smartphone operating systems, the key constraint on database size is the amount of available storage. But you cannot assume that every every user has the most expensive, most current device. Available memory may be well under 1 GB—and that’s if users haven’t taken a lot of photos. Thus, you probably won’t be able to store everything you’d want, so you’ll need to think about what information is critical and how it should be organized.
Mobile phones suffer performance issues when it comes to decompressing and searching databases. So you need to design them very carefully to avoid users’ encountering too many spinning delay indicators. While your design analysis may indicate that you should sync everything, you won’t usually be able to do that, so you’ll need to determine what data the user absolutely requires, what the user can wait to download, and what to do about delays and low-speed issues.
There’s a lot more to consider, but I wouldn’t expect the typical UX designer to do too much of this on their own. Get your organization to hire good DBAs (Database Analysts)—and if necessary, good data scientists as well. Then be sure to work closely with them, so they’ll understand the business goals and the needs of all your users. Listen when they bring up issues regarding the storage of large files or handling data mismatches, so you can design to avoid these issues as well.
Empathy Starts with Information
Too often, the practice of empathetic design is a bit too skewed toward the soft-skills side of design. We need to add data to our analysis to learn how users think and want to work. We need to turn empathetic decisions into real goals and run them through the filter of constraints so we can understand what our teams can actually build.
It is important that we not consider user needs just in isolation. Remember to explore your users’ environment and technology. Don’t assume users have good Internet connectivity because they’re sitting in a nice office. Whether you are designing high-contrast screens for outdoor use, avoiding relying on sound notifications in high-noise environments, adding labels so your icons work for everyone, or building good sync services to solve issues with poor connectivity, you must design for the entire experience people have with your product.
References
Adams, Scott. Dilbert. April 14, 2001. Retrieved April 19, 2016.
Similar with the new music app on iOS—if you have a very slow Internet connection, you can’t listen to your music offline. When you open the music app, it tries to load something from the Web—and denies you access to your offline music completely until it loaded. The only workaround is to disable Internet. Horrible UX.
Thanks for that example! Specifically, offline services that get confused by lack of connectivity are a new low. I will have to use that example more when I talk about this.
I think the first step may be more visits to real-world users—or even just general road trips where their phones don’t connect—for designers and developers.
Love it! I think these concepts are especially important as people are designing browser-powered apps either in containers—for example, PhoneGap and GoNative—or in the browser itself. Making a network request for every single interaction makes an app feel choppy, but downloading an entire restaurant-review database before loading the first screen makes it seem slow. There’s definitely a need for intelligent data-syncing behavior in these types of applications to make them feel optimally snappy!
For his entire 15-year design career, Steven has been documenting design process. He started designing for mobile full time in 2007 when he joined Little Springs Design. Steven’s publications include Designing by Drawing: A Practical Guide to Creating Usable Interactive Design, the O’Reilly book Designing Mobile Interfaces, and an extensive Web site providing mobile design resources to support his book. Steven has led projects on security, account management, content distribution, and communications services for numerous products, in domains ranging from construction supplies to hospital record-keeping. His mobile work has included the design of browsers, ereaders, search, Near Field Communication (NFC), mobile banking, data communications, location services, and operating system overlays. Steven spent eight years with the US mobile operator Sprint and has also worked with AT&T, Qualcomm, Samsung, Skyfire, Bitstream, VivoTech, The Weather Channel, Bank Midwest, IGLTA, Lowe’s, and Hallmark Cards. He runs his own interactive design studio at 4ourth Mobile. Read More
