Building great mobile apps has nothing to do with the language or IDE

analysis
Feb 2, 20136 mins

Skip all the noise about HTML5 versus native, and get away from monolithic app design to avoid crapplications

It’s kind of funny: The tech world is starting to catch up with what a bunch of us realized a long time ago. It’s all about the app. I’ve managed to read at least 15 articles in the last week and a half about how important apps are and how you should build them. Some articles argue that you should go mobile first, others assert you should do mobile only. There are the articles that claim you should write only in HTML5, and others say you should use products like PhoneGap to hit all the different platforms with your app. It’s all one gigantic mess.

Some people still think you need to be in the business of building monolithic crapplications, and others throw their hands up. In almost every case, they completely miss the point. It’s not about how you make these development decisions that look awfully like the IT decisions of old. It’s how you focus on enabling the user the best way possible.

[ Subscribe to InfoWorld’s Consumerization of IT newsletter today. | Get expert advice about planning and implementing your BYOD strategy with InfoWorld’s in-depth “Mobile and BYOD Deep Dive” PDF special report. ]

Almost all the decisions that determine how you are going to write the app that you need are secondary. The first thing you must figure out is what business need you are addressing. What is the business strategy that you are building an app to fit? How do you enable the users, whether they are the customers of your company or employees? An app should never start in IT unless the app is being built for the IT department itself. (Let’s be clear: IT needs its apps, too.)

The first thing you do is meet with the business and find out what it is trying to do. The businesspeople want the app so that they can meet a business requirement. That’s what you are there to do: Help them get there. But even after you’ve started nailing down the business requirements, you still aren’t ready to build the app yet. The next step is to sit with the actual users you are trying to enable. You need to focus on what they need to do and design something that enables them to get it done.

One of the definitions of focus is “the state of maximum distinctness or clarity of such an image,” while a second is “a condition in which something can be clearly apprehended or perceived.” These two definitions get to the heart of the problem of building an app. You need to have the clarity of understanding the business requirement while perceiving the users’ needs. Once you have this clearly defined, you are ready to start planning your app.

You can then shift your focus to building the best possible app. This mean the app you build will provide a user experience so that the users not only get their work done but can do so when they need to and where they need to. The combination of the app and the device gives your users a tool that fades into the background as they power through the task at hand.

It’s important to understand these needs first because just like you are creating a kick-ass UX for the users that allows their needs to be met, the same considerations apply to you and how you build the app. The goal is for the app to be designed in such a way that it is flexible and can be easily changed and updated. The same qualities of flexibility and agility must apply to the app design as well.

This is why you do not choose what language or how you will write your app until you know what it actually needs to do. Why would you choose to only use a small hatchet to cut down trees when you find yourself in an old-growth forest with four-foot-diameter tree trunks? Once you know the size of the trees and how many you have to cut down, it may make more sense to grab a chain saw.

Once you decide the tools you are going to use, you look at the frameworks that are available that allow you to get to your data. Hopefully, your company has invested in APIs that connect to your data sources and free that data to be accessed properly. If those frameworks don’t exist, take the time to build them if you can. When you choose to free you data, you’ll find a lot of ways to give the user access to it, and you’ll build multiple apps to meet the different needs out there.

The goal of creating great apps and avoiding crapplications is focusing on the needs and avoiding the scope creep that inevitably tries to influence your project. Your developers now have the outline of what they need to build, and they can very easily figure out the best way to do so. But they still need to specify how they’re going to do it. This specification or blueprint is created before they start to do the actual coding, as development doesn’t start with the first line of code. It starts with understanding the need clearly and then building a beautiful blueprint that you actually develop your code to.

These blueprints/specifications aren’t static, either. The goal isn’t to file them away in a drawer but to build a companion living, breathing document that follows the app. Nothing ever goes as planned and blueprints change, but the fact is your specification needs to live with the app and allow the app to grow as the needs change.

It all becomes one big cycle, because as you finish building the app, you go back to your users to make sure that everything works that way it should. You see, building an app is solely about focus. You need to be clear what the business and the users want. You need to focus on the data they need and build a clear, easily usable tool that allows them to be productive and efficient. Anyone can use a magnifying glass, but unless you focus that sunlight just right, you never get to burn the ants.

This article, “Building great mobile apps has nothing to do with the language or IDE,” originally appeared at A Screw’s Loose and is republished at InfoWorld.com with permission (© Brian Katz). Read more of Brian Katz’s The Squeaky Wheel blog at InfoWorld.com or at A Screw’s Loose. For the latest business technology news, follow InfoWorld.com on Twitter.

Brian is a director at pharmaceutical company Sanofi, where he manages mobile initiatives, including mobilizing the salesforce, building best practices for developing apps, handling BYOD initiatives, enabling new devices and form factors for success, and looking at ways to innovate in the mobile space for Sanofi. He started his career working with a multi-national New York financial company as an email architect, designing and maintaining their email and communications systems, which also involved supporting their mobile computing platforms. He later moved to Sanofi where he led the x86/Microsoft server group for many years before moving into his current position. He blogs on mobility, consumerization, and user-oriented computing at A Screw's Loose, where the original versions of his posts are published.

More from this author