UP | HOME

Web design checklist

Before redesigning this website, I decided to write down a checklist. The w3m test guided me before, but that's not enough, and not even a serious approach. Most of the sections here are written from two perspectives: that of a user, and that of a webmaster.

1 JS, cookies, ads, etc

JS may be useful (or at least not harmful) in rare cases, and even cookies may be useful, if you set a reasonable expiration date and store something actually useful in them, but more often than not they are just abused and harm UX.

As a user: noscript, self-destructing cookies, ublock or adblock, privacy settings, etc. Turning JS and cookies off completely may also be an option, especially in a separate browser instance/profile – keeping another one for the things where those are required.

As a webmaster: try to avoid them. If you can't, still be prepared that some users will do that. Perhaps the best strategy is to implement essential functionality without relying on those, and additional features with them.

2 Fonts

Perhaps the only way to get legible fonts everywhere as a user is not just to disable font loading, but to disallow pages to choose fonts, to limit their ability to change font sizes, and to configure the fonts for oneself.

As a webmaster, simply don't touch them. Even though not many users will disallow websites to screw their fonts, very few of them have fonts so bad that they require fixing by the means of CSS, and which can be fixed that way; it is much easier to just make things worse. Also, not assuming that users are stupid is a nice (even if wrong in most cases) thing to do. To be fair, very slight relative size changes may be useful, as well as size changes in specific cases, and perhaps setting font families (sans, serif, mono) – but that's it.

3 Colors

Here's a relatively tricky part, for it is not binary. A user may leave colors be, or change the defaults, or rewrite the colors. As a user, I'm currently rewriting them. An issue with FF color overriding is buggy input fields styling though.

But as a webmaster, I'd like to cover all 3 cases. Complete color overriding by a user is not a problem if you are following basic accessibility guidelines, such as not using background images for regular images, duplicating image data with text, not relying on colors, and so on. Colors simply become irrelevant.

But here is what's tricky: if you don't use colors at all, then users with default settings are likely to see a rather appaling page, but if you set them – then users with altered default colors won't get their preferred values. Though they are rarely getting those anyway, so it should be fine to set some colors. Just keep good contrast, don't rely on them, don't rely on background images alone to serve as background, and don't forget to set background and foreground colors together.

In a perfect system, a user would be able to pick reference colors (background, text, link), and a web page would be able to generate a color theme using those; alas, it's not the case here.

And, of course, usual color-related guidelines should be followed when picking color themes: sufficient contrast ratio that isn't getting screwed by background images, but not black-on-white or white-on-black, nice colors, not too many of them, etc.

4 Usual accessibility

Here are the things that can't be changed by a user in a reliable and simple way – such as page layout, alternate versions (~link rel="alternate"~), the possibility of keyboard-only control (with e.g. vimperator), standards-compliance, and all the other W3C recommendations. So they should be preserved by a webmaster.

5 Styling

Once HTML is ready, one should figure how to style the page in a way that would look nice with different settings. Paddings, margins, flex, and borders shouldn't harm; background-color-independent images, particularly SVG (making use of currentColor), and possibly with transparent backgrounds, should be nice for styling as well. I always liked minimalistic designs, but a few pictures can make a website to look considerably nicer – though they are not easy to make nice enough, and probably they harm designs more often than improve them.

6 Sizes

Relative (particularly font-relative) length units should be used for pretty much everything; just things like border widths may use pixels.

Main (content) div width is quite tricky: while one shouldn't reinvent OS and browser functionality, or to assume that users can't resize windows, in practice it may not work that well: users may just not wish to resize the windows all the time, since plenty of websites require a rather high resolution, so if it's not limited, lines may get too wide. A somewhat fine solution is to set max-width in ch.

7 Conclusion

Fortunately, it is still possible to both get and provide relatively nice web pages. Now I have a checklist, and will try to redesign this website someday soon.