Back in October 2017, we started toying around with the idea of rebuilding our studio’s website around the goals of differentiating ourselves from our competition, demonstrating our skill sets more accurately and trying to build a more honest connection to who we are as individuals and as a collective. Over the years, we’ve drawn inspiration from tons of studio / agency websites but most have all had this sort of holier-than-thou way that they communicate who they are and what they do. They’re all trying to compete to see who can speak marketing lingo better than the others.

Our branding process is better than yours. Focus, alignment, inspiration, execution, etc. Blah blah blah.

Hundreds of different shops with hundreds of different creative processes to do the same thing. We don’t want in on that rat race.

We want to be who we are and want our website to act as a window into exactly that. Don’t get me wrong, you need at least some level of that marketing lingo if for nothing else other than SEO, and lots of people definitely do read through and value that type of content, but we didn’t want it to be the cornerstone of our site.

We’ve always had an issue with how websites are typically thought of as a collection of pages. It’s 2018! The internet is capable of so much more. Asking a server to send you an entirely different “page” every time you click a link seems primitive. And why should a visitor of our website be considered so differently from a visitor to the studio itself? Both cases are opportunities for us to connect with another person but the former is often underutilized.

The studio slid some creative juices toward finding a way to connect to our audience in as honest of a way as possible, and somehow try to close the gap on the current differences between a visitor coming to our website and to our studio. We landed on introducing a combination of a few different ideas — a live webcam of our studio and an interactive chat laid directly on top of the webcam stream.

We were certainly not the first people to think of these ideas, but we didn’t need to be. The combination could allow for a variety of interesting ways to connect to our visitors — and that’s what we were after. A visitor could say hi and we could wave back to the camera. Maybe one day we’d all come to work with horse masks on. Who knows.

But hopefully people would leave our site feeling like they have an idea of who we are and not like they were just spoon-fed marketing gibberish.

Time to shine

Now that we had a little sapling of an idea, we needed to figure out how to make it happen.

We began mocking up ideas and tossing different approaches back and forth between the designers. We landed on an aesthetic and UX fairly quickly. Everything fed off our original idea and I personally find design to be the most fulfilling when it unravels that way.

Client side

Development started with scaffolding out the project’s client side first. We’ve been using React & Redux quite a bit at Keen and decided to build the entirety of our frontend with Create React App which I highly recommend. It’s just painless to use, and we don’t run into any problems due to it being overly opinionated. We barely even realize it’s there once we’re up and running writing code. And I have to say — I feel like React makes writing code fun again.

Components and 2018

When you start thinking about UI in terms of components, it’s like having a baseball bat made of logic smack you in the dome. The compartmentalization of code makes functionality much more reusable and extensible. It’s like each component is a little bundle of joy that you can just drag and drop wherever you want and have it render & perform perfectly. The web has a long way to go before this becomes native, but we’re excited to see progressions with the Shadow DOM and the ideas arising from it. The future looks bright, but also far away. C’mon, digital prodigies, prove me wrong.

An example we found to be a testament to exactly why components are so helpful to today’s web ecosystem can be found on our Subscriptions for SaaS project.

In the midst of building our own site, we designed, developed and launched a quick microsite for one of our favorite clients based in Germany. The site uses the WP Rest API for content, combined with a client-sided React app and was a very fulfilling project to design and build.

We ended up writing a few animated, graphical modules from React components for the microsite, were pretty pleased with how they turned out, and wanted to include them in our new site as a portfolio project.

It was basically as easy as copy and pasting a folder into another project, and boom — all the logic, the styles, and the markup were embedded into a completely different site, looking and performing perfectly. Sure, we had to bring over some typefaces and a tiny amount of supporting CSS, but it was a breath of fresh air. That’s some good stuff.

The state of CSS

Being a project for ourselves, we were able to do some exploration into new technologies and new techniques without the risk of introducing something too new into a production environment. Early on, we played around a good bit with how we would architect the CSS side.

We have been evaluating CSS-in-JS for a while now and really like its premise, and see the benefits of scoping styles directly to components, but unfortunately it comes with drawbacks and shortcomings that make it not a real candidate for us to rely on for anything close to universal adoption. Inline styles are slower for the browser to parse and pseudo elements, hovers, and other CSS aspects are more difficult as of now to implement. Also, in the back of my mind it’s always been sort of a shoe-horned solution to a much larger problem with web development and I don’t like relying on stop-gap solutions like that.

I mostly disagree with Create React App’s documentation and stance on the use of Sass within React. Yes, the component-based nature of the library means there should be less sharing of code, which eliminates a lot of why Sass is used in the first place, but we still use Sass functions, nesting and variables fairly often. Also, what would happen if we needed to provide a CMS with pre-styled HTML components that could be used in WYSIWYG fields? Think giving an admin the ability to insert a <button class=”btn”> into a WYSIWYG field at the end of a paragraph. That’s gotta be styled from somewhere and it’s not a React component. And any styles that compose this button should be reused throughout any other actual React Button components present in the codebase.

For these reasons, we decided to write our CSS still heavily reliant on Sass, and scoped each component to its own partial that is as isolated as possible from the components surrounding them, just as React says to. But almost all of our components do import a small subset of Sass partials as needed (mixins, vars, baseline, structure, etc) which are all the same for us from project to project. This works for us but still leaves something to be desired. I plan to write a post about this in the future.

The Server

For most of Keen’s web projects, we build locally, use a fresh droplet from DigitalOcean and configure it for production based on the tech stack of the project.

We often use Let’s Encrypt for SSL and did so for our own site. Nginx would act as a reverse proxy to our Node app. Pretty simple stuff, so far.

CMS

I could talk for three years about the state of CMS on the web. I yearn for a fully JS stack, and if we were going to use a PHP / MySQL CMS we might as well use the WP Rest API paired with Advanced Custom Fields and keep it decoupled from the client (which is pretty awesome to be honest). I don’t see much of a real reason to go playing around with any of the other PHP options out there. Different ways to do the same thing. But we had big plans for our Node server — it needed to beam a webcam stream to users as well as provide a realtime chat interface. The last thing we wanted to do was hodge-podge a LAMP stack with Node and websockets.

To fulfill our dreams of a fully JS stack, we ended up implementing KeystoneJS and relied on its Express webserver to serve both the Keystone admin UI as well as the static files from Create React App and a few specific routes we added on top of Keystone.

Keystone actually limited us a great deal in practice when it came to content management though. For example, each one of the projects featured on the site has a unique layout and therefore unique content model. Keystone is totally based on Lists, which as far as I can see, are limited to a specific content model per each list. Each one of our projects was to be built with React components though — and we have never liked or condoned the idea of just plopping in a big bundle of HTML into a WYSIWYG and then parsing it into HTML.

That means Keystone was of no use to us for the majority of why we’d use it to handle our content. We ended up statically storing our projects, team members and services pages as objects in JS arrays, each with their own properties and React components — imported into CRA and bundled. Lean and mean. We’re developers. That being said, we do plan to use Keystone for future Keen site content management needs where its list-based nature could be more appropriately applied (think blog posts, a future studio mood board, etc.).

Webcam Setup

The first real challenge of the site was trying to figure out how to stream a live video feed from our office to visitors on our site. There are lots of out-of-the-box solutions that can provide a live webcam stream to an app or to the internet, but we wanted a little more control over what was happening than what could have been provided with a premade solution.

After some research, we found two very helpful software packages that we could use to make the webcam happen.