Responsive Interview with Terabyte NZ

This week we’ve got back in touch with the clever folk over at Terabyte NZ.

They originally got in touch to let us know about the go live of NZ Trade and Enterprise site which was featured as the site of the week in week #57. Based on the very well built site we sent off a few questions to the team and these are the answers they came back with.

Big thanks to:

  • Steve Martin (Creative Director)*
  • Anne Ang (Art Director)
  • Pat O’Callaghan (Lead Frontend Developer)

*no, not that Steve Martin

Why did you go responsive, was it the client or did you push it? Did you run into any barriers with the client and how did you over come them?

There were two main drives for using responsive design in the New Zealand Trade and Enterprise (NZTE) project. Firstly, the project needed to be forward-thinking in its construction. Secondly, NZTE wanted to reach the widest possible audience with their content, which had formed the basis of their interest in having a responsive website.

Indeed, we were extremely fortunate that NZTE understood the benefits of responsive and how the online medium is changing. NZTE are particularly content-focused and had done their homework in what their audiences needed, so the biggest challenge was predicting timeframes and budgets.

We also were able to establish an open and collaborative process between our internal team and NZTE. We couldn’t use the old traditional waterfall process as with previous projects so we researched and introduced techniques such as style tiles, took away any “big reveals” and brought the client on the journey by providing snapshots of the development in progress for feedback.

During the design process were there any great challenges, and if so how did you over come them?

As responsive design is relatively in its infancy, finding the best workflow for our team was a challenge. We have been designing websites for quite a long time so change isn’t always easy to introduce. However, with a few internal discussions (aka butting heads) we found a good balance of design via Photoshop for the visualisation of large and mobile views and prototyping with iteration for the in-betweens via code.

So there were still some valid parts of the waterfall process but we now have a hybrid version that embraces the agile.

The one thing that responsive design has highlighted more than anything else for us is that you cannot make things 100% perfect. This is probably one of main reasons why you try and get the designs into code as quickly as possible and see first-hand how elements behave. Will those fully content-managed, perfectly vertically-stacked pods look that perfect when they tile horizontally on smaller views? Probably not. Embrace the imperfections; it’s so much more real and you won’t drive yourself insane. Knowing all the tricks comes with experience, and as our industry builds more and more responsive sites, these learnings can be shared and built upon.

Same question but for the build process, did you find that things that were designed didn’t work in the browser and how did you change your approach?

While wireframing and prototyping in the browser is fine, the sooner you check your site on a variety of devices, the better. In the early stages of design we wireframed several breakpoints for the main navigation. However, once we got it onto a device, we found we didn’t need some of the breakpoints as some “views” looked fine and didn’t need to change to a different layout. In addition to this, some elements looked fine in a down-sized desktop browser but once viewed on a tablet or phone it wouldn’t look or interact correctly. Making heavy use of Adobe Edge Inspect to test across devices made this much easier, as well as harassing people in the office to use their phones…!

We also tried to break out of the “320px, 768px and 1024px” mindset during development. When building we would have our viewport size set at random widths as this allowed us to spot layout issues earlier. Brad Frost’s ish. bookmarklet is a handy tool for this.

As IE8 doesn’t support mediaqueries we were initially going to use a JS polyfill, Respond.js, to give it the responsive experience. In the end we decided to serve IE8 a fixed-size stylesheet. We assumed the majority of users on IE8 don’t need a responsive site, and JS performance in IE8 is bad enough without us adding onto it. We used the Respond-To Sass plugin to manage our mediaqueries. It easily allowed us to build a separate stylesheet with no mediaqueries for non-supporting browsers.

Did you employ any helpful JS libraries to help you along the way? If so what did you use and why?

Some of the libraries which were integral in building the site were:

  • RequireJS. Over time we’ve been experimenting with making our JS more modular but this allowed us to jump right in. It allowed us to write small, concise (AMD) modules which kept track of their dependencies, making them easier for reuse in future projects. It meant we didn’t have to be messing around with manually ordering all of our script tags or trying to determine what JS had loaded on the page already. We started using it on our first responsive site and this made it easier to cherry-pick what we wanted and drop it into NZTE. RequireJS also has the added benefit that it allows you to asynchronously load JS, similar to YepNope/Modernizr. This meant smaller viewports didn’t get served JS built for large/widescreen views.
  • Enquire.js. To determine when to load our JS modules we used Enquire.js. This is a great library which allows you to manage your breakpoints by triggering events as you enter or leave them. It made it easy for us to load different functionality at different screen sizes or turning them on/off as we move between viewport sizes. The main navigation would be a good example of this.
  • appendAround – This is a really simple but very useful library from the guys at Filament Group. It allows you to change the source order of your HTML depending on viewport size. One place we used it was for the subnav on detail pages. On small views the subnav would appear at the bottom of the page, but on the larger views it would jump up the source order so it would appear on the left hand side. You can see it in action here

Did you focus on device widths (ipad, iphone) or did you let the design dictate the break points?

There has been a lot of good writing in the last year extolling the benefits of device-agnostic breakpoints, and I think that rubbed off on us. From the start we didn’t try to set in stone what our breakpoints were. We knew what the widescreen view would look like, and to some extent what the mobile view looked like. But what happened in between, and at what point they shifted, was worked out through prototyping and collaboration. We ended up having 3/4 main layout breakpoints but then lots of others in between targeting specific components. Our general approach was: build the component in the browser, grab the browser window and drag; when it looked rubbish we’d add a breakpoint to tweak it.

We also used EMs for everything including breakpoints, font-sizes and for paddings and margins where it made sense. This means if somebody zooms their browser the media queries should still kick in and the layout shouldn’t break (Chrome may require a page refresh). Cloud Four have a good article on this technique. Using a CSS preprocessor like Sass made that whole process easier as we didn’t have to do all the nasty maths.

Did you take performance into consideration at all?

From the outset we didn’t want to build the site like we traditionally would. We tried re-evaluating what is loaded on the page and these are several techniques we used to minimise the page weight at page load.

  • We built the site “Mobile First” so CSS assets for larger viewports weren’t loaded on smaller ones.
  • We lazy-loaded images. Images are either loaded on page load or are as you scroll down and they come into view. Also with rotators and carousels, we didn’t load all images by default. We only load the next image as it auto-rotated or once the user interacted with them.
  • As mentioned earlier we used RequireJS to conditionally load JS
  • We decided against using ShareThis or AddThis as they add a lot of bloat to the page. Each of the major social networks allow you to share using simple urls or OpenGraph tags so we decided to do that. When the user clicks the icon, it just opens in a popup or in a new window on smaller views.
  • Blindly including YouTube video embeds on your page can add a few hundred KB per video, even if the user never watches them. We wanted a better solution so decided not to embed videos by default. Instead, we load a placeholder image and once the user clicks to watch the video, the relevant JS modules are loaded. These then use the YouTube JS API to load the video and autoplay it (Example). We also have YouTube playlists on some pages but these aren’t actually loaded until they scroll into view for the user. See an example here).
  • We did some crude UA sniffing to serve smaller images to mobile devices. Images traditionally account for most of the page weight so this helped alleviate that a little for smaller devices.
  • Cache, Cache, Cache. All our front-end static assets have a far future expires header as “the fastest HTTP request is the one not made“.

What are the key lessons that you learned that will be invaluable for your next RWD project?

  • Keep it simple. The more complex the designs are, the more breakpoints you will need to reshuffle components between viewports.
  • Building a responsive site can be a costly and time-consuming affair, taking much longer than a regular fixed width site. If you are going the custom route (i.e. no Foundation or Bootstrap), build with reuse in mind. You’ll end up building an internal framework and what took you “X” amount of hours the first time will take a lot less the next time.
  • The waterfall process we have been using for the last few years won’t work effectively here. Get designers and developers collaborating from early on, sketching and prototyping their ideas. The first phase is quite an iterative process.
  • Try to keep the client informed throughout the process and don’t have a “Big Reveal”.

Responsive Design Ebook

A collection of interviews, tips, tricks and some responsive sketch pages in one easy to download file.

Learn from more than 26 leading responsive design experts across more than 80 pages for the price of an expensive coffee. Or, think of it like buying me a beer to say thanks for sending you a newsletter each week…. plus you’ll learn tons too.

Buy Now for just $6.99

One Response to “Responsive Interview with Terabyte NZ”

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>