Browse Content by Topic:
When Lives are at Stake, Mobile App Evaluation Becomes Even More Critical
Author: Todd Piett, ENP, Chief Product Officer, Rave Mobile Safety
Copyright: 9-1-1 Magazine, Feature Content,
Mobile apps claim to do just about anything imaginable… Some of them are extremely valuable and promise to transform emergency response, while others can be deceptive and even counterproductive. How do public safety agencies separate the wheat from the chaff? In advance of any national standards, here’s a framework to consider for evaluating apps.
Few words create more interest and discussion with public safety agencies today than the word “app.” Today, apps claim to do just about anything imaginable, and this kind of hype often drives decisions that aren’t always in the best interest of the agency or those they serve. There are many points agencies must consider when evaluating their technology decisions, especially when it comes to apps.
Let’s start by defining an app. The term “app” applies to any type of software which performs a function. However, our general use of the term has become more specific to mean software designed to run on a mobile phone or tablet. Apps are typically downloaded from the app store associated with that phone’s operating system. They can be self-contained, meaning all the functions and user experience run natively on the device, or they can leverage a data connection to interact with other services on the web. They may run across a public safety network or the public Internet.
In the public safety context, there are apps that connect citizens to PSAPs, PSAPs to responders, responders to responders, citizens directly to responders, and even some that connect citizens directly to other citizens. Some of these apps are extremely valuable and promise to transform emergency response, while others can be deceptive and even counter-productive. How do public safety agencies separate the wheat from the chaff? In advance of any national standards, here’s a framework to consider for evaluating apps.
First, understand your strategy. An app is simply a mobile interface with some ability to store data and access unique capabilities of the device on which it resides (for example location services, messaging, etc.). Ideally, those functions solve a problem for the user. You are applying technology to a challenge, hence the name “application.” Google Maps is a good example. The problem being solved is making it easier to find something. You access it from your desktop computer via a web site (a web “app”), via a mobile friendly web site (maybe the same site accessed from your web site that is responsive to the device viewing it), or via an app on your smartphone. The app is merely taking advantage of some unique capabilities afforded through the mobile operating system (e.g. access to your GPS location) to make the “problem solving experience” smoother.
A mobile app is a means of solving a problem, and often a very powerful one, but the key is to understand the problem. Check boxes on RFPs often ask “does your solution have an app, Y/N?” However, it is not clear what problem they are trying to address. Is there a problem with cell coverage that requires a function to run natively and operate without a data connection? Are they trying to make the experience of sending a notification easier from a mobile phone? Are they trying to enable citizens to more easily interact and share photos or videos with responders? The strategy must address the “customer” need. That customer might be a lost traveler trying to find the nearest hospital, a deaf caller trying to report a car accident, or a responder trying to provide in-building video back to the operations center.
There are a number of reasons this is critical for public safety to understand. Don’t spend money on apps unless you understand what you are trying to accomplish. Just getting an app is not a strategy. Remember that an app is just one way to perform a function. There are very few definitive lines between an app and back office applications that perform other mission critical functions. When done correctly, they are integrated in ways that solve a problem in an efficient manner. Looking at apps in a vacuum is short sighted.
Second, design for the future. If history has taught us anything, we know that technology will evolve faster than we expect and in ways we don’t anticipate. An app on an iPhone might be all the rage today, but in five years, people might wonder at how clunky it was to click buttons with a finger while they speak into a voice-enabled cloud. Driven off a wristband that uses 2-factor authentication based on their voice and DNA fingerprints, a responder may simply say “get me to the crash scene” and have the route visually projected in front of them. If they say “that looks good,” the route is projected via Bluetooth to their driverless car and they are instantly taken to the site. There may be no concept of an app, just access-as-you-go services without any downloads or clicked through interfaces. So what does this have to do with public safety? Networks, form factors, and computing power change drastically. If you evaluate technology and workflows with one eye toward the future, your solutions tend to age like fine wines instead of warm milk. Again, one must first evaluate the problem being solved and think of an app as one component of the solution. It may be that implementing an app is a natural first step, but the app itself is rarely the ultimate end point.
Third, understand your user. The user interface and expectations for a consumer app can be much different than a responder app. One tool available today has an ugly interface and massive cartoon-like buttons. Any designer would have gagged and a consumer would have thought it was ancient technology just based on its appearance. However, the developer explained the extensive usability testing they had done with their users – fire fighters – and how the buttons needed to be easily visible through masks and smoke, and accessible when wearing gloves. As you evaluate technology, remember the target user and the conditions under which they will be using it.
Fourth, understand your network and the entire stack of dependencies required of the app. In the development process, one must work closely with clients to pilot new technologies as the concept moves from theoretical to actual. Every app looks and works great in an office demonstration, but real-life situations are different and many questions must be asked: Does the app still work even if the user is a basement where no location services are available? If every user is expected to view a video showing the situation inside a school building, what happens when EMS starts streaming real-time patient information to the hospital? Can the network become overwhelmed and stop working? Does the solution compensate and gracefully degrade performance? What back-up procedures are in place when the assumptions of network availability prove false?
FirstNet holds the promise of a dedicated network, but even then, the bandwidth available can easily be monopolized by resource intensive apps that aren’t deployed in a manner consistent with the reality of field conditions and usage. Make sure you understand the limitations and plan accordingly as you choose and deploy apps. Further, most public safety grade apps are more than just a mobile phone resident. The external components such as Software-as-a-Service functions, which are called upon by the app, should undergo the same diligence you would apply to any mission critical system. What is the service level availability committed to by the vendor? Is there a public-safety grade infrastructure behind it or do you risk privacy breaches and downtime? Gartner Research reported in early 2014 that they predict less than 0.01 percent of mobile app vendors will make money by 2018. It may be fine for a standalone “to-do list” app to disappear, but if you have set expectations and designed processes around the availability of a solution, make sure you are comfortable it will be there when you need it!
Finally, continually evaluate. Technology is changing rapidly. It’s not just a monetary investment made one-time, but a constant evaluation of how both your technology stack and, perhaps more importantly, your procedures should evolve to best take advantage of what is possible. Technology such as SaaS, and the rapid deployment enabled by leading app stores provides for a speed of capability evolution not possible with many “old school” technologies. Plan to take advantage of it.
Apps are opening up an amazing spectrum of possibilities… both good and bad. Our responsibility is to thoughtfully deploy solutions with the end-game in mind: improved response.
Todd Piett, ENP, is the chief product officer of Rave Mobile Safety, a leading provider of safety software including Smart911 which is used by more than 1,000 communities in 35 states and Rave Alert which provides emergency text notifications for nearly 40 percent of the U.S. higher education system. Todd is a Board member of the NG9-1-1 Institute, a member of APCO’s Emerging Technology Committee, and participates in various NENA working groups related to NG9-11. He holds numerous safety-related patents, is a graduate of Harvard Business School and is a former US Army helicopter pilot.
For more info on Rave Mobile Safety, see www.ravemobilesafety.com/