Since the release of the iPhone we have struggled with best practices when it comes to designing and developing for mobile. We’re going on four years, and while we’ve made great progress, there is still a lot left to be desired. “Responsive Design” is the hot topic. With media queries it is so easy to take an existing website and reformat it for a mobile phone or tablet, or you can design something that is truly flexible so that it looks great on any device. While this is a fantastic new method of doing things, and will solve all of some people’s problems, it is not the only solution.

By working with content APIs, designers (who code, you code right?) can deliver unique user experiences to a range of devices without the "hacking" that is involved when using media queries. By hacking, I mean all the showing and hiding of content depending on the device, which often results in loading a ton of data that is useless to the viewer (images, background images, specific javascript, etc). A unique, tailored experience is a better experience for your customer.

Content first

We design for content. Content that is (hopefully) accessible across all devices. So let me ask you: does your design achieve the same goals when viewed on a mobile phone? Does your information architecture solve the problems for a customer on the go? Are you loading unnecessary content and toggling it visible or hidden depending on the device? No matter the answer, I hope to give you some things to think about.

When I switched from table-based markup to semantic markup and CSS (thanks to one Jeffrey Zeldman) I convinced myself that for the rest of my life I would write thought-out, semantic markup and never have to worry about it down the road. We would adjust our layouts later in CSS, right? Write once, view everywhere. This method worked great for a long time. Now that we actually have multiple devices to deliver content to we’ve found ourselves in a rut. My image-heavy homepage doesn't work in a mobile browser. My text-heavy homepage is pointless in a mobile browser. My navigation with all those dropdowns is a pain to use in a mobile browser.

Now, of course you can change the presentation of all this information using media queries, but do you stop to think about all the data you’re asking your viewers to download when you may be only presenting 80% of that to them? Let’s take a pharmacy like CVS (not Walgreens, I’m from New England and have pride). A pharmacy's mobile site should be very different from the desktop counterpart. As a customer you probably expect to see the closest location at the top of the screen with a phone number, and the hours they're open. Then maybe you’d want a list of action items such as refilling a prescription, or checking if your photos are ready. This is all important (but not a lot of) information. Would you load the entire cvs.com and rearrange it using media queries? You could, but you'd be forcing the user to download more data than necessary, resulting in slower load times and a less focused design.

A different solution

There are probably a hundred different ways organizations solve this problem; some develop entirely separate mobile sites, some go the media query route, some decide to deliver the same desktop experience and that’s where they stop. Using content APIs, you can build both mobile and desktop applications/websites using the same content and underlying system, but serve different markup that's tailored to each browsing experience. Now, I am not going to dive into what a content API is as my colleagues can do that much better. I am going to tell you how we approach design and front-end development.

Think about where else your content is going to live. Are you going to have a native iOS app? Android? How about on the Apple TV or Roku? Will people want to view it on their mobile phone and tablet? The answer to all these questions is without a doubt, yes.

With content APIs (and any API in general) we can quickly develop multiple applications off of the same data source. We can design and develop a big, complex application for a pharmacy or bank for the desktop, and then, with access to the same exact data, build a simple, stripped down version for mobile. We can do this using any technology we want, and usually with way less development time.

On the frontend it's an entirely new ballgame. New libraries are popping up constantly focusing on client-side rendering (here's a great related article), backed by APIs. A great tool we've been using is Backbone.js. We believe it helps us create the best experience possible for not only mobile customers, but also for the desktop. Tools like Backbone fit into the approach to software design that I find most efficient: serve content and layout separately, serve layout based on the device (or user agent), do all of this on client side.

I've been thinking a lot about the perfect CMS (who hasn't?). As a front-end developer I require one thing; I want direct access to the objects I will be manipulating and displaying. I don't want to ask the backend developer for help (which is a constant in Drupal theming), I don't want markup being served out of the CMS (Drupal), and I don't want to assume the content being served up is for a web browser. Imagine drawing out your models in a UML diagram, hitting 'Save', and having all of that data available to you as JSON. This allows simultaneous development of mobile apps, desktop apps, websites, and mobile sites that are all rendering that content on the client side. This means less back-end development time. Front-end developers and designers that have direct access to the content they need can build a multitude of unique user experiences quick and easy. This is also known as profit.

Think about where your content is going to live. Are you going to have a native iOS app? Android? How about on the Apple TV or Roku? Will people want to view it on their mobile phone and tablet? The answer to all these questions is without a doubt, yes. It’s time to think about the most efficient way to bring a unique experience to each device without being limited by the devices themselves. By implementing content APIs into your project you give your team (or client) the tool they need to rapidly craft custom experiences for each device, resulting in true responsive design.