By: Hutch Carpenter | June 6, 2011
The desire to “consumerize” mobile apps for their own sake is stoking today’s outsized enthusiasm with device-specific enterprise mobile apps at a time when HTML5 is right there staring us all in the face.
The runaway success of the iPhone app store has demonstrated that people love mobile, and seek the great user experiences that mobile apps provide. You see these wonderful little icons, beckoning you to give ‘em a tap on your phone. You browse the app store, find an app that interests you, you decide to try it on and see if it fits.
There has been a clear market shift to the apps market, and consumers have gotten comfortable with the different apps on their phones. It’s come to define the mobile experience.
So why doesn’t that logic extend to the enterprise? Because the native app experience isn’t a good fit with enterprise software. Four reasons why.
Think about your typical enterprise software. It’s purpose is to get a job done. What does it consist of? Lists, clicks, text and images. And that’s just right. You are presented efficient ways of getting things done, and getting *to* things.
This is the stuff of the web.
For the most part, the on-board functionality afforded by a mobile OS and native features are not relevant for the enterprise software. When trying to manage a set of projects, or to track expenses, or to run a financial analysis…do you really need that awesome accelerator function? The accelerometer? The camera?
The functions of mobile hardware and OS are absolutely fantastic. They’re great for so many amazing apps. But they’re overkill for enterprise software.
A key value of the app store is visibility for iPhone and Android users. A convenient, ready-to-go market where downloads are easy and you get to experience them as soon as they’re loaded. This infrastructure lets apps “find their way” with their target markets.
An AdMob survey looked at how consumers find the mobile apps they download. Check out the top 3 below:
Users find apps by search, rankings and word-of-mouth. Great! As it should be. Definitely describes how I’ve found apps to download.
Irrelevant, however, for enterprise software. Distribution and usage of enterprise software is not an app store process. Employees will use the software because:
Adoption via the app store is not needed. The employee will already have a URL for accessing the app. For example, I use gmail for both my personal and work emails. For whatever reason, the second work gmail will not “take” on the native email function of my iPhone. So I’ve been using the web version of gmail the last several months. It’s been easy, and I didn’t need to download any app. I knew where to access the site.
But you know what? You can do a lot with HTML5. Taking a mobile web approach to styling the page and optimizing the user experience, one can create an experience to rival that of native apps.
As you can see on the right, an enterprise software page presented in a mobile browser need not be a sanitized list of things. It can pop, provide vibrant colors, present a form factor for accessing with the fattest fingers and be indistinguishable from a native app.
Indeed, designing for a mobile experience is actually a great exercise for enterprise software vendors. It puts the focus on simplicity and the most commonly used functions. It’s a slo a chance to re-imagine the UX of the software. It wouldn’t surprise me if elements the mobile optimized HTML find their way back to the main web experience.
We all know that Apple’s iOS has pushed smart phone usage dramatically. And corporations are looking at iOS for both iPhone and iPads. Meanwhile, Android has made a strong run and is the leading mobile OS now. However, in corporates, RIM’s various Blackberry flavors continue to have a strong installed base. On Microsoft’s Phone 7 OS, “developer momentum on Windows Phone 7 is already incredibly strong.” (ArsTechnica).
Four distinct OS’s, each with their own versions. Now, enterprise software vendors, you ready to staff up to maintain your version of native apps for each?
37signals recently announced it was dropping native apps for mobile. Instead, they’re focusing on mobile web versions of their software. In that announcement, they noted the challenge of having to specialize for both iOS and Android.
Meanwhile, Trulia CEO noted the burden of maintaining multiple native apps for mobile:
“As a brand publisher, I’m loathe to create native apps,” he told me, “it just adds massive overhead.” Indeed, those developers need to learn specific skills to building native mobile apps, arguably having nothing to do with his core business. They have to learn the different programming code, simulators and tech capabilities of each platform, and of each version of the platform. By diverting so much money into this, he’s having to forgo investment in other core innovation.
A balkanized world of OS variants creates administrative, operational support and development costs. Not good for anybody.
While I’m sure there are enterprise software apps that can benefit from the native OS capabilities, such as integrated photos, for most enterprise software, mobile should be an HTML5 game.