Mobile applications improve mobility and, if done right, they can help make workers more productive.
The "if done right" part is really important. Apps are easy to screw up. You have to choose between native and Web apps, you have to make sure your app actually simplifies and improves a business process, and you can't invade users' privacy while you're at it. This month, some sage advice about building mobile apps has come from the blogosphere.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Building mobile apps with a purpose
Most developers start the journey to building a great app with a decision: native or Web app? There are people who believe that native apps rule and Web apps drool, and they have good reasons to think so. But Web apps have a purpose, too.
On his Diversity Limited blog, technology evangelist Ben Kepes writes that dismissing Web apps altogether is silly. The world isn't black and white, and IT doesn't have to be either. There are companies that can make native apps because they have the time, developers, resources, mindset and money to do it. But there are other companies that don't have the tools to build four different versions of the same app for different operating systems. Who can blame them for using HTML5-based apps instead?
"The major impact of going down a native development path [and] having to replicate development resources across multiple operating systems is a not insignificant burden on organizations," Kepes writes. "For smaller organizations, it is worth foregoing a little bit of native polish for the agility that a 'code for all platforms' strategy can deliver."
Just because you can't afford native apps doesn't mean your Web apps have to stink. And some companies find that the benefits of HTML5 apps outweigh the fact that they can't take advantage of device and OS-specific features: Lots of platforms support HTML5, Web apps are easier to update than native apps and they're backwards-compatible. That's not to say that you should only build Web apps, but don't discount them.
Whether you go Web or native, here are some important things to remember about building mobile apps. The first is that they have to be easy to use. Freelance technology writer Ron Miller writes that the appeal of applications is that "you don't need IT to help you choose them or install them. They are mostly free or very cheap, and if you try one and find it doesn't meet your needs, no harm, no foul."
When enterprise applications aren't easy to use or don't meet users' needs, workers aren't going to use them. "Employees just want to find a way to get their job done without wrestling the tool to the ground to do it," Miller writes. Plus, workers already have tons of apps available to them in their devices' app stores that are user-friendly, have sleek and simple interfaces and make work a lot easier.
Tracking mobile apps without spying on users
The next critical thing to remember about building mobile apps is two-pronged: You have to track app use and performance, but you can't invade users' privacy.
Once you've found a business process that you can simplify with a mobile app, designed a clean and easy-to-use interface, and deployed the app to users, your work isn't done. You need to know if, how, when and why workers are using the app. Collecting analytics about your app is a great way to see whether employees are adopting it and how you can improve it, but you can't collect that data anonymously.
Philippe Winthrop, founder of the Enterprise Mobility Forum, writes, "In the mobile case, the telemetry need not be anonymous. In fact, it's very easy to see how it could be anything but anonymous, because the device is enrolled in the MDM tool, and the security tools you're using for your mobile apps are able to recognize exactly who you are."
This is a hot-button issue around many aspects of consumerization: Users don't trust employers to not watch their every move, which is exactly what collecting data about application use is. You'll have to notify users that you're collecting data about how they're using their mobile devices, and they may not like that. Even though you know you're using your powers of telemetry for good rather than for evil, users won't necessarily see it that way.
Should there be an app for that?
The last thing to consider (or possibly the first) is whether your app is really doing anything. If your mobile app or tool isn't simplifying a process, what is it doing? Benjamin Robbins, co-founder at Seattle-based mobile consultancy Palador, says don't waste your time with mobile; "If you can't do it right, don't bother." He uses paying for a Starbucks coffee with his mobile device as an example:
"I was disappointed to find that there wasn't much difference in the payment experience…. It's only managed to change which piece of plastic we pull out of our pocket. Instead of grabbing a debit card, I grab my phone," Robbins writes. "It lacks innovation, is tied to the way it has been always done, and only puts a fresh coat of paint on an old outhouse."
Ouch. It might be a little harsh, but it's true, and it applies in the enterprise. You can't just take a business process and make it work on a mobile device; you have improve it. Robbins adds, "Many enterprises aren't even making [mobile processes] sexy, it's just the same bad process displayed in a much smaller window. They mistakenly think they are 'going mobile' by offering a mobile interface when all they've really done is gone small."