Tools arms race

Job titles are a good reflection of how complex the web industry has become. Only a few years ago we would call ourselves web designers, now we see titles such as UX designers and front-end engineers.

At the core of the web very little has changed. HTML, CSS and JavaScript still exists – sure there are some new selectors but the principles are the same. Complexity has been added on top of these in the form of tools. It’s now reached a point where many tools are considered a prerequisite to working on a website.

When was the last time you worked on a project that didn’t use jQuery? For me, a long time ago. It’s now assumed that you have an understanding of it to be able to work on a project.

We even have tools to run multiple tools. Codekit is a fantastic piece of software but it almost confirms complexity and over engineering of many of our projects and workflows.

Tools are good

Don’t get me wrong, tools are pretty damn awesome. People far smarter than me have built them to overcome a specific problem. They’ve helped me automate many of the mundane tasks leaving me to focus on the parts I enjoy working on.

Let’s take Gulp autoprefixer as an example. No one enjoys writing half a dozen browser prefixes to support gradients in every browser – hell, I’m not sure I could even remember them! Gulp autoprefixer solves this problem.

It’s not the tools but the implementation that is the problem. Continuing the example of Gulp autoprefixer – it has lots of options and understanding where it gets information and how it works is crucial to properly setting it up.

Choice anxiety

Fully understanding all of these tools takes a significant amount of time. It’s a big investment so you want to make sure you make the right decision.

A frenzy of panic ensues each time I need to choose a tool. Is this the best option? How difficult is it to learn? Will this be around in a years time? What is the most popular choice?

Take the example of Bootstrap vs Foundation. On the face of it they are very similar. They are both very mature tools and offer lots of functionality. Choosing one of these is a hard choice, whichever you choose has a significant learning curve to fully understand.

A quick Google of “Bootstrap vs Foundation” reveals how passionate people are around tools. Often it comes to down a matter of opinion or preference. They both do the job just fine. Like the authors of these tools, they have strong opinions on how they work, which creates cult followings.

Choose the tool that best suits the project and your requirements. Don’t choose based on the group who shouts the loudest.

Learning curve

Learning new tools is time consuming, it can take weeks to fully understand some. When working in an agency it’s very important to consider this when trying to implement new tools. The time to learn is multiplied exponentially.

Regardless of how useful a tool is, it’s completely useless unless the entire team fully understands how it works. Creating black boxes where code is thrown in leads to poor or even broken production code.

This is one of the problems with using tools. Because it takes so long to learn how to use them, we have a tendency to use them on every project – regardless of whether it’s required for that project.

I have fell into this trap myself. Using Sass and Gulp on the smallest of projects where plain old HTML and CSS have stood the test of time, work perfectly well.

Technical debt

Technical debt is the overhead for a project. The technologies, tools and information you need to know before you can work on it.

Let’s take the small project I recently worked on. For a small website using HTML, CSS and some JavaScript the technical debt is very low. Adding Gulp, Sass, imageoptim and bower_components to that project has increased the barrier to entry exponentially.

The technical debt of projects has never been more apparent than working in an agency full of designers, front-end developers, programmers and dev ops. The wide variety of people and skills opens your eyes to how complex some projects have become. Sometimes necessarily but often for the sake of complexity or self importance.

We need to be conscious of the learning curve involved to work on each project. Considering not just if but how each tool can help us. Keeping in mind the people who are working on the project, both now and in the future.

Scaring talented people away

There are lots of articles out there complaining that the web is starting to look the same. Regardless of whether you agree or disagree (and whether tools are to blame), we can all agree putting new people off joining the web industry is never a good thing.

Designers, students, hobbyists and new people to the industry must be overwhelmed by the sheer complexity, where to start and what to learn.

In reality all you need is a text editor and you could build a website. Searching Google and it’s buzzword bingo – Sass, Angular, Ember, Less, Gulp, Grunt, Bootstrap and the list goes on. None of these are required to get going, yet some encourage learning these from the outset. This results in learning tools rather than concepts and underlying languages.

Focusing too much on tools

How many of us have sat in front of our computers, on the verge of punching the screen because of an error compiling something? I definitely have and unfortunately it’s a common occurrence.

We have a habit of focusing on the process of building a website rather than the website itself. All this time spent writing and perfecting our processes means less time spent on the final website. I can’t help but think we’re neglecting the thing we’re trying to create in the first place.

Late to the game

I was very late to the game when it came to using CSS-preprocessors. Some people still don’t use them and that’s not a bad thing.

If you’re on the cutting edge you end up using new tools that are sometimes buggy and not ready to use in a production environment. In an agency environment this is a very dangerous place to be. Taking a step back and only introducing tools when you’re confident means you can avoid a lot of the pain that comes with these new tools.

Take Less vs Sass as an example. Many started using Less and have since switched to Sass which has become the more popular choice. Coming in later has meant we can skip this battle and learn just one tool, saving hundreds of hours in training the entire company.

Another example is compiling Sass using Compass and now Gulp. Compass was slow, very slow! Holding back on implementing new tools until we’re confident it can benefit us meant we could jump straight into using Gulp instead of going through the pain of 10 second (or more) compile times with Compass.

Tool legacy

Using tools are all well and good. They will help you now but what about in a couple years time. The web is a fast paced industry. Tools that are relevant now might be in a couple years.

Going back to the example of Less vs Sass. A few years ago Less was the dominant force, now Sass is. Soon even Sass will have it’s day being replaced by CSS pre processing. This is great for the progress of the web, terrible for working on legacy projects.

Not only do you have to learn the new tools, you have to remember all the old ones incase you ever need to work on those projects in the future.

It’s important to consider the legacy of a project in your technical debt. It’s possible that the tools you choose at the beginning will be the ones that remain attached to that project throughout the lifespan of the website. Are you happy to continue using these tools in a couple years time even if they’re no longer relevant?

Keep it lean and focus on the final product

It’s time to keep our projects lean and focus on the importants parts – the website. Consider every tool to make sure the benefits out way the technical overhead they bring. Educate everyone on the team how to use not just the new tools but the underlying languages they use. Don’t implement any tools unless everyone who will work on the project is happy to use them.

Online advertising has broken the social contract

I have always opposed ad blockers. Everybody has to make a living and adverts pay for thousands, if not millions of peoples wages. From someone who works in the industry I appreciate that adverts are a necessity for some websites.

The social contract

There is a social contract between website owners, advertisers and visitors. In exchange for great content, visitors should be happy to see some adverts.

This contract has been broken by all parties.

Advertising online has progressively gotten more intrusive. Advertisers found the humble text advert couldn’t grab peoples attention. This led to the use of images in adverts. This again didn’t grab peoples attention so they introduced gif and flash animations. Some even playing sound without permission or interaction with the advert. This is all before mentioning the speed impact.

This sort of behaviour from the advertisers has led to the despair of visitors and the creation of ad blockers. Website owners have a moral obligation to show adverts that are tasteful and not overwhelming to the user – after all, surely they want us to come back!

Let me show you can example of the Cnet website – with and without adverts.

Cnet with adverts
Cnet with adverts
Cnet without adverts
Cnet without adverts which is also 2 times faster

From the next version of iOS, Apple will allow advert blockers in Safari. This has understandably outraged publisher and website owners. They only have themselves to blame. Visitors have been forced to seek these tools as a way of returning the web to it’s natural state.

Death to bullshit

Brad Frost recently created Death to Bullshit. It’s a fun little website with a serious message.

We’re bombarded by more information than ever before. With the rise of all this information comes a rise of the amount of bullshit we’re exposed to. Death to Bullshit is a rallying cry to rid the world of bullshit and demand experiences that respect people and their time.

As designers, developers and website owners we have a moral obligation to respect people, their time, our industry and be sincere.

The social contract has been broken. I am slightly ashamed to say I have now installed an ad blocker.

Progressive design for the modern web

A couple weeks ago I was featured on Web Design Depot. The article was about progressive design for the modern web. In the article I talk about the changes to design and front-end development processes at iWeb.

Here is a brief snippet from the article.

Good responsive web design, by its nature, goes unnoticed to those consuming content online. So when someone asks for a new website, they’re often completely unaware of the concept, despite experiencing it on a daily basis. And yet, responsive website design is now acknowledged as standard practice throughout the industry.

Building responsive websites has altered our processes, from creating mockups of complete pages, to building libraries of reusable components and layouts.

Read the full article on Web Design Depot

The easier my life becomes, the higher the barrier to entry

As an industry we love automation. Seriously, we’re obsessed with it! It sometimes feels like there is a new thing each day I step into the office.

That’s not a bad thing, in fact it’s pretty damn awesome. The web industry is fast paced. It’s one of the reasons I fell in love with it. It completely satisfies my short attention span.

A few years ago I could never imagine running a script that would:

  1. Allow me to create organised CSS which could be compiled.
  2. Check for syntax errors in CSS and JavaScript.
  3. Prefix my CSS to support older browsers.
  4. Minify and concatenate my CSS and JavaScript.
  5. Optimise all the images!

And in a blink(ish) of an eye!

All these tools and libraries have made my life easier but the barrier to entry has never been higher. Learning the tools to develop front-ends is now as big a part as learning the front-end languages themselves.

If a tool makes my life easier, I am always up for trying it. There would be nothing better than halving the time I have to work. Who doesn’t like lying in a hammock sipping rum old fashioned.

I am sure most front-end developers share the same view, if not maybe with another preference of drink. The problem is these new tools often require learning new languages or libraries. It’s a double whammy.

New tools are only beneficial if the entire team understands how to use them. It doesn’t matter how useful a tool potentially is, if it doesn’t have the buy in from everyone it’s completely useless.

A magic black box where code is thrown into and mystical things happen is never a solution. Everyone needs to be part of the decision to implement them. Everyone should understand how these tools work.

Share knowledge. We can all learn from and help each other.

How commuting affects my mood

Like many, I commute to work. My average commute time is around 40 minutes each way. Previously it was nearly an hour before changing my work hours to avoid traffic (thanks iWeb!).

Sitting in a car by myself can be the best and worst thing. Often my commute will affect my mood for an entire day.

Like most creatives, web designers are a temperamental and erratic bunch. I’ll often go from elation to devastation in a matter of moments. It’s what makes us good at our jobs. We connect with our feelings – if not a little too much sometimes.

Ideas machine

A benefit of commuting is the ability to think and reflect on the day ahead. Many say sitting on the loo will encourage ideas – commuting is my idea factory. Plus uses less toilet roll. Solutions to both design and technical issues are resolved.


I consume a huge amount of audiobooks and podcasts. When you have 25+ hours a month of free time (or driving time), it allows you to enjoy content you may not otherwise listen to.

I like to think of them as my own personalised radio station. Topics range hugely depending on how I feel. I try to listen to random subjects that I may find interesting – rarely listening to work related podcasts.


This can develop either in the morning or while driving home. Travelling the same repetitive route hundreds of times a year takes a toll. I’ll often go 10 minutes without remembering the last 5 miles of my journey.

I wake up at 6:15am and don’t get home until 5:30pm. It’s a long day! It’s inevitable this will have an affect on my mood. This most noticeably happens in the evenings just as I get home. The overwhelming feeling of exhaustion which is hard to shake off for a few days.


Unfortunately when you’re in a car there is no one to talk to, so your mind talks to itself. Sometimes this becomes the most creative part of the day. Other times it’s spirals into depression.

Depression is rarely spoken about in our industry. It can have a significant impact on the day ahead.

Unfortunately with the combination of tiredness this is more of a common occurrence than I’d like. It can be triggered by the prospect of the work ahead, the previous days work or something completely random.

I’d love to know how others feel while commuting and how they help pass the time. Make sure to tweet me.

NPM and Bower: When to use each

Gulp was my first experience of using package managers. A quick search and you’ll probably notice that NPM and Bower are the popular choices.

Which do you use?

Surprisingly the answer is both. NPM is used for gulp packages – things that do all the crunching such as processing the Sass. Bower is used for website assets – things that will be served to the user such as jQuery.

Why use both NPM and Bower?

There is logic behind the madness. It’s all about how each handle their package dependencies.

If we were to use a carousel sxuch as bxSlider (everyone squirm on the count of three…) it would require jQuery to work. jQuery is therefore a dependency of bxSlider. For bxSlider to work it requires jQuery. So jQuery is a dependency of bxSlider.

Both NPM and Bowers use dependencies but where they store them differs.

How NPM handles dependencies

When installing a package from NPM it will create a folder inside the root of node_modules. Any dependencies will be downloaded inside of that package. If we take the example of gulp-sass, you would have a folder structure like this:


If another module requires gulp-util, it will download that dependency again into it’s own folder. Each package is isolated from one another.

Initially this sounds crazy but it is actually very useful. By each package having their own dependencies and not sharing it stops any conflicts with different versions. No matter what you install, it will work.

The nodes_module folder can get very large. But since we only use NPM for gulp packages we don’t care.

How Bower handles dependencies

When installing a package with Bower it will download all the dependencies to the root folder of bower_components. Taking the earlier example of bxSlider, it would give you the following folder structure:


Unlike NPM, Bower installs dependencies in the root folder. If we then decide to install another package that relies on jQuery it will use the pre-existing package.

Bower is more prone to conflicts with packages requiring different version of other packages. This may feel annoying but it’s very useful, who wants 3 versions of jQuery on one site?

Bower works much more like the JavaScript would on a website, using only one version of each script. This is why Bower lends itself better for assets that will be used on the website.

I spent an hour choosing a class name

There, I said it. It’s not procrastination, it’s planning and there is a big difference!

Modal, flag, media block, popup, drawer, overlay, suggestive search, breadcrumb, follow us icons, pagination, sort by, list item, facets, filters, widgets, newsletter, title, heading, social share, nav, nav dropdown, buttons, forms, inline forms, banners, carousels, tabs, accordions, tabs to accordions, toggles. I could go on…

What’s in a name?

Well actually a lot!

The beauty of CSS is it’s simplicity but it’s also open to interpretation. This is great for creativity, terrible for large projects.

Planning the structure and naming conventions of your CSS is critical for a successful project. Remembering to document everything as you go along. The goal is for anyone to be able to jump onto a project and understand what’s happening.

How to name classes

Here are a few pointers I use when naming my CSS classes.

1. A class should have one function.

Don’t over complicate things. Classes should only perform one task. As well as simplifying the naming process it creates a reusable style that can be applied anywhere. It’s okay to use multiple classes on a single HTML element. The goal is to create flexible, lean and usable code; not attractive code.

2. Name what it’s doing, not what it contains.

The same layouts or styles could be applied to lots of different content. Name your classes after what they do and not what they contain. We don’t want to be duplicating CSS down the road or even worse, giving things the wrong classes.

3. Use BEM – Block Element Modifier.

BEM is a naming convention that uses double underscores and dashes. BEM allows you to see the relationship between styles without delving into the CSS. Double underscore represents a reliance on part of the name that prepends it. A double dash distinguishes it as a modifier of the default functionality.

A good example is an article that contains a title and content with some being sticky. Here is an example of BEM in use:

Last November I presented a talk about BEM at Staffs Web Meetup. Harry Roberts also wrote an introduction to BEM on his blog.

4. Use namespaces

CSS doesn’t only apply aesthetic styles but also JavaScript or temporary states. Prepending your classes with js-, is-, has- or u- makes the function of that selector much more transparent. Again Harry Roberts wrote a great article on using namespaces.

5. A partner in crime.

There is nothing better than talking things over with a colleague. This will help focus your ideas while getting the perspective from someone who may eventually work on the code you’re writing.


I spent an hour deciding a class name and I’ll do it again.

The real CSS has landed

It’s took a while, but it finally feels like CSS has matured to what it originally promised.

Gone are the days of clearfixes and floats, let alone transparent PNG fixes and weird browser specific selectors! Remember having to use a * at the beginning of selectors to target IE6 and below? If you’re in a reminiscent mood, here are some more.

We often hear the phrase ‘good old days’. I am glad the good old days are behind us! Good riddance! I’m not a religious person, so to reference something from the Bible it has to be good! Ecclesiastes 7:10:

Do not say, “Why were the old days better than these?” For it is not wise to ask such questions.

Hello to a new era of CSS. It finally feels like it caters for our needs. The introduction of CSS calc, flexbox, nth child, just to name a few, are revealing the power of CSS and flexible layouts.

Responsive web design is what the web should have always been. Instead of mimicking other industries such as print, we’re now able to stand proud on our own two feet and innovate for a better web.

Internet Explorer is no longer a special case where we have to support several versions. Thanks to the introduction of other options, Internet Explorer’s majority has diluted down to a mediocre 12%, and that’s only if you include IE7 and IE8.

We often moan about the number of browsers on the market but it’s created a level playing field. For the most part they all behave the same. It’s forced browsers to keep up-to-date and include the new CSS features we’ve all been craving for. We can now focus on creating a better browsing experience instead of supporting quirky browsers.

The real web’s pretty awesome. I love real CSS.

CSS calc is more supported than media queries

Calc is awesome.

If you’ve not come across it in CSS, it allows you to do calculations. The big benefit is you can calculate across different units. It’s handy when building responsive websites. There are often times you need to calculate things like 20% – 1rem, well now you can! Here is an example:

The best bit is the support. Calc has better support than media queries, yes you read that right. Every browser including back to IE9 support it apart from Opera Mini.

Using SASS variables in Calc

You might try to include SASS variables inside calc and find they don’t work. The output in the CSS file with print exactly what was inside the calc function. If you include one it will print the variable name, not the value. After some digging I found you can wrap your variables so they work like anywhere else. It feels a little hacky but hey, it works!

Just one word of caution

When using it with pre-processors such as SASS or LESS you may start getting calc happy. Keep in mind if you’re calculating two values with the same units you can us your pre-processor. This will create cleaner and faster CSS. Just use calc when calculating two values with different units.

UPDATED 03/07/2015: Added using SASS variables inside calc

Sometimes you just need to write

To procrastinate as much as I have is a skill. It has to be, else I have a big personality deficiency. Starting a blog is hard, especially when you work in the industry and you’re a designer. My fixation on look causes me to down tools and run for the nearest dark closet.

Recently Phil Wylie said to me:

Sometimes you just need to write.

I’ve always had a fear of not knowing what to write about. I have lots of experience in the web industry but there is always a niggle that someone else has covered that topic better than I could.

I recently listened to Unfinished Business, a podcast hosted by Andy Clarke. On this particular episode Jeremy Keith spoke about writing a blog for your future self and not worrying about what others think.

The web industry is a fast paced place (say that after a few drinks). We’re continuously learning new things, writing them down serves three purposes:

  1. It helps us focus our thoughts.
  2. To help remember how to do things.
  3. It acts as a reference for our future selves.

I think setting goals are important. They give focus and targets to strive for. So here are my goals for this website:

  1. To express my personal opinions on topics.
  2. To experiment, learn and develop my skills.
  3. A reference for myself.
  4. A place to focus my thoughts, allowing me to think more rationally.
  5. To enable me to write more.

Sometimes you just need to write, so hello! I’m Dave and this is me writing.