Mobile government: the real one is yet to come

Let’s make a short overview of the situation: we have the global crisis, the Stability Pact, we can’t hire, we can’t give any bonus to our colleagues, and service and software providers are even more in troubled waters. So, what else should we face in the government IT? Is there any new funny thing – except, of course, Open Data – that we could wish for? Actually, there is something that is waiting behind the corner, namely, mobile government: the real one.

Nowadays, everyone has in some way interacted with a smartphone or a tablet application (for friends: app), or at least he heard about it.

So what is government doing with respect to this widespread success of mobile technology?

The term “mobile government” goes back to year 2003 and it was mainly meant to address citizen-government interaction through mobile phone, which then (a geological era ago) was focused on short message service and simple call-back rings to toll-free numbers.

The first adoption of app in government is linked to Open Data, as a positive side-effect of such a global transparency movement. This has been particularly related to collective brainstorming sessions (crowdsourcing), putting into practice the “Many Minds Principle: the Coolest Thing To Do With Your Data Will Be Thought of By Someone Else”.

Such a principle, applied to government, can be translated as: governments should think about producing good data, and publishing them in open and easy-to-use ways, without puzzling too much in looking for fancy app, this will be thought about by someone else out there, better if with a public contest, where government itself will establish the award in cash.

These are the so-called civic hackathons, such as BigApps in New York City, and in Italy AppsforItaly in 2012, an experience in Torino in 2011, and two in Bologna and Roma.

A structured approach to the massive production of app and, more extensively, of software “as a service” from government was conducted by the US government in 2009, with a first prototype of federal App Store, the “apps.gov” website, which has been dramatically downgraded since last December, mainly having become an unmanageable mix of free and expensive app.

Usually, governments are linking their Open Data websites with a showcase of app that were based on their datasets, even if this is done in an unstructured and unregulated way (see below the paragraph related to risks). In any case, a huge boom in app production is expected in 2013 from US local governments, with respect to central agencies. 

Moreover, app and mobile technologies have been included in strategic documents aside with Open Data principles: the so-called “Decreto Crescita 2.0”, published in October 2012 at art.8 encourages Italian governments and public utilities to build telematic services for intelligent transport systems and infomobility (implicitly based also on app), while in art.15 it anticipates the near adoption of technical guidelines for mobile payments.

The US Digital Strategy, published in May 2012 highlights the potentiality of mobile technologies for government, and asks each federal agency to select at least two services useful for citizens, no matter if they are currently online or not, and to make their mobile version within the next 12 months (see par.7).

Pay your attention to the change of pace: it is no longer a matter of creating a public app based on the Open Data published by a website of a certain city, rather it is a requirement to “convert” useful services for citizens to mobile technology.

Therefore, we are approaching the mature phase of mobile government, aiming at creating reliable, secure telematic services, linked with back-end systems of Public Administrations, and coherent with their internal processes, even though accessible from a smartphone or a tablet.

An app is no longer seen as a natural consequence of the public open data process, but it is conceived as a formal two-way communication channel with citizens, and not limited to this. As a matter of fact, the US Digital Strategy itself deals also with the adoption of mobile technologies among federal workforce, and with the corresponding security issues.

With respect to the early e-government taxonomy of interaction levels between citizens and public websites (page19), an extension of which to the mobile world would be desirable, we have a large amount of 1-2 interaction level mobile app, that is, a simple information content consumption and, more rarely, some simple interactions, mainly related to social media sharing. In very few cases an app makes it possible to start an administrative procedure with a Public Administration, or to pay some public services related to my personal profile as a citizen. If we scroll several official government websites, we can realise that this is true not only for italian public bodies.

Even this example of profiled contents provisioning offered “as a service” by a private company to US local governments in order to build interactive citizen-public links, it is mainly based on feedback collection from citizens, and barely on telematic procedures submission.

The real mobile government is therefore yet to come, and interesting opportunities could lay behind it, even for Italy and Europe, where a long-lasting regulatory process regarding e-government has been carried out.

Let’s now come to us, to those living in the trenches of the Italian Public Administration: what could be done with respect to such challenges? Let’s try to give some brush stroke to the whole framework. 

Costs

How much does an app cost? Here you can find some interesting evaluations, even if they are not specific to the public administration. However, the implementation of a mobile government app as meant in this article, which translates a whole service into the mobile platform, must take into account back-end integration, security, content coordination with the corresponding website service (if existing), and other context-related issues that make the whole thing quite complex.

If we really want to give an estimate, a good mobile government app, integrated with backend systems, will barely cost less than ten or fifteen thousand Euros.

It must be noted that the development of a native app for both iOS and Android can easily increase the cost by almost doubling it, unless some optimisations are carried out (see below).

You must also consider the overall direct and indirect costs related to the creation and management of the Government official profile in the Store, especially with the Apple Store, while the Google Play store makes the whole process easier, requiring less information to the Public Administration. 

The role of the IT department

Thinking at building in-house a whole mobile government app, given the amount of new technologies required with respect to the already dynamic Web technologies, can be quite prohibitive.

You could start with a training process, not just focused on mobile, but also on the new related web technologies (such as HTML5 and CSS3), in order to first better control the provisioning process, thus knowing what software providers are talking about, and being able to properly manage the testing phase.

To this extent, a good idea could be to plan a training on the job where internal employees work aside with app developers.

Do not underestimate the helpdesk issue: you’ll be facing mails from citizens asking «why in the smartphone X I cannot find your app, while in the smartphone Y of my sister the app comes out with a different keyword» (it’s not a bug, it’s a feature, is said here). Some app functionalities may behave differently depending on the specific smartphone or tablet model.

No matter how much effort you’ll spend to build a nice app, you may eventually face similar issues.

A role which is not properly belonging to the IT department, that is strategic in any case, is the one related to who will be collecting feedbacks and interactions that were sent through the app, and who will answer and react to those feedbacks within the different available digital channels (e-mail, Twitter, Facebook, or even contents being “pushed” back into the app itself).

Risks

Since we are talking about a frontier-land, several risks can be estimated, but even more cannot. Therefore, you’ll be likely forced by events to throw your heart over the bar, and just start doing mobile government without any further hesitation.

With regards to security, mobile technology implies interaction metaphors that are quite different from what happens in a PC or a laptop and, as a consequence, new risks can be present.

Moreover, many of the constraints that limit the widespread adoption of e-government services from citizens will likely continue their negative effect even in the mobile world: in particular, a huge amount of structural conditions that make the choice of doing a telematic service not affordable with respect to the physical paper submission must be removed – at a national or local regulatory level.

And what if a student came to you, having developed a useful app based on the open data published in your website? Wouldn’t it be worth to put that app into your brand new app showcase, among the app developed by third parties? In those cases where a civic hackathon was carried out, a jury was called to evaluate which apps were worthy or not, but what happens when you want to build this process as a permanent app showcase? How could you structure and organise the process of submission and publishing of app that were made by single citizens and are useful to the city, with a sort of sponsorship2.0?

Finally, by starting with single mobile government initiatives, each one getting data directly from the corresponding back-end system, you’ll be likely drowning into the typical “spaghetti-integration” of the web1.0 era, without an enterprise-wide platform with common services for common functionalities such as authentication, payments and business intelligence.

With the current shortage of resources, it is quite unlikely that a government will have enough energies to build an enterprise-wide platform, optimised for mobile, right from the beginning. 

Where to start from?

First, you need to analyse which services may be useful to translate into mobile technology, and which could be their potential users. Co-design may help in this phase, once a first internal evaluation has been done, you could ask citizens, talk to them and, most important, listen to their expectations, and react accordingly in the development phase.

It is also preferable to create a profile for your government on the Stores, starting with Apple and Google Play, by paying attention to the End User License Agreement: keep in mind that you’re putting your code in the devices that citizens hold in their pockets. Given that we are in a frontier-land, it would be also wise to ask service providers to formally sign that any malicious or harmful code will be ever present into the app that is going to be launched, even in its following updates, and to formally adopt the common best-practices related to mobile security.

You’ll be giving those guidelines to the app developer, for example by asking to follow the generic security controls addressed into the “Codice della Privacy” and its annex B, and the mobile security guidelines from the mobile section of the Open Web Application Security Project. By evaluating and verifying those guidelines and their adoption, side by side with the app developer, your IT team will also be starting to be trained into this new mobile technology realm.

The launch of your brand new app will be anticipated by a proper social media campaign, for example by defining a dedicated Twitter hashtag through which all the news related to the app will be delivered.

A group of beta-testers could be created among citizens, letting them try the app before it is available on the Stores.

You could also recall the app download – for example through a QR-code – in the physical office of your administration.

Particular attention must be paid to the performance issue, namely to the right tuning of: 1) the traffic exchanged between the smartphone and your server (in order not to force the citizen to watch for entire minutes the rolling circle before a page appears with her data), 2) the amount of data that need to be stored locally into the smartphone (a heavy app can be annoying for those having smartphones with little storage capacity), and 3) how many simultaneous calls will most likely be arriving to your server (in order to avoid a server congestion).

In your tests, you’ll need to pay attention to the effects of intermittent wifi connection, in particular in public hotspot, where after a timeout a new network authentication may be required.

Other elements to be considered include technologies and interaction metaphors typical of a smartphone or a tablet: touchscreen, gyroscope, and geo-localisation, giving me information regarding where the citizen is, and what is he doing (I could communicate differently with him while he’s moving than when he stands still).

One of the simplest and most effective mobile government service is the one pushing citizen data to his smartphone. Data are taken from the back-end systems and offered with notifications to the citizen, without him having to worry about anything. In order to achieve this goal, data quality becomes essential, otherwise you’ll be notifying that the school meal tax is near to the deadline…to citizens who do not have any children!

However, since a certain amount of wrong data can be physiological, it could a nice practice to put into mobile government app a functionality allowing a citizen to send feedbacks over her data quality, other than her appreciation of the app itself.

Another hard choice is the one related to which technology one should start with: whether choosing a native app (namely, an app made to run with iOS or Android), or realising a mobile web service (being accessible from the smartphone browser).

Here you can find a cool video clip throwing light on the issue.

Most likely the solution will be in the middle (mobile web app), that means that we’ll have – like it already happens in most famous app installed on your smartphone – some dummy empty boxes that make up the app to be downloaded by the Store, and this app, once launched, will get all the required contents from the Web as if it were a browser. The same app will embed functionalities that offer a user experience typical of a custom native app.

Thus, we’ll achieve the high usability of native app, together with the high compatibility with different screen sizes and smartphones, which belongs typically to the mobile Web.

The widespread adoption of technologies such as HTML5, if used properly, will allow governments to build contents once, and to deliver them on multiple platforms, according to the so-called Responsive Web Design – namely, the capability to create adaptive web contents.

Finally, as the Codice dell’Amministrazione Digitale suggests at articles 64 and 65 (http://www.digitpa.gov.it/amministrazione-digitale/CAD-testo-vigente), we need to take care of user authentication, whose strength, waiting for further regulating specifications, will certainly have to be not lower than the one currently adopted in your government website for online services.

By putting into the app the same credentials that the citizen already has for her online services with the public administration, she will be able to receive profiled contents directly into her smartphone.

With respect to this, at least other two issues need to be considered: one is related to the capability to store user credentials into the app. Yes, it may be useful to the user, to spare him to digit his credentials at every app launch. But we have to take into account that these credentials are equivalent to his hand-signature: what happens if his smartphone is stolen?

Moreover, another issue deals with the fact that almost every citizen is now used to interact-within the app – with her social networks: what happens if we mix up an app containing user personal data, even sensitive, with her Facebook profile, in order to let her share or Like an information she got through the app?

I’m thinking at different possible consequence, none of them is a nice one….therefore, for the moment, at least in this pioneering phase, it may be more cautious to keep the two environment separated, the one of institutional mobile government app, through which I can make formal interactions with the Public Administration, and the one related to social networks interaction.

Finally, dealing with in-app payments, given the complexity of the current micro-payment scenario, based on Near Field Communications, proximity interaction, and including high-level agreements among inter-bank subjects, a first approach could be based on the mobile translation of the same payment method that is being used in the online website of your government, even if this may require the user to digit his credit card numbers, of course on a properly safe and secure app, connection and interface.

As a further in-depth analysis, here you’ll find seven tips to make useful mobile local government app (mainly demanding to keep it simple, to exploit user localisation, and to think from the beginning at the integration with back-end systems). 

Opportunities 

The development of mobile technologies, together with the growing difficulties for governments to procure new hardware due to the Stability Pact, brings with it a new challenge that is mobile government meant as “internal workforce going mobile”. Here the frontier-land becomes even more pioneering, if we think that only in June 2012 the US Department of Defence published its memorandum for Mobile Strategy, pointing out at serious issues regarding the use of mobile technologies on the workplace, starting from the risks of the so-called Bring Your Own Device (bringing your personal mobile device from home and using it for work), which could imply cost savings, as well as severe security risks and consequent headaches to the IT department staff.

The same memorandum then calls for the implementation of an IT infrastructure for management, monitoring and policy enforcement specifically designed for mobile devices, and it sticks to the point of government personnel training, who will have to be able to distinguish the difference of using her/his device at home or at work.

The importance of having a common framework for the development of mobile government app is then recalled, in order to avoid the above-mentioned spaghetti-integration.

An interesting post dealing with the main challenges for mobile government in 2013 can be found here.

More recently, here you can find an analysis of how the US Digital Strategy for mobile government may be effectively deployed, for instance by leveraging already existing digital contents in each Public Administration. 

Mobile government may be a sort of shortcut to minimise the digital divide among citizens and governments: that portion of citizens that today are not comfortable with online services offered by Public Administration, may find it even simpler to interact and receive personal contents through an app.

Moreover, an app ties governments to keep it simple: those offices asking their IT department to make a simple and easy online service, producing to developers some administrative manuals of thirty pages explaining all the rules needed to make that specific procedure, will be finally forced to surrender to the obvious: in an app you can’t ask citizens to fill “tons” of forms, you can’t afford to ask them ten times his personal data, that by the way you already have in your back-end systems.

A new paradigm will necessarily have to be addressed. The “procedure” will soon become a «do you agree with what are you finding in this screenshot? If yes, please confirm, good bye and many thanks». Most likely the digital document will collapse in a flag of a database, where it will be stored that yes, on date X that specific set of data was approved by the citizen, and he declared it by tapping on the screen of his smartphone, or even better by putting his mobile phone near to a POS in a public office.

Even official government websites will be dramatically changed: after having been collected in one institutional website with huge efforts in a decade, government contents are disaggregating and taking thousands of flows, think for instance about how many hops a dataset published by a Public Administration can experience, once being re-published from other datastore in other forms or interfaces, or about how many flows can take an information regarding an event in the city, being “catched” by multiple apps developed by different providers.

Willing to do something in the short term, with respect to mobile government, we could mimic the US Digital Strategy, and try to convert at least one or two online services to mobile platforms, trying to find the right national and local regulatory context to make feasible and sustainable such an effort, and to facilitate citizens to use these new mobile services. 

Finally, with the current trend of the recent Italian national regulations to centralise the strategic and consolidated assets in the government IT (think about the unified national Civil Registry, and the unified online web service for primary school subscriptions), mobile government may be, for the next few years, a ground where local administrations may conceive and experiment new interaction metaphors among citizens and governments, then bringing the best practices to the central government, in order to spread them to the rest of the Public Administration.

*Gianluca Vannuccini

VAI ALLA VERSIONE IN ITALIANO DELL’ARTICOLO