Containerization or native email? How about providing both to keep your users happy.

One of the big questions in enterprise mobility management is whether to use the email apps that come built in to mobile devices, or whether to use a third-party sandboxed email app. Both of these options require some sort of compromise (because you have to find the balance security and accessibility some way or another).

One of the big questions in enterprise mobility management is whether to use the email apps that come built in to mobile devices, or whether to use a third-party sandboxed email app. Both of these options require some sort of compromise (because you have to find the balance security and accessibility some way or another). Assuming all other things are equal, why not just let the end users decide which way they want to compromise?

Even today email is still the killer mobile app, but also it’s in a unique position because it presents a fundamental choice between two basic options: Assuming that you want some basic management capabilities (password, encryption, remote wipe) and control over how the email-related data is shared, you either can use the built-in email client (the user will get a great email experience, but will have to be okay with mobile device management controls) or you can use a third-party app (no need to manage the device, but the email experience will be slower and more cumbersome.) There are also some other in-between options that can secure just the attachments in the built-in app, but for now I’ll lump those in with the MDM option.

This duality doesn’t really exist with other types of apps, because there you’re dealing with a third-party app no matter what. The playing field is a lot more level.

Now given these two email options, there are naturally a lot of opinions about which is better for what use cases. (For example, many will say to use MDM and the built-in app for corporate devices and use a third-party sandboxed app for BYOD.)

But I think that all other things being equal, if both options are valid for a given scenario, we should let the end user pick which one they want to use. Since they both represent some sort of compromise, users will have their own feelings about which way they want to go. Some might want a super-fast experience, so they’ll be okay with having a device-wide password and and maybe some other restrictions. Other users might be concerned about privacy, or they might like the keeping all their work stuff segregated in one app, the a third-party sandboxed client would be better. (Personally, I’ve gone with both at different times. I like the native app for work email, especially during conferences when things are coming at me rapid fire. But for personal email, I like the Gmail app. It’s slow, but I like that it’s integrated with all my other Google stuff.)

The consumerization of IT has taught us that we can’t just push one way of doing things on our users. Certainly specific use-cases or regulations will force us to use one technique or another, but when both options are acceptable, we should pass that choice on to users. This also means that the email options don’t necessarily have to map directly to corporate and BYOD, either. There may be some correlation, but that shouldn’t be the sole factor.

For EMM vendors, this means that providing both email options is key. A few years ago we had an environment where MDM vendors were in one camp, and mobile app management vendors were in the other, but fortunately today most EMM vendors offer both options on equal footing, which is great news for customers.

The next step is to make sure that both email options are well integrated, so that it’s easy for users to switch back and forth on their various devices whenever they want. Having licensing terms that make this possible would be a big help, too.

You might be thinking that since both of these email options represent a compromise, we should be working on better solutions instead. Indeed that’s the case, but the options are getting better. Just think back to the early days of the iPhone when it didn’t support Exchange ActiveSync and there weren’t any third-party email apps. We got those, and then later made more progress with more flexible email options like with iOS 7. There’s no doubt that will continue.

Even though the email options are getting better (or to put it another way,the compromises are getting easier to stomach) we still have to balance corporate desires for security and manageability with users’ desires for ease of access and integration, no matter what. As long as there are multiple valid options for how to strike that balance, whenever possible we should leave the choice to the users.

Join the conversation

2 comments

Send me notifications when other members comment.

Please create a username to comment.

Containerized email will not succeed without providing rich feature set (comparable to Outlook) with UI that match today expectation. If you only provide the same feature set as the native one, people will not see why they have to use it and if the UI is bad, people will prefer native email experience.


Have to say that "most" of the containerized email client are… awful...


TouchDown is probably the most advanced one in term of features but the UI is really ugly. The other one have reduced set of feature to say the minimum…


The only one that seems to be either rich and have cool UI (my humble opinion) is WorxMail from Citrix but it require the Enterprise Edition. There is still some work to do but it looks great.


Cancel

Jack you are absolutely correct.  Citrix can go both ways on this providing the end-user with many options.


Cancel

-ADS BY GOOGLE

SearchVirtualDesktop

SearchEnterpriseDesktop

SearchServerVirtualization

SearchVMware

Close