This post was written for my friends at Raona and appears in a slightly different form their September newsletter. I'll be speaking at their SharePoint Open day in October on the Mobile Intranet and will be covering some of the content below see www.Raona.com for details.

What do I mean by a convenient App

Apps usually run on convenient platforms that is devices that you pick up turn on and start using be they Mobile Phones, Tablets or in this day and age of more modern PC operating systems some laptop and desktops.

These devices usually have a relatively consistent user experience be it imposed by the operating system or a shell the device manufacturer has implemented. Using the built in apps on  these devices is usually really intuitive as long as they follow this convenient and consistent experience. With a few exceptions most modern devices do.

A convenient app is one a user can load and just start using with a minimal learning curve because it does what the user expects. Convenient apps allow the user to focus on the content not the control.

When it comes to apps Mobile devices are not Desktops

This might seem like a simple statement but it is so often forgotten in my experience that it is frightening,  

I'll get back onto apps in a moment. Before I do, I used to go further than just apps and say Mobile Web Sites are not Desktop Web Sites but that distinction is being rapidly eroded by advances in Mobile browser technology with all three major mobile platforms now giving a pretty near desktop browser experience especially on tablets. Having said that it would be crazy to fail to cater for all of those older devices still out there. I did some stats for a fairly well known retailer less than six months ago and they still had 12% of their traffic coming from old WAP browsers (i.e. Feature Phone browsers)  For example there are still a goodly number of older Blackberry devices out there with really restricted browser experiences.

If you are designing a web-site today I would probably aim to keep all the bells and whistles on the desktop site but also create a minimalist but functional site for older devices. Often by rethinking the user experience it is possible to give users of older devices the information they want without bloating the pages with graphics and animations. The old maxim of keep it simple stupid has never been truer.

There is also a very similar rule Keep it Small Stupid. When designing web sites for older devices you really have to take notice of the footprint. Some of these devices will simply fail to render a page if it is too large. A good rule of thumb is to keep each page below 3K. This might seem challenging but can be achieved by good use of typographical design rather than imagery, You should always include a link to your full desktop web experience on every page in case a mobile user with a more modern device is accidentally directed to the mobile version.

As always it is worth knowing your audience and if you know for certain that they won't be using older devices (but see don't assume below) then investing in a single resolution scalable full featured site might be a good alternative. 

 A lot of these rules also apply to App development. There are several issues that affect Mobile developments that are not common on Desktop developments.

Don't assume...

• That a desktop app will port to a mobile app just because it is written in the same language. For example porting a .Net Silverlight application to a Windows Phone is a relatively simple task from an underlying  code point of view but there are enough differences in the design markup (XAML) to leave you tearing your hair out at times.
• That  a desktop layout will scale to a portable device. This is so obvious but I have seen it done many times. People use portable devices with their fingers not mice they do not have the precision to click on that tiny button in the top right corner that looked really aesthetically pleasing on your desktop design.
• That all mobiles are the same. This is a critical mistake people make especially when designing cross-platform web applications. It is really important to note that the users of an iPhone will expect a different base user experience to the users of say an Android phone. A very simple example of this is navigation backward through an application flow. Android users either have a physical back button or an on screen equivalent visible in every app, whereas IOS users be they iPhone or iPad  expect apps to include back buttons.  It is possible to make careful choices and have n application that  uses common controls so that it feels natural to all users of all devices but often it is better to adapt to at least the three major device types.
• That users will understand your navigation paradigm. Most desktop developers come from a world where there is a limited concept on navigation basically point and click with maybe the occasional double tap or right click. That is blurring a little with  he gesture controls now in both Windows 8 and the latest Mac OSs but it is still how the majority of desktop developers think. It is not how mobile device users think they expect to be able to swipe their way through screens, finger scroll up and down lists. Double and right clicks are anathema to them. It isn't difficult to build for these expected experiences and most development tools for mobile do make it very easy to include such features but I have seen countless examples where such functionality has been left out. This leads to very confused users and busy help desks - not a good combination. One really classic assumption I saw last week was where a developer had built his cross platform application on a PC and was testing in a Google Chrome browser on the PC. He had a lovely working application. The problem was that it had an awful lot of input fields and he had been told it was bad practice to have too many screens in a mobile app, so he had put all the textboxes on the screen without labels and relied on tool tips to display what content was required. Tooltips that popped up perfectly in his test browser when he hovered the mouse over the textbox. This of course was disastrous once deployed as you can't hover over a control on a touch device and get any feedback. What he perhaps should have done was use Watermarked text boxes where the required content is shown in greyed out text until the user enters something. These are common practice on mobile applications. One slight aside to this story to show how things are always moving on in the mobile world - a number of manufacturers are now working on highly sensitive capacitive touch screens which will be able to tell the difference between hovering over an area of screen and touching it. It is likely these will appear in devices int he near futures and operating systems will evolve to support them.
• That you have memory to burn. This could also be entitled be careful with your test devices, I recently was called in where an application that had worked fine in testing was failing in the field. This was an Android application and the in-house development team had wrongly assumed all Android devices were pretty similar other than their OS version. They had carefully tested their application on a range of tablets bought especially for the occasion. These were of course newer devices with plenty of memory. Once the application hit the field it was being downloaded on four and five year old Android phones with limited footprints and their lovely graphic rich UI was just overloading the memory.
• That yours is the only app a user uses. I had good example of this recently where a LOB app had been locked down and didn't allow the user to exit. It was then distributed to employees including those who had Brought their own devices (BYOD) to work. The IT support desk were soon dealing with irate callers wanting to know why they couldn't get out of the app to read their mail or browse the web.
• That you have unlimited battery life - devices have small batteries and most of their built-in apps are built with this in mind. They go to great lengths to reduce battery usage. The key thing is not to use unnecessary processor cycles or as I once succinctly put it don't loop when you can sleep and wait. Equally don't use data connections unnecessarily - anything that uses the devices radio will burn battery. An app that drains a users device quickly will get noticed and probably quickly uninstalled.
• That your users will have modern devices. A number of recent surveys have highlighted the fact that whilst the majority of us change our phones within 2 years there is a significant minority, between 20 and 40% depending on who you read, that haven't changed their phone in the last 5 years, In my experience this is particularly noticeable in corporates where 5 or 6year old Blackberrys are often the norm. Certainly if you are building an application for a non-controlled audience you should consider providing Operating System version specific builds with reduced functionality or graphics for older devices. These are relatively easy to build and most of the app stores/marketplaces allow you to specify such multiple versions.
• That the device will be connected. This is usually the most difficult thing for desktop developers to get their heads round. Mobile devices are not always connected even in the best of environments. Signals drop out, devices are taken out of signal areas and Wifi points get overloaded. Even momentary drop outs can cause chaos for an app expecting to be always on. I once saw a very complex warehouse system grind to a halt because one of the store men had taken his handheld scanner with him for his smoke break. This had taken him just out of wireless coverage and the system, ported almost directly forma  desktop based scanning system, had not be designed to cope with that.
• Finally that you have control of the runtime environment. This is a dangerous assumption I have seen a number of times in recent months which I think is sometimes bred into established IT departments where they have always been able to control what hardware is used to run what software. In this current brave new world of BYOD it is not an easy assumption to make. Even if you control the issue of devices for an application you will probably find users trying to run it on their own phones or tablets. I should mention there are ways of  ensuring apps only run on certain controlled devices and that it is perfectly possible to have control of the runtime environment this way but you need to ensure that is truly what you want to do. Most Mobile LOB apps are all about productivity and as with the general BYOD discussion you have to ask is it more productive for users to use their own devices that they are familiar and comfortable with rather than impose a device on them. There is no right answer to that question. You could for example see that a point of sale application in a store could easily be tied down to company supplied devices but then an application for a travelling salesperson might be better to run on their own device.

In conclusion there are a significant number of pitfalls in developing a good, convenient, LOB Mobile App but if you take care and avoid the traps above then it actually isn't all that difficult to produce a one.