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

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.

Why do physical keyboards still exist for mobile?

There are a glut of companies offering touchscreen keyboard software. While this means the typing experience on touchscreen devices is getting easier, it hasn’t stopped people from buying, or wanting to buy, mobile devices with real keyboards.

Sooner shows real innovation in mobile UX

I have to say that after looking at a few dozen calendar tools for my iPhone, they all seem more or less the same. Sooner is new entrant that has adopted a wheel-oriented design motif in some interesting ways, one that breaks away from the seemingly endless agenda-and-30-boxes approach that most use.

Above you see the wheel for the current week with Wednesday selected, and displaying the day’s events on the innermost ring. The plus sign is the way to create new events, which is dragged over the inner or outer elements of the wheel.

Sooner is a task manager tool, as well. The task UI is reached by clicking on the list icon in the upper right corner, leading to this:

Here you see categories — for example, ‘1 year plan’ and ‘to do’ — and tasks — like ‘Luke meets droids’ or ‘Watch Star Wars’ — and clicking on any item leads to an edit interface. Dragging the plus icon into one of the categories leads to creating a task in that category and opening it in edit mode.

Because the UX is very oriented to touch it is actually very difficult to describe exactly how to accomplish things, like assigning a time to work on a task, which involves both the task and calendar wheels. However, the tool has helpful guidance built in, like this:

And when you select on items, like events or tasks, you are provided a more or less normal edit view like this:

Sooner syncs with the  default calendar on the iPhone, which in my case links to Google calendar, and creating events through Sooner just worked. However, Sooner tasks currently don’t sync with anything outside of Sooner, and so it is currently a standalone iOS application for tasks.

The obvious missing piece would be an integration with Google tasks, although I don’t think Google tasks is full-featured enough for very serious use. In the longer run, it would be interesting to imaging a shared calendar/team task management service that could grown from Sooner, and it would be great if that came sooner, not later.