We recently redesigned the WegoWise website and whilst doing so I approached some common problems a bit differently than I have in the past. This article is about how I tried out some new tools and techniques to create mockups, organise my code and write breakpoints (for responsive web design).

I ditched Photoshop in favour of Sketch

There are so many reasons why this made sense but here are a few of the key ones (Disclaimer: Sketch is a Mac-only application):

Price!

Sketch costs $79 to download, Photoshop costs $239.88 for a year (based on the price at the time of writing for one years subscription to the Creative Cloud for one full application).

Export to SVG option

It’s a format that I think there’s no avoiding in modern web design and for good reason.

Small file sizes that can handle a lot of layers before slowing down

I always found that large Photoshop files would get very unwieldy, slow to open, slow to save, slow to move groups of layers around...just about slow everything. That doesn’t seem to happen with Sketch: the mockup of the homepage with the illustrations of all the buildings is only 5MB and dragging or resizing groups of layers around is never a problem.

Linked layer styles

Sure in Photoshop you can lock files together and then “Select locked layers” and paste your layer styles, but it’s fiddly. Sketch handles this in a very elegant way and layer styles on linked layers are always kept in synch.

Everything is a vector

It makes sense that everything except a bitmap image should be a vector when you’re designing mockups. It means you can easily export a larger version of your artwork for retina screens, zooming in always looks great and if you decide to change the size of your design later it’s not an issue.

I could keep going. There are so many features that make me prefer it over Photoshop for UI work, like the way it handles exporting assets, the built in grid tool, artboards, its superior text rendering and the infinite canvas to name a few. It is worth mentioning that Sketch is not a bitmap editor and doesn’t try to be, for that you will probably still need to rely on Photoshop or some equivalent.

We built our own Compass framework

I’ve used Compass for a while now but this was my first experience building and using a proprietary Compass framework and so far it seems an ideal way to share styles among our different websites. You have to think a bit harder about how to break up your styles and make sure that all your common styles end up in the gem and not mixed in with the site specific styles. This lead me to create a guideline on how our stylesheets should be organised across all our sites and the framework. Check it out and maybe you’ll find it useful for your own projects:

scss/
|
|-- utility/
|   |-- mixins.scss
|   |-- placeholders.scss
|   |-- variables.scss
|   |-- ...
|
|-- base/   # Generic styles not attached to specific pages or components
|   |-- fonts.scss
|   |-- icons.scss
|   |-- reset.scss
|   |-- type.scss

|   |-- ...
|
|-- layout/  # Generic styles that give structure to a page
|   |-- grid.scss
|   |-- footer.scss
|   |-- header.scss
|   |-- ...
|
|-- components/
|   |-- buttons.scss
|   |-- forms/  # Complex components could be split up into multiple files

|   |   |--base.scss
|   |   |--inline.scss
|   |   |--search.scss
|   |-- subheader-nav.scss
|   |-- tables.scss
|   |-- ...
|
|-- views/   # Page level css
|   |-- home.scss
|   |-- tour.scss
|   |-- _about.scss
|   |-- …

We turned our Compass framework into a Ruby gem and keep it under version control at GitHub but if you want to create your own framework for personal projects and you don’t need to distribute it among a team it’s a very simple thing to set up that could save you a huge amount of time in the long run. Here’s a good intro video from Chris Epstein (creator of Compass) to get you started and if you decide to go down the route of turning it into a distributed gem then be sure to take a look at the guidelines for Compass extensions.

I started using meaningful breakpoint names

The site redesign involved quite a few breakpoints: horizontal breakpoints, vertical breakpoints and pairs of breakpoints. Keeping track of them all and what they meant was getting pretty tricky so I tried out the breakpoint gem from Team SASS and it helped keep things sane. Some of the breakpoints are still very general eg.

<a href='https://github.com/include' class='user-mention'>@include</a> respond-to(‘between narrow and widest’) { ... }

Which you could also write like:

<a href='https://github.com/include' class='user-mention'>@include</a> respond-to(‘portrait tablet’) { … }

Other breakpoints were very specific and I could tell at a glance what they were for, this is where the breakpoint gem really comes into its own, eg.

<a href='https://github.com/include' class='user-mention'>@include</a> respond-to(‘compact pricing table’) { … }

This was a tremendously enjoyable project for me to work on mainly because it involved such a wide range of skill-sets. My time was spent between creating illustrations in Sketch, preparing mockups of the main pages, sitting in on brainstorming sessions for the written copy, organising styles into a reusable framework, writing the front-end code and learning how to integrate it with Ruby on Rails...all the while fighting with Git and the command line as only a designer knows how.