A Hands-on Look at Our Touch First Design

We’ve explored tablet and Touch First design in a previous post, but we haven’t gone into much depth about what it takes to make the design a reality. Eight months ago, we set out to create a website for our new brand. Actually, we crammed about twenty people who make websites for a living into a room and asked them to make it happen. This post explores the process we used to build our new website and sheds some light on what it takes to bring a Touch-First design to life.

The Business Needs

We kicked off our project the same way we start all client projects, by defining the business needs.  And, as with most companies, we had a mix of stakeholders from various departments who all had very specific requirements they wanted us to meet.

1. The Creative department proposed an app-like, touch-first design
2. Creative tech insisted on HTML5 and was interested in Responsive Design
3. Analytics wanted distinct URLS for each page
4. Digital Marketing needed it to be SEO-friendly
5. The Product team and senior managers wanted it to be CMS-powered
6. Senior management wanted it delivered on-time (of course)
7. And everyone wanted the site to fulfill the audience needs

The Process

Next, it was time to define our process. Since this was an atypical project, we devised a roadmap specific for our responsive, Touch First design. That meant an iterative approach and some revisions to our more traditional steps and milestones.

1. Management/business needs
2. Strategy
3. IA, creative design and copywriting
4. Prototyping
5. Design completion
6. Creative development
7. Technical development
8. Responsive QA

The iterative approach meant that we repeated steps 5, 6, and 7 multiple times as we reacted and adapted to curve balls and challenges.

Getting Started

The inspiration for our site was the latest generation of tablet and mobile applications. We wanted to have an app-like look and feel, but on the web and without Flash. Our IA and design teams built wireframes and designs at three breakpoints – phone, tablet and desktop. This helped level set expectations across platforms. Once we settled on a design, we turned to our Creative Technology team for prototyping.

Prototyping

Taking the business needs to heart and working off of some early design sketches, our Creative Technology team sat down to weigh the concept against what was possible. Reconciling the business needs was a process that included a lot of research and testing of ideas. We tried a variety of options and ended up with a prototype of the functionality. What follows are descriptions of some of the technologies/techniques we eventually settled on.

One site for every screen

Responsive websites respond to their environment using adaptive or fluid approaches. Using CSS3 media queries in addition to device detection (WURFL) and feature detection (modernizr), we are able to target how the site looks across multiple devices, browsers and screen resolutions. The purpose of media queries are to apply different rules to achieve different layouts for specified viewport widths. This is achieved by using the @media rule in css3. Don't just take our word for it. Check out theprimacy.com on your desktop and mobile devices.

We've got Backbone

We needed a full framework to manage the site, so we used Backbone.js with Marionette. That gave us functionality like routing, templates and data-binding. Implementing those tools gave us the structure necessary to build clean, scalable code.

pushState

Looking to our business needs, we knew the site needed to be SEO and analytic friendly. This is difficult with traditional hash tag AJAX development, so we switched to a new browser functionality called pushState. PushState allows us to change the URL of a page in the browser as the user navigates—without the need for a page refresh. What’s the big deal? We still have the smooth, animated transitions as people navigate through our site. We also keep the ability to share individual pages, like the careers page or a case study. The big improvement is that we don’t lose the ability for Facebook or search engines to track those pages separately.

What the WURFL?

We utilized WURFL for mobile device detection. It’s a software repository for devices that helped us make sure we were considering the user’s interface, screen resolution, etc. Since bandwidth is still at a premium on mobile networks, we’re not sending the user more data than they need. For example – the server responds to image requests with a version of the image optimized to meet the constraints of the user’s device.

Bridging the Gap

Building the prototype provided us with the proof of concept needed to move forward. From there we began to transition from static HTML pages to feeding the content of the site from the CMS. Stay tuned for Part 2 for details on how we brought it all together. This post is a collaboration of ideas from several people, namely, Jordan Wilson, Jacob Bell, Chris Lagassey, Melissa Labbe, Greg Bradley, Kevin Middendorf and Kurt Gannon.