The future plans for a website dictate its design. The past gives it context and boundaries. 

There is a significant difference between designing a website and designing a printed object, like a magazine. Printed materials do not have to account for the technical debt of their pasts. The first issue of a magazine might look completely different from its twentieth issue. They are, for the most part, independent from one another. 

Websites are different. Old content is easy to find on the web, and the oldest content on a website will always share the new content’s design. A website’s design needs to account for what’s come before.

This means that your typical website re-design has a lot of work to do. 

Over time, this work can result in a degree of digital detritus that requires a wholesale overhaul of design and content. Even when that’s not the case, the work the design needs to accomplish increases exponentially with each additional type of content.

All this is a fancy way of saying: if your website has a ton of content types, the design itself increases exponentially to scale. A rising level of complexity lifts all boats. If you want to manage and maintain a unified, cohesive design for all your blog posts, pages, photos, and more, that’s a lot of content to design. 

What was, what is, and what will come to pass

This website has always been one thing: a series of blog posts, organized in index and archive pages in reverse chronological order. 

Most personal websites are just that: a collection of documents, ordered from the most recent to the oldest. This is what we’ve all accepted to be the norm on a weblog. There are no magazine-style landing pages, content isn’t being fetched from (or distributed to) multiple places, and it can load fast because it is typically bereft of the high-resolution imagery and javascript that slows down most websites.

In the future, I’d like to add more stuff to my website. I’d like it to feel less like a collection of loosely arranged documents, and more like my personal home on the web. I’d like to share links to the most recent case studies from my portfolio. I’d like to fetch what movies I’m watching from my Letterboxd profile. I might share the books I read1. I’d love to share status updates — like tweets, but on a platform I own instead of Twitter. Finally, I’d like to start sharing photos here too2. I’m not sure if I’ll share those photos in some sort of a grid, or if I plan on writing photo stories, or both.

All this new content means the design of this site will naturally increase in complexity. If I’m not careful, I worry that the site’s increased complexity and feature list will begin to resemble urban sprawl: poorly planned, boring to look at, and stripped of personality.

Typically, when I start seeing a long list of content needs and desires, I start worrying about website performance — particularly with my client work. How much javascript, CSS, and business logic do I need to animate all these different dinguses (dingi?), organize and re-organize content at different viewpoints, and display 200 images without forcing the reader to download a gigabyte of data from their cellular provider?3

As a front-end web design and developer, I’m well aware of the difficulties in making complexity both simple and performant. But it’s worth stating here: I expect this site to be fast, easy to use, and not destroy your smartphone bill.

Of course, some of that may be at odds with my other stated goal: to learn a component-based javascript framework like React or Vue. I do not believe the goal of performance is at odds with javascript. This site loads in 1/​3rd of a second. I think I can make it faster still.

In his redesign series, Frank Chimero stayed where he thought the design of his website was going to go before he started work on it. I like this. It’s interesting to see how a project mutates as it goes along. I’m inspired by this, so I thought I’d do something similar. I suspect that, since my website will be more complex than Frank’s, our end result will be very different. But I’m surprised at how aligned our initial goals are. Here’s what I’d like this website to be:

  1. Obvious: Just enough design to make the site feel like its design was inevitable. How else could it look?
  2. Performant: I mentioned this above, but to be clear, there is a large collection of people I respect in this industry who seem to think javascript and javascript-based frameworks, like React or Vue, make websites slower and less accessible. I’d like to prove them wrong. Even if I can’t, then this website will be an easy way to learn valuable lessons I can bring into my client work4.
  3. Timeless: I’d like the website to be simple and clear. I don’t want to add design that gets in the way. I don’t think my work will ever be comparable to Vignelli’s or Ram’s, but I’d like to take inspiration from their methodologies. I’d like the website to be useful, understandable, clear, and unobtrusive — and maybe have an air of quiet elegance.

With my long-term goals stated, and my thesis laid out, it’s time to begin considering the fundamentals. Because this website is going to be text-heavy, it’s about time we discussed type.

Footnotes
  1. Related: Goodreads is terrible and Amazon should hire somebody to redesign it. ↩︎

  2. I’m increasingly concerned that Instagram’s signal to noise ratio is getting worse. In the long run, it is also probably best to put anything I’d like clients to see on a domain I own, rather than feeding it to the Instagram algorithm. ↩︎

  3. Assuming people are outside. Don’t do that. Stay home. It’s a pandemic out there. ↩︎

  4. More on this in a future post, but as my clients’ sites have gotten progressively larger, even the compressed CSS files get huge. The last site I worked on had eight different content structures and five custom pages. Its zipped CSS file weighed nearly 200kb. That’s not because the code is bad or because I repeated myself. It’s just because that’s how much CSS was necessary. React-style components are a game-changer for websites like that. ↩︎