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.

As it seems to be with all popular pieces of software, there are several major misconceptions a lot of our Melbourne clients seem to have regarding WordPress.

1. WordPress is just a free blog that anyone can sign up for

Reality: WordPress is actually open source content management software. The sky is the limit when developing WordPress websites or applications. It can almost be thought of as a web framework.

2. WordPress is insecure, and your website will get hacked

Reality: Any piece of software can be hacked if it’s not configured correctly. WordPress should be configured by an experienced professional.

3. All WordPress sites look the same

Reality: WordPress powers almost 50% of all of the current websites on the internet. A large majority of those will buy pre-designed “themes” to save costs. This doesn’t mean that your WordPress site has to look the same. WordPress sites have no limitations on how they look.

4. WordPress has poor performance

Reality: Does a cars engine run well without being serviced? WordPress requires configuration and maintenance to perform well and handle high traffic, usually by an experienced developer.

5. WordPress can’t be very good if it’s free

Reality: Almost all of the worlds infrastructure runs on free software. Free & open source software usually outperforms commercial software, and it’s written by some of the most talented and influential people in software.

Often when a web developer gets busy converting initial design concepts into a functioning website, there’s a bit of a struggle comparing the original artwork to the product that is actively being developed.

Sure, you can take a screenshot of the project every time you finishing coding a module, and overlay it in Photoshop to see how it compares. The only problem is, this is a time consuming process.

A simple solution for a simple problem

We’ve gone ahead and written a super basic piece of javascript to overcome this problem. Here’s the basic idea:

• The developer saves a flat image of the artwork
• The javascript binds to a key (in our case, we use the z key)
• When the key bind is triggered, the flat image is placed as the body elements background, and all other elements inside the body are set to 50% opacity.
• Triggering the key bind again will set the page back to normal. It’s great for quick switching and comparing.

Although a super simple concept, this little trick has improved both our development accuracy and development speed.

An example

Here’s an example to show how it works. (The title is deliberately out of place to show the accuracy of this development method).

Press the “result” table, and then press the Z key to trigger the overlay comparison.

An important aspect of planning a new web project is the initial rough draft, or, as the industry tends to call it, wire frame.

Wire frames allow the designer to effectively communicate how they plan to lay out a web project. This is a brilliant way to experiment, and quickly pick up any issues that may arise in the user interface.

Why use wire frames? Why not just design the site from the beginning?

When used with appropriate software, wire frames are super quick to work with, keeping the cost of the project to a minimum. Major changes can be processed with minimal effort and time, and provide instant feedback on the user interface.

What wire framing / UI prototyping software is available on Ubuntu?

As a keen Ubuntu user in the web development industry, it can sometimes be tricky finding appropriate software for designing and prototyping.

With the power of HTML5 now dominating the internet, you have no limits to what apps you can run in the browser.

We’ve trialled three different browser based wire framing web apps, all of which have been fantastic.

• Moqups 8/10 – Free trial, $9 per month
• Balsamiq 7/10 – Free trial, $79 lifetime
• Mockflow 9/10 – Free, $19 per month

Going native

Browser based apps aren’t always suitable, especially for older computers. Thankfully, there are a few native desktop options on Ubuntu for wire frame sketching.

In house, we use WireframeSketcher, at a cost of $99 per license. It’s fast, robust and very flexible.