Airtype Rebuild – Part 1
In this post, we’ll be breaking down the techniques and technologies we used to create our recent updates to this site, as well as our new shop at ShopAirtype.com.
Below is a bird’s eye view of some of the changes we made to improve mobile support and page load speed.
Why the redesign?
Since the last version of our site had only been live since August 2011, it was very easy to feel content that it was meeting our needs. It looked great and got our message across. So why did we start over just a few months later?
After being “in the wild” for a while, we kept seeing the same few issues pop up. The site looked great on our giant monitors, but mobile/touch users were forced to suffer through slow load times and an interface optimized for bigger screens. As mobile web browsing continues to explode internationally, we knew we had to start factoring in these devices immediately.
As we continue to grow as a technology company, it’s become increasingly obvious that our sites must perform to the same standards we set for how they look. We’re not doing any favors by slowing a portion of our users down. This had to change.
Learning to adapt
Our first challenge was finding a way to deliver an experience optimized for every device that hits it. There are several approaches to this problem, each with its pros and cons.
→ Dedicated Mobile Site
One of the more common solutions at the moment is to simply create a completely different experience for mobile devices. On the surface, it’s a pretty solid method, and it’s especially well-suited to sites where visitors are looking to perform specific actions — checking a bank balance or making airline reservations, for example.
This wasn’t practical for a site like ours for several reasons. First off, people visit us for the content. They want to know who we are, what we’ve worked on, and how to get in touch with us. If we cut these pages out, we don’t have much of a site left.
More importantly, there’s still no way to know what type of mobile device the visitor has. If we build a mobile site that works great on iPhones, how’s it going to look on a Blackberry? What about the tiny Nokia screens? What do they get?
To make a site that works well across a broad selection of mobile platforms, we’d have to build 5 mobile sites. Clearly this isn’t ideal.
→ Responsive or Adaptive?
Responsive Web Design is all the rage right now, and rightfully so. In a responsive layout, the page resizes fluidly no matter your screen size. This is an excellent technique, but can leave a lot of room for guesswork unless you’re a math wizard (and I’m very much not).
Adaptive layouts, on the other hand, use responsive principles minus the fluidity. This means that, while a responsive site will scale to any size at all, its adaptive counterpart will serve a different fixed-width layout for each of four different screen resolutions (you could use more than this, but that’s where we stopped).
(For an explanation regarding Adaptive vs Responsive, read this post.)
This allows us to write and maintain one codebase for the entire site while meeting the screen requirements for just about any device you can imagine. We’ve set break points at widths of 320 (mobile), 480 (small tablet), 720 (iPad, large tablet, smaller monitor), and 960 (everything else).
If you’re looking at this post on a computer, resize your browser width to see the changes happen in real time. It’s not only an awesome effect; it makes our site look great no matter how you got there.
→ Getting started with Adaptive Layouts
Not wanting to reinvent the wheel, we started this approach by building the site using the Skeleton Framework to handle the resizing. It didn’t take long for us to learn that trying to shoehorn your design into someone else’s framework can stifle your creativity and force you to make some unwelcome concessions.
The search for another toolset let me to the Less Framework. In this framework, rather than each column changing width, you simply lose columns as the page gets smaller. This worked with my workflow a lot better, but I wasn’t crazy about their default units, so we built our own framework on top of Less, giving us a perfect starting point for every project we do going forward. This is a great example of why it’s a good idea to experiment every chance you get. You never know what you’ll create that improves your entire workflow.
Expect us to release our framework, along with a jQuery grid tool, as an open-source project later this spring.
Our other mistake was underestimating the value of page load speed. There are any number of studies suggesting that users simply won’t wait for your page to load before moving on to their next site. Also, Google is now penalizing sites for being slow to load. With speeds being slower on mobile devices, there’s no better time to get serious about page performance speed.
We found the most impact on loading times by repeatedly asking the question “is this necessary?”. Did we really need that hefty drop shadow image there for the site to look good? Is that textured background image worth the amount of time it takes to load? Do we need to load this jQuery plugin on every page? In nearly every case, the answer was a resounding ‘no’.
→ Progressive Enhancement
If the device allows CSS3, for example, now we can add texture, shadow, depth, and animated transitions to page elements in just a few lines of code. We used to use images for these to make sure everyone could see them, but it increased the amount of data needed to view the site well more than was necessary.
If your browser doesn’t support CSS3 (Internet Explorer 8 and before, for example), you’ll see the mobile version of our site with a friendly reminder that there’s a better browsing experience available if you upgrade to a better browser.
The beauty of progressive enhancement is that it lets you make the site work anywhere and rewards newer equipment with a very rich experience.
→ Shedding the weight
Our last site combined the flexibility of ExpressionEngine with the more user-friendly WordPress. This made development a little quicker but the technological limitations were really bogging us down. With the new build, we stuck exclusively to WordPress for our website and to Shopify for our online store. Wes built a whole new method for programming in WordPress to make it nearly as flexible as ExpressionEngine while giving us the freedom to keep all of our content in one place.
→ The race is on
Looking back at our old analytics, our August homepage took 10 seconds to load on average. Our new average load time for that page (and every additional page over both new sites) is just over 2 seconds – even though it now has code to make it work over four different page sizes. We expect this to help our visitors have more time to learn about Airtype’s products and services and to increase our new customer conversion rates.