More questions for mobile developers

You might have read my posting about the questions you should ask before a mobile project and still you decided to create a downloadable application for your customers. You probably have to support a use case that requires offline operations or user interface must be better than browser can provide with your target devices. Here is the next list of questions to think about.

Does installation package include configuration?

When your application gets installed to terminal, it must get configured; application must know the server address, username, port number, security scheme etc. Technically oriented people will ask correct settings from administrator, open settings screen, input values to right fields and start using the application. Unfortunately that is not enough. When application is delivered to hundreds or thousands of users, it is not likely that all of them are "technically oriented". Your help desk will get flooded by basic questions about correct settings or people will ask local guru how to do the settings, trying desperately to understand what is wrong with the application. Some users will make it, others don't. That's why you must create installation packages so that "installation includes configuration" or if that is not possible, create a startup-wizard to guide the user through the basic settings. If application is ready to use directly after the installation, you have done good job.

Can you manage the application after the installation?

Sooner or later something goes wrong and your customer will call the service help desk telling that “I didn’t change anything, everything was working OK but now all I get are error codes that I didn’t write down. Can you help me?” If you haven’t thought about this during the development I guess your service people will be clueless and frustrated quite soon. On the other hand, if you have some mechanism to remotely query the state of the application or you can ask the user some relevant questions, then the problem solving task is very much easier. Supporting device management (DM) solutions can be your life-saver.

Most probably installing your application using standard device management tools is not an issue - application installation is one of the basic tasks that those systems do. However, there are some other device management tasks that can be enabled or disabled by design. Can your application be configured with a configuration file? If yes, is the file stored to directory where device management applications can read and write it? If you put that file to a DM writable directory, you can find good ways how to fulfill requirement "installation includes configuration". Some device management solutions support plugins for 3rd party applications. Check what DM systems your primary customers use and try to find out if such plugins can be implemented.

If you feel that device management solutions are out of scope, then at least include feature that checks from your server if there is an upgrade available, something like what application inventory service suggests.

Is your application brand-aware?

If your business strategy allows, make your application "brandable" by design. That means that when large customer asks you to make them a special version with their corporate branding, you should feel safe to answer "yes". This might include things like changing the application caption, icons, about-boxes, or almost everything that can be used to promote company's brand. Branding questions may not be asked very often, but when that happens you will be happy when you know that it can be done.

//Harri