A new home for Percolate Galactic

A collection of thoughts regarding the all new Percolate homepage

Around 5 months ago, we decided to re-build Percolate Galactic’s website from the ground up. After 2 months of working on it, we had designed, built and scrapped 2 whole designs. Each time we would design something, love the idea, build it out, and realise it was “meh”. The problem was simple, we kept looking at it from an exterior perspective. We had a very art-first approach.

For our third attempt, we decided that our approach wasn’t working, and it was time to switch things up. We started off by building out a structure first (which you can see a glimpse of in this article), and followed that by trying to figure out what we wanted the experience of the site to be. We soon decided that we wanted it to be as bare-bones and functional as it could. We’re a design agency, and the primary reason people would go to our website, is if they were considering to hire us. This meant that our portfolio had to be star of the show, and by making sure our experience was as functional as it could be, we wanted the portfolio to showcase just how talented our art designers are. This resulted in a custom image for each portfolio entry, which has led to (warning: biased opinion ahead) some of the best art I have ever come across.

Being the first Percolate Galactic website that wasn’t built with a site creator, there was a huge opportunity here, in terms of technology. I was given the opportunity to start from scratch, and not having to support any legacy tech. However, this also brought the responsibility of having to pick the right tech and build the website in a way that another engineer after me will be able to look at the code and know what to do. One of the biggest problems I’ve had before when working on other people’s websites is bad CSS. Now yes, I’m aware of the syndrome where “every line of code that wasn’t written by me is shit”, which is why I wanted to write out our CSS so that the developer that would pick it up after me would know instantly where to start, this meant a few things.

1. Class Name Conventions

The biggest problem I’ve seen that would be a “bad practice”, is class names that don’t make sense. Class names that have nothing to do with the element they’re attached to, or in some cases refer to another element but affect something else, a mixture of kebab-case and camelCase. Even writing about it is confusing me. So that was my primary aim, to make sure anyone who would look at the css, would know what they were working with.

2. Pre-defined Variables

Anyone who’s ever worked with CSS will know where this is coming from. Too many times I’ve found myself going “whats the hexcode for that colour again? where did I use it?” or “wait how do I spell this fonts name? is this the font I’m using?”. In past CSS projects, I’ve fixed it with a comments paragraph at the beginning of the file, something like;

/* CSS CHEAT SHEET
Primary Color: #777
Accents: #ggg
Text Colour: #ccc
heading font: 'Signika', sans-serif;
body font: 'Open Sans', sans-serif; */

However, thanks to the power of SASS, I can take that to a whole new level, and have a bunch of variables that can be called in, without needing to remember the values of each variable. Now, SASS can seem quite daunting, especially to a developer that isn’t used to it, so I used SCSS instead, so even if someone who has no SASS experience came in to work on the code, they would be able to pick it up pretty quickly.

3. Redundant and Unnecessary Code

Redundant code is something I’ve only started noticing as of late. It refers to code blocks that take up a bunch of space for something completely trivial. like a whole code block to an element that just ads a margin-right element. Taking inspiration from BuzzFeed’s Solid CSS framework, I set up immutable classes for that specific reason. So instead of creating a whole code block to add a margin of 6px, I would just have to add a class like margin-6, saving space from the main CSS file. Mark Otto elaborates more about this process in his talk on mdoular css and here are some more of my thoughts on the matter.

By adding these constraints to the project, we were able to streamline the entire engineering process, and come out with a project that has the least amount of CSS I’ve ever used in a big project. Let’s just hope we can maintain that in the future.

I’ve not been at Percolate Galactic that long, so I don’t even know if I have authority to say this, but this was probably the first project that we have ever tackled by taking an engineering approach. In the world of creative advertising agencies, especially those that have a history of focusing more on brand and print design, that’s basically unheard of. I also believe that this gives us a major advantage over the competition, because in the Jakarta scene, you either get digital agencies that have minimal experience in creative design, or the vice versa. By placing ourselves at the intersection of creativity and functional engineering, well let’s just say the future is going to be exciting.

To read more about the ideas and approach that went into the art and graphics used on the website, stayed tuned to Dissected Durian.