One of the Post-PC challenges for many Executives is understanding the issues around designing and building products for mobile devices. The purpose of this document is to help explain in an easy-to-understand way, different development strategies for building and deploying applications across mobile platforms.
This Executive Summary is a document argo uses to examine factors for assessing and ultimately selecting the correct strategy and technologies for mobile development for our customers and partners.
Development tools and solutions for mobile deployment can be grouped into three application strategies:
- Native Application Development (Unique for Individual Platforms)
- Web-Based HTML5 Apps
- Cross Platform “Build Once Run Everywhere” Application Frameworks
In order to evaluate the various approaches, it’s important to have a basic understanding of project development methods, workflow and pipeline. There are many different methodologies used in development processes, and it is not the intent of this document to review them all, but it is useful to spend a little time going over some concepts.
Agile vs Waterfall
Both of these terms have been used quite a bit when referring to development methodologies. Essentially, the Agile development methodology was created in response to process issues between management and developers. Developers wanted managers to quit looking over their shoulders and demanding changes mid-stream, and managers wanted developers to spend more time showing them the current state of progress. In the older and more traditional Waterfall mode (PERT and GANTT models), managers and stakeholders may not see a product for months until after everything is finished, thus not allowing for interim feedback to affect the final product.
With Agile, developers agree to do specified work, unencumbered by management, in short periods of time called “sprints” which usually last a week or two. Then management and stakeholders can review, and iterate if necessary.
The iteration is the important part; this is where the app can be tweaked and refined to create a better end product.
Of course this is a gross oversimplification of the two methodologies, and more detail can be found in our 5D’s white paper. The thing to remember is that structured iteration is a key part of understanding how efficient a development pipeline can be.
At argo, we use a custom 5D project management approach. It combines the best of Agile iteration with the performance criteria inherent in Waterfall. For purposes of this document, we won’t concern ourselves with explaining all 5D’s, but will focus on the last three: Design, Develop and Deploy.
As far as Design goes, we will assume a project already has a world-class User Experience or User Interface (UI/UX) designed — by argodesign, of course! — and tested, and signed off by all stakeholders. Note: This is most different from Agile, where UIX is done simultaneously with development.
The next step is to convert the UIX design into a working application. Each Application Strategy listed below has a specific workflow pipeline. Understanding the pipeline is helpful in assessing a strategy’s strengths and weaknesses.
All pipelines will begin with Design and end with Deploy. This document does not review any of the mid-tier application levels and instead only focuses on the client application design. Let’s take a quick look at each Application Strategy.
Native Application Development
(Unique Tools for Individual Platforms)
Platform-specific “Integrated Development Environments” (called IDEs) provide maximum control, device access and execution speed for their respective operating systems and devices.
While these IDEs do not have the multiple domain expertise overhead which is part of the HTML5 development pipeline (more on that later), they do require experienced and seasoned C and Java programmers, and there is little overlap either in individual expertise or code reusability.
To program in XCode for iOS, Eclipse and Java for Android and Visual Studio for Windows 8 requires experienced senior programmers all working in parallel, and a rare team lead who understands and can possibly work in all programming environments. A tall task, for sure. Plus, keep in mind each platform requires its own code base, so keeping builds in sync across platforms can be an issue.
Typically, unique interface elements are created for each platform. So, for three platforms there can also be three times the work on interface designs. Next, the assets are extracted by a single team and forwarded to each platform development team. There the app is coded. If a mid-tier state is needed (not always), it is coded as well by a different group. Finally, a testing group tests the three different applications on the three different platforms.
Web-Based HTML5 Apps
There has been an ongoing search for a ubiquitous WYSIWYG IDE for HTML5 for some time. Originally, it was thought an easy Flash-like app builder would be forthcoming from Adobe and other vendors, but nothing has yet surfaced which is reasonably adept at providing the shortcut approaches that 4th-generation programming toolsets have already delivered.
Consequently, the main issue for those wishing to rapidly build and deploy HTML5 is the lack of an integrated and intuitive WYSIWYG (What You See Is What You Get) authoring system where controls can be dragged onto a canvas and instantly be set up for coding and use. Currently, in order to build HTML5 Apps, some or all of the following technologies must be mastered:
- Client-side frameworks and Libraries like AngularJS, Bootstrap, Ember
- Server-side frameworks and Libraries like Node JS
- Hybrid frameworks (both client and server side) like Ruby on Rails
- Middle-tier application languages like C#, php, Ruby, Python
Cross-Platform “Build Once Run Everywhere” Application Builders
These toolsets can be grouped into 2 segments.
- Fourth Generation Programming Languages (4GL) considered the easiest to use with the most potential for rapid development. They often use human–readable syntax and allow for extreme consolidation of tasks focusing on Rapid Application Development (RAD). Typically, these tools are great for smaller applications and tend to become unwieldy for large teams building large applications. This makes them a good fit for mobile. These tools typically use a runtime player (like a Flash player) which is embedded in the specific platform native app, thus performance, while good, still isn’t up to the native app standard. Not a good choice for twitch games, but simple animations can be created and run just fine. Examples include Flash, LiveCode, RealBasic, RAD Studio XE3 and others.
Experienced developers are needed to push these tools to maximum performance, and it may be difficult finding the right lead developer and team. These toolsets typically have a powerful IDE where all interface design, asset management and coding is done. Some can even create content directly in the IDE. These frameworks encapsulate a WYSIWYG environment, with a code editor using a Just In Time (JIT) compiler (like Java) OR browser to review the app as it is built in the development environment. This methodology creates a very fast design, build, run, test loop (no compiling necessary) which enables superior development times.
While these tools create apps which perform somewhat faster than browser-based apps, rarely do they produce apps as fast and snappy as if programmed natively. Still, as mentioned before, many times network latency is a far greater performance inhibitor than the small perceived performance lag inherent to these frameworks.
These tools also have better API access than browser-based apps, yet still not as good as native toolsets. Most can be extended using native coded external modules. So, if a feature is not yet supported, it can be added via a custom native module.
Compiling for different platforms is simple and direct. Plus, most of these toolsets can build stand-alone applications for Windows and Mac desktops as well. argo note: In perhaps the fastest development project to date, argo team members developed a full pilot app for Sesame Street with both Teacher and Student modules running on Android tablet using a 4GL in under one month. Not one bug was reported during the pilot run.
Cross-Platform 4GL Pipeline
In a 4GL development pipeline, one set of interface elements is typically created for all platforms to provide an identical User Interface. Next the assets are simply extracted by a single team member (or sometimes by the developers themselves), and forwarded to the app development team.
There the app is coded. If a mid-tier state is needed (not always), it is coded as well by a different group. The developer group creates separate builds for each platform. Finally, a testing group tests the application across the 3 different platforms.
There the app is coded. The developer group creates separate builds for each platform. Finally, a testing group tests the application across the multiple different platforms.
A Few Considerations
Some notes about the Kindle and Nook
Both Kindle and Nook have two levels of devices. The first level is called the “Reader.” The Kindle Reader and the Nook Reader are e-ink (also called “paperwhite”) enabled monochromatic devices with extremely slow display rates. As such, they are not capable of executing any but the most simple applications and there are no third party apps for these devices. The full-color Kindle Fire and Nook HD are both Android devices, and can run Android apps with little to no modification.
Observations about Windows 8
Microsoft has a confusing set of operating system offerings. In fact, Windows 8 comes in three different flavors.
- Windows 8 (Intel) for desktops, laptops and slates.
- Windows 8 RT (Arm) for tablets.
- Windows 8 for phones.
Each is compiled for different processors. This presents problems for application strategies outside of native and browsers. Many cross-platform frameworks have announced future compatibility as they are just now evaluating their own strategy for deploying on Windows 8 RT and Windows 8 for phone. Currently, it is unclear if Windows 8 RT will survive in enough quantities to justify third party vendors creating custom toolset builds supporting it. Its sales are lackluster with projections of less than $0.5 million this quarter. Many industry pundits believe the Intel Windows 8 tablets, with full support for Windows 8 (and Win7) apps, may be the product consumers eventually choose. In any case, it’s clearly a risk for any institution to establish a Windows 8 RT baseline as it’s a sole standard platform.
Google Chrome OS and Chromebook
Considered by Gartner Research as a “Post-PC” mobile platform, Google’s Chromebooks are netbooks with a Chrome browser-based OS which stores virtually all data in the Cloud. This very inexpensive laptop has a number of features which may be preferred over PC based netbooks and mobile tablets for delivery of learning applications to education customers. In late 2012, Google offered a $99 Chromebook laptop for classrooms, an unheard-of and unbeatable price point. Google Chromebooks have only 16GB of flash storage, so little if anything can be stored locally. Still, the devices are well designed with the best of breed Google Apps (Docs, Spreadsheet, Presentation, Sites and others) and are a perfect fit for many who don’t need or want a full-fledged laptop. Because everything is stored in the Cloud, if the laptop is lost, stolen or broken, remediation is quick. Just replace the laptop with a new one, login and the student or operator is back where they left off. Another advantage of Chromebooks is that they run Flash inside the browser. Therefore, a lot of Flash content not available to mobile devices is still available to Chromebook customers. Since Chromebooks run all software in a browser, the only option for deploying applications is to create apps using HTML5 frameworks and toolsets. Lastly, to date, there are no known viruses which attack a Google Chromebook. So, using the Chome OS keeps the student or operator safe from malicious code attacks.
What to do about Flash?
As we know, Flash is a dying mobile delivery platform. It has never worked on Apple’s iOS and now Android has dropped support for it. Many content providers have substantial assets built in Flash which they now need to reassess and probably repurpose. It should be noted that there are OS platforms which still run Flash. All modern desktop browsers run Flash just fine. Most netbooks can run Flash, but some struggle with heavily animated and high vector count Flash swf files. Google’s Chromebook runs Flash but also may see some performance problems with the more processor-intensive Flash files.
Types of Flash Files
Flash files, called “movies,” can be broken down into a few different groups. These are listed from easiest to repurpose to hardest to repurpose.
- Media Wrappers
- Content Players
- Animated Content
- Flash Applications
Flash Media Wrappers
Media Wrappers are video players, slide presentations, document viewers and other simple tools which store their assets outside of the Flash movie application. So, the Flash application code is fairly straightforward and has a small footprint as they have only a single purpose: to play an external filetype. For instance, a typical Flash video file outside the app has an .flv extension. This means it can only be played by a Flash player. It is a fairly basic task to recompile the video with an HTML5 capable codec and have it available for delivery on mobile. In fact, as long as the content is stored OUTSIDE the player, it can generally be converted and repurposed to play in an HTML5 wrapper.
Flash Content Players
Content Players are more evolved versions of Media Wrappers. They can have multiple purposes such as playing a movie while scrolling text in a separate pane. Or showing a slideshow while a voiceover is playing. Typically Content Players, like Media Wrappers, store their content in files outside the main movie application and are fairly small in size and function. In this case, repurposing these players is simply a matter of converting the content and then writing a small Player app to reproduce the functionality of the original Flash Content Player.
Content which is created and animated inside of Flash is much more difficult to repurpose. If it is mostly linear in nature, it can be converted (either via screen capture or Adobe’s Flash application, or various convertors) to a video, which can then be embedded in a mobile application. If it is not linear in nature, then it becomes a tedious task to extract the assets and reanimate in the mobile application. While there are various toolkits which claim this ability, none is foolproof and many just ‘barely’ work.
Flash and Flex can create very code specific Web and Adobe Integrated Runtime (AIR) applications which rival the functionality of many desktop applications. To convert and repurpose these types of apps requires a complete restart and recode from the beginning. This is the most time and resource intensive conversion process and is decidedly NOT simple.
There are many products which claim to convert Flash to HTML5 and other formats. These include Google Swiffy, Adobe Wallaby, Recool, Thundersoft Flash to HTML5 and others. Most can convert only specific filetypes, like banner ads. Rarely is the conversion 100% identical to the original. There is yet no silver bullet for converting Flash apps to other application runtime or source code.
There’s not a single best Mobile Application Strategy. For instance, at argo we’ve used a different approach for a single platform Android tablet app versus a multi-platform web- based application. This is because a mobile application strategy is based on many factors including target application platform requirements, budget and schedule, maintenance requirements and specifically conversations with clients and their customers. We recommend you contact argo for more information on how we can help you craft your mobile strategy and then help you build and deploy your mobile applications.