This is the second in a series of posts describing what I see as the primary issues affecting the current user experience.

In my previous article, I indicated that simple payment is one of the keys to a successful product or service. Following on from this, there are many other areas where simplicity is the key. I have a saying that, "The gain must be greater than the pain". Whenever I assess a new mobile application I ask myself if the gain from using it would be worth the pain using it on the mobile platform. This article is about minimising the pain and ensuring the device, product or service is easy to use.

Having worked on J2ME, Symbian and mobile web projects, there is something common to all of them. A large number of users give up before even using the application. Why is this? The first hurdle is provisioning, setup and installation. Most users’ phones are just not set up correctly ‘out of the box’. Access points are a typically not set up. Users aren’t given any clue as to the problem and even those who are, are powerless to know what to do. Network operator customer care is usually very poor and often gives out incorrect advice which confuses end users further. Those that successfully download applications tackle a bamboozling array of security warning messages and are eventually lucky if the version they have downloaded is compatible (runs) on their phone.

These complications aren’t limited to 3rd party applications. For example, the Nokia Series 60 has a helpful looking ‘Chat’ application. When I start it, it says, ‘No Server defined, Define One Now?’ When I say yes, it provides me with many configuration options which I haven’t a clue how to complete. If I ring Nokia I am sure they will say it’s network dependent. If I ring Orange, I am sure they will tell me to ring Nokia. These things just can’t be allowed to happen.

Say I run an added (or internal) application or service and I get an error. Is it a programming error, phone error or network error? There’s often no way to tell. Ring the phone OEM, application provider or the network operator and you will get the runaround. There’s no audit trail of what went wrong.

Lets say our application is successfully running. Confusion often occurs when things have been implemented in ‘non-standard’ ways. For example, on Microsoft mobile platforms, the close window button doesn’t actually close the application but puts it to the background. Also, you have to do Start…Help to get help on the currently active application. Both these things have confused my users for nearly a decade now. I am picking on Microsoft but examples are everywhere, especially third party applications. Consistency is the key. Guidelines and tools to enforce them follow on from this.

As an example from the OS world, UIQ 3.0 allows for a much richer user interface. Is this really a good thing?  I feel that I have seen this before. A while ago, Microsoft released the Palm-Size PC platform. It had the menu at the top of the screen and had rich graphics with shadowed icons. It all looked very pretty. Sales weren’t good and the press said that it was too graphics rich which was something more suitable for the desktop than a mobile device where simplicity should be paramount. Microsoft responded. They performed extensive user studies and implemented a complete overhaul of the UI. The result is the Pocket PC UI. All the icons, buttons and windows had their shadows removed. All the screens were cleaned up to provide the minimum amount of information. There are lessons to be learnt here.

Some of the descriptions above may be over dramatised and are obviously ‘worst case’ scenarios. However, they happen too often and I believe we should all think about the following when creating devices, products and services…

• Working ‘out of the box’. Think of it like working like a Mac rather than a Windows machine.
• Giving better help when things go wrong. This might include error reporting information and audit trails for support staff.
• Addressing poor network operator customer support (not sure how – send me your ideas!)
• Conforming to guidelines and established practices . For example, User interface guidelines with tool support.
• Keep it simple – even if it’s complex underneath.

All this has ignored the fact that the application itself must work correctly. This will be discussed in ‘Part 3: Testing’ of this series of articles.

This post was written by Simon Judge, Freelance Mobile Developer.