Designing Web Code in a Native App

Over the years I’ve heard developers say, “you can always tell when it’s a web app,” insinuating that web apps are lacking when compared with native apps. These same folks will claim that web app performance is poor and the design is inferior. Although that might have been true years ago, today’s web fairs much better than the web of yesteryear. Our runtimes are superfast, leaving no lack of performance for apps. And the best user experience on the web is generations ahead of that of native apps, with responsive design making web apps a great experience on any device.

The benefits of web apps continue. When well written, anyone with a browser can interact with a web app regardless of platform, version, or device. It’s single code base also makes it the overwhelming choice for developers, brands, and companies that don’t desire or have the resources to build and maintain native apps for each platform.

[caption id=”attachment_1901" align=”alignnone” width=”2376"]

Awesome web apps are awesome apps. Both in a browser or in an app store.[/caption]

Defining the problem

Every day I work with developers who are using ManifoldJS to take great web apps and turn them into store apps. ManifoldJS lets you maintain the spirit of the web by building hosted web apps. Hosted web apps are different because they allow your code to live on a web server just as it does when you access it in a browser. That means the codebase is always up-to-date, you can deploy changes whenever you desire, and, generally, if the code works in the browser then it will work as a hosted web app.

Great web apps have great user experiences and a web app that is designed to work on a wide variety of browsers and devices can perform quite well as a cross-platform hosted web app Some of key characteristics of apps like this are:

1. Responsive layouts. The design presents a good reading/viewing experience no matter what the screen size or orientation. Users can accomplish their goals without need to scroll in more than one direction or zoom in and out to interact with the app.
2. Appropriately-sized fonts. You should be able to easily read the font on the screen. This works both ways — it should be large enough to be read on a small screen, but it should not be ridiculously large on larger screens. Balance is key.
3. Flexible input. The app should support touchscreens, keyboard and mouse; but if you want to support next-generation interfaces, don’t forget about input modes like voice or gestures.
4. Speedy delivery. Not everyone has hard-wired access to a fiber optic connection and unlimited bandwidth. Many devices have limited bandwidth or slower processor speeds. Your app should not take too long to load or feel sluggish during interactions.

With all of that taken into account, the question I most frequently get is: How should I design my app? (And they mean that in terms of aesthetics.) In other words, what should the visual design look like? Generally, the options are:

1. Design a single interface for the app, so it looks consistent no matter what platform it’s being used on.
2. Design a more “native” interface for each platform to honor its unique look and feel.

My answer is consistently the same: I have no idea. Luckily, my teammate Aaron Gustafson has some thoughts on the matter though:

It Depends.

I completely understand the desire to have an interface look and feel like the same (or similar) to the native operating system. It creates a “seamless” experience for your users which may make it easier for them to understand how to use your app. That said, if your app is intuitive, there’s no reason to think the fact that it looks like the underlying OS is going to make it work any better for them. Furthermore, a “native” look and feel won’t render a crappy app instantly usable.

On top of that, chasing the design of a native OS is probably not a rabbit hole you want to go down. Here’s why: achieving exact design and functional parity between something as simple as a native control and a web control quite often requires extra markup, a bunch of CSS, and a bit of JavaScript. Anything is achievable with unlimited time and budget, so it’s completely doable, but it would be good to estimate the cost to see if you still think it’s a worthwhile endeavor.

Assuming it is, you then have the question of which operating system to model the control after. Or maybe you want to offer a different take on the control based on the operating system your user is on. In that case, you probably need to multiply the original estimate by the number of operating systems you want to support. It’s worth noting that, in the Android world at least, different device manufacturers often “skin” the operating system to look different from Android devices from other manufacturers. You’ll need to figure out which ones you want to include in your support matrix and multiply the estimate accordingly.

Then there’s QA and maintenance. You’ll need to test each native-like control on its corresponding platform. You’ll also need to test the script that chooses which experience gets delivered to which device in order to ensure you’re not accidentally sending the wrong experience. You’ll also need to test the delivery script on every other browser in your test matrix to be sure it is not causing issues there too.

Then there’s the question of what you need to do when a new operating system version is rolled out. iOS, for example, has made radical shifts in the design of their native controls with each major release. You’ll probably want to create unique versions of each control for each version of each OS you support. You’ll also need to keep tabs on upgrades so you don’t end up confusing your users if they visit our site in iOS 8 and have a control that looks like it’s from iOS 6. You’ll need to add the number of OS versions you want to support into the multiplier as well.

You’ll also need a baseline component look and feel for everyone who doesn’t fall into your matrix.

Finally: How many controls did you want to apply this approach to again?

Or you could embrace the web and use a native form control and the interface will just work. The web’s ubiquity is its power. Approaches like responsive web design and progressive enhancement embrace that and pay such huge dividends in terms of increased reach and decreased design, development, and maintenance costs. Build once, deploy anywhere — that’s the promise of the web and it’s what makes a great web app capable of becoming an awesome installed web app too.

— Aaron

Going Hosted is Easy

Not surprisingly, I think hosted web apps are a great approach to building store apps. For the “how to” on turning a web app into a hosted app, check out my blog post on getting started with ManifoldJS; it’s quite easy to do and you can even generate your app in your browser using the ManifoldJS website.

Hosted apps provide you with new and interesting opportunities not possible in browsers through platform APIs. iOS and Android apps can be configured to access Cordova APIs like media capture and contacts and for Windows 10 you get access to all those APIs plus the entire Windows Universal API set. New features can be added to your app by simply feature-detecting the APIs, then executing additional JavaScript.

It doesn’t require a ton of extra work to bring your web apps to app stores. Once there, you’ll have the benefit of store-based discovery and a truly native app experience. So why wait? If you have a great web app, take five minutes and make it a hosted web app.