The U.S. federal government may not be where you’d expect to see mobile innovation or find good app development suggestions. While there’s still a public sector bureaucracy in government, a number of government agencies are beginning to develop new ways to connect with citizens and invest in mobile technologies for internal use.
Granted, most agencies are doing so because of requirements under the Obama administration’s 21st Century Digital Government Strategy. One of which is that every federal agency must make two high-value, customer-facing services available via mobile devices over the next year. Still, the innovation is happening and the agencies that have already taken up the challenge are good models for agencies that have yet to do so.
They’re also good sources of advice for any organization that is beginning to develop an iOS or mobile app strategy.
NextGov’s Tim Hoechst reports that there are a handful of key lessons that most agencies have come to terms with in the effort to create successful mobile solutions. Here’s a summary of the advice he has for government agencies that can apply to any organization beginning iOS and mobile app development as part of a mobile strategy.
- Putting a mobile front-end (be it HTML 5, native code, or a combination) onto an existing desktop solution is not a mobile strategy. A stop-gap measure maybe – if that’s what it is, an organization needs to acknowledge that and develop a plan and timeline for replacing that stop-gap measure with something better.
- When developing a mobile app version of an existing tool, you should examine the underlying processes and workflows. Then use that information to design a user experience that works well given a device’s form factor and OS functionality.
- In designing an app, you should examine how specific mobile features of a device like the iPhone or iPad (GPS, camera, accelerometer and so forth) can enhance the experience and deliver a better or more versatile solution or workflow.
- Consider accessory devices and the additional capabilities that they can add. Some examples that are common at this point include biometric readers, barcode readers, and insulin glucose meters.
- Design for the future as well as for new features and capabilities that a device or mobile OS offers. As Hoechst puts it “Just as you wouldn’t design a DVR just to mimic a VCR, you shouldn’t constrain yourself based on what’s available (or possible) on the laptop today.”
- Understand that the most effective iOS or mobile apps have a relatively narrow focus, which allows them to better address user expectations. You may find it better to create multiple separate apps for a workflow than to create a single more complex app. One way to approach this is to design an app focused on the 20% of a process that gets used 80% of the time. Once that’s complete, move on by adding apps that cover the rest of the process.
- Understand the environment where the app will be used. Will it require constant connectivity to pull data or can it operating in an offline state? That’s a big question and one that should be considered before development begins.
Beyond these basic tidbits of advice, Hoechst notes that security should be a serious consideration for government agency apps. The same can be said of any internal enterprise app. While the security and encryption requirements for private companies will vary from the standards that federal agencies are required to meet, there are four key objectives still vital for enterprise tools: user authentication, access control to networks resources and data, encryption of data while at rest on a device and while being transmitted over a network, and app sandboxing – a security feature that is already built into iOS.
Source: NextGov
