Firstly, I’m so sorry for anyone subscribed to my RSS feed that just got spammed. I made some big changes to the site, but I’m confident this will be the final time.

Secondly, I went and did it. At the end of my first-year celebration post in March, I talked about changing some core parts of this site. Namely new static site generation (SSG) and fixing the janky CSS. Quite frankly, I thought that would be all that was needed, but over the past few months I’ve grown less and less satisfied with everything. Since March I’ve barely used the site, even though I wanted to add stuff to it. I also was growing quite dissatisfied with the aesthetic appearance, I don’t think the old design was terrible, but I felt like it was missing something important. At it’s core it lacked concept and identity, and figuring that out gave me the drive I needed to finally do this.

---

Re-thinking the process

From the start, I had three central goals I wanted to achieve. Each would both limit and influence the other, but getting a balance would be possible. The first and biggest for me was compatibility, the old design quite frankly was not usable on older browsers thanks to css variables and other modern features. To achieve this, I set NetSurf as the target browser for this new design. This presented some challenges, since NetSurf doesn’t have full coverage of css and html (even pre css3 and html5 specs).

Which leads into the second goal: design. This site has always been built around the idea that good design on the web doesn’t need to cost an arm and a leg, and this time I wanted to really prove that. I knew that overall, the communication of content and navigation could do with a boost. But also that I wanted to push the core identity of the site using just design. To best accomplish this, I decided to ditch the vibrant colour-based design of the old version in favour of a greyscale, shape-focused identity.

Lastly, the final goal was speed. I’ve always put a ridiculous amount of time into improving the speed, namely load times, of the website. This was almost always done by hand, and I knew it frankly wasn’t as efficient as it could be. I set out on this redesign aiming to improving almost everything, from images and fonts to css and html.

Altogether, I feel each of these goals represent a different kind aspect of accessibility on the web. Accessibility on the web is often thought of as the interaction between a site and users with disabilities, however I would argue that this term can also extend to the ability for all users to access your site in the first place. Keeping a website consistent across all connection speeds, devices and browsers, means greater power to the visitor.

Visual Language

The first problem I attempted to tackle was the visual design language. I took a deeper look at the content of my old site, as well as things I had to hack in along the way, and I quickly realised the content had many different contexts on the site that wasn’t well communicated.

I good example of context being communicated on sites would be codeblocks, the containers commonly used to display lines of code on a webpage. These almost always have a CSS styling to differentiate the content inside from the rest of the text on the page, without it there would be clear confusion. On my old site, there were many confusing cases like this. There was no distinction between content types.

I started by sketching some ideas out in inkscape for what different content types I would need to make, as well as how they could be styled. Which directly lead into prototyping these ideas on the site. I ended up with a large range of what I’m calling “Content Widgets”, which can be viewed together on the test page.

These widgets have made life incredibly easier when working on content, and also provided a much simpler model to reference when designing. They’ve made the vision of my content-rich wiki possible, while making the user experience of the website far better than it was before.

One of the core ideas I wanted to express in the site was the use of abstract shapes instead of logos and wordmarks. These ended up being called “Pieces”, and have served as the central pillar of the strong identity the site now holds. I want to experiment more with these in the future, and attempt to integrate them even further into the website.

Static Site Generation

At the end of my last blog post, I spoke about getting rid of Hugo in favour of a python-based SSG. I had gotten really frustrated with Hugo at that point, and the large amount of hacks I had to employ to make simple pages proved too much. I was certain the solution was held in making my own SSG, or using a more customisable one.

Then in June, right as I was thinking of starting this move, LOW TECH MAGAZINE launched their website rebuild in a blog post. Marie and Roel put a incredible amount of work into moving their site from a Python static site generator to Hugo. You can probably see where this is going already, but LOW TECH MAGAZINE’s main site is run on solar power and efficiency is of huge importance, so to make their decision they ran some tests. You can see the results in the footnotes of the post, but Hugo was far faster at generation.

This motivated me to try Hugo one last time.

I was driven largely by the fact that I already had knowledge of using Hugo, so I could jump right in rather than learning a whole new system. This let me see the possibilities of Hugo almost immediately. See, Hugo is canonically used for Blogs and blog-type sites, the idea being you make up a bunch of templates and then all you have to do is write content (while Hugo handles absolutely everything else). Trying to use Hugo in this automation-first way was where I fell on the old site. What I needed to do instead was use Hugo like an assistant, making use of the best of both worlds.

Which is essentially what I’ve done. I stripped the entire site back to sheer basics, each page simply passes on the content from my markdown files and generates a page. It does add the head, header and footer, and the rss feed is automatically generated, but that’s it. Every page on the site is now essentially hand-written. This allows me a huge amount of control over how pages are laid out, and also facilitates pages having different kinds of content together. I wanted this feature especially in my wiki, the old site was a plain and hard to navigate grid of boxes that linked to pages, whereas now it can be far more interesting and full of information.

The only major downside to this all has been the new dependency on shortcodes. Shortcodes in Hugo are custom markup syntax that controls how the content inside is rendered, and is used to create all the content widgets and other things like images. These have to be manually written out each and every time, and while I’ve tried to design them to be less tedious, it’s still some friction I’d like to try eliminate in the future.

But the final results are something I’ve proud of, I’ve got a far greater understanding of the generation of the site now alongside far greater control of everything, which will go a long way.

‘Old School’ HTML and CSS

Slight tangent, but I first learned to make websites about ten years ago now in a weekend coding club of sorts. Back then one of my most vivid memories about it all is how new HTML5 was, since then it feels like the web space has grown and expanded a lot. This time period incidentally lines up with when NetSurf was majorly worked on last, or at least from what I can tell. In a sense, my target for the HTML and CSS portion of the redesign is roughly a browser from 10 years ago.

This meant that in order to make a responsive site for all devices, I couldn’t rely on flex boxes, grid layouts, calc values and other incredible useful modern features. But ultimately, these constraints led beautifully into the design of the site, contributing to much simpler layouts and better thought out features. From what I can tell as well, NetSurf’s implementation of HTML and CSS is very literal. Where some syntax may pass in modern browsers, it wouldn’t in NetSurf, something which I feel made me a better web designer by helping me understand what I was doing better.

I did have to take several liberties here and there. For example I used clamp values for things like the font size of page titles and window padding in order to preserve the layout properly on screens with very small resolutions. These have respective fallbacks to be used if necessary. Alongside that, there’s some features like :hover and :active selectors that I use which NetSurf hasn’t implemented (yet?), as well as fit-content widths, z-index and font-family. These ultimately mean that my site isn’t entirely targetting NetSurf, however these features are essential in my eyes to the user experience and design of the site, so exceptions were made.

As challenges go, aiming for a less-modern set of HTML and CSS managed to result in better decisions and more solid web design, something I really didn’t expect going into this.

Making things small

And now for my favourite part: making everything as small as humanly possible.

There’s always the same two offenders when it comes to web pages being too large, custom fonts and images. In the past, I’ve tried various different methods to wrangle and control these issues, with decent success. However this time I knew I could do a better job.

Fonts

I decided to use keep using the two fonts I have always used with this site, Barlow for headers and League Spartan for content. I made a couple of changes, going for the next weight down for Barlow since black was unreadable at smaller sizes, and then swapping out the variable font of League Spartan for a non-variable (in order to improve compatibility with older browsers).

While my old font optimisations were doing manually, using FontForge, this time I gave a tool Thomasorus recommended to me called glyphhanger. Essentially it’s a font subsetting tool (removing unused characters), but most interestingly it can automatically crawl a given website and subset your font based on the content of said website. Even better, you can tell glyphhanger what font-family to look out for and it will only crawl text set to that font! What this means is that using glyphhanger will give you a set of fonts that only contain the characters used in your site, the epitome of optimisation!

The results really speak for themselves: ~19kB total for both fonts loaded. This is in comparison to a roughly 28kB total on the old site! (League Spartan alone being 16kB). I expect the total number to fluctuate up a bit as I add more content to the site, but I really cannot complain at the results.

Images

If I was to discuss this in it’s totality, it would be far, far too long. But to cut it short: I did a lot of research, which I plan to cover on the web wiki really soon.

Cutting down images as small as I can has been a rather big obsession on this site. I’ve spent countless hours testing and trying different things. Ultimately, my goal has always been the same: get the size down, but don’t compromise the information inside. This time round, I’ve decided to be far more experimental.

Through my research I found that jpg is still the king of full colour images, providing decently small file sizes with little to no loss in visual information in return for a slight loss in quality. However, thanks to some inspiration from TenDigit’s new redesign of their site, I decided to incorporate low-colour images into the site. You’ll find these as furniture to pages, photos with no real impact on the delivery of the content, purely for aesthetics. These are coloured using the site’s greyscale theme, typically with between 3 and 8 colours. It’s here that png really excels, producing images with filesizes far smaller than I could achieve with jpg at the same quality and sharpness.

This likely wont be the end however, as I continue to perform more detailed research into this topic.

CSS

It’s fair to say I truly poured over the css for the site as part of this rebuild. Before, it was quite a mess and rested at around 5-6kBs in size. During the process of designing the stylesheet, I realised that a 3kB css file was within the realm of the possibility in the design. I spent many, many days simple combing over the file to see what miniscule changes or efficiencies could be eked out of it. Several times it did in fact dip under 3kBs, but in the end I made some small additions to improve user experience that leaves the final size of the CSS at 3.36kBs. I’m still really proud of this, if I didn’t include WOFF files for the fonts, then I’d have easily made it to 3kBs flat.

Conclusion

For a long time, I’ve sought to make my personal website an example of my philosophy that good design on the web doesn’t need to come at a cost of performance or user experience. I think I can finally say that with this redesign, I have finally achieved this goal.

Alongside this, I’ve finally become excited again about actually using this website. When friction builds up in the system, you will inevitably stop using it, and now with it gone I can finally begin expressing this site even further than before.

I want to thank all the people who have been following me along building this site, as well as it’s redesign. And for all my friends for providing incredible feedback and advice.

Here’s to d00k.net, and this design lasting a little bit longer than the last one!

- Dook