Hello toggles, goodbye sprites

No, not that kind of Sprite.

Before today, if you visited my site on a device with a high resolution screen, like the iPhone 4, you would of seen some blocky icons in the header made with an image sprite. Which was something that always really bugged me.

When Apple announced the retina display they introduced the -webkit-device-pixel-ratio media query to WebKit, the rendering engine used by Safari, Mobile Safari and Chrome (amongst others) to detect higher resolution displays. I could have used that media query in my stylesheet to serve a higher resolution sprite to visitors, or just served a higher resolution sprite to everyone.

Instead I opted to use an icon font, which has a number of advantages over rendered images:

  1. They’re vector based so can be scaled to any size without an increase in file size and look great on higher resolution screens.
  2. They have transparency that works properly in IE6.
  3. They can of course be styled with CSS properties like text-shadow, color or rotate.

There’s one small Gotcha with Firefox: it won’t load cross-domain font files. This confused me somewhat as it worked when I tested it locally, but not on the live site where I use a CDN. The solution was to encode the fonts as Base64 in the stylesheet, which has the added benefit of saving a http request as well.

Toggles are nicer than buttons

Ok, buttons are still cuter.

This is as true of duffle coats as it is web design, which is why the second feature I’ve added is a toggle on my portfolio to switch between a two and four column layout. I spent quite a while thinking what combination of jQuery UI modules it would need before I realised I could just do it with a CSS3 transition.

The toggle itself is just a <button> element styled with a background image and a couple of lines of jQuery that switch the class on the button and column containers when it’s clicked. I probably spent more time getting the toggle image looking just right with drop shadows and gradients in Photoshop than I did on the CSS and JavaScript.

To see how many people use the toggle I’ve attached a Google Analytics event that gets triggered every time it’s clicked. At the moment it’s just some simple code that tracks clicks, but in the future I might add some logic to see which layout is more popular. I’m not sure how I’d remove the bias towards the initial layout though, maybe with some sort of randomisation.

It’s always good to try new things out on your own site, so when a client asks for them you can point to live demo of the technology and you know how to implement it.

Farewell Facebook

Don't you forget about me

I’ve decided to leave Facebook for a while. Not because of a lack of privacy, the new timeline – quite the contrary, I’ve been using it since the developer preview  - or obnoxious new advertising placements.

The other day I noticed that Facebook was sitting at the top of the list of most visited sites in my browser, its actually been at the top of that list for a while, but I realised that to be at the top of that list I must be spending hours and hours of my life there. Those hours turn into days and I daren’t think how many of those add up into weeks or even months since I joined in 2006.

Hours of my time and effort are spent every week feeding this insatiable machine. I’ve given it more information than the last census, hundreds of photos of and countless messages shared between my friends.

So I’ve invested my time in Facebook, but what have I gotten in return? Are my friendships richer because of it? Have I made new friends through it? Am I using it to network with professional contacts? For me the answer to all these questions is no. Perhaps I’m not using it to it’s potential in that case, but I don’t think I want to double down on my investment.

My online relationships mirror my existing relationships – I’m most social with those I’m already close with and I don’t really care about what my friends from primary school are up to these days (sorry).

What I do find useful about Facebook is it’s convenience. To quickly invite a bunch of friends to a party, for example, without having to worry about keeping your phonebook up to date and texting all of them. Send a quick message to someone whose phone number or email you don’t have. There’s probably other completely obvious things that I’ll miss when I’m gone, but I’ll see how it goes.

For now I’ve decided to block access to Facebook on my computer, disable notification emails and delete the app from my phone so I won’t have to resist the temptation of logging back in. In a month or so I’ll come back and review how things are going and if I find I’m not missing it terribly I’ll deactivate my account.

Farewell Facebook, it’s been fun, but I think it’s time I moved on to other things.

When will my website be ready?

There’s a good series of answers on Quora to the question: Why are software development task estimations regularly off by a factor of 2-3?

Asked recently if I could work quickly, I pondered for a moment, trying to think of a more eloquent answer than ‘yes’ and replied that I found the slowest part of development was waiting for feedback on changes. To elaborate: redesigning my photography site a few weeks ago took less than a day from development to deployment.

Firstly, because I knew exactly what I wanted and how to execute that with WordPress. But more importantly the feedback on changes was instant. Because there was immediate feedback there was no break from work to grab a screenshot, write up the changes, email them to a client and then wait to hear back. The final sentence of one answer on Quora is succinctly brilliant:

Request-Response latency between humans is thousands of times longer than in a single person’s mind.

— Why are software development task estimations regularly off by a factor of 2-3? – Walt Howard, Quora

Bringing responsive web design to P2

The P2 WordPress theme has had over a 280,000 downloads from the theme directory, is used on over 40,000 wordpress.com blogs and changed how Automattic communicates internally.

Reading the WordPress development blog, which uses P2, I noticed that it was serving a iPhone specific stylesheet but wasn’t responsive. Since I use WordPress so much myself and for clients I thought a good way to contribute to the community that makes such lovely open-source software would be to spend some time making P2 responsive.

The layout of P2 isn’t that complicated and the theme files are fairly logical so it didn’t take too long. Most of the adjustments were made with CSS, but there were a few things that needed moving around in the markup so they displayed well on small screens.

Today I’m making my work available as a child theme on GitHub. There’s one small Gotcha, which is the iPhone stylesheet. P2 serves the stylesheet using some code in the functions file in such a way as it can’t be overridden from a child theme, so you’ll need to comment out or delete lines 443-453 in p2/functions.php. It will work without this modification to the parent theme, but may appear incorrectly on iPhone’s.

Unfortunately I was only able to test it on the few devices I own, so I’d love to hear from anyone on an Android tablet or phone. But it should work fine in all modern browsers and iOS devices.

I’ve submitted my work to the Automattic theme team so hopefully in not too long a while the changes will be merged into the parent theme. In the meantime you can try out a demo of the theme or download a copy from GitHub.

1kB JavaScript = 1ms parse time

Optimising some JavaScript today (exciting, I know) and going through the Google Page Speed documentation I came across this little snippet:

In our own tests conducted in early 2011, we found that on modern mobile devices, each additional kilobyte of JavaScript adds about 1ms of parse time to the overall page load time. So 100kB of JavaScript included in the initial page load would add 100ms of load time for your users. Because JavaScript must be parsed on every visit to a page, this added load time will be part of every page load, whether loaded from the network, via the browser cache, or in HTML5 offline mode.

— Optimize for mobile: Defer parsing of JavaScript - Google Page Speed

Developing & Deploying with Git

Even the grandest structures are built from modest blocks.

As part of updating my site at the start of the year I switched to developing and deploying with Git. I’m surprised how it’s improved my workflow, even though I’m not (yet) using it to work collaboratively.

Git, for those of you not familiar with it, is a distributed revision control system. It’s usually used for source code, but it can handle any type of file.

For a while now Espresso has been my IDE of choice, but recently I’ve been fooling around with a few others behind it’s back: TextMate, BBEdit and Sublime Text 2. Using Git has meant I don’t have to remember which files I’ve been working on and need to upload. Incidentally, Coda handles this nicely without a full on revision control system.

Previously my workflow involved developing and testing locally before pushing changes over FTP to the live server (I don’t run anything of significant complexity to warrant a staging server). As I developed I would generally work through a checklist of functionality, but not always linearly or systematically.

Developing with Git has made me focus on working on a smaller incremental features or bugs at a time. Where before I would of started working on one thing and ‘just quickly do this other thing’ now I can focus on working towards a single commit before moving on. This focus has also sped up development because I’m jumping around less and can work through changes more systematically.

Deploying changes is a breeze too. I’ve based my setup on this tutorial by Joe Maller, pushing commits to a ‘hub’ repository on my server that uses a post-update hook to pull changes into the live repository. Whilst I’m comfortable using the command line, GitBox has got a simple UI and a bunch of handy keyboard shortcuts to quickly commit and push changes.

There’s still a few things I haven’t tried yet, like merging changes from other contributors, making branches to work on new features and using git-svn to contribute to other projects such as WordPress. But I’m really happy with how it’s changed my workflow and I expect I’ll be using for all my future development.

WordPress job hunting

The Grote Markt at The Hague by Paulus Constantijn La Fargue

Most of my previous clients have found out about me through word of mouth, which has been great as I’ve been able to work with people I already know and have rapport with. But coming into the new year that source has slowed from a healthy flow to more of a trickle so I’m being more proactive about finding work.

In one sense it’s counter-intuitive to write about where I’m finding work as I’m potentially inviting others to eat my lunch, but one of the best things about the open source community is sharing and collaboration. Below is an overview of what I’ve found so far, if you’ve had an experience with any of theses sites or know about one I’ve missed, let me know in the comments.

  • WordPress Jobs – The official job board for WordPress, that’s people looking for WordPress developers, not jobs at WordPress. I’ve followed up a few leads I’ve found on there, but unfortunately a lot of posters have slightly unrealistic expectations in terms of scope of the work relative to the proposed budget. It’s also very US-centric.
  • Code Poet – The other official WordPress job site, though rather than a job board it’s a directory of WordPress professionals for clients.
  • WooJobs - Aside from the previous two official sites, this is the only WordPress specific jobs board I’ve come across. At the moment all the ads are for freelancers, with the exception of one full-time position with WooThemes themselves.
  • Gumtree – A British version of Craigslist. Mostly freelance and contract work.
  • Authentic Jobs – One of the best jobs boards for WordPress and front end developers I’ve found so far, they also have a specific UK site, hooray!
  • 37signals – Tends to feature more back end and language/platform specific jobs but chock full of high quality recruiters.
  • Forrst - Billed as a community for developers they’ve recently opened a jobs board. Sadly there’s only a handful of UK jobs listed at the moment, but it looks promising.
  • Smashing Jobs – Leans heavily towards designers and front end developers. Along with a good range of filtering tools including a well populated freelance section.
  • GitHub jobs - Like 37signals, features more back end and language focussed roles. They also offer a dedicated iPhone app, which none of the others so far have.
  • Stack Overflow Careers - Every developer’s favourite troubleshooting site has a job board too. Unfortunately no WordPress specific jobs have been advertised here for a few weeks, but the odd frontend job does come up.
  • Themely - An honourable mention as it hasn’t launched yet, but aims to match up WordPress theme designers with developers.

Unsurprisingly the paid sites offer much higher quality jobs, whilst the free boards have a greater quantity of ads, especially for freelance and contract jobs.

The best way I’ve found to get through all these sites is to try and find the most specific RSS feed and put that into a ‘jobs’ folder in my Google Reader account. For the sites that don’t offer location or keyword specific feeds I filter them through a Yahoo! Pipe. Then once a day or so I can go through them and apply to any relevant ones.

Of course if your looking for a lovely WordPress / front end developer in the UK who’s hip with all the latest HTML5, CSS3 and responsive web design you should drop me a message: or give me a ring: 07793940759.