If you ever check our Facebook page, you may have seen an image of the finished product for the new Ziggy Denim website.


The site is powered by WordPress, fully responsive, and is cross-device compatible.

We took cross-device compatibility to a whole new level on this project to ensure the website was almost exactly the same on all common desktop and mobile devices.

In the beginning

We were approached by the team behind Ziggy Denim in June who told us they were chasing a developer for their new website. The company has a highly talented in-house design team which was fantastic to work with.

Stepping through the initial planning stages

Planning for a big website is always a difficult task, and things almost always change mid-way into development.

We sat down together and went over the proposed design, their ideas, and their vision of the completed product. We tackled common issues such as

  • Web-safe fonts
  • Common web safe image dimensions for the proposed site
  • The translation of the desktop design into a mobile friendly format

For the main website copy, we ended up rolling with Alternate Gothic No.3, delivered and licensed by TypeKit. It matched the design, is considered web-safe (for modern browsers) and a license that fitted the criteria.

We also decided that eMarketeer would take on the role of translating the desktop design into a mobile friendly responsive website.

Starting the development

On such a large project, we spent almost an entire day purely planning exactly how we would develop the site

  • How we’d utilise and structure CSS
  • What javascript libraries we would use to match the required components
  • How we’d structure the WordPress development for easy updating
  • The best dimensions and breakpoints to use for the responsive design aspects of the project

The planning decisions

As usual, we utilised SASS as a pre-processor and management platform for the CSS.

We decided to go back to basics with javascript, and only use one library (jQuery). The website was too specific and unique to try and utilise other libraries, so we decided we would program our own functionality to directly fit the site.

It was decided that for the WordPress development of the site, we’d draw up some custom post types and taxonomies best suited to the content.

Developing the site

After writing the front-end code for the splash page, we went ahead and wrote a generic page template for the site that would serve as a multi-purpose boiler plate.

All of the content pages on the site (except some archives) required a flexible, height adjusting <div> element that allowed the content to scroll horizontally.

We avoided a bunch of headaches by developing the generic content page template before we got too deep into adding content or integrating WordPress. We developed it, tested it on multiple devices, fixed it, tested it (And so on) until we were satisfied the functionality was spot-on.


The primary stylesheet for the site quickly reached just under 1,000 lines of SASS. This would have been frighteningly higher if we didn’t utilize a pre-processor.

The meeting of the front end and back end.

Everything went according to the plan when we started to integrate WordPress – the splash page and its slider worked a treat, and the generic content template slotted perfectly around the content we populated in WordPress. Talk about a text book planning scenario.

Finding unforeseen issues

A bunch of the pages to be included in the site ended up having more required data than we previously realised. This included information such as sizes, available colours, and photo information.

We decided the ideal scenario to future-proof our development was to utilize some WordPress meta boxes, with some specific meta fields setup on a product type basis. This would allow future additions to the content / product range without issue.

Another issue uncovered was the fact that the website needed to run on the same WordPress installation, utilize the same content, but have small differences between the local and international branding. We spent some time searching for an “out of the box” solution to handle this, but ended up settling to write a small custom plugin and child theme that managed this.


A demonstration of the product meta boxes

Mapping a domain to a theme

We wrote a small WordPress plugin to detect the current URI that the website was being accessed by, either ziggydenim.com (AU & NZ) or zeegeewhy.com (US). Depending on the result, the plugin re-routes the active theme to either the parent or child, allowing the website to change its content around some pre-programmed filteres to suit.

A snippet of the domain theme mapping plugin we wrote

The big testing phase

Being a larger brand and website, we were really tasked to have the site looking uniform on all modern computers and mobile devices.

We utilised BrowserStack for a bunch of testing, as well as bringing in all the devices we could get our hands on for further testing.

We spent a lot of time fixing bugs and making everything look uniform to a satisfactory level.

The finished product

We were all very pleased with the results, and after a few further modifications and tweaks, were ready to push the site online.

The feedback received from the public was very positive – we even had a development enquiry the day after we launched by an impressed customer.

You can view the finished site by going to http://ziggydenim.com , or having a look in the viewport below.