Adding favicons was surprisingly easy with the use of modern Web tools. The last time I tried to do this for Intergrid, it took some time to figure out and configure and put out. It seems that I've used a worse tool back then.

This time, I put "favicon" into search, and one of the sites that came up was this one, called Favic-o-Matic. Silly name, but it did its job superbly well: I am now equipped with all kinds of icons for all kinds of purposes.

One of the things I did immediately was optimize the PNG icons, given that they each had a bit of heft to them that I wasn't comfortable with. They are by no means perfect right now, but they're perfectly workable, and each of the PNG icons weighs under 1kB. I achieved this (from their usual 3~5kB) by reducing the colors down to 4: testing with different color sizes made it apparent that 2 was too few for a pretty image (it was all jagged at angles, which is where half-pixels reside), while 4 made for tiny yet nice ones. Any more, and the quality does not change significally for the better, yet the size grows noticably.

The ICO file itself – the format that used to be the foundation of site icons for a while – is 34kB, but I'm not worried about it, given just how widely browsers support PNG icons nowadays. As long as it isn't a major obstacle to getting the site to work (which it isn't), I'm content with letting it stay as it is while I work on other items.

Since adding favicons required me updating every live page, I thought I might as well add the "jump to content" link. This is useful for people who navigate the Web via keyboard: pressing Tab lets you jump to the next anchor (which is usually a link) on the page. "Jump to content" links allow keyboard users to skip navigation menus and such (which, in my case, is directly "in front of" the content, so to speak) and move directly to the thing they may have come here to see. This should also help those users who rely on text-to-speech for navigating the Web, but I don't have enough data or experience to say that with certainty.

Something I've been thinking about for a while is exposing my redlist. A redlist is a list of things to fix, named so because red is generally the color of errors and priority messages. Exposing the redlist online is in line with my policy of exposing my errors, in ways that both helps others learn (nobody is perfect; in an age where everything is tempered towards utter perfection, this is refreshing to learn and be mindful of) and allow me to improve (when visitors suggest ways to fixing this or that problem).

Given how much maintainance this site already takes, I'm considering publishing the redlist raw, in the same way I take care of it: a Markdown file, with idiosyncratic notation and terminology, sans any styling. Making it into its own well-formatted HTML file after every change feels like another task I'm not up to, considering it is, after all, an internal document. (Build automation might help with this when it comes.)

I'll have to think about it.