Microsoft drops support for IE10 and below

Next week Microsoft will drop support for the their older versions of Internet Explorer. This includes IE8, IE9 and IE10. For many web designers and developers it will come as a relief.

With most browsers now offering automatic updates, it feels like a giant step forward compared to just 5 years ago. As an industry it feels like we are now able to start adopting new technologies much quicker, without the fear of some users not being supported.

I recently wrote a post on iWeb’s blog discussing the implications of this change.

Starting from Wednesday 13th January 2016 Microsoft will drop support for all but their latest version of Internet Explorer and they’re new browser, Edge. This means that Internet Explorer 8, 9 and 10 will no longer be officially supported.

Currently those three browsers account for just under 3% of the browser market.

This announcement coincides with the announcement that some older browsers (including Internet Explorer 8, 9 and 10) will no longer be able to take secure payments online. This was originally going to be implemented this summer but has since been delayed until 2018. Last June SagePay, a popular payment gateway, removed support for Windows XP users.

Read the entire article on iWeb’s website.

Ampersand Conference 2015

A few weeks ago I was lucky enough to attend Ampersand Conference in Brighton. Here is an article I wrote on iWeb’s site, where I work, for the top takeaways from the event.

Typography is probably the most important thing to get right on the internet. Text is everywhere, I challenge you to find a page on the internet where it doesn’t play a major roll in the content.

Great typography on the web combines design and technology. Attending conferences allows you to meet lots of people with different abilities and experiences. It really opens your eyes to the vast effort that people put into every aspect of a website.

One of the biggest advantages of visiting a conference is being around hundreds of people who share the same passions as you. The one day conference had a wide variety of talks to covering all tastes. This meant that those attending ranged from front end developers, type designers, web designers, UX designers and everyone in between. This huge variety of people from different background makes you really appreciate how much effort goes into websites.

Read the full article on iWeb

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.