The right way to release a mobile app – Human Services’ new student app

I’m pleased to say that with all the apps now being developed by Australian governments, the Department of Human Services’ new ‘Express Plus Students’ App, has managed to address almost all the criticisms I’ve had previously regarding government mobile apps.

What were these criticisms? And which did the Department fail to address? Read on…

Have a clear purpose

The first criticism I have about government mobile Apps is that sometimes they seem to be created without much thought about whether they actually are needed at all.

It is important to resist any urges to create a mobile App simply because you want to make one (as a shiny toy, for experience or credibility), or a senior manager wants to look good to their peers or Minister.

There are aspects of government business which, frankly, the community just isn’t interested about. Apps, particularly in government, need a reason – a good reason – to exist, as well as an audience interested and ready to download and use them.

Don’t create an App when you need a mobile site

One of the most costly mistakes governments (or anyone else) can make is in developing a mobile App when a mobile site would have met your needs and be more cost-effective.

If you’re mainly providing a wrapper around website content and functionality, or providing textual information with a few images and buttons, it is usually faster and cheaper to build a mobile site than a mobile App.

This is because, well, building websites is simply cheaper, and while a mobile App needs to be recoded for every operating system and screen size, a mobile site will work across all internet-capable mobile devices without the coding overheads.

It is far easier to update as mobile site to suit emerging devices – by creating device specific style sheets, which are automatically applied when someone using a particular device visits.

This saves the money that would otherwise be spent in developing versions of your App for different devices and keeping them all up-to-date.

Mobile sites (should if built well) allow you to update the content easily, quickly and cheaply without potentially requiring development time and a user download. Though note that with clever App design this can also be achieved through having a mobile App that presents content drawn from a website or even a text file online.

The worst case – and I have seen it in practice – is when content is hard coded into an app, then there’s a need to update it urgently. Frankly it’s not easy to push an App through the iStore in less than two weeks, and this is after development. Apps are bad news for urgent updates.

Where your content is mostly words, mobile download speeds aren’t generally an issue. It is when you get to video content and sophisticated functionality, or where your users are likely to operate beyond cost-effective 3G or wi-fi range (such as boat owners, remote communities and foreign travellers) that you may wish to consider a mobile App approach actively.

Design to standards including accessibility

When designing apps it seems that many basic usability and accessibility features can get forgotten, with many apps designed to operate in non-standard and non-intuitive ways. There are standards for a reason and standards-based apps will stand a better chance of feeling easy for regular app users to adopt (just like most Windows and Mac programs follow standards).

This means using the design paradigms for iOS, and Google’s design principles for Android.

It also means tapping into the accessibility features built into iOS, and Android.

Use inbuilt controls

Using the inbuilt features and controls in mobile operating systems is also important. For example rather than building a map feature, use the one provided on the device.

I have seen Apps where the developer has built all kinds of nifty features that already existed in the operating system. This is sloppy, expensive and rarely results in a better experience.

Built in a reporting system

While you can find out how many App downloads have occurred from most App stores, tracking actual use of mobile Apps requires a reporting system hooked into the code itself.

This is fairly easy to do today, with Google Analytics supporting App reporting, and a number of custom reporting packages available from other organisations that are simply embedded in your App’s code.

Having this reporting information is about more than accountability to the Minister, it is about understanding where, when, how and why people are using your mobile App, and helps you build an understanding of your audience so you can keep improving the App – and build new ones – that are even better.

Too many government apps are released without a reporting system, and it’s very hard to reverse-engineer one in after release. People who previously downloaded an App can get mighty sensitive about the information you are suddenly collecting plus you miss the initial burst of activity that helps you identify issues and strengths.

Have an official agency account at App stores

This is one of my biggest frustrations, as seeing an official government App listed in an App store as having been created by ‘Silly Mobile App Company’ instantly reduces the credibility, trust and the ability to actually find the App by searching on the agency’s name.

Also when an agency is making several Apps, often each is with a different Mobile App developer due to tender processes or skills. They then get listed under the name of the developer in the App store, which then cannot list your Apps together in a single place (‘see other apps from this organisation’), reducing your agency’s ability to cross-promote.

Plus, what happens if you make an App with a company, then have a falling out? It can be tricky, even impossible, to get the App out of the developer’s account and move it to a new account on App stores.

It seems a no-brainer to me that agencies should register accounts on the main App stores before they start creating mobile Apps. This allows them to register their Apps under their own name, rather than that of developers and to use their reputation to build interest and trust.

Link to your Apps

Due to the wonders of modern technology it is possible to link from your media release and website to your App, as well as to link from your Apps to your other Apps.

Something that agencies still don’t appear to do well is to link their mobile Apps together, with an in-App method of downloading other Apps from the same agency, or even government.

Also media releases still lack basic details such as screenshots of Apps or links to them in the App stores. I know it might come as a surprise to some people, but journalists understand how to use hyperlinks, as does the community – and both groups love pictures as much, if not more, than they love words.

Most media releases are read online, not on fax machines – so links can allow someone to get straight to the mobile App without messing around with a search in an App store.

With many releases now read on mobile devices, it makes sense to allow people to click to download the App straight away. It is inconsiderate to force someone to search when they can click.

And that final point is my only criticism of Human Services’ ‘Express Plus Students’ App.

Go to their media release, which has been widely tweeted, and there is no link to the App in the iStore. Hopefully this is an oversight they will fix. It should not take long!

Note that I can’t tell if Human Services’ App has a reporting system built in either, but I’ll give them the benefit of the doubt!

So how has Human Services’ App been received by its audience?

This is a great ‘good news’ story already – with a number of five-star reviews. Check them out yourself at the App iStore (and note that there’s more reviews to read if you can click through to iTunes).