Whether you're a developer looking to design and market an application for the health and wellness environment or you want to learn from the mistakes and best practices of others, Sunday's WIPJam@mHealth Summit was the place to be.
Few in the audience actually have an application on the market, but many said they were planning. That's the goal of the Wireless Industry Partnership, headquartered in Vancouver, Canada, which hosted the WIPJam.
Richard Mendis, co-founder and CMO of AnyPresence, a cloud-based mobile platform company, began the day-long session by reviewing the basics of mobile app development, noting that testing an application is key. That includes testing apps when they’re running on the variety of operating systems, like Android and iOS, and also testing how they run on the variety of carriers, such as AT&T and Verizon, because the differences that could affect performance.
He also reviewed distribution options beyond the public store, like internal or ad hoc for a more select distribution. Deciding on server deployment, such as public or private cloud or private hosting, is an important decision for developers bringing an app to market.
A service aspect can use an abstraction layer to help connect to a source system. “If something changes in source system, you don’t have to change your native client, and it's considered a best practice now,” Mendis said, adding that with native apps, clients have to be updated – something that’s not always done now.
When personally identifiable health data leaves a secure data center for push notifications, he said, it's no longer HIPAA-compliant. Mobile developers have to be cognizant to comply with HIPAA security protections when they have access to patient data or support payers and providers to perform that task.
“There has been an explosion of mHealth apps, but providers still lack patient-facing apps and mobile sites,” Mendis said, adding that usability and design are critical to effective apps.
Developers need to measure their progress by collecting data from established benchmarks for the application and/or company; analyzing it with tools, such as Google Analytics or Flurry Analytics; and taking action and making adjustments where needed, said Alicia Dixon, mobile product manager of the Sheridan Group-Tech Lab.
“You can’t monitor what you don’t measure,” she said. “And don’t wait until the app is built and people are using it. Start the measuring and monitoring from the beginning.”
Judging from her own application experience, Dixon said the biggest surprise was the difference between those downloading the app and those actually using it. “That was an eye-opener,” she said. By measuring and monitoring usage and return users, she said her company decided to conduct marketing campaigns to remind users to come back.
Something that both experienced and novice developers could use is a checklist of what not to do, or common deadly pitfalls for applications. Todd Moore, founder of TMSOFT, said he could have used on when developing the White Noise application in 2008, which features a variety of sounds to improve sleep. It wasn’t his first attempt – he’d developed 40 apps. “You just have to keep doing it until you succeed,” he advised.
It’s important to listen to the customer – a user in the Midwest asked for a cricket noise to be added to the app. He also has a beta feedback group whom he asks to test sound upgrades. A loyal beta group could be family or people who enjoy being beta users.
“Never rush an update out before you’re sure it works, especially if you have hundreds of thousands of users,” he said, saying he learned from that stressful experience. “They will hold your feet to the fire.”
Developers in the audience shared information about their current or planned applications, including for suicide prevention, reducing hospital infections, and making it easier for physicians to communicate with each other.
