I’m a designer and front-end developer with a passion for details and performance.
A long-time client of mine, I was approached by lake owner Paul to redesign an existing build from the ground up to reflect how they were using the site and what their visitors wanted. The previous build was WordPress based to help with easy self publishing and gallery updating, but most of their traffic was over at Facebook so it only made sense to go where the viewers are.
I completely started over with the design on a mobile-first approach with development, simplifying the interactions and focusing on the steps they wanted visitors to take. We moved from WordPress to Jekyll and optimised our build process with Grunt and a selection of dependencies. The gallery functionality now utilizes the Facebook API for automatically fetching the latest photo uploads from their fan page.
From The Blog
So you’re working on a new client project, you’re in charge of design and you’re starting with a blank canvas. Speaking of which, you fired up your graphics application of choice and started fresh with a width of 320 pixels. You’re doing it wrong.
If you’ve ever worked with a system locally that generates absolute paths to assets, you’ve no doubt encountered the problem of images and styles not working when testing across multiple devices on the network. You could always deploy to a staging server but Finch is here so you don’t have to.
A quick run-down of my typical Jekyll process to show how I manage my projects and how Jekyll ties into the rest of my build processes without getting in the way or conflicting with anything.