For the past 3+ years, at Matrix we have been evaluating smart phones for corporate use. For most companies, the selection of a smart phone device is a non-issue: its RIM's Blackberry product and associated BEZ (Blackberry Enterprise) server.

Being a Waterloo University engineering graduate, I certainly would have no qualms about going the Blackberry route for a corporate smartphone device. However, working through the evaluation process at the corporate level puts a different perspective on these devices.

The biggest issues are: cost (device, dataplans, setup), maintenance, usability (not always in that order) and finally farther down the list - application platform. By application platform I am referring to custom business applications that are outside of contacts, email and calendar. I suspect as time goes on the application platform item will become more important at Matrix, but right now its not a priority.

Matrix users at present though have very basic requirements for a smartphone - they want it to work well as a phone, and be able to use it as a tool for managing their calendar, contacts and email in that order.

The Blackberry excels at these, but its requirement for a server to enable corporate messaging makes it more costly than other offerings, when you factor out the device as an application platform.

While the Blackberry Enterprise Server provides more value in terms of features, the market it was designed to serve has changed since its inception. The security measures on other platforms, while not as sophisticated perhaps as the BEZ, are good enough to be effective (more about this later). The dataplan monitoring and restrictions were something that used to be important - but now that phone companies are being forced to provide more logical plans that offer data pooling and reasonable data limits, the requirement for centralized monitoring has diminished significantly. The BEZ acts as a platform for software development - but other platforms are now providing sophisticated developer tools as well.

Finally the BEZ requirement adds yet another server (albeit virtual) that requires licenses, maintenance, updates, expertise and attention. The additional requirement of a CAL for devices connecting to the BEZ add another layer of cost - especially when you consider that many companies already pay for Exchange CALs.

So at Matrix, the focused shifted to evaluating mobile devices that could directly connect to Exchange via the Exchange push mechanism - which narrowed the search to Windows Mobile based devices.


We started with Windows Mobile 5 running on the Audiovox 5600. This was a reasonable device, but proved too limited for most users so never got off the ground at Matrix. We followed that up with the Motorola Q on the same version of Windows Mobile. These proved to be flimsy, difficult to use, and very unstable.

We tried the Treo - but it was pretty clunky and uninspiring, and suffered from many of the same issues.

So we decided to wait for Mobile 6. The first device on Windows Mobile 6 we got from Bell was the HTC 6800. While the push email, calendar and contact sync and security features all worked exactly as advertised, the devices themselves were terrible. They crashed constantly both while using the data features and while talking on the phone. The crash would typically involve the device freezing up and requiring the user to remove the battery to get it to reboot.

So we returned these to Bell and tried out the HTC touch, which appeared to be getting better reviews. It turned out though that the Touch had an annoying habit of cutting calls off and locking up when notifications came in while on a call - requiring the user to remove the battery. This happened to me so many times I lost count.

It was pretty astonishing that all of the Windows Mobile devices were so unreliable, considering that Windows Mobile is in its 6th version, and how long Microsoft has had to get this right. I don't blame the providers or the hardware makers, as its Microsoft's responsibility to ensure products labeled with their brand are implemented correctly.

The real killer though for these devices is the poor quality of the user interface, especially in light of the length of time Microsoft has had to perfect it. All of the Windows mobile devices suffered from poor UI implementation - regardless of which version we tried. It seemed to stem from two Microsoft traits - attempting to force the same metaphor used in Windows onto the device regardless of its form factor, and the fact that in the past Microsoft has been able to slowly iterate its way to success through patience and market attrition.

The dynamics of the mobile market though are completely different from the pc market - it moves much faster, customers are much less tolerant of hardware problems and phones quite simply cannot crash.

Because of all the problems with the Windows Mobile devices, we have now deployed the Apple iPhone to our test group - to great success. The devices are very stable, fast, and the user interface is outstanding. There are still areas of improvement to be sure, but they are by far the best device for doing basic email, calendar and contacts for the price out there.

It is interesting to note that Apple is doing the same thing in effect as Microsoft by leveraging their core operating system OSX onto the iPhone device. But that is where the similarity ends. Apple recognizes that the presentation layer is dependent on the hardware used, and takes great pains to ensure their presentation layer is well matched to the device it is being used on. Microsoft does not seem to understand this - and has attempted to put exactly the same UI metaphor designed for PC screens onto a small form-factor device. Google's studies on their home page illustrate how enormous a difference even a few pixels can make.

The problem is exacerbated further by the fact that Microsoft do not control the hardware used to host their mobile OS - so manufacturers rather than using one defined interaction metaphor, attempt to get around shortcomings by offering all metaphors for interacting with the device.

The HTC 5600 was the worst offender here. Not only did it have a touch screen it also had sliding keyboard, a stylus and a joystick. To make matters worse, different interaction methods had to be used in different places. When scrolling through the contact list, the touch screen was best, making an entry it was better to use the sliding keyboard. Dialing a number - best to use the stylus, since the onscreen keypad was too small for effective finger use (unless you were 4 years old)... Very very confusing and complicated to use.The HTC touch was marginally better in that you didn't have the keyboard, so the onscreen keyboard was better. It still offered a stylus and joystick though just in case. The latency on the onscreen phone dial pad was unreal, making something you do all the time on the phone - dial numbers - incredibly irritating.

Contrast this with the iPhone in which Apple decided to use touch only, and therefore designed all applications on the device to work properly with the touch UI. Magic - the thing works so well we have not had a single user come back to us with any issues. The amount of time this saves in terms of helpdesk support is enormous when compared to the Windows mobile devices.

Now you are probably saying - 'you know if you had gone Blackberry in the first place, you would have saved probably as much as the BEZ server would have cost to implement..' and this may well be true. However, we were doing the evaluation with a very small (5-6 users) group of users. The HTC devices were returned to Bell, who to their credit, were quite understanding about the problems we had with the Windows Units.

Finally, by taking our time and not being in a rush to choose a device, the cost of dataplans has plummeted since we first started looking into this 3+ years ago. With the iPhone plan we now get 6gigs of data for 30 dollars vs. more than $100 for 100m as recently as last year.

While the dataplans still have a long way to go when compared with the US, the cost savings by waiting were enormous. Especially when you put that into the context of a company where there are likely to be 60+ of these things in use, that is a huge cost savings....and we still don't have to buy and provision another server!

In terms of security of the iPhone/Windows mobile devices - we had several live tests of this. We had several users including myself who lost the HTC devices. In anticipation of just such an event, we had implemented the security policy on the Exchange server to enforce passwords and clean wipe after 10 attempts.

Turns out someone found my HTC phone, attempted to log into it, gave up when it wiped itself and discarded the device. A nicer person found the device, and returned it to Bell, who contacted me.

We think the iPhone->Exchange is a winning combination. There are still a few limitations with the setup, but we anticipate they will be addressed in future updates of the iPhone platform.