Harri Salminen's Forum Nokia Blog

Random thoughts about mobile (enterprise) application development.

Browser and enterprise applications

widianuser | 11 May, 2007 07:09

For all these years that I have been in mobile industry one question has remained the same. Typically at some stage of enterprise project customer poses the big question: "But why we just can't use the browser of the terminal, instead of making this client application?"

First the answer was that making data calls (this was before GPRS) is so slow, unreliable and expensive. Then we got GPRS, UMTS and even WLAN.

Then the answer was that browser is not capable of doing the right things or the browser is so slow to use. Then came xHTML browsers.

Then the answer was that browser user-experience is poor, page rendering bad and browser misses some vital parts that desktop browsers have. Then came the new OSS web browser for S60 3rd edition.

Although the infrastructure now seems to be there, I still think that native application is the number one solution for mobile enterprise applications. Here are the most important reasons for this.

Most importantly: native application can be used offline. It is a common scenario that application will be used by field workers in places where network coverage cannot be assumed. Do a test: visit some basements, machine rooms or stairways and see what happens to network coverage. Browser based solution that works fine outdoors and in offices would become unusable in places where application would really be used. Native application can cache data and work fine without network.

Important design rule for (enterprise) applications is that user interface must be easy to use, robust and follow the same look and feel with other applications. UI that would in some other context be judged as uninteresting and non-innovative can work fine in enterprise application. Remember that users are not technology savvy early adopters, but people that probably use the application because their manager has told to. Native application with familiar UI components like settings screens, tabbed dialogs, searchable lists etc. are valuable asset when trying to manage and display large amount of enterprise data.

In many cases applications must be aware of the surroundings of the terminal and integrate with terminal's native applications. Assume an application that needs to take a picture, geotag it with GPS information, attach it to email and send it to office. Or application that switches terminal's profile based on meeting information stored to calendar. These are examples of features that just cannot be made with browser, but are typical enterprise requirements.

Don't get me wrong, I like browser solutions and I also create those for enterprise and consumer use. Just remember to assess carefully the application requirements and usage scenarios before making the big decision about the overall architecture, no matter how fancy the browser would be.