Tag Archives: Mobile Apps

Building a Native Mobile App Experience—Without the App

Note: This post was adapted from the more developer-oriented “Piggybacking on backbone.js for performant mobile web”, originally published on Sawdust Software.

Native mobile apps are great. They provide a rich user interface (UI). They can easily access other core applications (e.g., camera, calendar, message center) on your smartphone to create stickier, more immersive experiences. They routinely provide a much faster user experience (UX) in terms of menu traversal and screen-to-screen navigation.

However these benefits come at a cost. They require lots of work: learning, developing, and testing on an entirely different tech stack (most likely iOS or Android). They bind you to navigate a proprietary app store release and submission process (one far slower than the ability to release software on your own web farms). Worse, these are not one-time costs. They can double the cost of adding new features (as you have to develop these for web and native mobile). The also introduce a new mobile OS compliance cost: keeping your app up-to-date with new mobile OS releases—while supporting users on older mobile OS versions—can routinely add 30% to your costs of mobile development and testing.

In some situations, the benefits of using a native mobile app far outweigh the costs; in others they do not. Luckily, there are many technologies and approaches available when you want to create a mobile web experience and do not require (or want to) development of a native mobile app:

Create mobile web-optimized templates

The responsive web design (RWD) movement has gained much traction in the design and development community. While it is appealing to create universal web templates that can detect and respond to the size of the browser screen, this is not always ideal for mobile web. More often than not, universal web templates can have quite large file sizes. Downloading these over a 3G connection can be quite slow. Worse, they can burn battery life on your customer’s phones, leading them to not use your site on mobile.

When considering functionality for mobile pay attention to size of the pages you need users to download. If the desktop (or ever increasingly Tablet-plus-WiFi) versions of your HTML templates are large, create mobile-only templates that are smaller and optimized for download and display on smartphones. If you are on a standard web framework, you have a range of plug-ins you can add to easily detect then customers are accessing your site with a mobile device and serve these templates (e.g., Django Mobile, User Agent (for Rails), Spring Mobile Device Module). You can even use these to serve up a different experience for mobile tablet (vs. mobile smartphone) users.

Use HTML5 and jQuery Mobile to emulate native mobile UIs

Thanks to the rise of mobile and responsive web design, there are now many libraries available to develop lightweight (i.e., small file size) touch-responsive web interfaces using HTML5. Some great examples include: JQuery mobile (if you are a jQuery purist), jQT (if you have a Sass shop), and Zepto (if your really want super fast performance).

When you combine these with mobile browser detection (see above), you can serve up HTML interfaces that use widgets that are virtually indistinguishable from their native mobile counterparts to 80% of your customers:

Entirely HTML5, Sass and jQuery mobile web--with emulated iOS widgets (www.custommade.com)
Entirely HTML5, Sass and jQuery mobile web–with emulated iOS widgets (www.custommade.com)

It is worth pointing out that using these libraries not only lets you emulate a mobile app experience, using them also keeps your teams on a single technology stack. Developers building web UIs can easily switch over and develop mobile web equivalents (or vice versa). This makes life much more interesting for developers (they can do more, more easily) and management (people can do more and switch to whatever is most important more easily).

Use backbone.js to load navigation control into the browser

One of the reasons that native mobile apps are able to navigate (between menus and moving from screen to screen) so quickly is that they embed a model-view-controller (MVC) architecture directly into the app installed on the mobile device. In an MVC architecture, the Controller directs what Views (screens, menu elements) to display when a user touches (or clicks) on something. On native mobile apps, the Controller is located on the device itself (an is accessible virtually instantly). This is very different than “traditional” browser based web-applications, where the View Controller is hundreds (or thousands) of miles away on a web server—something made even worse when a smartphone is trying to ping a server over a 3G (or worse) mobile connection.

However, over the past 2-3 years, several JavaScript (JS) frameworks have been developed that solve this problem. All of these frameworks were created to simplify development of Single-page browser Applications (SPAs): rich web applications that approximate the interactivity of traditional “thick client” applications. They do this by loading MVC (or MVC-like) frameworks into the browser. This not allows browser-based apps to display updates without action by the end user; it also provides the secondary (and critical) benefit for mobile web apps of moving the View Controller from a remote server into mobile device in the hands of your customer:

Adding a SPA-oriented JS framework like Angular, Backbone or Knockout embeds a MVC architecture in the hands of your customer, just like a native mobile app does.
Adding a SPA-oriented JS framework like Angular, Backbone or Knockout embeds a MVC architecture in the hands of your customer, just like a native mobile app does.

As result web apps on a smartphone, tablet or desktop can be just as fast as native mobile OS apps. Several JS frameworks are available to achieve this. Google first developed Angular.js in 2009. Steve Sanderson of Microsoft developed Knockout.js a year later. Jeremy Ashkenas also developed Backbone.js—a favorite of many eCommerce and consumer web companies—in 2010.


This technology stack does not allow for completely offline operation, something that is possible to achieve with a native mobile application. If you need to support offline operation (for extended periods of time) without losing any data, you will still need to build a native mobile app with an embedded SQLite database. However, that is not the use case more the vast majority of mobile apps.

Credits & Disclaimer

This author of this post used to lead technology at CustomMade Ventures where we have used HTML5, Sass, jQuery Mobile, Backbone.js and Django Mobile to create a mobile web experience for ideation and collaboration for our two-sided marketplace. Translation of this architecture into reality is the work of two great members of our Engineering team: Brendan Smith and Mike Manning.

An Opportunity Missed: The Olympics-as-a-Platform

Article first published as An Opportunity Missed: The Olympics-as-a-Platform on Technorati. Embedded video of “Rethink Possible” added in this blog post.

The Summer Olympics are very special. Every four years, for over two weeks, people all over the world (even those who are not normally sports fans) spend hours every day engrossed in the innermost details of dozens of sports—at home, at work, at school and at play.

However, in 2012 the IOC had opportunities never seen in any prior Summer Olympics…

olympic_open_data_280pxThis year was not just the first Summer Olympics since social media, multi-media mobile phones, and smart phone (and tablet) apps have become the ubiquitous means that over a billion people use to find and share information, opinion, photos and video globally—and instantly. It was also the first Summer Olympics since the rise in use of Open Data Platforms and Apps Competitions to tap the innovation of thousands of people to create better ways to access information (without adding the cost and complexity of hiring thousands of designers, developers and testers).

The IOC could have taken advantage of this by doing four things:

If the IOC had done this they could have created the biggest, most exciting Open Data and App competition we have ever seen. Not only would this have tapped into the innovation of tens of thousands of developers, it would have harnessed competition between teams who wanted to highlight the technology strength of their countries, their love of their country’s history and culture, and their passion for the athletes representing them in their favorite sports.

Imagine what kind of Apps this global technology could have created:

  • Apps written by ex-gymnasts that combined athlete bios and explanations of events and rules with (official and fan) video of preliminary rounds and the World Championships. Apps that even let the audience score what they saw in real-time.
  • Apps combining location-based data with captured photos and video along the entire 26-mile, 385-year course of the marathon, letting you play back key parts of the race, see every part of the course at once, and cheer on runners via Facebook and Twitter
  • Fantasy Olympic Team apps that let you assemble your own dream team for events and compete with your friends—or globally in the Olympic spirit
  • Training gamification apps that let you record and visually display your running and swimming times (like Nike’s training apps) to understand in new ways the tremendous the speed, strength and endurance of Olympians

AT&T’s Rethink Possible Ad: Imagine if the swimmer did not have to write down the new record (and instead an App logged his times and showed them again every record Olympic Record—and every qualifying round—back to 1896)

Apps like these would have made these Olympics more interactive and participatory than any in history. While we did not get this in 2012, I am keeping my fingers crossed for a 2014 Sochi Winter Apps Competition, and perhaps an even 2016 Rio Summer Apps competition.