I’m slowly winging my way back home from a week at Interop and as I sit here reflecting on the panel that I participated in, it occurred to me that the way the panel ended would make a great blog post.
Philippe Winthrop has asked the panel about developing apps in HTML 5 as a way to build for every device and using that as a strategy in the enterprise. It was based upon the fact that the entire industry is a buzz about HTML 5 and the fact that it is often seen as the panacea for all our app problems. It was pointed out that the Financial Times has been very successful in completely dropping their native app for iOS and had instead turned to HTML 5 as a way to present the news.
My answer, which I repeated more succinctly when we wrapped the session up was simple. Don’t spend your time worrying about what language you are going to use to develop your apps in. Spend your time understanding what your business objective is that you are trying to solve, figuring out what data you need to access, figuring out how you are going to provide that access, and finally who gets access to that data (identity). Once you have done all these things, now you can spend time worrying about how you are going to write your app. You need to understand what the inputs and outputs are for the app, and how a user will interact with it. What, if any sensors do you need to interact with on the app? Will the app need to be available offline? Does data need to be stored on the device? Will you be using the camera or microphone? All these things will allow you to essentially storyboard your app and design the UI and UX for your app. These storyboards are what the programmers/designers need to see and understand in order for the app to be successful. It is only at this point that you can figure out the best way to write your app. These constraints will make it very easy to understand whether the app should be a native app, an HTML 5 web app or a hybrid app.
Let’s look at the example of the Financial Times. They had 2 objectives when they built their app. Their first objective was that they wanted to present the news to their customers (they are a news organization/newspaper after all). Their second objective was just as important, as they were erecting a paywall, they didn’t want to have to pay Apple a 30% cut of their revenues. Since any app that goes through the app store is required to pay Apple 30% of the revenues, it was very obvious to the Financial Times that they needed to build an HTML 5 app, as native and hybrid apps are required to go through the apple store.
Let’s take a look at another example. Another company decides that they want to improve how they track expenses. They have a business objective to try and get the expense reported as soon after it occurs and they also want to improve the expense reporting experience. They realize that a large amount of their expenses occur on the go so they want to make it possible to record the expense where it happens. They figure out that their inputs will require the use of the camera on the phone, the gps location, and keyboard access. They also know that the user will need to input names in some cases, such as at a dinner, so they want to give access to the global address list. Due to this, they want to map the identity of the user reporting the expense and encrypt any data cached on the phone as well as allow offline access, since there may not always be coverage for the device. They map out how to access the expense system to submit the expense, and how to give access to the data. They then map out how to authenticate the user. We will skip over the the UI and the UX for this example, but if you look at all the parameters, you very quickly realize that an HTML 5 app isn’t a great choice for this. You want offline access, the ability to use sensors on the phone, as well as the camera and keyboard input. Most companies would go with a native app here, although, if your presentation layer is easy – you could build the presentation part in HTML and the hooks into the device APIs natively creating a hybrid app.
The advice I left the audience with is know why you are creating an app, figure out what data you need to access and how you will do that securely and then worry about the best tool to use for building the actual app. Don’t spend so much time working it backwards, it will only make the job harder and in the end the app may not work the way you want it to because you confined yourself in how you were going to do it before you figured out the why and the what.