Four reasons enterprise software should skip native mobile apps

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.

Tony Byrne, Enterprise 2.0 B.S. List: Term No. 1 Consumerization

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.

[tweetmeme source=”bhc3″]

And all the cool kids are doing the native app thing. Path is an iPhone app. Facebook wins high praise for its iPhone app. And Wired ran a story declaring, essentially, that apps killed the web star.

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.

1. Lists, clicks, text, images

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.

2. Enterprise adoption is not premised on the app store

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:

• It’s the corporate standard
• They’re already using it
• They need to use it
• It’s already achieved network effects internally, it’s the “go to” place

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.

3. Mobile HTML looks damn good

Visually, native apps can look stunning. They are beautiful, and functional. No limitations of web constructs means freedom to create incredible user experiences.

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.

4. Too many mobile OS’s to account for

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.

I’m @bhc3 on Twitter.