Guidelines for a website
A website is a complicated thing.
If you don't have a clear idea of what you want to do, there are a lot of different ways to end up with a website that, plainly, stinks.
Impressively, it seems that some of the world's premiere institutions of the written word struggle as soon as that word needs to be wrapped in an <html>.
Have you ever clicked a link, hoping to read some article or opinion piece from a great writer, just to become locked in battle with that page, which is desperately trying to get you to do anything except read their work?
Sure you have.
Now, I can't exactly claim to be a great designer; I consider myself fairly visually clueless.
I also don't spend a great deal of time working in the browser, so it's fairly easy for me to forget about some of the various things I care about in a website.
So this page is to help me remember exactly what guidelines I'd like myself to follow when working on this site.
I'm publishing it on the site so that it's definitely available when I want to work on the site, but maybe it'll be useful to somebody else too.
From what I've seen, I think I have different design goals than many others who make websites.
Some people seem to want a website that serves the fastest devices, best internet, and largest screens.
I'd rather have a website that might be goofy and crufty, but actually works, for a lot of folks.
Making a website that's good
The first thing to make sure of is that your site is compact.
Maciej Cegłowski did the canonical talk on the website obesity crisis (sadly, apparently, half-broken at this time).
Dan Luu has done some great writing on this as well, focusing on both slow and intermittent internet and slow devices.
His site is quite a bit more spartan than this one, even.
As it turns out, reducing page size is, mostly, a matter of reducing the presence of javascript.
HTML is basically the stuff you see, so it's difficult to write excessively-huge HTML for a certain amount of actual content unless you're being actively malicious.
CSS is also relatively blameless, possibly because nobody wants to write more CSS than they strictly have to.
But people go just crazy for Javascript.
The style with a lot of sites these days seems to be to stop the browser from doing anything that it does for you, and rewrite all that behavior yourself.
In theory, there are lots of good reasons to do this.
In real life, it makes your product page a Russian novel that unloads itself at random and doesn't let you control-click on anything.
So, we can do better than this by simplifying the site.
Pre-“render” static content so that neither the server nor the browser have to assemble an identical page every single time it's loaded.
Rely as much as we can on the browser to know when to load which links, when and how to render which content (maybe with some CSS to help), and how to actually implement a page history.
The browser is going to be better at that stuff than we are.
Some good pages in this space:
After simplifying, we can get back to making things complicated, but for other purposes.
An inherent complexity of the web is how many ways it can be accessed.
Consider these things computers, tablets, mobile phones.
Old browsers, javascript-less browsers.
Screen readers.
Translation apps.
Dark mode, light mode.
Printers.
The MDN is a good resource for responsive design.
(They're a good resource for lots of stuff.) Mobile-first is a great principle, like other forms of progressive enhancement.
Screen readers and non-mouse-based navigation add a whole set of constraints on design.
Some tips related to these include:
Use semantic HTML, not just a pile of <div>s.
Put a useful amount of text in links for someone tabbing around, not just one or two words. (Admission: I don't follow this one reliably.)
Use the <abbr> tag for abbreviations. (have I ever done this?)
Lots of people have opinions on dark mode.
It's probably nice to include, and pretty dang simple with a media query in CSS.
Printing is also a use-case that's worth some active effort to support, in my opinion.
Maybe I'm the only one who thinks this, but it's not for no reason.
I like to print articles to my e-ink device to read later, and it's very nice when the page doesn't more or less explode when I try it.
Supporting this well involves using media queries for printing.
One straightforward choice is to display link targets for printed content, since you can't exactly click a link on the web.
@media print {
a[href]::after {
content: " (" attr(href) ")"
}
}
CSS for displaying link targets in printed pages
Language and encoding are also considerations, since the web is a global platform and “English is the implicit default” isn't a very nice way for the world to work.
As part of that, it's good to declare which language you're writing in, so that the browser and OS don't have to guess, and that you're using UTF-8, since that's basically what you have to use.