With mobile development, it's easy to get caught up in the excitement of new technologies and new features, but it's critical to stay focused on what the app should achieve from a functional standpoint.
Over many years of working with mobile since its early days, from 5250 barcode scanners and Windows Mobile to today's stunning devices, I've seen many applications fail to meet the actual business needs. That might sound crazy, but the way mobile apps are built in terms of focus, use, and form factor is new for many people.
Prioritizing those three items—focus, use, and form factor—should really help you meet business users' needs.
A mobile app has to be much more focused on specific needs and functions. Take an enterprise app like BPCS, JDE, or any other enterprise ERP; they are generalists letting you achieve many things for many different types of businesses and users. You should not try to mobile-enable this kind of application in its entirety because users out in the field don't need the entire app's heads-down data entry, reporting, and full BI suite. They will need some core functions of these things, and you can put these together into an app that allows them to get what they need without having to navigate the entire mass of the enterprise. Having a good understanding of which functional parts of the app mobile users require will enable you to give those users just what they need to be effective. In the office, it many be OK to put 60 fields on a screen and let the users pick out the key info, but in mobile we need laser focus on what the users need to do their jobs.
Keeping navigation simple and intuitive is also important. Ensure you remove any unnecessary navigation from your mobile design. If your users have to drill down through multiple levels of menus, you really need to think again. Focus on what the users need and how to get them to perform it most quickly and efficiently.
To get that focus, you should deeply understand how the app would be used. While starting with a clean slate is nice, it's often useful to look at what you already have (assuming you're enabling mobile access from existing apps and services) and work from that. A good start is to spend time with users on their desktop apps, get them to talk through the scenarios on mobile use, and look at the screens and fields they'll need. Doing that won't give you a 100% hit rate, but it works much better than assumption. For brand-new development, you'll need to look at the business users' requirements.
In use, the new mobile app should look and feel similar to other apps users know and are already using on their mobile devices. The bar in terms of look, feel, quality, and interaction has already been set by the native OS and other apps already in production. This is a standard you should strive to meet.
Regarding native vs. web apps, don't worry about the delivery at this point, and don't believe the hype. Ensure that the app will serve the intended purpose, and leave the delivery method down to when you have firm needs. I have seen many arguments against HTML delivery—"Web apps can't do this" or "Our native app had a better feel"—when those so-called native apps are actually HTML in a container. There are advantages and disadvantages to each method of delivery; just make sure you find the truth.
The specific form factor you choose will determine some capabilities and limitations, and it will provide you with the constraints you'll need to work with.
Smartphones have a small screen (typically 4-5 inches), are mainly used in portrait orientation, and are touch-based with a small virtual keyboard. They can support Wi-Fi, but most likely your apps will be accessed over a cellular network. Smartphone apps should generally be used for light interaction and consumption of information.
Tablets range from 7-12 inches, generally the smaller versions being more useful in portrait orientation, and the larger being used in landscape mode. They can support Wi-Fi or cellular, and it's important to be aware of the characteristics that these modes provide from a security and performance standpoint. Tablets have a much larger and more functional virtual keyboard or may have a physical keyboard attached. The great thing about tablets is that they can be used for light and heavy use. Tablets can be incredibly productive for both creation and consumption of information.
The form factor for mobile devices with limited space can seem a real issue with data intensive applications, and that's where IT wisdom comes in. Several years ago, I was with IBM i champion Trevor Perry in South Africa and heard a session in which he explained our job in IT is to turn data into information. Never has that been truer than with mobile delivery. Think about how you could turn your data into information that would be immediately understood with just a glance. Think of an existing big IBM i app as the weather forecast on TV that is 3-5 minutes in length. On a mobile weather app, you can drill down, but you see today's weather in just a couple of seconds. Now imagine the weather app pinging the user with something useful like "It's going to rain, so take an umbrella out with you." Could you add the same kind of proactive value add to your apps?
Provide What's Needed
In summary, if you take a small step back, you can engineer your apps to be totally aligned with business-user needs, providing compelling value. It does not have to totally change the way you work, but attention to the key differences between full-screen apps and mobile apps will yield a different and often remarkable result for everyone.