Neil
Carpenter

Design & front-end development

Blog

Thoughts

General thoughts on web design and front-end development - trends, frameworks, tools, APIs, tips, new techniques, old techniques, good cat videos, funny GIFs etc etc.

Making this site

Apologies in advance if this post goes on a little long and seems a bit self-indulgent – it is for my own personal benefit more than anything else, just so I have a record of exactly how I approached things and what I was trying to achieve, as no doubt I will have completely forgotten within a couple of weeks…

Initial sketch of a page template
Yeah, I can’t really draw

The idea

So the big thing the past year or so has been responsive web design, it has been pretty hard to get away from it. And it has opened up a whole new world of questions, issues and priorities which need to be addressed in order to successfully design for multiple devices. And I personally feel that to some extent, many responsive sites currently out there have compromised on the level of attention given to every design decision, at every viewport width. And the result is sites that are instantly recognisable as ‘responsive’, before you even resize your browser window.

Something different

And so what I was trying to do with this site was ultimately create a responsive design, which at first glance may not appear to obviously be a responsive design (to those of us who open and new site and bet with themselves whether or not it is responsive before resizing the browser window… Just me?).

By this I mean incorporating elements which might not frequently be seen in responsive sites, such as a fixed header navigation when at ‘desktop’ width, and mobile navigation more akin to a mobile website than responsive site, rather than simply creating an inline list of links. These aren’t groundbreaking things in themselves by any means at all, my goal was to use techniques such as these in tandem to create a decent user experience at all widths, not simply a desktop site that displays all elements at 100% width below 500px.

I was also keen to stick to as many best practices in terms of performance and scalability that I could, meaning a heavy reliance on CSS for presentation, and optimising the front-end code as much as possible.

The components

It’s more than fair to say the best parts of the site are due to other developers’ hard work:

Services/frameworks

The site uses the HTML5 boilerplate, and makes plenty of use of the included frameworks (jQuery, Modernizr) and H5BP Ant build script.

The site is built on WordPress, which I like more every time I use it. Turning the static HTML/CSS/JS in to WordPress templates and migrating content literally took about 3% of the time I spent building the site.

Fonts are served through Typekit, background patterns are from Subtle Patterns. The icon font used is made from Pictos icons, hosted myself, and the icon set was actually put together using IcoMoon by Keyamoon, which is an incredibly useful font-building app.

Plugins/extensions

The image slider on the homepage is thanks to Flexslider, which I seem to be using on every project at the moment. The slideshow which is displayed at tablet-y widths and below on each project page is powered by Photoswipe. The layout for the ‘snaps’ page is thanks to jQuery Masonry. The code syntax highlighting on blog posts uses Google Code Prettify.

Each page also has jQuery debounced resize, Nicholas Gallagher’s async social media script loading technique and H5BP mobile boilerplate helper JavaScript baked in.

Fully responsive

The site is fully responsive: fluid layout, flexible media and media queries. Unfortunately I initially didn’t design it with Mobile First in mind – I thought I would be able to retrospectively adapt the CSS to be mobile-first but it turned out to be trickier than first anticipated, and so had to put that on hold, I may revisit this later at some point.

Images

At the time of writing this, the future of serving images to responsive sites is very much uncertain. There is currently no clear and easy solution, but there are several possible workarounds, each with their own benefits and pitfalls. I chose to use a very simple JavaScript-based solution, in which each responsive image has three size variants, the smallest of which is the default image. JavaScript then loads in a different size depending on the screen width/resolution. This solution suits my needs – although it means two images are downloaded on larger screens, the perceived load is actually faster for the user, and it isn’t applied to every image, only the ones where there is a significant gain in loading two images over one. Some would argue against using a technique like this as it is reliant on JavaScript for users who require the larger images, but that’s okay with me.

Performance

As mentioned earlier I tried to put a focus on performance and front-end optimisation – using CSS for presentation, and minimising HTTP requests where possible. This was done through combining, minifying and concatenating all JS and CSS, using a font for icons, using data URIs for background images where possible and reusing assets across the site.

I also tried to improve the user perceived load time by lazy-loading some assets, such as larger images and third party requests, such as the social media feeds on the homepage or sharing buttons in the projects/blog areas.

The W3 Total Cache WordPress plugin takes care of caching database objects and pages, and gzipping and adding expires headers to all site assets.

Browser support

As far as desktop goes – unfortunately, older browsers don’t much like sites that extensively use CSS3, and so any browser that doesn’t like border-radius, rgba(), @font-face and box-shadow will not play nicely with this site… Basically, that means the site will either look fine (most ‘modern’ browsers), look fine but not have CSS3 transitions (IE9, old versions of ‘modern browsers’), or… will look like arse (IE8 and below). I did think about polyfilling the CSS holes, but in the end didn’t have time, perhaps I will revisit this in the future (I won’t).

I haven’t had time to do a great deal of multi-device testing, but I know the site works fine on iPhone 3GS+, iPad 1+, Android 3.2+ and Opera Mini on iPhone.

So that’s it

This is my first personal website, and so I wanted it to be good, use cutting-edge techniques, and be something I can be proud of. But ultimately, the speed things move with the web, I anticipate that it will be completely outdated in no time, so I hope I get the time and motivation to do it again in the not so distant future.

Update - In case anyone might be interested, I have put the theme source for this site on GitHub here now.

Share this

Leave a comment...?

4 Responses to Making this site

  1. Hello, Neat post. There is an issue with your site in web explorer, might test this? IE still is the marketplace chief and a huge component of people will pass over your wonderful writing because of this problem.

    • Hey there,

      I haven’t had time as yet to make the site particularly well in IE8 and below, but I may do when I get the chance. It should work fine in IE9 and above though.

      Thankfully, the majority of traffic to the site is from more modern browsers, mostly Chrome, so it’s not huge issue.

      Anyway thanks for reading, glad you liked the post!

  2. I liked the design a lot, its just i need to put more stress to read the content (may be too much use of gray).

    Anyways, i want to know how you show the loading image before displaying full contents of every post/page, i tried jquery but couldn’t get it working properly on my website . Images still loads after displaying the content.

  3. Wow! Places like this make me think more in continuing to design websites

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>