Making on Charles Reynolds-Talbot

Apply for a clown car licence

Fri, 13 Nov 2026 19:00:00 +0000

I’m writing this on the train home from London. I left the house 14 hours ago and I’m still not back. I’m wiped.

It was a great day.

Becca, Tash and I ran a full day of training on prototyping in code with the GOV.UK Prototype Kit. There were 20 people in the room, from central government departments, the wider public sector and consultancies. Some of our own joined, because we train our people on this content too.

We started with the basics of HTML and CSS. Then the kit itself. The aim was to build a service and publish it online. The service was “Apply for a clown car licence”.

Why a clown car licence? For fun, and because nobody would believe it’s a real government service. And it’s still within the common service pattern of applying for a thing.

Little moments of joy

The best part of the day was watching people get something working.

Sure, there were parts people found frustrating. A line of code deleted by accident. Syntax that wasn’t quite there yet. But the frustration is what made it so good when the page finally loaded and they realised they’d made a thing.

There were actual little physical joy reactions. It was lovely to see.

Why we do this in person

People were at different levels, and that’s okay.

Not everything went to plan. Different organisations have put different security controls on their laptops, so not everyone could get to the software they needed, like the terminal or GitHub Desktop. That’s no reflection on anyone in the room. We worked around it where we could, and we’ve offered to follow up once people have sorted things with their IT departments.

We never stopped. Keeping a sense of the whole room while helping people one to one kept all three of us busy. It’s also why this is the sort of thing you need to do in person, so you can troubleshoot together.

Why designers should know how to code

I believe all designers should know how to code.

Not because they should become developers. There’s a sweet spot much, much sooner than that. It’s another tool in your toolkit.

It’s about understanding the medium you’re designing for. I wrote back in 2017 that interactions are made of code, not mock-ups, and I still think that. A prototype in code makes the interaction real, and that gets you better evidence from research sessions. It also leads to deeper conversations with developers, translating design intent from policy and problem to working software.

Not every prototype should be in code. But when it should, it’s better to know how than to make do with Figma or a similar design tool.

And it shouldn’t become a prototype so complex that you’ve created a whole new environment to maintain, one more before dev, test and prod. That’s why we kept repeating why we prototype in the first place. To learn something new. To communicate intent. To validate or disprove an assumption. At some point the deep collaboration with developers should be happening, and the product should be the thing you maintain.

Thank you Becca and Tash, for organising and for assertively controlling the room. You were great.

And thank you to everyone who came and gave it a go.

Designer in the loop

Thu, 15 Oct 2026 17:44:11 +0100

Anyone can prompt an AI for an output now.

A user interface. A set of personas. A service strategy. A 10-page paper. Ask, and a few seconds later you’ll have something that looks finished.

I think that’s a good thing. The lower the barrier for anyone to turn their ideas into something, the better. In that sense, everyone is a designer, and always has been. I’m a big advocate for ideas coming from everyone, and for the value of diverse thinking. In workshops, I encourage people who say they can’t sketch: words and boxes are sketches too.

So I’m not lobbying to stop any of that.

But when outputs come this cheap, it’s easy to mistake them for design that’s done. The best designers know: it’s never been about outputs. It’s about outcomes.

Why AI feels like a threat to designers

A lot of designers are worried AI is coming for their jobs. I understand why.

The people we work with are going to use it. If a stakeholder can get something that looks like a design in minutes, rather than waiting for a team of designers, why wouldn’t they? Why not skip the design process altogether, and cut the designer out of the loop?

It’s a fair question. If you boil product and interaction design down to making pictures of websites, AI can probably do that quite quickly.

But that’s not the job. It’s never been the job.

So can they do it all themselves? I’ve decided they can’t. Not because only designers are allowed to design, but because of what gets skipped: the critical thinking that design brings to a team.

Designers have always had to adapt

We’ve been here before, in smaller ways.

Once upon a time it was Macromedia Fireworks. Then Photoshop, Sketch, Figma, and now prototyping directly in code.

Every new tool changed how we work. None of them changed why.

A designer’s greatest skill is being able to adapt. That’s what gives me confidence now. Not that AI will leave design alone, but that designers have always worked out what a new tool is for, and what it isn’t. Our value in teams doesn’t disappear. It evolves.

How I’m experimenting with AI

I’m not writing this from the sidelines. I’ve been experimenting with AI for a few years, and so has my team. We’ve agreed principles and guardrails for what we will and won’t use it for. In particular, we don’t use it to generate user interfaces or graphic design that could feel imitative or derivative of other people’s work.

Most recently, I wanted to see what was possible beyond the basic generation of assets. So I stress-tested it against an end-to-end design process. What would it get right? What would it get wrong? How much could it support a team doing real-world work? And how much would it simply make up, convincingly enough to catch people out?

The briefs came from our design team away day on 30 September. We split into multidisciplinary teams and tackled three related briefs about women’s urinary tract infections (UTIs).

I took one of those briefs to experiment with AI: a patient sharing their history of UTIs with pharmacists and GPs. Crucially, I didn’t just prompt “give me a solution to this brief”. That would be lazy. It’s also the biggest risk I see when anyone uses AI.

I started by framing the problem to be solved: what I already knew, and the why. As designers, we don’t simply rely on the brief. We challenge it, pick it apart and look for the opportunities in it. Doing that here shifted the problem. It wasn’t really about the patient remembering their history. It was about showing it to a rushed GP in a way they’d believe. Proto-personas for everyone involved, from out-of-hours clinicians to pharmacists, set out what each of them needs before they’ll act on what they’re shown. From those came a set of design principles: a framework to guide every decision that followed, so each one was deliberate.

Then three genuinely different ideas, scored against those principles so the choice was traceable rather than a matter of taste. A prototype built with the NHS Design System so nothing was borrowed. An accessibility statement, written from what was actually built and used straight away to improve the prototype. And a strategy for what to validate first, and with whom.

Each step fed the next, and I made sure it kept track. Every stage includes a short narrative on how it shaped what came after, and messages to socialise with a real team at that point, to maintain shared understanding.

Transparent traceability of decisions, so everyone has a shared understanding.

Then I audited the whole chain, tagging every claim as verified, desk knowledge, assumption or illustrative. That’s provenance: being clear where each claim came from. Has it been checked? Is it drawn from existing knowledge? Is it something we believe? Or was it made up to make the design look legit?

Most of what looked like progress was assumption. Tagging it doesn't make it wrong. It shows what to test first.

Everything looked finished: the personas, the prototype, the strategy. None of it had been tested with real people.

That’s fine for a first pass, as long as you’re honest about it. What matters is calling it out, by declaring the provenance of every piece of data, evidence and decision.

I didn’t just use AI to give me a solution or a pretty picture. I used it as part of a deep design co-creation process, albeit with a computer.

I was impressed by how far it got. I’ll share more detail at some point. But I’ve only done it once, and not in a real team context. Putting it out into the world as a finished thing would be the very thing I’m arguing against: prompt, response, done.

The real risk is what people act on

What the shortcut gets you is an output. It may well look plausible.

And that’s the real risk. It’s bigger than who gets to design. AI output is so convincing that people act on it. A prototype gets mistaken for a decision. A confident summary gets treated as fact. Just because it looks right doesn’t mean it is.

So someone has to ask. Is it solving the right problem? Is it solving the problem right? Is it built on evidence, or on something that only sounds like evidence? Did anyone think critically about it, or did that step get skipped? Who does it leave out? And who else understands it, or was it made in a silo?

Those are design questions. Answering them is the job.

It took seconds to design, and it's probably the label a GP would trust most. Nobody has checked whether it’s feasible.

People talk about keeping a human in the loop with AI. I’m not saying everything has to go through a designer. But the critical thinking that design brings to a team has to stay in the loop, and that’s where designers earn their place.

They start with outcomes. Before anything is generated, a designer makes sure the whole team knows what problem we’re solving, for whom, and how we’ll know if it’s worked.

They think critically about what comes back. Ask an AI for personas and every quote in them will be written, not heard. A designer keeps the thinking traceable, and treats all of it as an assumption or a hypothesis to test in delivery, until it’s validated or disproven with real people.

It reads like a real person, and that's the risk. It's useful for starting a conversation, but not as evidence.

They look for the edges. Generated work drifts towards the average. A designer asks whose needs we’re not meeting, because those people are often the hardest to reach, and their needs the most interesting problems to solve.

They align humans. Getting a GP, a pharmacist and a patient to agree on what problem we’re solving doesn’t happen one-on-one with a computer. Designers create shared understanding, communicate it, and inject enough certainty that a whole team can make progress.

And they’re connoisseurs. Over years of experience, designers build a sense of what good looks like, and what bad looks like, mostly from getting it wrong. The best connoisseurs are connoisseurs for a reason: they have a deep understanding of users, of the problem, and of the product and technical context. That’s what lets them steer the back and forth of prompting and iterating towards something worth having. And it’s what lets them see what’s missing when something only looks finished.

I see a lot of people saying roles are changing and designers need to become prompt designers. I don’t agree. What you put into the machine is part of it, sure. But the more critical end is what comes out.

None of this is new. It’s always been the job. AI just makes it easier to skip. That’s the unintended consequence we all need to be aware of.

Using AI purposefully, as a multiplier

So this is also a message to designers. If you use AI, use it purposefully. Be pragmatic about it, not dogmatic.

Used well, it becomes a multiplier rather than a replacement. It accelerates the skills you already have instead of standing in for them.

Just be open about it. Using AI quietly, on your own, is how silos start. Openness is where shared understanding starts. So own it and say it plainly. Yes, we’re using AI. This is how.

That’s why I’m excited by the idea of using it in a structured and repeatable way. There’ll be a process. We can go through it together.

These are strong opinions, loosely held. I’m still experimenting, and I expect my position to change. Adapting is what designers do.

But I’m sure of this much. Anyone can make an output, and I hope more people do. Outcomes still need someone in the loop thinking critically.

So don’t be afraid of AI. But don’t be lazy with it either.

Be the designer in the loop.

The Dark (Mode) Web Rises

Wed, 28 Nov 2018 20:50:37 +0000

This is part 3 in a series about why we need Dark Mode to be an inclusive design consideration.

Molly Watt
Apple need a Dark Mode
The Dark (Mode) Web Rises

In 2016, I met Molly Watt.

I was inspired by Molly and her experience of living with Usher Syndrome; a condition that has left her deaf with 5–degree vision in one eye. I wrote about my immediate desire to solve some of the problems Molly faces with using digital products.

Then, in 2017, I wrote a follow up post on how Apple (and others) need a Dark Mode; a system-level preference setting that would affect the interfaces of native, third-party apps and websites.

This year (2018), we were gifted with an update to MacOS: Mojave. Mojave shipped with a system-level Dark Mode preference setting. Finally!

Turning on Dark Mode in Mojave made instant changes to the system interface and the native Mac apps. Soon after, third-party apps started to release updates that took advantage of this preference setting too; making their interfaces work in Dark Mode. But, there was still a gap: websites.

Whilst the Safari app supported Dark Mode, there was no change to the content of the websites viewed through it. Glaring white websites were still glaringly white. It felt like a giant leap in the right direction but a small step short: until now.

Give yourself to the dark side

Please, allow me to introduce you to the prefers-color-scheme CSS media query.

Media queries are used to modify a website depending on specific characteristics (print, size, orientation, etc).

Now, we have one to detect if a user has set system-level preferences to use a light or dark colour theme.

MacOS Mojave has system-level colour preferences

This feature is not yet ready for use on general release browsers but it’s coming soon. Safari Technology Preview 68 added support last month so hopefully, it won’t be long before this finds its way into a mainstream Safari release.

Add support for Dark Mode on your website

Developers can (and should) start getting their websites ready for Dark Mode. You can install Safari Technology Preview now and start designing the perfect Dark Mode theme using colours that compliment your brand and work consistently across your website.

A simple example, to get you started:

@media screen and (prefers-color-scheme: dark) {
 body {
 background-color: black;
 color: white;
 }
}

Dark by default

You might notice that my own website is dark by default. I have made this decision as it’s not only my preference but I know it works better for Molly and for users in certain scenarios (browsing at night, migraines, hangovers, etc). Designing for the few, makes things better for the many.

I’ve used the prefers-color-scheme CSS media query to target the light preference. If you are using Safari Technology Preview on Mojave and have your preferences set to light you’ll see the light theme of my website.

You do this using:

@media screen and (prefers-color-scheme: light) {
 body {
 background-color: white;
 color: black;
 }
}

The future is dark (a good thing)

I am a designer at the UK government. This series of posts started as a result of wanting to influence the design of GOV.UK (a typically white website) so that it works better for users like Molly Watt.

So far, I haven’t got very far with this. Every potential solution seemed to come with a degree of risk and complication when considering the design principle: this is for everyone.

I reckon that using prefers-color-scheme CSS media query is a risk-free low-impact solution. It will give GOV.UK a Dark Mode for the users that prefer one and remain the same for everyone else. I’m going to prototype this and start pushing to make it happen.

I’m hopeful that, the more websites (and big brands) that implement and blog about their Dark Modes, the more chance we’ll have of seeing this feature across all browsers (not just Safari).

Other platforms need to start introducing their own system-level Dark Mode preference setting to work this way too.

Look out for a similar feature coming to iOS soon.

I can’t wait to see how websites take advantage of this new CSS media query. Share how you use it: tweet me @charles_rt or toot me @crt.

Better responsive iframe for embedded YouTube video

Thu, 09 Aug 2018 08:03:51 +0100

I started to include embedded music videos from YouTube on a couple of blog posts, just for fun.

This presented an interesting challenge; YouTube videos are embedded in iframes. You can give them a fixed height and width which ensures they display correctly but then they overflow the screen on a smaller viewport. Alternatively, you can specify a width of 100% which makes the width respond as intended but there’s no way to get the height to comply and maintain the correct aspect ratio.

I searched online and found a couple of solutions; neither of which I was keen on.

Extra HTML

The first common solution I found involved adding an additional div.wrapper around the iframe and applying CSS to both. Whilst this does work, I didn’t want to have to add extra HTML for stylistic purposes. I should be able to do this job using CSS only, on the main element.

Javascript 😒

The second solution involved the use of javascript which I wasn’t interested in. If I can get away with it, I don’t want to use any javascript on this site.

A better solution using calc()

After [a lot of] trial and error, I discovered a great use for calc(). The calc() function lets you perform calculations on CSS property values.

The clever part that makes this work is knowing the width of my main content containing block: 512px. I don’t need to worry about the iframe being responsive beyond this width. I know the width it should be. I can specify the appropriate height for a 16:9 widescreen aspect ratio.

I set width: 100%; as this should always be true even though I know the exact width it makes things simpler later. I then set height: calc((512px / 16) * 9);. Technically, I don’t have to do this. I could calculate the height manually as it won’t change when the width is above 512px but I’ve left the calculation in so you can see what changes later to make the magic happen. (512px / 16) * 9 equals the correct height for a 16:9 widescreen aspect ratio when I know the width is 512px.

When the viewport is narrower than 512px, I use a media query to make the iframe respond accordingly. The width is already set to 100% so I don’t need to worry about that. It’s the height I need to start responding at the correct size to maintain a 16:9 widescreen aspect ratio. The width of the viewport is suddenly very relevant to help achieve this. I am able to find out what the width of the viewport is by using vw as a measurement unit.

vw is equal to 1% of the width of the viewport and the browser knows what this is whenever it changes. I can use the measurement of 100vw in my calculation to track the width of the viewport and serve up the right height to maintain a responsive aspect ratio with height: calc((100vw / 16) * 9);

iframe {
 width: 100%;
 height: calc((512px / 16) * 9);
}
@media (max-width: 512px) {
 iframe {
 height: calc((100vw / 16) * 9);
 }
}

That’s it: a better responsive iframe for embedded YouTube videos using CSS only, on the element.

Dat’s the way I like it

Fri, 03 Aug 2018 19:10:07 +0100

I committed to supporting a decentralised peer-to-peer web by serving my site over dat:// as well as https://. Since starting this I have been stumped as to how to make my url over dat:// friendly, because dat://59278ae8cc9d27492b4a0a5d4392ff3c913aebd8fa079760ce732f26b70c4eef (open in BeakerBrowser) is just mean.

I could see other sites had achieved this. Beaker’s own site does exactly what I wanted with dat://beakerbrowser.com/ (open in BeakerBrowser).

I read several docs about it and kept getting confused to the point that I’d give up, hoping to return later with a fresh mind and try again.

Eventually, I have succeeded and it is ridiculously easy so I’ll share a simple step-by-step guide so you don’t have to do through the same pain.

Create a folder called .well-known in the root of your https:// served directory.
Create a file called dat in that folder.
Add the following code to that file, replacing {key} with the mega long dat URL key to your site. Fe, dat://59278ae8cc9d27492b4a0a5d4392ff3c913aebd8fa079760ce732f26b70c4eef
```
dat://{key}
TTL=60
```
Save and upload to wherever you host your https:// site.
Now, visit your site in BeakerBrowser but use dat:// instead of https:// as the URL and automagically it works 🎉

dat://charlesrt.uk is finally working and it turns out it was easy peasy hotdog squeezy.

This is my baseline

Thu, 26 Jul 2018 16:47:08 +0100

I’m throwing caution to the wind and forgetting about global CSS resets like normalize.css and Eric Meyer’s reset.css because:

I’m not convinced I need to make use of everything in these resets (I don’t even know what <kbd> is 🤷‍♂️) or support all the browsers they attempt to. Does it matter if someone visits my tiny website in IE8 and something doesn’t look perfect? I’ll give you a hint: no.
They’re pretty bloated because they’re trying to fix everything for everyone. I don’t need 341 lines of code before I’ve even written a line of my own.
There’s no point in resetting something that I’m just going to override later. I should declare the values I want to set and forget the reset.

This is my master plan: to lay only the CSS foundation I need to—when I need to—and layer on my opinionated component styling to serve as my own default for building websites: my baseline.

My Baseline

This post is out of date relative to the CSS I’m currently using on this site. I will update this and create a repo as soon as possible.

:root {
 font-family: system-ui,
 -apple-system,
 BlinkMacSystemFont,
 "Segoe UI",
 "Roboto",
 "Oxygen",
 "Ubuntu",
 "Cantarell",
 "Fira Sans",
 "Droid Sans",
 "Helvetica Neue",
 "Apple Color Emoji",
 "Segoe UI Emoji",
 "Segoe UI Symbol",
 sans-serif;
 font-size: 16px;
 line-height: 1.5;
 overflow-wrap: break-word;
 -ms-text-size-adjust: 100%;
 -webkit-text-size-adjust: 100%;
 -webkit-font-smoothing: antialiased;
 -moz-osx-font-smoothing: grayscale;
 -webkit-tap-highlight-color: transparent;
 background: black;
 color: silver;
}
body,
blockquote,
figure {
 margin: 0;
}
main {
 display: block;
 max-width: 512px;
 margin: 0 auto;
 padding: 0 1em;
}
h1,
h2,
h3,
h4,
h5,
h6 {
 font-weight: bold;
 font-weight: 800;
 line-height: 1;
}
h1 {
 font-size: 4rem;
 margin-top: 4rem;
 margin-bottom: 4rem;
}
h2 {
 font-size: 2rem;
 margin-top: 4rem;
 margin-bottom: 2rem;
}
h3 {
 font-size: 1.5rem;
 margin-top: 2rem;
 margin-bottom: 1rem;
}
h4 {
 font-size: 1rem;
 margin-top: 1rem;
 margin-bottom: 0.5rem;
}
p {
 margin-top: 1rem;
 margin-bottom: 1rem;
}
a {
 color: aqua;
}
a:link,
a:visited {
 color: aqua;
}
a:hover,
a:active,
a:focus {
 color: yellow;
}
img {
 max-width: 100%;
 height: auto;
}
figcaption {
 color: gray;
}
pre,
code {
 background: navy;
 color: gray;
 font-size: .875rem;
 letter-spacing: .05rem;
 padding: .125rem .25rem;
}

Let’s break it down.

Images

One of the immediately obvious problems viewing my website using only native browser styling is how images are rendered: huge. Well, full size to be fair, but in all circumstances that full size is much bigger than your average viewport. On mobile it’s just ridiculous so let’s add some CSS to take care of this.

img {
 max-width: 100%;
 height: auto;
}

By using max-width: 100%; images will confine themselves to the <figure> element and stop overflowing the viewport. Aspect ratios are kept in check with height: auto;

Before

Clearly there's a problem with lack of default img styling.

After

Much better. Now you can see me, Chris and the legendary Jake Knapp.

Margins

Now my images are in control it’s clear there are some unwanted margins present. It might be necessary to play with the content rhythm later but that’s a conscious design decision that’ll need be made. In the meantime everything should be aligned consistently.

body, blockquote, figure {
 margin: 0;
}

Before

Browser defaults have made design decisions for me.

After

Consistent alignment but too close to the edge.

All content is now aligned to the very edge of the viewport and is only constrained by the width of the users browser. This isn’t ideal and can make for some lengthy reading lines.

I’m going to solve this problem by wrapping the dominant content of the page in a <main> element with a maximum width of 512px. This keeps line lengths appropriate for better readability. The content block is centred with auto margins left and right, while a little padding keeps content off the edges of smaller viewports.

main {
 display: block;
 max-width: 512px;
 margin: 0 auto;
 padding: 0 1em;
}

Better

If only, browsers did this by default.

Typography

I’ve already started to address some typographic defaults by setting a maximum width on the content to maintain a readable line length. Time to get serious.

System fonts are the new black. All browsers should use system fonts by default. This means my website will use the same core font as the device you are using. Fe, San Fransisco on iOS or Roboto on Android.

Let’s go through them:

system-ui is future proofing this concept and the latest versions of Safari and Chrome already use this so eventually we don’t have to maintain a huge stack.
-apple-system, BlinkMacSystemFont is for Apple device users and dynamically uses the correct font depending on size between San Fransisco and San Fransisco Display.
"Segoe UI", "Roboto", "Oxygen", "Ubuntu", "Cantarell", "Fira Sans", "Droid Sans" take care of every other operating system I could find.
"Helvetica Neue" is for legacy Apple devices.
"Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol" force the use of the devices emoji fonts which are often more up-to-date than the browsers.
sans-serif if all else fails.

Not all browsers share the same font-size and line-height so setting defaults for this ensures consistency and provides a base to build off. 16px and 1.5 are a great default for better reading.

On occasion, I display full URLs as part of links in content. If lengthy, these can overflow the <main> container and cause some unwanted side-scrolling. overflow-wrap: break-word; stops this from happening.

The text-size-adjust declarations stop mobile browsers from scaling your text causing rendering issues. Why they do this: I don’t know.

It’s good to use font-smoothing to make text lighter and easier to scan. This also helps prevents occasional flicker on load or scroll and takes some load off browser performance too.

Finally tap-highlight-color hides the flicker that happens when you tap an element on mobile devices. I’ll need to ensure I have suitable hover states later so users get feedback to their interaction.

:root {
 font-family: system-ui,
 -apple-system,
 BlinkMacSystemFont,
 "Segoe UI",
 "Roboto",
 "Oxygen",
 "Ubuntu",
 "Cantarell",
 "Fira Sans",
 "Droid Sans",
 "Helvetica Neue",
 "Apple Color Emoji",
 "Segoe UI Emoji",
 "Segoe UI Symbol",
 sans-serif;
 font-size: 16px;
 line-height: 1.5;
 overflow-wrap: break-word;
 -ms-text-size-adjust: 100%;
 -webkit-text-size-adjust: 100%;
 -webkit-font-smoothing: antialiased;
 -moz-osx-font-smoothing: grayscale;
 -webkit-tap-highlight-color: transparent;
}

Before

This looks a little unpleasant and the browser doesn't understand the latest unicode [emoji] characters.

After

A much better default.

Colour

Colour choice can be highly opinionated—such as my desire for ‘dark by default’ user interfaces—but there’s sound reason behind it you can read more about in Apple and others need a dark mode for people like Molly Watt.

Where possible, baseline colours should aim for strong Level AAA contrast ratios. Whilst Level AA is the minimum, there is rarely a need to go so low and higher contrast can be better for everyone. However, go too high and you could be introducing unwanted glare.

Be mindful of the colours you choose. This is where colour choice is less about opinion and more about responsible selection and use.

Another thing to be mindful of is links. Links are the cornerstone of the internet so it’s surprising they’re still not handled well by default.

Hover states should always be honoured regardless of whether the link has been previously visited or not. On that subject, visited links don’t need their own distinguished style; they should be styled the same as regular links. Don’t forget about focus states for keyboard users.

:root {
 background: black;
 color: silver;
}
a {
 color: aqua;
}
a:link,
a:visited {
 color: aqua;
}
a:hover,
a:active,
a:focus {
 color: yellow;
}
figcaption {
 color: gray;
}
pre,
code {
 background: navy;
 color: gray;
}

After

Dark by default; Level AAA colour contrast.

Font size and margins

A lot of CSS resets aim to do just that: reset. They take away any browser styling and make everything the same so you can declare the values you want after—but. You can do this anyway. There is no need to reset a value. Just declare your own from the outset.

I enjoy working with multiples of 8 and only tend to deviate for certain elements. You can achieve good progressive size and spacing this way: 8px 16px 32px 64px 128px.

I use rem as it’s easier to work from my root em measurement which is 16px.

h1,
h2,
h3,
h4,
h5,
h6 {
 font-weight: bold;
 font-weight: 800;
 line-height: 1;
}
h1 {
 font-size: 4rem;
 margin-top: 4rem;
 margin-bottom: 4rem;
}
h2 {
 font-size: 2rem;
 margin-top: 4rem;
 margin-bottom: 2rem;
}
h3 {
 font-size: 1.5rem;
 margin-top: 2rem;
 margin-bottom: 1rem;
}
h4 {
 font-size: 1rem;
 margin-top: 1rem;
 margin-bottom: 0.5rem;
}
p {
 margin-top: 1rem;
 margin-bottom: 1rem;
}
pre,
code {
 font-size: .875rem;
 letter-spacing: .05rem;
 padding: .125rem .25rem;
}

8 16 32 64 128.

Making progress

Wed, 25 Jul 2018 10:23:59 +0100

Things are still looking basic but I'm making progress

I’ve had some time away and I’m mostly relying on train journeys to make updates so progress has been slow but I’m getting somewhere.

All of the important content from my previous website build has been migrated and is better structured from a directory perspective. Redirects are in place to ensure I don’t break the web and I have a Gulp task running to compile Stylus (my preprocessor of choice) into CSS.

I’m ready to think about my design goals and how I will structure the content better for the user so that navigation is contextual and I’m getting across the right message and flow.

Before that, I’m going to consider what a good baseline CSS should be.

Style.less

Wed, 11 Jul 2018 09:54:15 +0100

No style here

Right now, things are looking a little basic.

Style Attribute {
 🤷‍♂️
}

The plan was to get the website up and running and let your default browser styles do the work, then carefully layer on top the bare minimum required to achieve the design goals I set.

You’d think I would have done more research into Hugo before choosing it as the framework to rebuild my website. It turns out it doesn’t natively do any CSS preprocessing. I don’t know why I assumed it did—I guess because so many static site generators do.

This isn’t the end of the world—I do know how to write in vanilla CSS—I’ve just gotten used to writing in syntax, like less, and taking advantage of the power that has to offer, such as variables, mixins, etc.

Not to worry. I’ll take a small break to add some sort of Gulp task and do some of the mundane work that needs doing first; like migrating all my old blog posts and making sure redirects are in place so as not to break the web.

Design goals

Wed, 11 Jul 2018 09:40:39 +0100

Design decisions will be based on a combination of the assumptions I make on what people might want, and the message and flow I want to get across.

I also want to achieving the following goals:

move away from Jekyll and build my site with Hugo which I’ve had my eye on ✅
use only contextual navigation; no “I don’t know what I want” menu
focus on typography; include emoji (the universal language of the future) at every opportunity 😉
allow for long and short form posts
create an owned space for my content to exist first before sharing to centralised social networks.

I’ll add to and revisit this list of goals as I go.

Hello World

Wed, 11 Jul 2018 08:24:18 +0100

A screenshot of my zero dawn refresh served over the peer-to-peer web via Beaker Browser. It works!

I have been meaning to redesign my website for a long time. I want to do more than just another re:skin so I am starting from scratch and designing the site live; partly to open my process to others who want to see and learn, partly to hold myself accountable so I do it properly.

Live design: means more than just having my code commits in the open on Gitlab. Instead of large wholesale design changes magically appearing on the internet, each individual change I make can be tracked live over dat:// the peer-to-peer web, enabled by the Dat Protocol. If you use BeakerBrowser you can turn on live reloading, to experience changes and blog updates auto refresh, as they happen. This, essentially, allows me to create a live blogging engine without any additional code.

You will still be able to refresh [the old fashioned way] over https:// if you use any other browser.

I can’t promise I will blog about the reason behind every design decision: but I will try.

This, is all part of my commitment to support a better, open and decentralised web for the future.