Mobile Development Strategies an argodesign White Paper by Chipp Walters by argodesign

! ! ! ! ! ! !

! ! !

Mobile Development Strategies An argodesign White Paper

by Chipp Waltersâ&#x20AC;Š

! ! ! ! !

Mobile Development Strategies An argodesign White Paper

by Chipp Walters

! !

Executive Summary !

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.

The Basics

Development tools and solutions for mobile deployment can be grouped into three application strategies:

1. Native Application Development (Unique for Individual Platforms) 2. Web-Based HTML5 Apps

3. Cross Platform â&#x20AC;&#x153;Build Once Run Everywhereâ&#x20AC;? Application Frameworks

Development Methodology

In order to evaluate the various approaches, itâ&#x20AC;&#x2122;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 3

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.

The Pipeline

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. 4

! 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.

Native Pipeline

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.

Evaluation

Native Pipeline Pro

Con

Typically elegant WYSIWYG IDEs allow for faster

Different developer expertise per platform which is

development PER platform.

expensive when used to develop apps for multiple platforms.

Good debugging tools and tightly integrated

Multiple codebases to manage. One for each

development environment.

platform.

Superb for developing a single app for a single

No forced uniformity of interface across all apps and

platform.

platforms, which many times is desired.

Can be delivered as an application in the platformâ&#x20AC;&#x2122;s

Difficult to sync builds and features across all

app store.

platforms. Much more work keeping all platforms up-todate and maintained.

Can have platform specific user interface.

Does not create browser HTML5 applications.

Complete access to all platform APIs.

Pro

Con

No requirement to be compatible with the platform browser or standards. Offline caching of data. Broad rather than deep workflow pipeline. No need for too many specialties. Compiled apps generally run faster.

! ! Native Pipeline Report Card Issue

Notes

Grade

All apps are complete unique codebases, therefore each application needs to be

Cost of

programmed from scratch.

Development

projects, multiple products,

Multiple platforms equals multiple multiple management and multiple testing. Overall the MOST

expensive way to develop for all mobile platforms. While the pipeline is shorter, the teams are broader. Unlike Web-

Speed of

based, which has multiple

Development

approach has fewer steps but

steps in a single pipeline, this more pipelines. It can be difficult to manage process across

C+

multiple platforms.

Issue

Notes

Grade

Generally, the highest quality apps come from a native programming approach. This is because the

Quality of Build

tools and optimizations are geared specifically for each platform and there are generally better testing and debugging

tools for platform-specific IDEs. Assuming multiple platforms, each codebase must be separately maintained. So, if a

Maintenance

change is to be made or a feature needs to be added, all code bases must be updated, requiring twice the work, testing and

D+

deployment of updates. Multiple parallel development paths can be problematic,

Risks

especially if all are set to ship product at the same time. Also, it can be difficult to replace experienced programmers if they

leave.

! ! 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 8

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:

1. HTML 2. CSS 3. DOM 4. Javascript 5. JQuery 6. Client-side frameworks and Libraries like AngularJS, Bootstrap, Ember 7. Server-side frameworks and Libraries like Node JS 8. Hybrid frameworks (both client and server side) like Ruby on Rails

9. Middle-tier application languages like C#, php, Ruby, Python

HTML5 Pipeline

In an HTML5 development pipeline, one set of interface elements is created for all platforms. Next the assets are extracted and then converted to HTML/CSS/Javascript by a single team and forwarded to the client-side (browser) development team.

Many times the HTML/CSS/Javascript UIX's need to be refactored for the specific framework being used. Then the app is coded. Finally, a testing group tests the web browser application across the three different platforms.

! ! !

Evaluation

HTML5-Based Pipeline Pro

Con

Typically Browser-based so itâ&#x20AC;&#x2122;s available on all

Because it runs in a browser, support for device-

browsers.

specific APIs varies a good bit.

Because it runs in a browser, it is theoretically

Requires expertise in A LOT of different domains.

possible to create a single codebase to support all mobile AND desktop browsers. Can use responsive web design practices to

HTML5, browsers and CSS comprise a constantly

reconfigure for different screen resolutions

changing platform, and apps can quickly and easily

(smartphone vs tablet).

break due to mobile browser updates.

Workflow pipeline is easy to specialize for different

Because not native, the app may perform more

developers.

slowly.

Open Source tools offer a variety of options for

More difficult to change UIX in the middle of

developing and deploying.

development because many different specialists are needed to rebuild interface code.

Single development effort is much less expensive

Can be resource-intensive and expensive to develop

than having to support separate developments for

because of the complex workflow and all the people

each platform.

needed to build the app.

Typically does not need recompiling for new

Complex apps are difficult and can be time-

devices. It just works.

consuming to build. No desktop solution. This does not take into account the Javascript/HTML frameworks discussed below. Cannot be delivered as an application in the platformâ&#x20AC;&#x2122;s app store. Limited offline caching of interactive elements and user credentials. 10

! HTML5 Report Card Issue

Notes

Grade

The lengthy pipeline and the multiple individuals with

Cost of

specialized domain knowledge

Development

expensive-to-manage teams. The

creates larger and more fact that there is a single unique codebase for all mobile platforms

offsets the cost somewhat. The lengthy pipeline, and issues with iteration outside a particular group's scope of expertise, can

Speed of Development

sometimes create problems for working in an Agile environment. Thus, the speed of development for this approach suffers. It is very easy to run and test apps using

C+

this approach, as they can run in a development environmentâ&#x20AC;&#x2122;s browser. While some mobile APIs are accessible from browsers, they are somewhat limited. And because all client side code runs

Quality of Build

in interpreted modes, the speed for some functions may suffer. Still, network latency is typically the biggest single speed factor,

which can help mask slow performance concerns of the browser. Using a single codebase, this

Maintenance

approach scores high marks, only slightly offset by the possibility of platform-specific updates with changing browser compatibility.

A11

Issue

Notes

Grade

The single pipeline and the fact that all code runs in browsers makes for less risky development.

Risks

Specialty web app developers are easier to find than experienced   C++ application developers. Cannot be chosen if the end goal

is to be in app stores. Must be deployed on the web.

! Cross-Platform “Build Once Run Everywhere” Application Builders

! These toolsets can be grouped into 2 segments. !

1. 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.

2. Javascript-based Application Toolsets can also create native cross-platform applications. While based in a more traditional, multi-staged pipeline approach, they don’t have the RAD advantages of the 4GLs but are still quick to learn and can 12

provide great leverage in terms of effort vs speed of development.     These tools generate a Javascript-in-Browser solution, which can compile to a native app – which is actually an app running a browser instance. Because of this, the speed is not as fast as native, but acceptable.    Examples include Appcelerator Titanium, PhoneGap, and others. There are also other

languages embedded in cross-platform IDEs such as LUA.

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.

Cross-Platform Javascript Pipeline

Cross-Platform Javascript Description: In a HTML5 development pipeline, one set of interface elements is created for all platforms. Next the assets are extracted and converted to HTML/CSS/Javascript by a single team and forwarded to the development team.

! 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.

! !

Evaluation

Cross-Platform 4GL Pipeline Pro

Con

Typically elegant WYSIWYG IDEs allow for extreme

There can be significant learning curve in learning

speed in development. Apps can be built in half the

new IDEs and framework.

time. Simple workflow. Same person lays out the app and Can be locked in to one vendor. codes it, interactively testing each step. Single codebase compiles to multiple native apps.

Because of JIT compiler, still not as fast as native compiled apps.

Performance typically better than browsers.

Less than 100% APIs supported.

Creates apps which can be offered in each

Not as good for large apps or large teams of

platformâ&#x20AC;&#x2122;s app stores.

programmers.

Access to most platform APIs.

May need to add custom modules for custom features.

Easy to create bug-free code.

Many do not create browser code so resulting app CANNOT run on the web (though it can connect to web services).

Can create desktop apps with the same codebase.

Can be difficult to find the best developers.

Easy to create offline caching

! ! ! Cross-Platform 4GL Report Card Issue

Cost of Development

Notes Because of extreme RAD, the time to develop is short. And because it is short, it is less expensive. Also, fewer people are needed in development.

Grade

A 16

Issue

Speed of Development

Notes Again, because of RAD and existing libraries, the time it takes to complete a project is significantly shortened.

Grade

Still not as fast or robust as a 100% native app. Plus may not have support for all platform APIs.

Quality of Build

The quality of the build depends more on the developer experience than other approaches. Supports more APIs than HTML5

B+

development. Single codebase creates different native apps for each. Each

Maintenance

platform needs to be built and deployed for. Good solution if you MUST HAVE the app in an app store and want minimum

B+

maintenance. Just like every other approach EXCEPT Native Development, you can â&#x20AC;&#x2DC;boxâ&#x20AC;&#x2122; yourself in to performance and feature corners as this technology does not

Risks

support 100% APIs, nor does it render as fast as Native. Most Agile of all approaches. Very easy to iterate design changes. Also,

C+

important to assess the risk of working with a single vendor toolkit. Plus, does not create

! ! !

browser compatible builds.

Cross-Platform Javascript Framework Pipeline Pro

Con

Typically elegant WYSIWYG IDEs allow for good

Locked in to one vendor.

speed in development. Single codebase compiles to multiple native apps.

More complex workflow. Similar pipeline to HTML5 Development.

Creates apps which can be offered in each

Still not as fast as native compiled apps.

platformâ&#x20AC;&#x2122;s app stores.

Performance same or slower than browsers.

Access to most platform APIs.

Less than 100% APIs supported.

Works well with larger teams of programmers than

May need to add custom modules for custom

does 4GL.

features.

Can also deploy builds in browsers.

Can be difficult to find the best framework specific developers.

Most frameworks offer offline caching.

! ! ! Cross-Platform Javascript Framework Report Card Issue

Cost of Development Speed of Development

Notes Similar pipeline to HTML5 Development. Single pipeline with lots of stages.

Again, similar to HTML5 Development.

Grade

B C+ 18

Issue

Notes

Grade

Performance is slower than HTML5 in iOS due to problem with Apple not allowing

Quality of Build

developers to embed Appleâ&#x20AC;&#x2122;s faster JavaScript interpreter. Still, has more APIs and nice crossplatform support for them. Can be

B+

designed responsively. Using a single codebase, this

Maintenance

approach also scores high marks, offset by the need to compile for each platform independently. Same as HTML5. Longer pipeline creates more difficult Agile

Risks

process. Also, important to assess the risk of working with a single vendor toolkit.

! ! ! ! !

B+ B

Overall Scorecard ! ! !

Cost of Speed of Development Development

Quality of Build

Maintenance

Risks

Native

C+

D+

HTML5

C+

B+

A-

4GL

B+

C+ 19

Cost of Speed of Development Development Javascript

C+

Quality of Build

Maintenance

Risks

B+

! ! ! ! ! !

Recommendations !

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 webbased 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.

Appendix 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.

1. Windows 8 (Intel) for desktops, laptops and slates. 2. Windows 8 RT (Arm) for tablets. 3. 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.

1. Media Wrappers 2. Content Players 3. Animated Content 4. 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 22

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.

Animated Content

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 Applications

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.

Flash Converters

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.