Piecingit TogetherCrafting a quality mobile experience for your users starts with understanding your options

User Experience Design TeamControl & Visualization Business

November, 2013

+

2

Table of Contents

Foreword 3

HTML5: UX be nimble, UX be quick 9

Native: Performance is my business. And business is good 21

Hybrid: Yes I want my cake. And yes, I’d like to eat it too, thank you very much 33

Let’s review, shall we? 41

So what should you do? 44

References 48

3

ForewordThe purpose of this document is to help shed some light on a few different methods for designing and developing mobile applications and the user experience advantages and cautions for each. Now, while UX is the primary focus of this paper, it is almost impossible to discuss the advantages and cautions of each path and not have some technology and feasibility considerations sneak their way in. Furthermore, if you are hoping for a document that will illuminate a golden path to mobile enlightenment… you might beslightly disappointed.

As the title “Piecing it Together” implies, our goal is to arm you, our appreciated reader, with at least some information to help you formulate your own opinion on what method(s) will help you craft a mobile strategy that makes sense for you and your users. Recommending an approach is the not the purpose of this document as an effective mobile strategy depends on your goals, your skills, and your industry — but most importantly, it depends on yourend users.

You will also find we’ve conveniently sidestepped security andin-depth coding considerations for each path as those topics are best reserved for our partners in the development community. But if you are looking for an unbiased look at different mobile development paths and their various advantages and disadvantages from a primarily UX perspective, then please read on!

4

First, let’s meet the contenders

5

In one corner we have...

HTML5Stepping into the ring with unmatched nimbleness, this featherweight method of mobile development leverages web-based applications via HTML5 and it runs in a browser. As a result, an HTML5 app can run on any smartphone, tablet, computer and pretty much anywhere else that has a modern browser. It should be noted that “HTML5” is everyone’s favorite term right now, but this methodology basically represents the evolution of HTML — regardless of what it will be named in the future.

Examples of HTML5/Web-based apps

• Financial Times® “FT Web App”• Google Docs ™• Google Mail™ (Gmail)

6

In the other corner, we have...

NativeThis bruiser is the heavyweight of thecontenders. It is powerful and it knows it. Native apps are specific to the mobile operating system, so an iOS app will only run on Apple® devices, an Android™ app will only run on Android devices, and so on. Native apps are downloadable via the hosting platform’s app store, they do not require a browser and they can tap into all of the device’s capabilities.

Examples of native apps:

• Angry Birds™• Facebook• Contacts, maps and calendars

7

In the other, other corner, we have...

HybridThis middleweight application is written inweb-based languages like HTML5, but also includes native code to access device features that a web-based app could not achieve onits own.

Examples of Hybrid apps:

• Yelp• Netflix• Banana Republic

8

Decisions, decisions… let’s delve into each method, shall we?

9

HTML5UX be nimble, UX be quick

10

Advantages

11

It’s ready for the Zombie Apocalypse. Are you?

In a presentation at UX Immersion Mobile 2013, Karen McGrane, author of Content Strategy for Mobile appropriately summed up the state of rampantly emerging devices and screen sizes as the “Zombie Apocalypse of form factors.” We are on the verge of experiencing a deluge of digital touch-points — everything from your refrigerator, to the very accessories you wear on your body will have some kind of user interface in the very near future. In fact, it is already happening. This is the very problem responsive design proposes to address and it is rooted in a web browser-based solution — HTML5 (with some help from its trusty sidekicks, CSS and JavaScript).

The benefits of leveraging HTML5 could be many. We say “could be,” because it is still a growing technology — and to-date, has been used most commonly as a means to stamp out the pesky “m-dot” mobile website versions so many companies still employ today to satisfy mobile and tablet visitors. To remedy that situation, we’re finding all you need today is a cup of HTML5, a heaping teaspoon of CSS3 with media queries, a pinch of JavaScript (if desired) and a modest splash of UX design and development skill. And voilà, you have a UI that scales to users on just about every form factor. And the best news? A heck of lot of people have easy access to this recipe and many have the skills needed to make it. This leads us to another major benefit of a web-based HTML5 approach…

12

It’s highly feasible

With the spoil of web technologies available today, it is becoming increasingly feasible and practical to deliver a device agnostic experience to your users. And readily available open source tools such as Twitter’s Bootstrap and HTML5 Boilerplate are making it that much easier to get a foot in the device agnostic door. Another compelling argument for HTML5 is there are not many hoops to jump through in order to craft a viable user experience. Unlike a native approach, designers and UX professionals do not need to constantly have one eye on the Apple Human Interface guidelines — as well as its Android, BlackBerry® and MicrosoftTM counterparts as they struggle to wireframe, design and test their UI. Having this practical freedom allows them to put more focus onto the design problems at hand and subsequently succeed much faster. Furthermore, this latitude also gives designers the chance to get out in front of other form factors not quite ready for show time yet.

Lastly, there is no gatekeeper like the App StoreSM, Google PlayTM or Windows Phone® App Store to contend with — frustrating dependencies that slow the ability to deploy native apps. This leads us to another major benefit of HTML5…

XX

MobileDevice

XX

SmartTV

X X

Household

Appliance

Figure 1: The Zombie Apocalypse of form factors is upon us! Your PC and mobile device will not be the only things with a user interface.

13

It supports lean UX

The ability to fail fast to succeed sooner is becoming a critical requirement given the number of zombies threatening to break down your door. A major benefit of choosing the HTML5 path, is the fact that it folds nicely into the lean UX model, which focuses less on delivering unwieldy, time-sucking documents and more on actual experience. An advantage of developing via HTML5 is the idea that designers and developers can prototype a concept using the same tools and technology that will eventually be used to deploy the final product. There is less design debt and working concepts now have the ability to live on, going through iterations of changes that can eventually scale into the final UI. Not as much work needs to be wasted or reinvented. This is especially beneficial when there are a multitude of form factors to address.

Distribution control is also a key benefit for HTML5. Updates can be deployed directly to the server and then to user via the web browser and no App Store middleman is needed. With HTML5, teams have a way to react to ideas much quicker, validate them through A/B and multivariate testing (something you cannot get with native/hybrid apps) and ultimately succeed faster than teams who need to wade through all of the third party guidelines and barriers that bog down the native process.

14

“Usability rules the Web. Simply stated, if the customer can’t find a product, then he or she will not buy it.”

- Jakob Nielsen

Discoverability… the web kind

While this is a benefit associated with websites as opposed to desktop software products, there is something to be said about how quickly users can find you based on your content. A web-based solution yields the possibility of a discoverable app because search engines can index popular keywords and phrases associated with your industry. Not only is being findable through organic search practical, but it is also something that can be honed and controlled. Search engine optimization is an art unto itself and it gives you yet another hook into the overall usability of your site; understanding how and why users arrive at your storefront. This could potentially be a major advantage depending on the purpose of your app; particularly if you are dealing with an e-commerce or business-to-consumer experience in a competitive vertical where optimizing for certain keywords and phrases is a critical method of getting users to your app.

15

Cautions

16

An “A” for effort?

Not likely granted from the typical user. Today’s smartphone user wants to jump in and out of tasks quickly and with as little mental load as possible. The “don’t make me think” generation is further enabled by slick native apps that run fluidly and provide instant feedback — they are not especially tolerant for UIs that slow them down and you’re lucky if your app even has their undivided attention. As Luke Wroblewski, author of Mobile First puts it; you need to plan for users only being partially engaged with your app per his “one thumb, one eyeball” rule. That is, your app must be designed to contend with the lowest common denominator of user engagement — which is typically just one hand using the phone at a time with only partial attention on the task they are attemptingto complete.

Alas, there is much to contend with here, even for a native app that is a true extension of its host OS. Even if expertly designed, coded and deployed, this challenge is even greater for an app developed using HTML5. Because it leans heavily on web-based technology, you are essentially placing another barrier (the browser) between the user and the task they are trying to quickly accomplish. Regardless of your industry or utility of your app, mobile users have very little patience and HTML5 cannot duplicate the performance, speed and number of device features available to them. Even the treatment of gestures and basic UI patterns could create noise and frustration for the user since they will undoubtedly differ from the familiar native metaphors they’re used to.

17

“So while utilizing web technology has allowed us to support more than 500 million people using Facebook on more than 7000 supported devices, we realized that when it comes to platforms like iOS, people expect a fast, reliable experience and our iOS app was falling short. ”

- Jonathan Dann, Facebook Developer

Furthermore, the highly visible switch LinkedIn® professional networking services made from the technology to native because HTML5 was unable to replicate the smooth user experience they were hoping to create is arguably a black eye for HTML5. And while a good deal of time has passed since this decision was made, it is also well known Facebook dropped HTML5 as its primary weapon of choice and switched to native. As Facebook CEO Mark Zuckerberg put it, the technology “just wasn’t there” when considering the speed and efficiency users expect to have with their mobile apps.

18

The problem with “not owning the chrome”

If a web browser-based HTML5 app is online, it can continually save data to the cloud. When it’s offline however, changes may not always be stored in the cloud. For example, if a user changes browsers, data synchronization becomes a problem since the session has been interrupted, making it difficult to find the latest saved data. This is one of the issues with relying on a browser and not owning the chrome — that is, the wrapper that houses the app. HTML5 has come a long way with offline capabilities and is expected to continue to do so, but for now, native apps enjoy an advantage here since they do not have as much overhead when it comes to launching the app and giving the user at least some ability to interact; like for example, on an airplane or in a place where they do not have access to a connection. Because of its dependence on the browser, no connection typically means no app (with the exception of Google Docs and a few others); particularly if it has not been cached from a previous session.

Furthermore, there is something to be said for an app’s sole dependency on a web browser shared with millions of other “tenants” — as if the app is part of an elaborate timeshare where competition for the user’s attention is stiff. You’re lucky if they have your domain bookmarked at all and you might as well be living in a fantasy world if you believe they have your website saved as their home screen default. As you can imagine, quite a few obstacles need to be overcome for a user to arrive at your app unless their intentis high.

19

On the flip side, native apps essentially enjoy their own parcel ofland on your smartphone or tablet; they have visible “addresses” where they can be easily located via their respective app icon. A user taps it and they have instant feedback. They are interacting with your app and your brand (even if offline). You own the chrome. No middleman needed.

Joe User OperatingSystem

NativeBrowser

App

YourApp

Figure 2: Relying on a web browser creates yet another barrier between the user and your app, not to mention a host of other distractors.

20

Fragmentation is not just a native problem

Many of the arguments against a native approach center around the fact that teams must design and develop the same experience multiple times for multiple operating systems — and this becomes extremely time consuming and costly. This is true and a web-based approach may allow teams to sidestep many of these hurdles, but it does not absolve them of having to deal with some browser and OS inconsistencies.

As much as browsers like Chrome, Safari, Firefox and Internet Explorer (yes, even IE) are becoming more standardized, there will always be a need to perform extensive testing on a variety of devices and platforms with differing screen sizes and dimensions. While it may not be a wash, procuring and then testing on a statistically significant collection of mobile devices can be time consuming in its own right. Iterating on designs and then cycling through this testing process again and again to correct defects can obviously result in some serious scope creep. And when you finally get to the point where you can sit back and press the “launch” button, Android releases yet another version of its operating system that affects Chrome, which in turn wrecks your interface.

Finally, a web-based solution is no silver bullet when it comes to common controls like form inputs and drop-downs. Unless you try to hack something together with JavaScript to force consistency — which poses its own host of challenges, you will see differences across browser + OS combinations.

21

NativePerformance is my business. And business is good.

22

Advantages

23

One word: speed

Imagine you’re watching your favorite sports team on TV and witness some crazy or implausible play. You’re compelled to tweet your excitement to all of your followers on Twitter — or at least join the conversation since it probably has people talking already. Regardless, you grab your smartphone (since it is never far out of reach), quickly swipe your screen until you see the friendly Twitter bird app icon and tap it. Boom, done. The native Twitter app quickly updates and is ready to rock and roll since it is only going to pull down the latest data. You can tap the “compose” button and proceed to impart your wisdom in 140 characters.

Now as unlikely as this is, let’s imagine there is no native app available for Twitter. They do however, have a mobile website and you have just enough motivation to take action given you want to share your excitement with the world. You grab your phone and then what? First, you’ll need to open whichever native browser you have installed on your phone. Okay, no problem. Then assuming you do not get distracted by whatever content you had previously opened in your browser (you’re lucky if it is just one window), you carefully fat-finger in “twitter.com” into the tiny address bar using the virtual keyboard on the device, while saying a prayer of thanks that the web address is relatively short. Still kind of a pain, but you roll with it. Then, you arrive at the “mobile.twitter.com” website — and assuming you’re lucky enough to have your credentials cached from a previous session, you wait for the browser to load the entire app before you can finally fire off that tweet.

Figure 3: With a single tap of the Twitter bird app icon, the native Twitter app only needs to fetch the latest updates.

24

Still motivated to tweet? It’s possible, but it is safe to assume which experience you would prefer. When an app has its own visible slice of the pie on your device, you can call it up much faster… and this is priceless. A simple tap and you are in. And because it has been designed and developed for your specific operating system, you will enjoy faster graphics and more fluid animations once you are engaged with said app. And the icing on the cake is the fact that all of the rich capabilities of the device are at your fingertips, adding even more expedience to whatever you are trying to accomplish. This segues nicely to another advantage of native…

Figure 4: A blank canvas: it may not always be significant, but relying on a web browser to pull down the full app instead of just the latest data (as with a native app) can cause a noticeable lag.

25

Figure 5: While web technology has come a long way in terms of invoking features such as map integration, GPS and the device’s camera, there are still plenty of other places where a native app shines.

OS features and capabilities are our friends!

This is a big argument in favor of native. While certain features such as maps and GPS are now possible to invoke via a web-based solution, a native experience still has capabilities that exceed anything a web-based solution can deliver today because of the array of device features and tools it can tap into. Want to easily allow users the ability to receive Push Notifications? No problem. How about providing users the ability to connect devices via Bluetooth®? You bet. Allow your app to leverage the convenience of in-app purchasing? Done. A native app runs in lock step with its host operating system, allowing you to have full access to embedded device capabilities and this makes the app really easy to use. Plus, you can still use a native app offline. While you will obviously not have the full richness of the app available at your fingertips without a connection (in most cases), you can still access data stored from a previous session. With a web-based app, you are dependent on the browser having your session previously cached and this scenario is less likely.

Joe UserOperating

SystemYourApp

Bluetooth In-app purchasing

Push noti�cations Background taskmanagement

26

When in Rome… be consistent

What should not be underestimated with native is the fact that it speaks the same “language” as the rest of its host operating system (if done properly). Leveraging familiar UI metaphors and contextual interactions is a surefire way to encourage tolerance of your app from the outset. This in turn will build trust with the end user and allow them to focus more on achieving the tasks you hope they will versus becoming frustrated by an app that generalizes a “one size fits all” user interface for all operating systems. For example, Apple’s Human Interface guidelines arms designers and developers with enough information to keep the basic UI components of their experience similar to other iOS apps and certain requirements must be met before an app can be accepted into the App Store in thefirst place.

Figure 6: Apple’s Human Interface Guidelines provide practical instructions for creating a consistent UI across all iOS apps (screenshot retrieved from developer.apple.com).

27

One could argue this amount of control is the better alternative when crafting a quality experience versus the risk that comes from creating a rogue UI that does not truly fit anywhere — even if well branded. Based on your app’s genre, one could also argue discoverability in the app store associated with your app’s respective platform is just as (if not more) powerful than the practical SEO benefits you might get on the web with an HTML5 solution. Just as important is your app’s discoverability on the device itself once it has been downloaded, per the “real estate” your app icon will occupy. As users have become more accustomed to native apps, it should be noted discoverability means different things to different people based on the type of app you deploy, what your competition is doing and what kind of niche your app needs to fill.

28

Cautions

29

“F” is for fragmentation

Let’s imagine you’ve made the decision to create a native app for your user base. Congratulations, this is a big first step. Now comes another hurdle. Where do you hedge your bets? After all, the mobile landscape is constantly evolving. For example, creating an iOS app and then calling it a day likely won’t fly with many your users any more. This is because Apple’s iOS platform is now facing some stiff competition and only represents 14% of the overall 2013 mobile market share according to Gartner Inc. Even more significant is the fact that Android has gone from a commanding 64% market share in 2012 to an even more dominating 79% in 2013. And while it still owns a small share of the market, Windows Mobile has overtaken BlackBerry as the #3 operating system at roughly 3% and is expected to continue making noise.

Creating a compelling native app offering while mitigating the risk of a potentially bad investment in a rapidly evolving mobile landscape is a delicate dance. This is why most organizations simply avoid this agonizing decision altogether and throw enough money and resources at a project to satisfy both Android and iOS users. And just like that, the amount of overhead needed to create a usable native experience has exponentially increased. What works for the Android OS does not necessarily translate to iOS since both platforms possess their own unique UI patterns and code base. Metaphors that are shared across each platform, such as date pickers, sliders and list views are treated differently; from both a visual and an interaction perspective. This is a big challenge with native.

30

The unfortunate reality is the fact that design and development teams are now going to have to navigate some choppy waters in order to essentially create the same experience twice… or thrice, if you decide Windows Mobile or BlackBerry are worth the investment as well. And that’s not even the half of it if you would like to offer a tablet-specific app for your users. Sure, the app you create for a mobile/hand-held form factor might work for a tablet form factor, but odds are the UI will look stretched, images will not be optimized and the layout will not take advantage of the extra real estate. Time to create a native app for tablet as well? While a responsive web-based or hybrid approach will still have to account for designing an effective UI for a tablet screen size, there is more overhead and cost involved in deploying a fully native tablet offering.

Of course you could always choose to go all in with one platform if you suspect your user base will readily adopt it based on your business model and/or existing user data. If this is the case, count yourself lucky. In most cases and for most products however, no such luxury exists. Your users will want you to adapt to them, not the other way around.

Figure 7: A screenshot of a native DatePicker from iOS7 (left) in comparison to a native Android DatePicker (right) shows how these common UI components differ greatly across operating systems (screenshots retrieved from Kintek.com.au).

31

Time is not on your side

Where HTML5 is the doomsday prepper, locking and loading for the impending zombie apocalypse of form factors, native is living in denial. No prepping here, we’ll do just fine huddled in our cozy little OS ecosystem. While it is doubtful a web-based solution will ever completely replace native; as mentioned before, it enjoys a significant advantage in feasibility and accessibility. You can succeed very quickly by employing a web-based solution, allowing you to address a multitude of form factors and platforms; something that cannot be accomplished as easily with a native approach. Furthermore, the skills needed to build a device agnostic web-based experience are rampant, easy to acquire and relatively easy to learn in most cases.

Unless your organization already possesses the requisite OS-specific skills, native is not so easy. From a development perspective, expertise in Objective-C, Java or another OS-specific language is more specialized and there is a greater learning curve in most organizations. This poses its own host of challenges. Not only will it take your app longer to develop initially, it will make it more difficult to maintain as well given the niche knowledge base needed for each platform. Designers can design, copy editors can edit, Information Architects can architect, but at the end of the day the OS Developer is the key cog in this machine as more rests on his/her shoulders. With an HTML5 approach, a Designer could feasibly augment a Front-end Developer’s work load, and this keeps process and head count leaner.

Is this true in all cases? Certainly not. A company that specializes in developing software may already have enough platform-specific skill available in house to make a native offering more feasible than a web-based approach. Creating a mobile app does not happen in a vacuum and each organization collectively brings its own skill set into this process.

32

Finally, the last reason time is not on your side has to do with those pesky gatekeepers. While you get to reap the benefits of their native ecosystem, it of course comes at a price. Profit sharing costs aside, there is the opportunity cost to consider for the amount of time it takes to have your app submitted and approved, which can sometimes take weeks depending on its complexity. Apple is known for being the strictest, but there is still the uncertainty associated with possible rejection and then a re-submittal process fromany platform.

33

HybridYes I want my cake. And yesI’d like to eat it too, thank you very much

34

Advantages

35

Native with a side of practicality

Somewhere along the way, some brave soul dared to dream they could create a native container to look and feel like a true native app, but still have a web-based “write-once-run-anywhere” core. This in theory, could be a great way to help deal with the uncertainty of the evolving multi-platform landscape while still being able to tap into native OS capabilities.

The good news is this is no theory. It is reality. A hybrid approach can result in a development cycle that is faster than native-only given the app’s DNA is primarily made up of open source web technologies that can be used on any modern platform. As with HTML5, teams can bring some leanness to their design and development process while making specialized knowledge of certain OS platforms less of a dependency. Design and technical debts are reduced. This is good. Furthermore, maintenance becomes a more manageable process, as does the ability to progressively enhance the app over time.Even better.

If the “guts” of your app are basically HTML5, JavaScript and CSS, then you can more or less enjoy many of the adaptive benefits an HTML5 web-based solution enjoys.

36

HTML5 with a helping of platform awesomeness

From a user experience perspective, it’s a no-brainer that giving users access to native OS tools and capabilities is a good thing. A hybrid approach can deliver these very benefits as it uses enough of the native SDK to invoke useful capabilities like push notifications and background task management. As a result, users will appreciate this and will likely be more tolerant of your app.

In addition, because your app sits inside a native wrapper, it will be discoverable in the app store ecosystem associated with its host platform. As of May 2013, Apple reported its customers had downloaded a staggering 50 billion apps (not including re-downloads or updates). As of June 2013, Apple’s App Store had over 900,000 (375,000 native to iPad) apps available for download while Android’s Google Play had over 1 million apps – and that number is steadily increasing. It is safe to say there would not be that many tenants if the real estate was not so coveted. It can also be argued having a place in the native app store is also a UX considerationsince your app can be found with relative ease via categorical or manual search.

Furthermore, because it is packaged as a downloadable native app, it can run locally on a user’s device, has its own share of real estate on their device and does not have to needlessly suffer through as many online dependencies of a web-based app. Score for hybrid?

37

Gaining momentum

According to Gartner Inc., 50 percent of mobile apps deployed by 2016 will be hybrid. The emergence of frameworks like Apache CordovaTM (aka, PhoneGap) and TitaniumTM from Appcelerator® have made development of hybrid apps much simpler because they help bridge the web-to-native gap (hence, “PhoneGap”). Because these tools magically allow JavaScript access to the native APIs available on each platform, you do not need as much development expertise as you would for a native-only approach. Needless to say, this little bit of wizardry makes the development community giddy with excitement and more organizations are looking at hybrid as a serious mobile strategy. After all, feasibility and afford-ability areimportant too.

Finally, giants in the software and tech industries (Adobe and Intel) would not be backing a technology such as PhoneGap if they didn’t feel it was viable.

Third party hybrid tools

+ PhoneGapAMPChromaTitanium...etc.

Fun with App Stores!

=

Figure 8: A variety of third party tools are available to help developers bridge the HTML5-to-Native gap, allowing their apps to be downloaded from native app stores.

38

Cautions

39

Not quite native…

It sort of looks the part. It kind of acts the part. But something just isn’t right. A wolf in sheep’s clothing? A concern with the hybrid approach is that it almost feels like a native app, but it isn’t quite “walking the walk.” This is because users have certain expectations when it comes to the native features of their operating system.

While it is true a hybrid method can help you tap into the native features that reside in each respective platform, you will still not capture the look and feel in a way that makes users forget about the other native apps on their device. Some slick interactions can be achieved via JavaScript, but even small UI elements such as activity indicators (spinners) and expected gestures and animations native to the device cannot be 100% spoofed by web-based technologies.

In addition to an inability to truly mimic all of the UI patterns across each OS, is the fact that a hybrid app cannot replicate the speed of a native app. While it may not be overly perceptible in every situation, a solution based on web technologies essentially throws up another barrier between the user and the tasks they are trying to accomplish through the app.

Graphics and animations are not quite as fast… slight differences with the UI. While these things might seem minor by themselves, they could amalgamate to an app that is subpar. And your users will know it.

40

And not quite lean…

In for a penny, in for pound. You can’t have the best of both worlds without having the worst of both worlds. The leanness you may enjoy from the HTML5 part of the app is bogged down by the need to satisfy some native requirements for each platform. The ol’ ball and chain is still there. That is, the knowledge needed to navigate the waters of each native SDK is still a necessity since you are using their chrome and this still requires some specialized skill. And to a lesser extent, the learning curve it takes to understand some of the middleman tools like PhoneGap. Combine this with the need to submit an app store update each time you need to make a change to the chrome and the nimbleness you thought you might enjoy isnow diminished.

Could equal a solution that is…

“Meh.” If you cannot fully tap into all of the rich native goodness of a platform, you could be robbing your users of a quality experience. On the other hand, if you cannot fully leverage all of the glorious lean benefits that are associated with a web-based approach, you could be over-tasking your design and development teams. Herein lies the issue with a hybrid approach. While hybrid is viable, it leaves some valuable opportunities on the table since it does not leverage the totality of either the native benefits or the HTML5 benefits. Web-based technologies and third party tools are continually evolving, but will they ever be able to completely close that gap in a way that no longer necessitates a native app? It is doubtful in the near future.

41

So, there we have it. Three options for delivering mobile apps.

Let’s review, shall we?

42

Advantages

• Ready for zombies

• Supports rapid UX

• Discoverable on web

Cautions

• “A” for effort? (not likely)

• Doesn’t own the chrome

• More fragmented than

you think

Advantages

• One word: speed

• More OS capabilities

• OS consistency

Cautions

• Highly fragmented

• Time consuming

(repeat work)

Advantages

• Native with practicality

• HTML5 with better

OS capabilities

• Gaining momentum

Cautions

• Not quite native

• Not quite lean

• Is it enough?

HTML5

Native

Hybrid

43

HTML5 Native Hybrid

Performance Slow to moderate Fast Slow to moderate

User Interface Emulated True Native Mostly emulated

Discoverability Web App Store App Store

Availability Mostly online Online and o�ine Online and o�ine

Device Features Limited GoodExcellentCamera, GPS, Calendar, Noti�cations,

Accelerometer, Gyroscope, etc.

Speed to Deploy Fast Slow Moderate

Skills Needed Web technologies Objective-C, Java, C++ Web + Objective-C, Java, C++

Code Portability High None Moderate to High

Speed to Develop Moderate Slow Moderate

GUI Maintainability Easy to moderate Easy to moderateDi�cult

User Upgrade Requirements None (Web) High (App Store - this is improving) Moderate (Web or App Store)

Gesture Support Di�cult (JS required) Excellent Di�cult (JS required)

Fragmentation Web browser + OS OS Web browser + OS

Let’s get a little more technical

Note: while it is true this document focuses primarily on user experience, there are certain technical advantages and disadvantages that impact the ability to deliver a quality experience. The purpose of the chart above is to provide an at-a-glance view of these factors.

44

So what should you do?

45

Changing your ship whilst at sea is no easy task. And neither is changing mobile methodologies midstream. Just ask Facebook. So you can bet it is worthwhile to think about your mobile strategy before becoming too invested in one direction or another. That said, several companies have responsive web-based solutions and native offerings; but this also means they face the challenges of managing and maintaining fragmented UI properties, which is especially daunting if the native offerings are available on multiple platforms (not to mention smartphone versus tablet). And this approach is clearly costly given the amount of time, money and resources needed to keep it afloat.

What is best for you? It depends. Will your application require a healthy amount of processing power — something that will need to deliver some speed and pack some performance punch while having persistent offline capabilities? If so, you may want to consider a native approach. By default, many games on your smartphone or tablet are native apps for these very reasons; they can essentially run offline and still deliver a very rich user experience. Depending on the utility of your app, there could be many benefits to having this type of autonomy.

The caveat with the native approach being its exclusivity to a host operating system, a web-based solution might be more beneficial if you know your users have a preference to “hop” sequentially from screen to screen. This is an increasingly common behavior and it is now the norm with many business-to-consumer relationships. For example, a user who expects to engage with you on their phone or tablet while sitting in a waiting room also expects to pick up right where they left off on their laptop/PC later at home or work. While it is certainly feasible to enable back-end systems to carryover data from a native app to the cloud, a simple web-based approach can fulfill this user expectation with little overhead.

46

According to Google’s multi-screen world study completed in 2012, 90% of their respondents used multiple screens sequentially to accomplish the same task over time. What does this mean? Users expect to accomplish the same task in multiple ways based on their context: where they are, what they’re trying to do, how much time they have to do it. As mentioned before, a benefit of an HTML5/web-based approach is that it can allow you to adjust more quickly to evolving user behaviors as well as the constant evolution of form factors. If you do not need exclusively native capabilities like Bluetooth and in-app purchasing — and do not mind living inside the browser (not “owning the chrome”), than a web-based solution might be a practical way to go. You will just need to be aware of how effectively your UI responds from screen to screen for existing and emerging form factors.

So what about this hybrid approach? It is gaining momentum, after all. If you are primarily looking for a “write-once-run-anywhere” solution but would like your users to enjoy some of the native benefits of their host OS, then a hybrid solution might be a good fit. This obviously assumes you are okay with ceding a little bit of control to the native OS in terms of the development, packaging and deployment of the app. In addition, it also assumes that while you would like to reap some of the native benefits, you are okay with letting go of some of the core UI metaphors, patterns and contextual interactions (e.g., pickers, spinners, steppers, and sliders) users are accustomed to. Web technologies are continually getting better at bridging this gap, but it is difficult to spoof core OS features across multiple platforms in a way that makes users forget about their native counterparts. And if you attempt to retrofit a one-size-fits-all UI into multiple platforms, the challenge will be to do so in a way that does not frustrate or alienate users.

47

Thank youThe User Experience Design Team at Rockwell Automation is committed to delivering best in class software that shapes the future of our industry and exceeds customer expectations. We hope you enjoyed reading this document and found it educational. Thank you for taking the time.

— The User Experience Design Team, Rockwell Automation Control & Visualization Business

48

References

As retrieved from the web

“Native, HTML5 or Hybrid: Understanding Your Mobile Application Development

Options.” (Date N/A). Retrieved from the Salesforce Developers website.

<https://developer.salesforce.com/page/

Native,_HTML5,_or_Hybrid:_Understanding_Your_Mobile_Application_Development_Options>

“Hybrid or Native Mobile App Development: Six Key Considerations.” (June 2013).

Retrieved from the SandHill.com website.

<http://sandhill.com/article/hybrid-or-native-mobile-app-development-six-key-considerations/>

“There’s More Than One Way to Build Mobile Apps (Part 1).” (May 2013). Retrieved from

the Meltmedia website.

<http://blog.meltmedia.com/2013/05/theres-more-than-one-way-to-build-mobile-apps/#.

UkMAshazpOF >

“HTML5 Hybrid Applications.” (Date N/A). Retrieved from the WebPlatform.org website.

<https://docs.webplatform.org/wiki/concepts/internet_and_web/html5_hybrid_applications>

“Advantages and Disadvantages of Native, Web and Hybrid Apps.” (Date N/A). Retrieved

from the Javascriptstyle.com website.

<http://www.javascriptstyle.com/advantages-and-disadvantages-of-native-web-and-hybrid-apps>

“Native, Web or Hybrid: How to Choose Your Mobile Development Path.” (October 2012).

Retrieved from the InfoWorld website.

<http://www.infoworld.com/article/2615122/mobile-development/native--web--or-hybrid--how-

to-choose-your-mobile-development-path.html>

“PortKit: UX Metaphor Equivalents for iOS & Android.” (Date N/A). Retrieved from the

Kintek website.

<http://kintek.com.au/blog/portkit-ux-metaphor-equivalents-for-ios-and-android/>

49

“The New Multi-screen World: Understanding Cross-platform Consumer Behavior.”

(August 2012). Retrieved from the Google website.

<http://services.google.com/fh/files/misc/multiscreenworld_final.pdf>

Published Books Sourced

Wroblewski, Luke. Mobile First. New York, New York. A Book Apart, 2011. Print.

Presentations Cited

McGrane, Karen. “Content in a Zombie Apocalypse.” User Interface Engineering.

Washington, Seattle. 23 Apr. 2013. Lecture.

Wroblewski, Luke. “Designing Intuitive Mobile Inputs.” User Interface Engineering.

Washington, Seattle. 22 Apr. 2013. Lecture.

Copyrights

The HTML5 logo is licensed under Creative Commons Attribution 3.0 Unported.

Publication RA-WP002B-EN-E — November 2013 Copyright © 2013 Rockwell Automation, Inc. All Rights Reserved.

Allen-Bradley, LISTEN. THINK. SOLVE. and Rockwell Software are trademarks of Rockwell Automation, Inc. Trademarks not belonging to Rockwell Automation are property of their respective companies.

“If we want users to like our software, we should design it to behave like a

likeable person.”

- Alan Cooper