There is more to mobile web development than just HTML, Javascript and CSS

7 Comments

There are three main technology choices to consider when building apps for smart devices; web, native, and hybrid.

Web apps are built and deployed to a web server running in a data center and viewable through any device’s web browser. Native apps are built specific to a device’s platform and are downloaded and installed onto the device through an app store. Hybrid apps are built using similar web-based technologies as web apps but are bundled up and deployed inside native app wrappers that are distributed to users through app stores just like native apps.

Choosing which of the three different types of mobile apps to build involves prioritizing three potentially conflicting sets of goals. Those goals are time to market, total cost of ownership and the user experience. Time to market can include the total time it takes to develop an app for multiple platforms, or just one platform. Total cost of ownership includes all development and support costs incurred over the lifetime of the app. The user experience is a little more difficult to measure as it deals with aspects of the app, like performance, responsiveness, ease of use, and overall appeal. These experience-based aspects of an app can be a more subjective measure of an app’s quality rather than an objective one.

The problem is that these three very different goals can be influenced by factors that are not directly related to what technically distinguishes the web, native and hybrid technologies themselves. These outside influencers can directly impact how an enterprise prioritizes each goal.

Exposing an enterprise’s infrastructure to everyone’s device

Most enterprise architectures are distributed across multiple tiers. Each tier is typically hosted on a different network that the other tiers have controlled access to, as they are protected behind firewalls to better protect and secure corporate data. For instance, there most likely will be a web tier, a services or business tier and a data tier.

These tiers have evolved over the years to accommodate an almost twenty-year boom in desktop-based web development. While this web tier can directly access the services tier in order to get to the information it needs, the same is not always true for native or hybrid apps running on smart devices disbursed across the internet.

Most enterprises have a roadmap in place outlining which of their services will be accessible over the internet and which ones will not be ready. The services are accessible can become the primary reason that a purely web-based development strategy is adopted over a native or hybrid app.

The existence of these services can certainly affect time to market decision when services do not exist, while on the other hand will drive up the total cost of ownership when they do.

Write once, test everywhere, twice

When it comes to evaluating the total cost of an app, targeting multiple platforms can at first be seen as a cost multiplier. If a change or enhancement needs to be made to the app on one platform, it needs to be made across all platforms. Efforts to eliminate this multiplier have created Mobile Application Development Platforms (or MADPs), like Adobe’s PhoneGap, Apache’s CordovaAppcelerator’s Titanium and Konythat promise to deliver an app to multiple platforms from one code base. While this can have some effect on the total cost of owning a mobile app, it will not eliminate all of the costs associated with supporting multiple platforms.

One challenge that enterprises face when choosing a development strategy that addresses more than one smart device platform is testing. Buying multiple test devices and developing a test strategy that includes an acceptable mix of platform versions, screen sizes and device capabilities is something that must be done regardless of how one decides to get an app onto a device. There are even occasions when testing efforts can benefit from having two identical test devices to compare how two different versions of the app behave, or how the same version of the app behaves on two different versions of the platform’s OS.

There are places you can go that will allow you to test on a variety of different devices without having to actually purchase multiple devices. One such place is OpenDeviceLab. OpenDeviceLab is a grass-roots community movement that is helping create a community pool of test devices that developers can use. Services like TestFlightApp and HockeyApp can make managing the distribution of test builds a much easier task as well. However, the costs associated with managing a battery of test devices is only one part of the total cost equation, albeit a very visible one. There is still the matter of spending time executing the tests.

Currently the smart device market in the U.S. is dominated by two platforms. While the current market share and usage data point to adopting a development strategy targeting at least two mobile platforms, does it make sense to increase one’s total cost of ownership by adding a third?

Repurposing existing desktop web developers

A new discipline among web designers and developers alike is what is known as responsive web. The goal of responsive web is to design websites in such a manner that they adjust themselves to fit appropriately on different size screens. This strategy lends itself well to repurposing existing web developers and designers as responsive web developers and designers. At least that is the theory.

When it comes to repurposing desktop web developers as mobile web developers, it is true that some of the core technologies used in each type of development have similar structures to them, like HTML, JavaScript and CSS. But in practice, the libraries and techniques that are used to implement a touch-friendly web design can come with an unexpected learning curve. Switching from a barebones JavaScript development discipline to more of an AngularJS based JavaScript framework like those used with Ionic or OnsenUI, two popular touch-based JavaScript frameworks, can take some getting use to. Perhaps not quite as steep of a learning curve as transitioning from Javascript to Objective-C, but a learning curve none the less.

For both mobile web and hybrid development using tools such as Apache’s Cordova, the setup and configuration of a mobile developer’s work environment alone can be a daunting task for a traditional desktop web developer. The task of managing and maintaining a workstation equipped with the latest version of Xcode, iOS simulators, Android Studio, SDKs, emulators and device profiles is a skill-set in its own right. One problem realized right away is the slow performance exhibited in Android emulators compared to the iOS Simulator. Fortunately there are technologies like Genymotion that have stepped in and improved performance considerably.

Ensuring that you have the right talent to craft a positive mobile experience can certainly increase costs up front, but expecting a veteran developer that has spent years perfecting your online desktop experience to instantly transition over to becoming your star mobile developer may not be as instantaneous of a process as one would like. You’ll need to give them some time to retool and wrap their brain around what you are asking them to do.

7 Comments

Jeff T

Don’t forget tools like Worklight which support native, hybrid and mobile web. :-)

cbesnoy

Great article Geoffrey. To solve to issues you identify in the article, I have advised my clients who develop more than 5 applications a year to evaluate one of the many new mobile tool sets that have come onto the market over the past 12 months.

These tool sets provide a platform for collaboration, development, data integration and EMM Security concerns around device, data and applications. For many organizations, the licensing cost of the platform is less than the cost of internally trying to solve the mobile web challenges you have outlined.

fredhstein

Going beyond ‘test everywhere, twice’, there are two more issues: 1) help desk; 2) security.

1) When users call in, how many manufacturers times how many OS releases do the help desk staff need to understand? IT will have to limit support to a top vendors and OS releasees.

2) If the mobile devices are “BYOD”, security is too big a topic for a comment section.

R. Paul Singh

A good article but it brushed aside the issue of exposing enterprise infrastructure. In our customers we find that they are spending almost the same amount of resources in their back end as they are doing on their front end. To make your infrastructure ready for mobile, one needs a REST API – whether your data is in SQL, NoSQL or enterprise systems – something that can be done in days and not in months. There are many aspects in selecting a platform to create REST APIs. Here is a link to a document that provides the criteria for selecting the best REST platform – http://bit.ly/1B7GbJI

Madlyb

Some great callouts, but one of the bigger challenges I have seen is getting web developers isn’t about technologies, but thinking differently about the user interaction or more importantly about different ways a user can interact with the application depending on the device they are using.

Another is understanding the multi-dimensional impact on performance mobility brings to the equation. Whether it is dealing with the much lower performance curves of mobile devices versus traditional computing devices or the higher latencies of mobile networks, managing…even micro-managing, the code is critical to insuring a positive user experience.

Benjamin Knight

One thing not mentioned here which I think makes all the difference is how native apps and web apps are distributed. People understand apps as tools that you download from your platform’s respective “store”, that they have a searchable name, and downloading it will add an icon to your home screen. Web apps don’t do this (although there are workarounds for adding an icon to your screen, for example). So how do you tell people to go “download” and use your cool new web app when they have to open an browser first and navigate to a URL? This is confusing in my opinion and doesn’t feel like an app.

Also there’s really no way to make a quick $0.99 off a handy tool web app since there’s no native payment integration like in the app stores.

Another huge hurdle the web faces which it will likely need many more years to gap is the fidelity of user interactions.

So, overall, as a web developer, I’m sad that it still makes more sense to develop native apps. Firefox OS if done well could pave the road for native mobile UX with web, but I think the web being a standardized open platform will always lag behind proprietary platforms.

Comments are closed.