The case for consistency: native design isn’t always right

5 Comments

Credit: graphicnoi/iStock

Quite a few companies are reclaiming mobile app development these days. Some are moving outsourced development in-house, and others are consolidating line-of-business development projects under a single department. In both cases, one of the most popular questions they ask Gigaom Research is whether to go native, hybrid, or HTML. It’s a perfectly valid question, but in many cases, they’re asking it for the wrong reason.

“Native or not” remains an important choice when you’re concerned with application functionality. HTML-based development (the “mobile Web”) trades performance and control for increased code reuse across devices. Native apps, coded specifically for a target platform, take longer to develop and port to other platforms, but allow developers to squeeze out every ounce of device performance or write to specific hardware features. By placing HTML and JavaScript inside a native container, hybrid apps split the difference between the two, combining a large amount of code reuse with substantial device connectivity and performance advantages.

Choosing a development strategy can have a huge impact on your application’s responsiveness and feature set, but a lot of the questions we get are about design, and with rare exception, there are three reasons why native design (making an app look and feel like it matches the operating system’s UI) often isn’t worth the time.

1. Good design is app-centric

I’m not claiming that design is unimportant. Quite the opposite. Mobile design is critical, and in some cases, as Gigaom Research Analyst Paul Pangaro outlined in Designing for mobility: directions for mobile UX, design can actually define your app – like Tinder’s left-right swipe. That’s precisely why your choices need to reflect the best possible user experience within your app. No one is suggesting that you toss decades of UI on a whim, but if custom icons, fonts, gestures, or menus work best for your app and the context in which its users will interact with it, that’s far more important than staying in sync with the OS running it.

It’s important to remember that mobile apps are rarely used in conjunction with other apps beyond a standard set of export functions such as email, social sharing or copy-and-paste. And given the size of even most tablets, it’s rare to have more than one app active on the screen at one time. This frees developers to focus on building the richest, most appropriate context for one specific app.

2. Developers are busy, and customers are impatient

As another Gigaom Research Analyst, Rich Morrow, noted in his Sector Roadmap on cross-platform mobile development, the “talent crunch” is the biggest challenge development organizations face. There just aren’t enough qualified developers and designers on the market, and enterprises and ISVs alike need to focus the limited resources they do have on tasks with the greatest payoff. At the same time, mobile users are notoriously impatient and more than happy to find another app to meet their needs. Both situations call for a faster release schedule, and hybrid apps with a single, shared interface across platforms are often the middle ground to get you there.

3. Consistency is king

We’ve all experienced the annoyance of “That isn’t where it was in my version of Word” when using a friend’s computer. Imagine that experience repeated across an iPad, an iPhone and an Android handset as you access the same app from different devices. Now imagine supporting that application or training users in a BYOD environment. A consistent interface across platforms is far less likely to frustrate users, and it will make your business more efficient, too. If you’re mobilizing an existing Web or desktop app, there’s a good chance that your mobile UI will be substantially different from the original — optimized for touch, smaller screens and focused use cases — but consistency among mobile platforms is good for everyone.

There are always of exceptions. For example, if you’re building an app that extends the operating system or another core application, matching the default UI is core to your value proposition. But if you’re building B2C apps that can stand alone or developing any sort of enterprise app, consistent design is much more important.

5 Comments

Alok Ranjan

An excellent point and at the end of the day the business owner need to decide which way will be suitable for their business based on their exact need. Not all the applications use device intensive features and Hybrid. Specifically in enterprise applications, most of the times you see data driven screens. Hybrid approach makes a lot of sense – specially when you do know that mobile app developers don’t come at low cost.

Thanks for putting this article.

Rahul Kaul

HABIT – It remains! This is the key… I agree with Joe that there are very few people who keep switching the platforms back and forth… and even if they do, they don’t typically do it on 50-50 time basis. We do it generally on very specific need basis. There is one platform that we use for long in their 24 hours day… and this becomes a part of our long-term and muscle memory… spending lot of time on a platform sub-consciously train our mind in specific way. It sets our expectation! I switch-on the light of my bathroom every morning and I even do it without opening my eyes!!! This is why I call the place where I live as HOME. This also plays a key role in forming my mental model.

To be able to build a consistent experience, there are changes needed in our HOME as well.. and how many people are willing to accept change in their HOME/ HABIT so easily? Its not easy to get out of the comfort zone!!! Rule of 80-20 has to be applied here… who are we building the Apps for? 80% of those who don’t switch the platforms?? OR 20% of those to switch platforms on specific need basis?

I inclination will always be towards 80% category. Saving the cost is important, but not on the cost of experience… otherwise its the adoption that we will ultimately compromise!

Trying to satisfy everyone generally makes everyone unhappy! Pushing things on screens as small as 3.5 inches should be done very cautiously other it will increase a lot of Visual Clutter that will put off all types of users who we were trying to please!!!

Just a last note on this thread… users are habitual of using the platform and not just a single App. We should provide them the interaction that is aligned to their mental model to have them clear the most critical stumbling block. Rest depends on the content and other factors.

Note: I agree with the fact that decision of choosing between a “Hybrid App” and “Core Native App” depends on the requirement but please try to keep yourself away from “One size fits all” because we don’t ever want to wear your neighbor’s jacket just because he/ she has one!!!

Peter Loerincs

If the application has enough intrinsic value, then I’d expect that the users will put up with the UI being a little “off”. But if I am competing with 5 other apps that offer similar value, then which one will the user prefer? the one running natively.

The argument for non-native apps can be valid for companies that create enterprise software that also are the only publisher developing apps for that same enterprise software… If the publisher of the enterprise software is the only publisher of apps for it, then the users are locked-in and they will have to use a non-native design because it is the only one available.

In this case the only value of a non-native design is for the publisher (avoid talent crunch, increase speed to market), not the end user. Ignoring the end user experience in favor of faster time to market because ‘customers are impatient’, is like me demanding to be served my meatloaf half-cooked at the restaurant because I am hungry. I will get what I asked, but I doubt it will be an experience that will thrill me and that would have me coming for more…

Back in the day we developed applications using Smalltalk on Windows 3.1. (Smalltalk gave the promise of cross-platform freedom and provided their own runtime, similar to Java). The UI was always a little “off”. Yes, we had listboxes, dropdowns and buttons… But they were always a “little different”. When we needed to implement a basic Windows behavior (let’s say a hover over tooltip) the request was met with a lot of push back… It took just too much work to properly replicate some of the subtle UI behaviors that the Windows user was accustomed too. At the end we wrote a new front end native to Windows.

Joe Michels

“A consistent interface across platforms is far less likely to frustrate users, and it will make your business more efficient, too.” Only for people who switch platforms, or switch back and forth, back and forth, most people don’t switch. I would suggest that designing to the platform design language will make your business more efficient.

Cormac Foster

An excellent point, and there’s also something to be said about the ability of users to learn two interfaces if they spend a good deal of time in both platforms. For example, when I used a Mac at work and a PC at home for many years, I never confused Alt-F4 with Command-Q, because I saw them as distinct platforms in distinct spaces. However, in addition to the truly mobile professional who really may access from 3 or more devices, I’m starting to hear more from clients about the incidental mobile users – the “I forgot to do this at work, so I’ll grab my son’s tablet and log on for a bit.” Those users are the ones who are most consistently thrown by platform differences. Granted, those differences often have nothing to do with an app’s UI (the connection process itself is often a big hurdle), but anything you can do to simplify that process is a help to everyone involved.

I’m definitely not suggesting that enterprise employees will eat what you feed them because they have no choice. That may have been true in the desktop era, when a one-size-fits-all app with 20 tabs was “good enough,” but with 4-5 inches of screen, you need to do things right. But I think there’s a balance to be struck, and a lot of it may be based on the app’s content. Some apps really do call for a native interface, and as you mentioned, that might actually be a lot more intuitive. Others–particularly environments in which you’re spending a lot of time in a session–might call for something more custom.

Comments are closed.