Rules for This Website

🗓 posted Oct 21, 2024 by Josh Erb
🔢 727 words
🏷

I've been adhering to some loose mental rules whenever I change or add anything to this website, and I think it's worthwhile to write them down here for posterity. I'll also keep a CHANGELOG section down at the bottom and do my best to keep it up-to-date if and when these rules shift.

  1. Don't overthink the color pallet. I think it's really easy to go overboard with colors, and this is a personal cause of many an existential tailspin. So, to avoid falling down this rabbit hole over and over again, I only use black (#000), white (#FFF), and a slightly transparent yellow (rgba(238, 238, 51, 0.6)) on this site.
  2. If I need something that's already on the computer, don't bundle it. This rule mostly applies to fonts. For my money, this is the most straightforward way to speed up a site. All computers ship with fonts as part of their operating system. Browsers have access to these fonts. So why not use what's already there? With this approach, my site doesn't have to rely on heavy network requests just to show text. Sure, this limits my design, but I've been happy enough with how the site looks when I use Palatino & Courier New. At the end of the day, I set some fallbacks that feel reasonable and I sleep soundly at night.[1]
  3. Viewing a page on a phone should be similar to desktop, but it doesn't have to be identical. A good portion of people viewing my site are probably coming to it via their phone's browser (especially if they click a link I share on social media). I could be a crank and refuse to accommodate them, but media-queries exist and aren't too hard to use, so why not make life a little more enjoyable for everyone?
  4. If it can't be achieved with HTML & some clever CSS, it might not be worth it. I have no ill will against JavaScript (unless we start talking about strict equality), and I'll use it if I want my site to do something and it feels like the only way (ref. footnotes). That being said, I think it's easy to overuse JavaScript and slow down a site unnecessarily. As a result, my first attempt is always to stick with HTML + CSS.
  5. The site should be as close to fully baked as possible when a page is loaded. This is complimentary to the above rule about JavaScript. Lots of big, complex apps rely on a design pattern of "send the bare minimum and then fill in the blanks as they arrive." In many cases this makes sense, and is a useful strategy. But this website is not a big, complex app. I use a static site generator (11ty) to turn Markdown files and Nunjucks templates into HTML. If I have a project that includes data I want to show visitors, I want to bake that data into the pages when I build them, not when the browser loads them (ref. maps & dithering).[2]
  6. Let people peak behind the curtain. This one is more philosophical than technical. I'm not trying to make money with this site, and I don't think I'm innovating or doing anything exceptionally unique here. However, I think that the Internet is at its best when ideas are allowed to travel and cross-pollinate. This is only possible if stuff is documented and we explain how the sausage was made. That's why almost every bigger feature on this site has an explanation post (ref. #development), and it's also why every page includes a link to the source code on GitHub. I find that doing this leads to good things. Like pull requests that improve the site's navigation links, or forum comments that give me new ideas for how to optimize site features.

CHANGELOG

  1. There are plenty of useful lists of operating system fonts to help decide which ones will most likely keep things consistent across platforms.

  2. Note that an exception to this rule is the "currently reading" feature on the site's landing page. However, I am currently working to change this.

<< all notes.