Avoiding the Top 3 Gotchas of Mobile App Development

By Ted Gauld, Adapx — November 14, 2012

As the next wave of tablets hits – more and more managers are getting besieged by requests for custom mobile apps to automate their unique workflows. While it can be straightforward to automate browser-based online-only processes, building fully customized apps that can be used offline remains challenging.

It becomes especially challenging when teams want a variety of form factors and the workflows may change. While new technologies bring new challenges, there are also a common set of pitfalls to avoid regardless of the technology being considered. Here are the top three avoidable "gotchas" to ensure a successful roll out.

Gotcha #1: Everyone likes your mobile app except the employees — and they don't use it

All too many teams have invested large amounts of money in mobile apps only to see them fail in the field because the teams don't like them. The source of the issue can range from the device itself, the app layout, the sequence of the workflow or even the size of buttons.

Key to avoiding this gotcha: get mobile worker feedback from the start. It's critical to work with mobile teams to not only understand their work flows, but to also understand the environment in which they are working.

Some environments may be best suited to rugged devices, or even pen and paper. An app that is snappy and responsive in the office over a good network connection may slow to an unusable crawl over a poor connection.

You only really understand the potential issues and solutions when you get in the field with mobile workers, understand all aspects of their environment, and really get to know the sequence of their workflows.

Teams on their feet constantly will want lightweight devices with long battery life. Teams collecting data in sporadic bursts like inspectors will also want fast-starting devices or paper with digital pens or scanners for quick, ad hoc data capture.

Unexpected issues could be, for example, with gloves or bright sunlight resulting in expensive solutions failing in the field. Start a test with a small group that has an interest in the project's success. Trialing with a team that is uninterested or overwhelmed by other tasks may not give accurate results.

They may also be less forthcoming with feedback or forgiving with tweaks to the approach that you may want to add over time to fine tune the experience. The other side of the user-acceptance coin is that successful apps will also get more people asking for additional apps to streamline other business processes. That's a good thing.

You may also find that you want to have different device options – even for the same workflow – to best meet the needs of different workers or environments.

Gotcha #2: Getting locked into a proprietary solution that stakeholders like IT don't like

Along with the many device options, there are also many software options for building mobile apps. The recent press about HTML5 versus native app development reflects both the options and the fact that there may not be a single best approach for all mobile app development.

One of the key avoidable gotchas is selecting a proprietary solution that few people know how to implement and support. Since resource-strapped IT teams can be reluctant to support unfamiliar apps or bring them on their networks, new solutions could face resistance. It's especially challenging when it comes time to make changes and the only way to implement them is to rely on employees who may have changed roles or go back to the vendor for more expensive consulting.

Key to avoiding this gotcha: Pick an approach that is built on standard tools and data formats.

Even though many apps can be developed and deployed in the cloud independent of your IT team, it still makes sense to include IT early in the process. Regardless of how you implement your solution, your IT team may ultimately want or need to get involved to extract data or even to support devices. To make that process smooth, get their feedback early.

They can avoid such gotchas as selecting browser-based app development that is incompatible with a future planned device purchase. They can also avoid issues with vendors and architecture that make it difficult to extract or integrate data into key internal back-end systems and process.

The likelihood of hitting these issues reduces dramatically as teams work with vendors and solutions that are based on familiar, standard tools, generating standard file formats and methods for accessing data.

Gotcha #3: Not preparing for change

Even in the fast-moving mobile app world, it's surprising how many developers build hardcoded apps, get the thumbs-up from mobile teams and expect that their work is done.

Even for great apps, the more they are used, the more that change requests will start arriving. While change requests can be a pain, they are a good thing to the extent that they reflect mobile workers are using the app, engaging, and wanting to improve it. It's even better when they start requesting new apps, forms and mobile workflows to automate.

The gotcha comes when you realize that your hardcoded solution has painted you into a corner and it's too cumbersome to change your apps or forms. Many teams are shocked when they return to vendors or custom developers and see the expensive change fees.

Key to avoiding this gotcha: Work with solutions that can be changed and updated relatively easily.

Build change into your original plan – from perspective of technology, vendor, and budget. Teams are often tripped up by complex apps or forms design tools that require a lot of training, custom coding, or scripting. Making changes can often seem as if you are rebuilding the entire app, with the same costs.

Coding the changes is only part of the issue. Many teams also struggle with actually getting the changes pushed out to the mobile workers in the field.

In an ideal world, operational groups could easily make changes themselves without creating a burden on IT or requiring expensive change fees that ultimately cost more than the entire original project. The key for this is using familiar form design tools. Ideally, anyone who can design a form in Excel should be able lay out a mobile form so they can easily create and change forms.

You can test a solution by sending a potential partner one of your forms and asking them to do a quick live demo. If it takes a lot of time or they require a lot of money upfront for a pre-sales demo, then that may be a future glimpse into the complexity of using that tool.

The other set of important change-related vendor questions is about how to deploy the changes. Any solution that requires devices to be physically gathered and handled by IT would be difficult to manage, especially for larger organizations with distributed teams.

Entirely web-based apps can be easiest to manage since changes can be made and managed on the server. If apps need to be usable offline, then offline client apps that can be managed and updated remotely would be the best choice. For example, new web-based technologies like HTML5 can enable apps that can be used online or offline – all through the browser – greatly simplifying app development.

Of course the ultimate approach will depend on a team's specific needs. The key is for teams to plan for change and make sure that their solution can support the likely change requests and needs that they will encounter.

There is no one-size-fits-all in mobility and successful deployments require a range of considerations and important steps. While many of those considerations depend on the specific technology choices, these three gotchas are common across all mobile technology deployments. The good news is that they can be easily avoided.


comments powered by Disqus

RATE THIS CONTENT (5 Being the Best)

Current rating: 3.3 (3 ratings)



Must See


What Enterprise Apps Need Now

Mobile Enterprise explores how companies across all segments are increasingly leveraging mobile apps to enhance productivity for everyone, from field service workers to C-level executives.