Mobile Considerations In User Experience Design: “Web or Native?”

59 min read
Mobile, UX, Hybrid, Native, Web Development
Share on Twitter, LinkedIn

About The Author

Aral Balkan is an experience designer and developer working to improve the world through design that empowers, amuses, and delights. These days, he’s organizing … More about Aral ↬

Email Newsletter

Weekly tips on front-end & UX.
Trusted by 200,000+ folks.

brand new Smashing Books #3 and #3⅓ have been released last month and we’re sincerely grateful for the tremendous feedback, reviews and photos submitted by our truly smashing readers across the world.

We appreciate your time and your interest, and thank you for your support and love.

We are happy to present a yet another sample chapter from the book. In his chapter, Aral Balkan explores what “native” actually means, what options designers and developers have and gives practical advice on what you need to know when deciding on tools for your next mobile-optimized project. The sample is also available for free download in PDF, EPUB and MobiPocket or .ZIP with all files.

— The Smashing Editorial Team

Smashing Book #3: the cover of Aral Balkan's chapter — Written by Aral Balkan, reviewed by Josh Clark and Anders M. Andersen. This cover image in the Smashing Book #3 was designed by Kate McLelland.

As you probably know, user experience design is the discipline concerned with all aspects of the design of interactive products. Although it incorporates important elements of graphic design and motion design, it is primarily concerned with the design of interaction. Its closest cousin in the design realm is product design. As user experience designers, we design virtual products. Furthermore, since hardware design and software design are so intrinsically linked and inseparable, the line that separates product design from interaction design — if it exists at all — is a faint one.

What is “Native”?

Have you noticed how people throw around the term “native” willy-nilly without grasping what it really means? Let’s change that, starting with what native is not.

Native Is (and Is Not) Ones and Zeros

If we are going to be pedantic, “native” — insofar as digital devices are concerned — refers to the absence or presence of electric current in the transistors that power our computing devices. We usually visualize this as the basic cliché of digital computing: binary code, a series of ones and zeros. We call these binary instructions machine language.

While it is true that computers were once programmed in binary using switches, we no longer write applications at a level that is so close to the metal. However, every other computer programming language we have devised — assembly language, C, Python, Java-Script, etc. — is eventually translated into the ones and zeros of machine language. These are further translated into the presence or absence of electric current in transistors.

Each of these technologies is built upon layers of abstraction. Python is written in C, for example. The purpose of each level of abstraction — each higher layer in the layer cake of technologies that comprise the modern computing ecosystem — is to make it easier for developers to author applications.

So, although technically correct, using “native” to mean programming in binary is a rather meaningless definition in today’s world.

So, now that we know what native is not, let’s figure out what it is.

Figure 9.2. Web technologies can be the native technologies for certain operating systems. Here we have a Samsung laptop running Chrome OS, on which HTML, CSS and JavaScript — and Web applications — are first-class citizens. (Image: Google’s promotional image.)

Native as Culture

“Native” refers to the technologies — i.e. languages and frameworks — that form the culture, language, conventions and norms of a platform. It is the base level of abstraction that comprises the core symbols, gestures and interactions that users employ to communicate with applications on a given platform. These elements are of utmost importance because they constitute the culture and norms of a platform.^[2] They are the language—both visual and behavioral—that users learn to communicate in when using a platform. Conversely, they are also the words, phrases and concepts that applications on a given platform use to communicate with users. The more usable and consistent these are on a given platform, the more advantages there are to creating native applications for that platform.

At one end of the spectrum we have Apple’s iOS, with its detailed “Human Interface Guidelines” and its elegant and consistent Cocoa Touch framework. A native productivity app on that platform that conforms to the guidelines will inherit much of the usability inherent in the core frameworks and will seem instantly familiar to users who are already familiar with other applications on the platform.

Figure 9.3. Apple’s “Human Interface Guidelines” provide clear instructions on how native apps on the iOS platform should look and behave. They help define the culture of the platform.

At the other end of the scale, we have native platforms like Android that are heavily customized by manufacturers, carriers and users to the point that there is little, if any, consistency between different Android phones and applications. Designers of native applications on such platforms might have a harder time providing a consistent user experience.

Figure 9.4. The Swype keyboard is actually quite amazing. Simply slide your finger from letter to letter, and it automatically guesses the word you’re thinking of. Unfortunately, it is not on every Android device, just some. Others come with keyboards that are more similar to the one on iPhone, and users can buy and use a multitude of other third-party keyboards. While this array of choice might seem good initially, it means that there is no single unified Android user experience. There are, in effect, as many Android user experiences as there are different versions of Android as customized by manufacturers, carriers and users themselves. This makes it very difficult to use a common design language when building apps.

For example, my iPhone app, Feathers, has a custom keyboard that I made for users to enter extended Unicode symbols. On iPhone, it works exactly like the built-in iPhone software keyboard. Achieving this took some effort, but it was not impossible. If I were to port the application to Android, I would have to know which of the many software keyboards the user has installed and then customize its behavior to match. Needless to say, this would involve a lot more effort and might not even be feasible. The Swype keyboard that comes on some Android phones, for example, is patented. So, on an Android device with a Swype keyboard, I cannot make my keyboard behave exactly the same way as the system keyboard.

Figure 9.5. Porting Feathers to Android would require making different versions of the custom keyboard to support many different keyboard types.

The compromise would be to make a single custom keyboard and use that regardless of the user’s system keyboard. Of course, it would neither look nor feel like the main keyboard and thus wouldn’t provide the same seamless experience of Feathers on iOS. Instead, users of the app would have to learn to use two different types of keyboards in the app and have to exert cognitive effort when switching from one to the other.

Similarly, on native platforms that do not have a strong, consistent visual language and culture—such as Android—or on native platforms that are notorious for being confusing to use—such as Windows—non-native applications will have less of a handicap. They might even provide better usability and user experiences in some situations.

A great example of a non-native application providing a better user experience on certain native platforms is Gmail. Using a desktop mail client on an operating system (OS) such as Windows could require you to find and install the application itself, keep it updated, keep your mail synced between your various devices, and make sure messages are checked for viruses and other malware. Compare that to the simplicity of Gmail, in which you enter a URL in the Web browser of any device and — boom! — you have your mail. End of story. Beautiful.

Figure 9.6. The Gmail Web app provides a consistent experience across platforms. Users don’t have to install anything or worry about syncing their email to multiple devices.

Gmail is also a great example of how creating good cross-platform user experiences can require a lot of platform-specific optimizations. Although the Gmail app runs across desktop and mobile platforms, there are actually several highly optimized versions of the app.

The Web as a platform itself, however, has few user experience consistencies of its own. Although Web applications share common features, there is no “Human Interface Guidelines” document for the Web (maybe there should be).^[6] Instead, we focus on documenting good coding and design practices, such as progressive enhancement. Different browsers (that is, native applications that run Web apps) implement the bahavior of core form controls differently. And that’s why a Web application could behave differently in different browsers even if it has the same markup, components and code.

Figure 9.7. A browser is an application that runs in the context of the OS. In other words, a browser is a native application. A Web app, on the other hand, is an application that runs in the context of the browser. It is not a native application since it has one degree of separation (the browser) between it and the OS. Similarly, a Flash app runs in the context of a Web app. It is not a native Web application since it has one degree of separation (the Web app) between it and the browser. Flash apps, therefore, are not native to the browser, just as Web apps are not native to the OS. (Image: Rosmarie Voegtli, smashed.by/voegtli)

Hybrid Applications

So, we’ve got native applications, which refer to the culture of the platform that they run on, and we’ve got Web applications, which run in a browser on the Web. But we’ve missed a third category that many modern applications fall into: hybrid apps.

We need to understand the strengths of various technologies and use them where appropriate. Declarative Web authoring technologies (primarily HTML and CSS) are great for creating complex documents and styling them beautifully. Thus, many designers of native applications use HTML and CSS when they need to display rich content. These types of applications are called hybrid applications because they employ a mix of native and Web technologies.

Figure 9.8. The Facebook app on iPhone is a hybrid app.

The Facebook app on iPhone is one example of a hybrid app, in which certain sections (such as the news feed) are rendered using Web technologies.

Similarly, as we saw before, Web applications can also be hybrid. A website authored in HTML, CSS and JavaScript and that uses Flash to display rich interactive content is an example of a hybrid Web application.

Many applications today are hybrids, and if you are accomplished in HTML, CSS and JavaScript, it is safe to say you will never go hungry regardless of which platform or platforms end up becoming the most popular in the decades ahead.

Overcoming Ideological Bias

All too often, technology and design decisions are made based not on a desire to choose the best materials and tools for the job but on ideology. The Web standards advocate who blindly recommends the Web platform and Web authoring technologies for any project, regardless of the users’ needs is, unfortunately, all too common. Developers who blindly recommend Flash and native iPhone or iPad apps for any project are all too common, too. The old adage “When all you have is a hammer, everything looks like a nail” comes to mind. So, it is important to recognize such biases and to base your decisions on the needs of your users, not on ideology. It is also important to be able to recognize ideological views so that you can steer the discussion back into the realm of design.

Some advocates of Web standards hold a core assumption that the Web platform and Web authoring technologies are, by nature, a force for good. One wouldn’t dispute that the Internet and, by extension, the Web have had as radical a democratizing effect on the world as the Gutenberg Press (if not more so). However, the Web platform and authoring technologies are inherently neither good nor bad, and they could easily be used for either end.

In the case of the Web platform, the common assumption is that it is inherently good because any document or application placed on it is universally accessible. While this may be true for open collections of documents — as was the norm for content in the early days of the Web — it is generally not true for what we would consider a modern Web application today. Take Facebook. Facebook is a Web application. It is not open. It is free, but what this means is that you, the user, are not Facebook’s customer. You are Facebook’s product.^[7]

Your personal information and behavioral traits are what Facebook sells to its real customers, advertisers. Is this in any way inherently better or more open than having to buy a commercial application from Apple’s App Store?

Not really.

In fact, you could easily argue that buying a license for a commercial iPhone app is a more honest and up-front transaction. You pay for it and thereby own a license to use it. You become the customer of the company or individual who made the application. There is transparency in how the company makes its money. In many ways, this is a much more traditional commercial relationship.

Of course, even commercial apps can use your data in devious ways, so being vigilant about your personal information these days is important. But the point is that simply being a Web application does not somehow magically make it a force for good in the world.

Are Native Applications and Platforms Endangered Species?

As Jeremy Keith famously put it at the Update Conference, “Writing a native app is like coding for LaserDisc.” The implication here is that native platforms, like CD-ROMs and LaserDiscs, will be obsolete soon since the Web is “catching up.”

I sure hope that is not the case, because the Web itself is a native platform and is becoming even more so (in the traditional sense) with the rise of OS’s such as WebOS and Chromium, which are based on native Web authoring technologies. We have to understand that what the Web is supposedly catching up to is a moving target. New features, user experience enhancements and more are being added to native platforms all the time. It’s not like Apple will decide on 1 September 2012 that iOS is “done” and stop creating new versions of the OS or new models of iPhone and iPad, at which point the Web can take a few years to finish catching up.

We know that “native” refers to the core culture and language of a platform, so predicting the demise of “native” is analogous to saying that different devices will not have distinct cultures in the future.

The assumption inherent in this view is that a monoculture will arise in the future in which every application on every device will speak via the components of the Web and be authored using native Web authoring technologies, and moreover that these applications will all be served from the Web platform. If anything, this is a gray and chilling vision of the future, in which people will have even less control of their own data and in which their devices will simply become dumb terminals that hook up to great silos in the sky (“the cloud”) that are controlled by large corporations.

Instead of owning a license to a word-processing application, for example, you would write everything in Google Docs. Google, for its part, will be analyzing every word and sentence, trying to understand more about who you are and what makes you tick so that it can use that information to better manipulate your commercial behavior.

This is not to say that Web applications are necessarily evil, but they are definitely not inherently good.

Blurring of the Lines

We keep hearing that “the Web is catching up to native.” What people mean when they say this is that Web authoring technologies are getting better access to device features such as touch, hardware-accelerated graphics, GPS, accelerometer support and cameras. What is rarely mentioned, however, is how native applications are catching up to Web applications. In some respects, the strides that native applications are making are far more important because they threaten the core user experience advantages that Web applications have historically enjoyed over native applications.

The three main areas in which native applications are catching up to Web applications are ease of deployment and access, automatic updates and seamless access to data.

Ease of Deployment and Access

One of the core user experience advantages that Web applications have historically had over native applications is the ease with which they can be deployed and accessed. Click the “Upload” button in your FTP application of choice^[8] and your app becomes accessible to anyone who has the URL anywhere in the world.^[9] Simples.

No need to download a Zip file, then search for an application to unzip it with, then look for where you downloaded it to, then unzip it, then install it, then run it, only to find out that it doesn’t support your graphics card. Eek! Is it any surprise that Web applications like Gmail and Google Docs have enjoyed such phenomenal success, especially on native platforms with poor usability?

Figure 9.9. The line between the user flows of Web applications and native OS applications is blurring. In fact, in OS’s based on Web technologies, Web applications are native OS applications.

However, native apps are catching up to the ease of deployment and access offered by Web applications thanks to the development of app stores. With an app store like Apple’s, the process of finding an application is as easy as hitting a URL in a browser. In fact, you can hit a URL to reach an app in the App Store and, from there, simply click a button to download and install it.

Automatic Updates

Web applications, by nature, have always provided automatic updates. In fact, we don’t even think about the “version” of a Web application because the Web is inherently version free.

You’re always using the latest version of Gmail, and you don’t care what version it is.

It’s not Gmail 7; it’s just Gmail.^[10]

Native applications, by contrast, have usually had clunky update mechanisms that interrupt the user’s flow. That, too, is changing with more and more native applications implementing seamless updates. When, for example, was the last time you noticed Google Chrome updating? Never. It does it silently.

Seamless Access to Data

The other huge advantage that users of Web applications have traditionally enjoyed is the ability to access their data from any device. You never have to worry about syncing email from your desktop to your mobile phone when using Gmail. It’s always there. Compare this to the nightmare that has traditionally plagued syncing on native platforms.

Native apps, however, are again catching up. With Apple’s iCloud, for instance, manual synchronization is becoming a thing of the past. Your data is simply, transparently and automatically available on your Apple devices and is kept constantly in sync without your having to worry about it. Although iCloud is primarily an Apple-centric continuous client solution, other cross-platform technologies, such as Dropbox, bring similar advantages to other platforms.

Just Another Client

Did you read the previous section thoroughly? Good. Then you may have noticed the common thread in all three areas where native applications are catching up to Web applications. They are all areas where the advantage in user experience is due to a characteristic of the Internet and not the Web. The Web is just a stack of technologies — namely, HTTP and URLs — on top of the Internet stack. So, native applications are catching up to the Web by taking advantage of the very same characteristics of the Internet that the Web does.

Furthermore, we are seeing the rise of a new type of user experience pattern, called the continuous client. A continuous client experience — as originally proposed by Joshua Topolsky^[11] — lets a user seamlessly continue an experience across devices and contexts.

For example, if you are reading your Twitter stream on your computer and then grab your phone, you should be able to continue reading the stream from the same place. And when you get home, you should be able to continue from the same place again on your TV.

A good example of a continuous client in the wild is the Trillian instant-messaging application. It can store chats in the cloud, share chats between all of your devices in real time, keep track of and synchronize your read and unread messages, and even make use of “presence technology” to know on which device you’re currently active so that it can send current notifications only to that device.

Figure 9.10. Kelly Sommers has a nice sample app that showcases a continuous client experience: smashed.by/multi. Users can start watching a video on their Windows Phone 7, continue in a Web client, and then on their iPhones.

If you think about it, in the age of continuous client experiences, the Web becomes JAC (just another client). It may be the best client to use in certain contexts, but users have the choice of switching to native clients without worrying about synchronizing data. Soon, continuous clients will be a core expectation instead of a novelty, especially as high-level technologies, e.g. iCloud, make it easier for developers to implement them.

Figure 9.11. The instant messaging app Trillian is a good example of a continuous client. (Image: Trillian Blog, smashed.by/trillian.)

The Future is Native

The Web today is just another native platform and one that, going forward, has to compete on its own unique merits and not on the advantages bestowed upon it by the Internet, because other native platforms are also implementing those same advantages.

The tricky question to answer when deciding whether to use the Web platform or other platforms for your next application is whether the advantage lies in exposing the user interface of your application as a native app or in exposing it via a URL and serving it via HTTP.

As Web applications catch up to native platforms with features like Local Storage and the ability to run while the device is offline, the line between Web and native applications blurs even further. This is taken to its logical extreme in OS’s like Palm’s WebOS and Google Chrome, where the native technologies are Web technologies.

We need to understand that a Web application running on such an OS is a native application. At that point, our decision is between different native OS’s and native frameworks. That choice will be greatly influenced by which native OS’s offer a superior user experience. Subsequently, our technology choices will be between different native authoring technologies — HTML, CSS and JavaScript for native Web applications, Objective-C and Cocoa Touch for native iOS apps, Java and Android SDK for Android apps, C# and .NET for Windows Phone apps, and so on and so forth.

Regardless of which platforms and technologies win out in the end, the future is clearly native and the Web is JAC. Now, the billion-dollar question is not “Do we go Web or native?” but rather “Which platform or platforms and which client technology or technologies should our new product support?”

To answer this, we need to understand the nature of our product and, specifically, where it falls on the documents-to-applications continuum.

The Documents-to-Applications Continuum

On the Web, one way to classify products is according to whether they are content-centric or behavior-centric. We call a content-centric collection of documents a website. A behavior-centric product is called an application (or “app”). Instead of falling entirely in one camp or the other, your product will probably lie somewhere between the two extremes on the documents-to-applications continuum.

When a product falls closer to the documents side of the continuum, we can use progressive enhancement to layer features and interactions on top of the content-based core while keeping that core accessible to the largest number of people possible. These progressively enhanced features usually either layer advanced formatting or layout on these documents or add fanciful interactions for navigating within or between them. We can make the content adapt to different screen sizes and make the limited interactions that are used to navigate the content adapt to different input mechanisms. This isn’t an easy task, but nor is it impossible.

As products shift from the documents side of the spectrum to the applications side, however, implementing progressive enhancement gets harder. In fact, it might become entirely meaningless or impossible. How would you gracefully degrade an online image editor, for example? How would an image editor work on feature handsets without graphical displays? What content would you actually fall back to displaying?

Figure 9.13. The principle of universality, as composed by the creator of the World Wide Web, Tim Berners-Lee, was written in an age when the Web was mostly a collection of interlinked documents. It doesn’t necessarily apply wholesale to applications, which have very different design constraints and requirements. See Lea Verou’s comment on John Allsopp’s retort to my one-version manifesto on .Net magazine: smashed.by/netmag

Applications are not content-based; they are behavior-based. Gracefully degrading to a simpler representation of whatever content an application might have does not always make sense. Applications are often made up entirely of behaviors that let users create content. Consider the image editor again: it doesn’t have any content itself, but it enables users to create content.

In order to create exemplary user experiences, we need to maintain focus. This focus has to be placed squarely on meeting the needs of our users in the best way possible. No product team on Earth has the resources to create applications that provide the best possible user experience for every user.

Given unlimited time and resources, we could optimize the user experience of our apps on every device and platform known to humankind. However, given limited time and budget we have to work with in the real world, we must be selective with our audience, problem domain, platforms and devices. We do this not to exclude people unnecessarily but because we realize that including everyone and giving everyone a great user experience is impractical.

Mobile Design Considerations for Document-Centric Products (Websites)

On the documents side of the continuum are websites. A website comprises content as well as the presentation of that content. The content may be text, images, audio, video, etc., that is marked up with HTML in order to add semantics and structure. The presentation includes both the visual layout and the interactive elements (such as navigation between pages or states) and is usually implemented using a combination of CSS and JavaScript.

If you have a website, the first thing you should do is test it out in mobile contexts to see how it displays and performs. I’ve encountered far too many companies that overlook the importance of making their websites mobile-friendly and jump straight into creating a native application. Be careful of making this mistake, especially if your website is an important revenue generator. For document-centric websites, use progressive enhancement whenever possible to make sure the content and core interactions for navigating and consuming that content remain accessible to as wide a base of your users as possible.

To do so, you can follow these broad steps:

Make sure your content is accessible to everyone, and mark it up with proper semantics. Separating content from presentation is key.
Progressively enhance your content to provide a more optimized experience for people viewing it at different screen sizes (this is the focus of responsive design currently).
Progressively enhance your content to provide a more optimized experience for families of devices based on supported features and capabilities (for example, touch). In other words, make the website responsive in behavior, not just in layout. At this point, you are optimizing for features, not for specific devices (say, for all mobile phones that support touch, not just the iPhone).
Progressively enhance your content to support the unique culture and capabilities of the various devices you want to support. At this point, optimizing for specific devices is all right. There’s nothing wrong with trying to make the user experience as beautiful as possible, even if it is for a specific subset of your users at a time.

#### Make sure to test your designs on actual devices A simulator or emulator is great for testing the effects of code changes while you’re developing, but they cannot recreate the unique ergonomics of the device itself. Context is also a key factor that affects the usability of mobile experiences, and a design that works perfectly well under the perfect lighting conditions of an office might not work as well in bright sunlight, for example. Also, remember that when you test with a simulator, it uses your computer’s powerful hardware to run the application. You might see slower performance—and even slightly different behavior—when running on an actual device.

Of course, each of these steps will take time and more resources, and you will need to plan and budget accordingly. But what if making your current website responsive does not meet your users’ needs in this particular instance? Perhaps you need to provide a more optimized and focused experience than progressive enhancement allows given your budget and schedule, or perhaps you need a level of device integration that is simply not possible through a browser currently? In this case, you might want to start thinking about whether to build an app, and if so, whether it will support multiple platforms and which technologies you should use to build it.

Cross-Platform or Single Platform?

Can you best meet your users’ needs with an application that runs on multiple platforms or — at least initially — on a single platform?

When answering this question, keep in mind that creating an application for a single platform does not mean that you cannot create a separate app for a different platform later on. It just means that you will be focusing your design and development efforts on a single platform (or perhaps even a single device) to start with.

It also does not, by itself, imply whether you will be creating an application that runs as a native binary or whether your application will use the native components of the device or devices that it runs on. (Using cross-platform authoring technologies to create an application that you have optimized for a single platform is perfectly possible.)

The answer to this question will, however, determine how much optimization you must do on different platforms. If you care about the user experience, you must optimize your app on each and every platform that you support. It will also affect how much testing you must do (because you will need to test on every platform that you support), the size of your support department (because you will need to troubleshoot user issues on every platform that you support), and how much time and budget you need to set aside for these various functions.

The Myth of Write Once, Run Anywhere

A common mistake I see many designers make is to assume that by using cross-platform authoring technologies they will be able to write once, run anywhere. This is a myth. And acting on the myth can lead to rather costly underestimations. Your application might run on multiple platforms, but this rarely—if ever—means that it will run well on multiple platforms.

The only way to get an application to run well on multiple platforms is to optimize it for each one of those platforms and devices. As mentioned earlier, every platform has its own culture, language and norms that users expect apps to conform to. And most users do not care how many other devices your application runs on — they care only about how well your application runs on their device.

Designers who do not take the unique cultures, customs, language and norms of their respective platforms into consideration risk making their applications look and sound out of place. The applications will appear noticeably foreign, unnecessarily loud and usually rather arrogant, simply because they are culturally insensitive.

Because we don’t want our applications to exhibit such obnoxious behavior, we must optimize them for every platform we support. Our aim is to create applications that are culturally sensitive to the language, norms and customs of the platforms they run on. Anything less and we would be showing varying degrees of disrespect to certain segments of our users.

Death by a Thousand Cuts

The worst thing you could do, of course, is disrespect all of your users by creating a lowest-common-denominator application that gives every user on every platform an unoptimized user experience. At that point, you would be at your most vulnerable. Even though your cross-platform application might have the potential to reach a large number of users because it runs on a large number of devices and platforms, it will be at a disadvantage in user experience on every one of those platforms. To put it bluntly, who cares if it runs on a certain platform if it runs badly?

More importantly, what happens when a competitor comes by on one of those platforms with a beautifully designed, precisely optimized, delightful user experience and blows your app out of the water?