The tools

I know it's what you want to see, so let's get into what I'm using for this project.

My uses is here too.

Planning and organising

• Obsidian for tracking what needs to be done, lists and notes
• tldraw; for sketching/mapping

Design

• Affinity for vectors and photoshop-like work
• Penpot for UI design
• HTML, CSS and web components for prototyping

Website system

• Navi for the pattern library/design system (this is our internal software that we use in the studio)
• Astro for the front-end framework
• sugarcube for CSS utilities and converting design tokens to custom properties
• HTML, CSS and web components: to make everything look good and work nicely

Existing page audit

The aim of the game here is to surface the current pages landscape.

I like to do this process for the following reasons:

1. I like to be able to draw all over it in a sketch up plan (which I cover in Complete CSS FYI) to help me work out what patterns I need to account for
2. It's a useful method of seeing the scale of the design job I've got ahead of me
3. I can keep referring back to this audit to make sure I've either got a pattern covered, or I've removed the need for it all together

Map out data sources and their URL segments

I like to do this with a pen/stylus when I'm doing a project on my own, but for a client project, we'd usually use Figma/Penpot because expecting other people to read my handwriting is asking too much (as you will see).

I did this part in two passes. The optimistic pass, then after a couple of days (to freshen my mind), the pragmatic pass.

Optimistic pass

I can only apologise for my awful handwriting.

As I covered earlier in the series, blog content comes from an existing headless WordPress system and the Bluesky/AT protocol posts (and in the future, interactions and discussion) come from the @atproto/api client library.

The original idea was to merge WordPress and AT Protocol data into a shared /feed route and then, based on type/source, render in different sections of the site. The music collection will always be treated as its own little ecosystem.

Everything in this pass is idealistic. Now let's get pragmatic.

Pragmatic pass

The sections are near-enough the same, but there are less arrows. With fresh eyes, I rightly considered how stinky merging two different types could be, both technologically and creatively, so I simplified that. There's no more stream crossing, as it were.

I also did exactly what I said I would need to do in the last post too: I measured this idea against the list of problems I was trying to solve and I couldn't in good faith tell you that point 2 — "The codebase is difficult to maintain and I’ve carried over tech debt from multiple personal sites and half-baked ideas" — would not be put at risk.

I'd also mapped out the deeper integration with the AT protocol in iteration three, so at that point — especially as this is a new addition to the site — I'll render individual posts and hopefully all of the replies and interactions.

I'd also quite like to detect and give my own threads their own specific treatment too because I like to go off Online

Sketching and prioritisation

Ok, the last pit stop on our planning tour is to do a bit more sketching, but this time, the focus is on content prioritisation. Aside from the blog, music-collection and posts, the three most important pages are:

1. The home page
2. The about page
3. The links page

As I identified in the last post, one of the most important problems to fix is:

The homepage is underwhelming and doesn’t communicate what I do well at all

I'd say the same for the about page too. For too long on the web, I've leaned into reputation and social graph, but what about people who've never heard of me or seen me around? I need to make it clear to those people especially what I'm about.

For the links page, I quite like the idea of a Linktree, "link in bio" sort of thing without all the KPI-chasing weight, so it's worth sketching that too.

What is very important when doing this sort of work is that you do it fast. Your tool of choice needs to work as fast as your brain does. Sure, you can make a neater version of these guides if you need to collaborate, like we did here, but working fast and loose helps my brain, especially, remain in a focused state. If I'm faffing around aligning stuff and making stuff neat, it's busywork.

Maybe I should have been a doctor with this handwriting.

What an absolute shambles, eh? Let me break down what's going on here. I first sketch out blocks of content in priority order, from top to bottom. Sure there's a bit of layout going on, but generally this is vertically ordered blocks.

One thing to note here is that none of this process is designed to inspire UI design. Just content priority.

After I got the priority sorted, I then went ahead, annotated with blue and commented with red. This is a me thing: I need the different colours so specific types of information stick out from each other. Mostly I'm either identifying what an element does, or if it's repeatable.

Notice on the about page I didn't re-create the blocks of content? There's no point, when I can make a note that I have a repeat of the homepage or a variant of that. This is mostly there to remind me to consider both contexts when I come to do the actual UI design. I also want to retain the longform prose on my about page, but that is less important, priority-wise, so it gets pushed down.

I mapped out the links page too — I'm looking forward to working this part out especially in design. In terms of prioritisation it's pretty straightforward. "Repeat of most important" means links like Piccalilli and Set Studio, followed by icon-based social network links. This will help me map out the Astro collections too.

Lastly, because I am also a big fan of a good off screen menu, I'm going to give myself that creative freedom. I just needed to work out what went in there, aside from navigation. I've settled on links to important stuff and expanding into a sub-navigation where appropriate. For example, the sub-navigation of the music collection might free me up to simplify the music collection layout itself.

Determine an order of operations

Now I have all of this planning done and I've got my iterations worked out, I can quickly map out the order of operations:

1. Planning (done)
2. Sketching and priority guides (done)
3. HTML only shell of the site with shell components
   • Aside task: creative inspiration and scrapbooking
4. Creative UI design and prototyping
5. Core build, including design system, followed by full pages
6. Flair pass and nice touches

You see that? We're getting into some coding in the next one: the start of getting to the website's current state (at the time of writing).

See you in the next one!

I can't stress enough how even a modest amount of pre-thinking, sketching or even just making a checklist beats jumping into a code editor or design tool, regardless of whether you're doing a small ticket at work, building a personal site or even starting a whole client project. Sitting down and thinking away from the tools really helps you to consider what is actually important, what is a nice to have, how you measure improvement and importantly, what the process of iterations/cycles look like.

For me — who works obsessively in iterations — I needed to work out what I would like the end goal to look like. With that, I can map out how I get there in sensible iterations. I could just start from zero and work up to the end goal, then publish my website. It's how I usually do it! The reason I want to work in iterations this time though is because I'm determined to have a solid, scalable system that I can tinker with as I please, long into the future, regardless of how my personal technology preferences change over time.

With all of that in mind, my ideal endpoint is as follows:

I want my website to be built out of much smaller pieces that culminate in a themeable, light design system where a future redesign is a simpler job of editing a single theme CSS file and switching out some creative assets.

I'm in a lucky position with this project because we've achieved this not once, but twice in the studio already.

Then of course there's this very website you're looking at! This whole thing is a themeable system which not only powers dark mode, but also the heavily customised course landing pages and courses themselves.

Anyway, let's get stuck into some planning.

Find the pain points and measure against them

This is the live version of the final state of my old codebase on web archive, because remember, you're reading these articles in the past. Anyway, that stack was:

1. Headless WordPress for blog posts
2. Notion database for the music collection
3. Markdown-powered static pages
4. Eleventy front-end

The setup was not too heavy as far as setups generally go, but it was riddled with technical debt, regardless. A lot of that technical debt can be assigned to it being a personal website — something I built quickly and maintained very infrequently. The codebase was also over 3 years old with the CSS and markup being nearly 5 years old, from when it was a full WordPress site. The source of the technical debt, very much pointed in two places for me though:

One of the benefits of making good, or at least decent technology choices up front is the damage, even when bad, is never as bad as it could have been.

1. The Notion-powered music collection had to go. The API is slow and working on the site locally was a nightmare (even with caching). I'm also in the process of "de-Notioning" everything.
2. The WordPress system was wildly out of date and becoming cumbersome to work with in the admin areas, which meant I blogged a lot less than I could have.

That's the main sources of technical debt identified, that are worth fixing up front.

The WordPress one was easy, I just had to update as I was [gulp] several years out of date…

The Notion-powered system was also quite simple. I already have a pretty robust script I use for Piccalilli that pulls content from Notion, turns it into markdown with front matter, then downloads any media assets to a relative, local destination. All I had to do was create a variant of that script, which resulted in this big ol' pull request to migrate the content.

The music collection is now markdown files which look like this:

---
title: 'The Artist In The Ambulance'
artist: 'Thrice'
cover: '1768832680013-335.jpeg'
formats: ['Vinyl']
tags: ['Top 10']
pubDate: 2022-03-02T22:08:00.000Z
---

Who amongst us doesn't manage their music collection at 10pm?

I already know I'm doing a re-platforming, so I don't need to worry about the lower priority items of technical debt such as HTML, CSS and JavaScript I've sloshed around over the years, so let's now identify the other main issues I'm trying solve, now that I've managed to do a technical debt sweep.

The list to measure against

1. The homepage is underwhelming and doesn't communicate what I do well at all
2. The codebase is difficult to maintain and I've carried over tech debt from multiple personal sites and half-baked ideas
3. I don't feel the urge to maintain and look after the current site because I'm fundamentally not a fan of it anymore because it bores me
4. The music collection should do more to help people discover music in the places they actually listen to music
5. I know I can do much better in terms of look and feel than I have for the last few redesigns

This list of issues can be used as a measuring stick as I work through the project because if I'm not fixing these issues at least, there's no point in even bothering, as I see it. This list is a useful canonical anchor too.

The anchor is something to think back to when I'm going off pisté a bit too much and a useful method of determining whether an idea is worth pursuing. If the idea puts any of the items on this list at risk in any way, it's not worth pursuing, which I imagine, will be touched on a lot as I add those nice touches and flourishes that I will undoubtedly take too far in the flair pass.

The first and fifth issues of the list are actually tangibly related to each other. When I designed the now old version of the site you could sum that process up as "I spend all day in iA writer so I might as well make my website look like that". In short, I was lazy and crapped out the front-end in a couple of days. What I really need to be doing is more of a content strategy and look and feel strategy this time around.

We've also partially tackled point two of the list, but like I said earlier, re-platforming (which we will get to, don't you worry) and re-building properly should sort the rest. In a similar vein, point three should be addressed by the end of this process.

Work out the core features

I know where I don't want to be and where I want to be at this point in the planning, so it makes sense to actually start working out the core features of the website to find a sensible, iterative route to the end.

I ended up just making a list in markdown:

This is the point I'm making: any planning is better than nothing. If I had just started coding and designing, I might well get to iteration four quicker, but the journey there would forever be in the first cycle in this diagram, I use every day, forever and always.

Right, this feels like a good place to break off for this part one of planning. I know, I know, planning is boring but we're gonna be patting ourselves on the back, later in the project, I just know it.

Let's do some more tangible sketching-based planning, technology-based planning and a touch of auditing in the next one. Then we can open our code editor.

We set up this open working infrastructure on Piccalilli last year and although it didn't take off quite like we would have hoped, the idea hasn't died. I've decided to use this infrastructure to break down a complete redesign and re-platforming of my website, bell.bz. Sure, this is not as ambitious as a full-blown client project in the open — maybe we can make that happen still — but I'm approaching this project in a similar manner to how we approach client work, so I think it's going to be really valuable for you, our treasured readers, regardless.

I've been struggling to decide on what I want to write about this year. I feel like I've covered stuff that's very important to me — and what I believe will make you a better developer and designer — in great detail already. I focused a lot of my writing over the last few years on flexible layout systems, pragmatic CSS methodologies, being the browser's mentor instead of its micromanager and embracing core skills (often called "soft skills") as the means of producing excellent websites that work for everyone, rooted in progressive enhancement. This year onwards, I want to focus on showing you the how.

Sure, I'll publish articles — I always do — but I quite like the idea of getting my teeth into a focused writing project I can do over time because that's exactly how I (and we at the studio) design and build websites!

Why I’m doing this

At Set Studio, we’re obsessively iterative. No implementation is fully set in stone and everything can be improved in cycles, always. I plan to do this project in exactly the same manner. It's starts incredibly rough but as the iterations complete, the output becomes increasingly polished and delightful.

You can get a bit of a sneaky peek of this approach in our redesigning Piccalilli series from 2024. The process of this redesign is going to be very similar. The difference here is though is that this is a personal project, so I'm forced to work in cycles. I can't just do a big bang redesign because I've got a design studio and publication to run. What this setup does do though — which I wish could be the case with client work, which are based on budgets and deadlines — is I can pause between cycles of work to reflect on and refine everything. That's the work and that's the difference between a good website and an excellent website.

Reader, I want to help you to design and build excellent websites. It's always been my focus in everything I do as an educator. I'm going to do that by breaking this project down, piece-by-piece and explain what I'm doing and why. At points it's going to feel like I'm putting immense effort in stuff you might not think is important, but it is all important. By the end — even though I won't break stuff down line-by-line a lot of the time (I've already done that) — I hope you're going to build confidence to do this yourself, so join me over the next several posts, over the next several months as I turn my website into something I'm truly proud of and hopefully inspire you to do them same.

The format and how this series works

The format of this series is that for each iteration — which we call sprints — there will be several posts breaking it down. For example, there is an iteration that is already live — a "wireframe" version because my first priority was to start with a clean, (mostly) tech debt free codebase. Another iteration will be focusing on the UI design and design system, followed by another iteration where I focus on more deeply integrating the AT protocol, and so on.

I'm always going to be working on stuff, then publishing on a delay. It's because I make a lot of notes when I'm building and my brain is in "code mode", not "teaching mode". By spacing my time building out from explaining and reporting, I'm giving my brain time to work out the best way to communicate the lessons to be learned.

For example, as of today, this is what the website looks like.

Over the next few posts in this sprint, I'm going to break down how we got to there from this.

There has been loads of planning, sketching and of course, building that's happened between those two states. We'll get into that more in the next few articles though, so I recommend that you follow along as these posts go live via RSS or get links emailed to you.

Stay tuned.