Beautiful mobile applications, beautiful user experiences Part 2

In part two of this guest blog for the Computer Weekly Developer Network, Sybase technical and mobile evangelist Ian Thain discusses the new mobile application landscape characterised by new and more beautiful user interfaces. Part one can be found here.


If I have one piece of advice to give when you’re migrating your application over to mobile — please talk to your existing users first.

Find out what application features they use most, what they like and don’t like about your existing interface and what new features they’d love to have incorporated to make their lives easier.

You may be surprised by the answers you get!

Once you have that invaluable user feedback in hand, it’s time to get a formal functional specification down on paper, an Application Definition Statement (ADS).

Application Definition Statement – a definition

The ADS is a concise, concrete declaration of an application’s main purpose and who its intended audience is — to build an ADS you should have little or no preconceived idea as to what the application will eventually become.

• Firstly, list the features that you think the users might like based on your previous research, around a dozen items in the list is a good number.

• Secondly refine who you believe the core users users will be and then cross reference the features list with the user list to ensure best fit.

• Once the one paragraph ADS is complete and agreed, pin it up on the wall and make sure that it is adhered to! It’s your roadmap, and it will keep the development team on track.

Keep in mind the four main cornerstones of User eXperience (UX) design – availability, simplicity, efficiency and familiarity. Even though you’re starting with a fresh mind-set for the mobile development, it pays to ensure that your users should still get a sense of familiarity from your product, something to ease them into using the new mobile version without jolting them out of their comfort zone. Factors like efficiency and availability will require intelligent use of backend technologies, especially if your app is data heavy in any way.

Ed: Is Thain correct about those cornerstones? If we apply those rules to a car for example, it has to be available (it should start), simple (functional without safety concerns), efficient (goes without saying) and familiar (ergonomically and aesthetically pleasing) — so that works, but just how far can we carry the analogy: televisions, yes – but pizzas, probably not.

Personally I am a great believer in building as much of the application in an ‘occasionally connected – always available’ model that allows data to be stored locally on the mobile device and updated bi-directionally back to the backend systems when available, minimising down-time for the application and the user alike.

There is nothing more annoying for a user of a mobile application than not being able to use the application when they want or need to. Mobile users tend to concentrate on one thing very well and so the application should make the interaction simple and efficient. The user is an expert in their field and understands the business domain intimately, so the experience you deliver should be familiar and relate to their expertise as well as following the default experience they are used to within their mobile operating system of choice, such as iOS for example.

Remember innovate and enhance!

It’s wise to choose your application interface development tools carefully, as they can make all the difference between a good result and a great one. There are any number of tools that help with iterative design processes. These include such services and software as Balsamiq Mockups, iMockups (iPad Application) and App Layout (iPad Application). There are also an increasingly large number of mobile interface elements available for Adobe PhotoShop, Illustrator and Fireworks. Some can be interchangeable, for example iMockups can generate .BMML files for Balsamiq mockup import.

The concluding part of this story follows shortly.

Editorial disclosure: Adrian Bridgwater works in an editorial capacity for the International Sybase User Group, a completely independent association that represents thousands of users of Sybase products in more than sixty countries around the world. He is not an employee of Sybase but seeks to work with ISUG to support its work challenging and questioning Sybase product development and training.