#006 - Cloudy with a Chance of SaaS
The #1 Mobile Application Fail
Application as a Browser
Lately, I’ve been noticing a few different mobile applications doing one thing very poorly. For all intents and purposes, each application is delivered as a web application that expects, or rather, requires an always-on connection to a server. But it gets worse; the application deployed is another implementation of the website, with another codebase and in many cases different features and capabilities. The differences in experiences fostered by two different code bases, not to mention the expense of twice the testing, twice the development (or is it three times, if you also have a separate Android Application), are massive to your organization. How do you keep all user experiences in sync? How do you ensure your backend data stores are not being written with bad or corrupted data? As a human-centered technologist and consumer of these applications, it just horrifies me at all levels of my being and shows a failure of leadership.
Leadership Failure
Show me a software delivery organization and I will show you one that is behind the curve on delivering the capabilities needed for the business. I am not sure how any business at any scale can afford to have duplicates of any part of the stack they are using. It is certainly possible to have multiple authentication providers, but why would you? A fast-moving user will always be confused when their password change took effect on the mobile app, but not yet on the website. Or in the case of United Airlines, different password lengths are supported, depending on whether you updated on the mobile application or the website. Further, scheduling two releases or even three to coincide with each other is a structural scheduling failure of epic proportions. The amount of time you will wait for laggards to catch up with the leader ready to ship, compounds with every release and over time adds up to months, or possibly years of lost productivity and huge opportunity costs. When you think of the expense of development teams and require at least 3 teams to be in sync for every update, the employee costs are staggering. At the end of the day please have just one code base for your end users, no business can afford to have duplicative development teams.
Always On, The Silent Killer
Mobile Applications are by definition mobile, this is a benefit and curse. It is a benefit because this application is with you at every point of your daily journey. Where this falls down for me, on far too many occasions, is not being on Wi-Fi. Thankfully, Apple allows you to turn off internet access over cellular for applications. Did you know that many applications will silently fail and not let you know that no route to the server was found, or worse, they give you a silent error with the application seemingly not working at all? MyFitnessPal I’m looking at you. I have experienced this countless times and with every poor experience I wonder who was developing and testing the application, and how could the developers have such a lack of vision to understand a core way in which users will be using the offering. Further, not testing this use case and giving good error messages is an outcome worse than just about any I can think of. If your testing does not account for a no-network modality, you probably should rethink your testing strategy.
Disconnected Design, It is Inevitable
Your users will inevitably use your application while not connected to the internet. This lack of connectivity could be induced by a failure of your cloud provider, the network, or even when you need to do some maintenance. While there are many ways to ensure that an application always has something to talk to in the backend, these redundancies cost extra and create a lot of headaches. In the end, you will always have a bit of downtime, unless you work really really hard to solve all possible outages. It would be much better for your back-end teams and developers, to assume there are times when your back-end services will not be available, and you should code your mobile applications to deal with this reality. I am especially thinking of applications that provide meditations, tracking, or to-do list capabilities. Why in the world can I not utilize these applications without a connection, and why doesn’t the application just sync when the network is restored? If applications were available regardless of connectivity, the benefit to the user is seeing nearly instantaneous responses to all actions, a big win for the end user. If you do have a browser and application in use, you will have to do some work to indicate the information is not yet saved centrally yet, but that is a small UX detail that can be easily worked out.
5 Suggestions to help:
Do not duplicate or triplicate development teams and efforts, you can’t afford it, and your customers deserve a consistent experience.
Do not have different systems of record that depend on the source of your users, mobile, browser-based, or call centers.
Don’t expect your users to have an always-on connection to the internet; and test and design for that possibility.
Don’t ever give your users an experience with a white screen of death or empty results without some indication that something has gone amiss.
Do provide a degraded but useful experience for your end users when they are without a network connection and seamlessly sync the back-end when connectivity is restored.
Thank You
Jim ‘The Designatic’ Tyrrell