Behind the scenes
Gentle on the outside, a beast on the inside - my most accomplished work so far.
Wolf Pilot is my portfolio site. It's also an identity. It's the culmination of many struggles, and an expression of my artistic self. It's modular, but light. It's minimal, but doesn't compromise any essential features. And most of all, it has been an adventure in itself.
A rather naive start
My plan was simple: what do I need? I need a site that I can display my work on. The bare necessities are made up of a short section about myself, a gallery of sorts and a contact area. Easy enough, right? Right.
I decided a one page design would best suit my needs.
Back to the basics
I built my previous site in WordPress. It was a no-frills, hack-your-way-at-WordPress' 20xx theme using shortcodes, styling pages by their IDs and generally a pain to maintain, especially when I would only update it every once in a blue moon. In the meantime, I learnt my way around the wonderful ACF and realised that there's a whole world of possibilities out there. Needless to say, I struggled to find a reason for which I would opt for such a heavy CMS, or a CMS at all, when my requirements weren't so high to begin with. I decided to look into lighter alternatives.
Eventually, I bumped into flat file site generators and the idea really struck a note with me. This would become a static, bare-bones site, built from scratch just like in the good ol' days. The only exception would be Jekyll, which would provide some basic DB-like functionality through the use of plain text files.
Here be dragons
Jekyll, as it turns out, is a very opinionated static site generator. During the building phase, it removes the previously generated files unless specified not to. This will, of course, become an issue if you want to run other automated tasks, such as through Gulp, since these tasks are now required to run after Jekyll's clean-up phase. As such, integrating my own front-end boilerplate required a decent amount of hacking and slashing in order to get things working again.
Another point of contention is the folder structure. It's impossible to group blog posts and assets into the same subdirectories - Jekyll tries to convert everything into a post format; when it finds images, it can't parse the data properly, and so it just crashes. It's the classic case of "it's not a bug, it's a feature" that a few people tried to sort out (Nicolas Hoizey's Jekyll Post Files is a good example, which unfortunately was crippled by the same bug I encountered and that no one can find a solution to). As a result, I gave up after a few tries of my own and just stuck with somewhat of a more default project structure.
After I set up my source and distribution directories, the Github repo and so on, I was faced with Jekyll's Liquid syntax which, although intuitive, proved to be more cumbersome to read and write, as well as less flexible than PHP. It is, nonetheless, a life saver, as it allows for a very basic data management system via plain text files located in Jekyll's data include folder.
Like previously mentioned, setting up Jekyll for a truly bespoke project proved to be more difficult than I initially imagined. Despite my many attempts to visualize the data on paper before starting the actual work, I still ended up refactoring it countless times: going from local page variables to external data files and ultimately integrating everything into collections, all in the name of modularising and DRYing out the code as much as possible.
As I worked on the project however, I started to notice a number of faults and limitations of the original design. There was no space to add a blog, I had no way to display case studies and the site overall felt barren, lifeless, even a bit outdated. I decided to take it up a notch and ended up with what you see at the moment.
In the works
A list of future considerations
- Create a blog and import old posts [WIP]
- Add keyboard support for the showcase slider
- Switch to Webpack and ES6
- Add a night reading theme