Apps were a $5 billion business in 2010

Last week I facilitated a session on mobile apps, for various interested parties. We were joined by Jamie and Mike from the Improvement Service, as well as Gordon and Niall, developers of the Android and iOS apps for the popular Edinburgh My Bus Tracker.

It was a really interesting session, with lots of great ideas thrown around. Below are some of the headlines and common issues.

Native apps vs mobile web

Macmillan's mobile-friendly web pages

One issue that arose time and time again was the difference between providing native mobile apps, which people download and install to their device, and offering a good mobile experience with your existing web offering. There are many great examples of web content being served up for mobile devices in a clever way – Macmillan’s mobile website being a good example of design that imitates a native app.

But there are many reasons why a native app might be useful – to exploit a device’s hardware, to make full use of location based information, or to provide functionality that doesn’t rely on a permanent web connection. However, the developers around the table were quick to point out that a native app has to have a clear use, and needs to be something that people would come back to. Users typically judge the value of an app in the first 30 seconds of using it. If they’re not impressed by that point, they will most likely delete it or just not bother using it again. There’s also no point building an app which simply mirrors a website’s functionality – serving up static information. That should be left to a well constructed web page which renders itself well on mobile devices.

Why mobile?

Jamie Kirk from the Improvement Service delivered a fascinating presentation on mobile usage and the rise of the app, providing various intriguing examples. His overall message was that mobile browsing is indisputably on the ascendancy – it is expected that by 2013, more people will be using mobile devices to access the web than PCs. In fact, Jamie tells us that there are more mobile phone subscriptions in the world than there are toothbrushes. And these advanced devices will continue getting cheaper, meaning more and more people have access to them (including those who can’t afford a computer).

This profound shift in how people are accessing online services will have a massive impact on how we are providing those services and information, and we need to start thinking about this now.

How to build apps

A common concern amongst local gov colleagues is the time and effort that it takes to develop mobile apps. In these days of budget cuts, it is hard (if not impossible) to justify directing valuable funds to such developments. But there are alternatives to an organisation forking out thousands of pounds on a trendy new iPhone app.

Working closely with local developers is perhaps the best option, but raises a vital issue – open data. To build useful local gov apps, developers needs access to useful and usable data. This is a crucial element and is something we need to start doing better. If we get that right, people will have everything they need to build the apps that they, as citizens, see a need for. If we invest in documenting and releasing data in standards-compliant formats, expose that data to the right people, and advertise the problems that we are trying to solve, the people are far more likely to help us solve those problems. A good example of this happening is challenge.gov in the US.

Challenge.gov - a place for public and government to solve problems together.

Local universities are also great place to scout for talent – students will often happily take on a project in support of their studies, to gain valuable experience and reputation.

However, the cost and time required to build an app should not be underestimated, and the necessity to design for multiple systems and form factors adds to this exponentially. The developers around the table were unconvinced by app-building competitions, where a prize fund is offered to successful developers. Their concerns were about the amount of time and effort required to submit to such a competition, without any guarantee of a return on investment.

People power

Another aspect discussed was that of crowd sourcing – getting the public to gather data themselves. Obvious examples include allowing residents to report street faults to their local authority. In this instance, the potential of a mobile app is clear – it provides all the functionality needed to log the relevant data (location and perhaps a photo) on a device that is always with you.

Whilst this opens up a lot of exciting possibilities, it also presents challenges for the local authority in terms of how they monitor and deal with these potential new channels of customer engagement.

Social exclusion

Just as our efforts on the web must always come with the caveat that “not everyone is on the web”, so too must we remember that web-enabled mobile devices are a long way from ubiquity. Anything we do with these channels must be seen as complimentary to other methods, and not exclusive.

However, web and mobile also opens up new opportunities for reaching out to certain individuals who we may be struggling to reach. An obvious demographic is young people – where possession of a smartphone is likely to be very high, whilst engagement with government may be very low. Innovative use of the web and mobile can offer us new and powerful ways to reach these citizens.

Make it fun

Foursquare badges

Many of the successful apps we’ve seen recently include an element of gaming, even if the app or task itself is not a game. Foursquare or Gowalla are good examples, where badges and other rewards add a competitive edge to the basic and arguably dull act of geotagging your current location. It’s not hard to think of ways in which this could be incorporated into local gov apps, to encourage engagement and uptake. And local authorities often have good ties with local businesses to offer prizes, to further attract interest.

The risk of success

Something interesting happened when the Edinburgh BusTracker service got really popular during the extreme weather of Winter 2010, it started putting unexpected pressure on the servers responsible for delivering the data, ultimately leading to performance issues and the need to expand capacity. This is an important aspect to consider when building such functions, or allowing others to do so. Through limiting access to an API, and retaining the right to withdraw that access (even if just temporarily), we can mitigate some of that risk.

These points simply scratch the surface of the challenges we face in becoming mobile-friendly, and there are no doubt many more elements to consider. There is definitely a groundswell of interest, though, as well as a growing demand from the public, making for interesting times for anyone involved in making sure their services are ready to go mobile.

Jamie is off to the US in a few days to conduct research into mobile and government. Follow his adventures at howappt.com.

iPhone photo by yum9me – shared under the Creative Commons license.

Dave Briggs (@davebriggs) told us that people scatter their knowledge in various places, as unconnected snippets, and the job of Knowledge Management (KM) is to connect up those snippets and present them in a meaningful way.

Lesley Thomson (@lelil) underlined the importance of conversation and reported on last year’s highly successful ScotGovCamp, inviting others to run similar events (also welcoming volunteers to organise ScotgovCamp11!).

Annie Robertson of Subsea 7 showed how a well-developed KM process can lead to a rich repository of ‘lessons learned’ which add huge value to large organisations, harnessing internal knowledge and overcoming geographical barriers.

Annette Thain from the NHS outlined their approach to KM and how they convert this into action to change lives in the real world.

Jamie Kirk (@jamie_kirk) from the Improvement Service showed how mobile browsing is the future and told us about his upcoming research project on mobile app usage in North America.

David Friel (@ISreporter) told us a bit about his job as reporter for the Improvement Service and asked us to consider the relationship between KM and comms.

Finally, Mike Mclean (@michaelJmclean) gave an update on the forthcoming Knowledge Hub, which is looking like it has huge potential.

Apologies to the speakers if I haven’t done you justice in these one-liners. Feel free to leave a comment to flesh things out!

One particular point that will raise eyebrows is the continued advocacy of separate sites for mobile devices. There is an ongoing debate about the pros and cons of such an approach, brought to the fore by Neilsen’s post last February comparing Mobile Web 2009 with Desktop Web 1998, and concluding that a separate site is best. Many of us were not convinced, and as Henny Swan argued at the time:

It also hints at repeating the mistakes of desktop web design circa 1998 where we thought the answer was to design for one browser, use proprietary technology, build text only websites for disabled users…the list goes on. So let’s not make that same mistake and instead fast forward to one of the principles of good web design that dug us out of the dark hole of 1998: progressive enhancement.

Henny Swan: Progressive Enhancement for mobile

Henny described how a ‘one site fits all’ approach can be achieved using media queries, and it’s certainly a far more attractive solution than designing and maintaining separate sites.

But this all relates to websites in general, rather than specifically to Intranets, and I was interested to look closer at the suggestion of a separate mobile Intranet.

Intranet on the move?

Mobile Intranets – a unique case?

Intranets serve a very specific business purpose, and for a defined set of users, so the scope for delivering a useful mobile version is arguably better than with a public site:

1. You’ll have a far clearer idea of who would want to access a mobile version, and for what purpose.
2. You’ll also have a good idea of the devices being used to access the Intranet, assuming they are company-issue.
3. Finally, the potential advantages that a tailored mobile version could deliver to staff are tangible and might justify the time and effort required to build and maintain.

Neilsen points out a couple of potential problems – one being that most staff will already be in an office (and therefore presumably have desktop access) and the other being the possible lack of technical expertise at operating handheld devices. The first point is simply part of the business case – if you have a significant amount of staff needing Intranet access out of the office, then you have a compelling business case. The second point is a training issue – and in fact many companies might equally observe that some of their staff aren’t skilled enough to operate their desktop computer properly either. If the business case exists for such usage, either from a desktop or a mobile device, then training should be in place to support that. Neilsen also observes that devices are becoming far easier to use, reducing this risk.

Neilsen also points to a move towards “anytime, anyplace” access. This is certainly true of many large companies who are promoting flexible working options, and is likely to be a crucial element of any business case for creating a mobile-friendly Intranet.

Working on the move

So let’s assume we do want a separate mobile Intranet. What will it look like?

For a start, how do we access it? Will the user be required to log-in? That would seem sensible – an Intranet is, by its very nature, not for public consumption, and the risk of the employee’s mobile device being lost or stolen means that security must be considered paramount. Measures such as automatic time-outs might also be necessary, as well as preventing log-in details from being saved by the device.

Once logged in, what would we want to see? This is where a bit of research will prove invaluable. Find out what the key tasks are and make them easy to access. Accessing staff directories seems to be an obvious one, for example, as well as receiving any urgent news or alerts. Customisation would be ideal here, allowing people to compile a list of common tasks and links.

Opening documents

My organisation’s Intranet is probably fairly typical in that it has a massive amount of information available as downloads – PDFs, Word documents, Powerpoint presentations etc. Whilst some newer generation devices can handle these quite well, it’s important to remember that they can cause issues when downloading and opening (because of large file sizes, incompatible formats etc). As with any website, any key information should always be available as a web page as well as a download, and a company moving towards a mobile-friendly Intranet must keep this in mind.

Is your Intranet awash with downloads?

Apps

Neilsen mentions one team that developed a dedicated iPhone app, rather than building a separate site, to optimise the design for mobile users. This sounds like a perfect compromise, but only if you have full control over the devices that your staff are using, and only if those devices are advanced enough to support such apps. We’re not all lucky enough to get iPhones from our employers, so this may not be realistic for many, but the use of apps is nevertheless a good example of improving usability for mobile users.

Publishing from a distance?

As a web author for my organisation, I can see tremendous benefit in being able to not only access the Intranet on the move, but also to update the pages too. Mobile access to the publishing environment could be a killer feature, either via a browser-based interface or using a dedicated app. Again, the security risks of this are obvious, so measures would need to be in place (such as multiple log-ins or gated publishing requiring third-party approval). But the potential could be huge – especially in emergencies or out of office hours.

Standalone systems

One issue that may be harder to conquer is the fact that many Intranets are also a portal to numerous standalone systems and databases. Staff directories, forums, pay systems, HR processes, online forms, room bookings etc – these are very often delivered as separate products and making them available to a mobile device could be far trickier than simply re-formatting some webpages. Any business case would need to look at the practicalities of this and decide how crucial these additional systems are to an employee on the move.

Adaptability

One of the most convincing arguments against designing mobile-specific sites is that devices are constantly updating and advancing, and that there are very few universal standards to design to. Even if you know what devices your staff are using today, it could be that they are upgraded far sooner than your website will be. Any attempt to design a mobile-specific site would need to have sufficient adaptability to ensure that the next corporate upgrade of devices does not leave you with a useless mobile site. I’ve seen huge problems with companies designing Intranets to suit their dominant corporate browser version (for example, IE6) which then holds back any attempt to refresh that browser later on, in the fear that their sites will break (which, in the case of IE6-friendly sites, will almost certainly be the case).

Mobiles - evolving fast (image by True Blue Titan*)

Conclusion

For the reasons explored above, it’s more likely that a mobile Intranet will be a stripped-down version of its desktop self for reasons of practicality, rather than usability, although there is an argument for offering a tailored design to streamline the most common tasks undertaken by staff on the move. This is unlikely to be successful without significant investment of time and expertise, however, so a strong business case is crucial to put focus on what is to be achieved.

Failing that, designing your Intranet with mobile-specific styles, or at least adhering to common best practice and web standards, will help to ensure that anyone logging on whilst away from the desk will still get to what they want.

* Phone Evolution image is a derivative of a photograph by True Blue Titan, used under the Creative Commons licence

However, a debate has been sparked about how best to provide for your mobile users. Usability expert Jakob Nielsen has just published an article comparing the Mobile Web 2009 with the Desktop Web 1998. Ultimately he calls for the creation of separate sites for mobile devices, and therein lies the debate.

Henny Swan discusses why building a separate site is not a great idea on her blog. This follows on from Bruce Lawson’s own musings on whether mobile web development is compatible with the One Web.

I’m definitely against the ‘two sites’ approach in most instances, and many devices nowadays have decent browsers which render pages just fine anyway. For this reason I hate it when I get directed to a Mobile version of a site, often with greatly reduced functionality. By all means offer a stylesheet optimised for mobile browsers, but make it my choice to switch to that (I’ve seen good examples where the main page says “we have detected that you’re using such-and-such device – you might be interested in viewing the mobile version here”).

One issue brought back to the fore when building for mobile devices, though, is the need to keep page sizes down. Designers have increasingly been discarding that ethic with the rise of broadband, but we need to keep building lean sites with clean code to help those who are paying by the MB to browse (as well as for all the other reasons)!

Of course, we’re also seeing a proliferation of apps designed for mobile devices, often allowing them to bypass the standard websites completely (for example, I have Y! Mobile on my device which pulls in my Yahoo e-mails, weather and news etc, without actually visiting the Yahoo website itself). This is a whole new way of enticing mobile customers to access your site’s functionality.

All of this is really about the wider issue of usability. I’d like to do some decent research on what disabled users expect from their mobile devices before taking a definitive stance on the accessibility issues. For now, though, I won’t be building any separate mobile sites – just concentrating on getting the main one right.

Related links

• There’s a discussion about this on AccessifyForum, including an edited version of this very post.
• Bruce Lawson has written an article on ZDnet: Forget the mobile web: One site should work for all.
  
• Also see the W3C’s Mobile Web Best Practices (MWBG), as well the relationship between MWBG and the Web Content Accessibility Guidelines.