5 years ago, if you were looking for a free photo management website you could host yourself, Koken was a great option. I started with Koken for a photography client in 2014, and decided upon it based on the great documentation and very easy theme development.

Note: I would highly suggest against anyone setting up a new Koken site now. I'm not even sure if it's possible! This is for people maintaining their existing sites.

History of Koken

Koken's public beta was released in Early 2013, and got fairly popular pretty quick. It's creator Todd Dominey nailed what photographers wanted and needed from a self-hosted CMS. Although it became stable and fairly well-supported, it never made it to 1.0.

Fast forward a couple years and in 2015 Koken is bought by NetObjects, a software company which in the 90s had success with a desktop site-builder.

NetObjects continued to update Koken for around 2 years (although focusing on premium functionality), with the last release of v0.22.24 in August 2017. As far as I am aware, there has been no further development of Koken since then. The help centre and social media was active for about another year before they also had no further updates.

As of 2020 Koken still functions, but has some major issues. The store and documentation went offline sometime around the end of 2019 which obviously makes development harder and prevents the easy installation of themes, plugins, and even causes issues with logins on some older versions.

There was a Community Koken Forum called Koken Community, but as Koken died it went not long after, understandably given the lack of any official support.

My relationship with Koken

Every few weeks I get a message on twitter or an email from someone asking for help with their Koken site. This is because I have the 'honour' of being the last tweet on Koken's twitter @koken. In 2017 I developed a theme for Koken for the previously mentioned client called Monolith. Over the end of 2017 and early 2018 I refined this and released it onto GitHub open-sourced under a GPL-v3.0 license. At this point I was unaware of the problems going on with Koken and perhaps had I known that client would be on a different platform.

Since 2017 I have been maintaining a Koken site, and have encountered a few problems that I am consistently asked about. These are my fixes for them, I hope they help!

Note these are all made on v0.22.24 and may differ for previous versions.

"Cannot connect to the API" on login, PHP 7+

When using Koken with PHP 7+ (confirmed on PHP 7.3 and 7.4) and visiting /admin/, you may get a red error box appear with "Cannot connect to the API" without any further error message. Usually this appears with a database error etc, but this is code related. To fix it:

In your installation, find /app/database/DB_Driver.php and take a look at line 1018 and you should see something like this:

else
{
	$args = (func_num_args() > 1) ? array_splice(func_get_args(), 1) : null;
	if (is_null($args))
	{
		return call_user_func($function);
	}
	else
	{
		return call_user_func_array($function, $args);
	}
}

Now, replace line 1028 (the $args declaration) with the following two lines:

$func_args = func_get_args();
$args = (func_num_args() > 1) ? array_splice($func_args, 1) : null;

The code should now look like:

else
{
	$func_args = func_get_args();
	$args = (func_num_args() > 1) ? array_splice($func_args, 1) : null;
	if (is_null($args))
	{
		return call_user_func($function);
	}
	else
	{
		return call_user_func_array($function, $args);
	}
}

Images not loading, PHP 7+

You may not notice this immediately if you have images cached, but if you cleared the cache or uploaded a new image you may find it is not rendered. This can also occur in PHP 7+ (confirmed with 7.3 and 7.4) and is another easy fix.

Find /i.php in the root of your installation. On lines 13 and 14 there is the following:

require $root . '/app/koken/Shutter/Shutter.php';
require $root . '/app/koken/Utils/KokenAPI.php';

Replace those lines with:

require_once $root . '/app/koken/Shutter/Shutter.php';
require_once $root . '/app/koken/Utils/KokenAPI.php';

You also need to open /app/koken/Shutter/Shutter.php and on line 274 replace the following:

include dirname(__DIR__) . '/Utils/KokenAPI.php';

with:

include_once dirname(__DIR__) . '/Utils/KokenAPI.php';

Forgotten Password

First try to enter a wrong password and click the "Forgot Password" link that appears in the bottom right. This is the easiest way on more recent version of Koken

Unfortunately however it seems that previous versions relied upon store.koken.me in order to offer forgotten password functionality. We can still reset the password, but it's a bit more manual.

You need access to your koken database for this, whether than be through phpmyadmin, another database management tool, or mysql on the command line. I won't bore with the exact commands/clicks required for each, just the general process.

1. Gain access to the database. If you don't know the login details, you can find them in /storage/configuration/database.php;
2. Go to the koken_users table. This should have only one entry, your user with associated email etc;
3. Copy the internal_id for the user;
4. Then go to "http://yourwebsite.com/api.php?/users/reset_password/" with the id at the end of the URL;
5. Visiting that link should send the email attached to your account a new password

Conclusion

If you haven't gathered from the rest of this post, unfortunately Koken is dead. I will continue to maintain a Koken site as my client cannot afford the cost of a rebuild and relies upon the Lightroom integration, something I haven't seen anywhere else. I would however say you shouldn't be setting up any new Koken websites, and if you still have one you should be seriously looking at alternatives.

There is a change.org petition calling on NetObjects to open-source Koken but I am not hopeful. They are a commercial software company, and most software companies will cling to thier code to the end.

A couple of people have asked me about alternatives now, so I've included a list below. Unfortunately there's nothing quite like it Koken but hopefully one might fill your needs

If you have any further issues with Koken then feel free to leave a comment and I'd be happy to help.

Koken Alternatives

Custom-built website

As a freelance developer I am more or less obligated to suggest that if you have the money, the best solution you will get will be through a web developer or development agency. This can be the design you want and function exactly as you need. If you're interested in my services as a developer or want some throughts on what you need, feel free to get in touch.

Hosted Photography Solutions

There are hosted photography portfolio services out there including:

• Pixpa
• Photoshelter
• Format
• Clickbooq

I haven't used any of these platforms but I have heard they are reliable and easy-to-use and not too expensive.

Hosted Websites

For a bit more work you could use a hosted website builder like Squarespace, Wix, or WordPress.com. This will give you a bit more flexibility than a platform designed to fill a niche.

WordPress

As much as WordPress can have a bad reputation, if you consider themes and plugins carefully then you can get a great looking and performing WordPress site for photography.

It's worth looking for themes that are designed for photography so functionality like EXIF data, lightboxes, and copy protection is included. I don't have any examples but there are several free ones on the official theme directory and many options in commercial theme directories like ThemeForest.

For more Technical...

If you're fairly technically minded, there are also some great programs designed to generate a static website from your content and once you get used to them are really quick and simple.

One I've come across is called "Prosopopee" (github.com/Psycojoker/prosopopee/) and is designed for photography websites and features everything you'd need. It's a bit more involved to publish content as it's done with text files rather than a GUI or Lightroom integration, and you'll probably initially need a developer to make it look how you'd like but that wouldn't be too hard to come across.

Not focused on Photography, but again for the more technical 11ty (11ty.dev) is a static site generator that could absolutely work as a brilliant image gallery. You'd also probably need a developer to get the initial site going and perhaps integrate it with a headless CMS, but with a bit of extra work you can get a system that's a lot more flexible and resilient.

If I were to set up a new site for a photographer, this is probably the direction I'd go down. I've been burned by Koken dying in only a few years, a static site and static site generator will be around a lot longer than that.

If you have any comments or feedback on this article, let me know! I'd love to hear your thoughts, go ahead and send me an email at alistair@accudio.com or contact me on Mastodon.

The post Fixes for Koken Problems appeared first on alistairshepherd.uk.

It's a big change from Nuxt, Vue and Webpack to doing pretty much everything myself with 11ty (Eleventy) and gulp—I love it. More on that in a future post however, today is about the star of the show—the parallax landscape you see at the top of the page.

If you're the type who wants to dive straight into the code, here's a CodePen - go and have a play!

For those still with me, let's go through it.

Note: I'm writing JavaScript in ES6 and CSS in SCSS. I compile my code anyway so this makes it easier for me to work with.

Inspiration

If you recognise the art-style, it's super inspired by the game Firewatch. Firewatch is a 'walking simulator' game that came out in 2016 and people loved its art style. Featuring a bright, layered landscape it inspired many, myself included. For several years the wallpaper of my phone changed between these wallpapers based on time and weather.

When I was planning my new site, I decided to centre it on this art style. I wanted it to feel interactive, and parallax felt like a natural way to do that.

The Markup

My wonderful sister Becci Shepherd produced the landscape, and sent me a raster PNG for each layer. Although I experimented with masking, it's browser support isn't quite there. SVGs were the obvious choice.

To convert to vector I used Vector Magic Desktop Edition. It does a brilliant job of anything you throw at it, and is the best raster-to-vector converter I've found.

I tidied up the paths in a graphics program; exported it to SVG; tidied up the markup and optimised with SVGOMG. This left me with a decent sized SVG for each layer.

Try ensure the viewbox is identical as it will make sizing much easier.

Now in HTML, we need to stack them:

<div class="landscape" role="img" aria-label="This is equivalent to an img alt attribute.">
	<div class="landscape__layer">
    	<div class="landscape__image">
      		<svg viewBox="0 0 4000 1000" xmlns="http://www.w3.org/2000/svg">...</svg>
    	</div>
  	</div>
	<div class="landscape__layer">
    	<div class="landscape__image">
      		<svg viewBox="0 0 4000 1000" xmlns="http://www.w3.org/2000/svg">...</svg>
    	</div>
  	</div>
	<div class="landscape__layer">
    	<div class="landscape__image">
      		<svg viewBox="0 0 4000 1000" xmlns="http://www.w3.org/2000/svg">...</svg>
    	</div>
  	</div>

  	... and so on.
</div>

Remember accessibility! Despite being a whole bunch of markup, this is really a fancy image. We use role="img" and aria-label to make it accessible.

I didn't have the two wrapping divs at first, but realised that wrappers for each layer allowed me to use flexbox. This made positioning the SVGs easier:

// wrapping landscape
.landscape {
	background: var(--c1);
	height: 75vh;
	overflow: hidden;
	position: relative;

// make each layer fill parent
.landscape__layer {
	height: 100%;
	left: 0;
	position: absolute;
	top: 0;
	width: 100%;
}

// svg wrapper
.landscape__image {
	// position at bottom of element in center
	position: absolute;
	bottom: 0;
	left: 50%;
	transform: translateX(-50%);

	// set sizes that work for my image
	max-height: 100%;
	max-width: 300%;
	min-width: 100%;
	width: 2500px;

	// use flexbox to center SVG elements
	display: flex;
	flex-direction: column;
}

// basic styling for SVG element
.landscape__image svg {
	display: block;
	height: auto;
	max-width: 100%;
}

We now have a static landscape and are set up to make it more dynamic!

Parallax Animation

Perspective and translateZ

There are two popular methods to implement parallax on the web. The more performant implementation is a CSS-only solution using the perspective CSS property with translateZ(). This is what browser vendors suggest, as it allows the browser to render changes with the GPU. This makes it super quick and smooth and is how I tried to implement it for weeks.

Google Developer docs have a good example of this method.

Although it's great for simple implementations—I found that in my case it was unreliable. This was because:

• Browser implementations vary. Chrome handles a deep 3D perspective easily, but Firefox interprets the spec differently. This meant I had to apply transform-style: preserve-3d on every element between my scroll element and my layers.
• Firefox on Android handles 3D transformations inconsistently with deep DOM trees, making it hard to adapt to my structure.
• Mobile Safari on iOS has quirks, and the current solution is to use a trick which 'reverses' the parallax direction. Not an option in my case as that would break the effect!

I spent about two weeks trying to get this working before giving up and going for method two.

JavaScript parallax

JS-based parallax has had a bad rep, as a few popular libraries weren't very performant or accessible. Their size was to deal with browser inconsistencies, but with modern CSS and JS we can do it ourselves without much work.

With CSS custom properties and calc() we can come up with a light and neat implementation ourselves. In JavaScript we use window.requestAnimationFrame and if the scroll position has changed we set it to a custom property.

// constant elements: your main scrolling element; html element
const scrollEl = document.documentElement
const root = document.documentElement

let scrollPos

// update css property on scroll
function animation() {
  // check the scroll position has changed
  if (scrollPos !== scrollEl.scrollTop) {
    // reset the seen scroll position
    scrollPos = scrollEl.scrollTop
    // update css property --scrollPos with scroll position in pixels
    root.style.setProperty('--scrollPos', scrollPos + 'px')
  }

  // call animation again on next animation frame
  window.requestAnimationFrame(animation)
}

// start animation on next animation frame
window.requestAnimationFrame(animation)

That's it. That's all the JavaScript we need. As someone who loves CSS it feels great knowing that we can keep the JS simple and use CSS to implement this descriptively.

The real action is happening in the CSS, this is what we need to add to our previous styles:

.landscape__layer {
	// parallax
	transform: translateY(calc(var(--scrollPos, 0) * var(--offset, 0)));

	@media (prefers-reduced-motion: reduce) {
		transform: translateY(0);
	}
}

The key line is the first transform and it's custom properties. What we are doing is translating the layer down a certain amount based on the scroll position.

We use a prefers-reduced-motion media query to remove the parallax effect for those who might get motion-sick or prefer less movement in their browsing.

The --offset property is a value that would be between 0 and 1, and changes how much that layer scrolls. Let's look at what happens when we vary that property and scroll down by 100px:

• --offset: 0 — the element isn't translated and scrolls as normal;
• --offset: 0.5 — the element will be translated down by 50px. This makes it look like it's moved 50px;
• --offset: 1 — the element is translated down 100px, it's in the same place it used to be. This makes it look like it's not moving with scroll;

The --offset property is the key to our parallax system. If each layer has a different value it will scroll at a different speed from the other layers. We can manually set how much each layer will scroll so it looks natural.

The way we apply this to our layers is using the style property. This way we can avoid adding any more CSS, no matter how many layers we have. We set the front layer to 0 so it scrolls with the content, and increase it with each layer. This is what worked for my image:

<div class="landscape" role="img" aria-label="This is equivalent to an img alt attribute.">
	<div class="landscape__layer" style="--offset:0.96">...</div>
	<div class="landscape__layer" style="--offset:0.92">...</div>
	<div class="landscape__layer" style="--offset:0.9">...</div>
	<div class="landscape__layer" style="--offset:0.86">...</div>
	<div class="landscape__layer" style="--offset:0.83">...</div>
	<div class="landscape__layer" style="--offset:0.8">...</div>
	<div class="landscape__layer" style="--offset:0.75">...</div>
	<div class="landscape__layer" style="--offset:0.4">...</div>
	<div class="landscape__layer" style="--offset:0.2">...</div>
	<div class="landscape__layer" style="--offset:0">...</div>
</div>

Notice the big gap between 0.4 and 0.75. If you look at the landscape structure, the loch is a lot further away than the trees. We produce the same effect by making the offset a lot further away from 0.

Result

And here we have our final parallax landscape!

Thank you for reading! Next up we're going to take this landscape and add colour schemes—including one that matches the visitors local time!

If you have any comments or feedback on this article, let me know! I'd love to hear your thoughts, go ahead and send me an email at alistair@accudio.com or contact me on Mastodon.

The post Making a Parallax SVG Landscape - new site part 1 appeared first on alistairshepherd.uk.

If you haven't tried it yet, visit my website and click the "paint bucket" icon in the top-right of my website to see the theme picker. Here you can change the colour scheme of the website.

There are four 'static' colour schemes of 'Sunrise', 'Day', 'Sunset' and 'Night'. These set the colours to a specific palette.

I implemented two special 'dynamic' colour schemes, the default of 'Live' and 'Cycle'. Live sets the colour scheme of the website to roughly match your local time, whilst Cycle is a 60 second loop animating through the four static schemes above.

The main point of this post is the colour changing functionality, but I'll briefly mention the 'Sun' animation too.

If you want straight at the code, enjoy! 👋

Note: This post is more technical and less visual than my previous one. There aren't many demos, and it's mostly code snippets from here on. You've been warned!

Background

I have wanted to implement a 'live' functionality in my personal website for a few years. Something that makes my site feel more current and that evolves with the day excited me.

My first attempt at this was in my previous site, where I had a background video of a stream on the Isle of Skye. This was a simple 30s loop, but what I wanted was a 24-hour video that would be synced up with your local time. I liked this idea, but it was impractical thanks to the difficulty in getting 24 hours of consistent footage. It also turned out to be a pretty major technical challenge, I had no experience of streaming video and HLS and DASH weren't widely supported.

When I came up with the idea of the SVG landscape, this seemed like a perfect accompaniment. I could make the time in the 'scene' match up with your local time and demonstrate that through the colours and sun.

Initially I implemented a prototype of this with anime.js—a great JS animation library. When I boiled down the essential elements however, the problem was a lot simpler than I thought. There's more JavaScript here than my previous post but stick with me!

Static Custom Properties

We are starting from the final CodePen in my previous post. First let us set up our colours in custom properties:

As we are going to be using JavaScript to 'enhance' this with the colours of our animation, we're starting with greys that roughly match the tone of our colours.
This helps us in a couple different situations:

• If the visitor has JS disabled or our JS doesn't load, we can be sure the colour contrast is sufficient and the site accessible.
• For performance reasons, we don't want to include our JS blocking the render in the <head>. That means that for a brief period our fallback colours might be displayed before the JS kicks in. By choosing neutral greys it looks more natural than going from one colour to another—like the saturation is turned up from 0.

Colour Config

So we can access them with JS later, I'm configuring my colours in the JS:

const config = {
	states: [
		{
			at: 0,
			name: 'night',
			colours: {
				c0: '#7da5d5',
				c1: '#0c4e8f',
				c2: '#00101f'
			}
		},
		{
			at: 6,
			name: 'sunrise',
			colours: {
				c0: '#fed4d5',
				c1: '#a496c4',
				c2: '#2e2c3f'
			}
		},
		{
			at: 12,
			name: 'day',
			colours: {
				c0: '#ffe2a6',
				c1: '#fc813a',
				c2: '#2f1121'
			}
		},
		{
			at: 18,
			name: 'sunset',
			colours: {
				c0: '#ffad39',
				c1: '#e17b17',
				c2: '#1e0000'
			}
		}
	]
}

We'll add to this later, and the at property will become more clear with more code below. We are defining an array of different themes, giving each a name so we can look them up later, and defining our colour palette.

My website has 10 unique colours, I have reduced it to 3 in code snippets for simplicity. If you're interested in all 10 have a look at the CodePens!

Animating Custom Properties

In CSS we have the animation and transition properties. These help us animate between two values without needing JS. We should be able to use that to animate our custom properties right? Unfortunately, not right.

As great as custom properties are, at the moment they have limits. One of those limits is in animation or transitions. At the moment custom properties are strings, so the browser transition engine can't know how to interpolate between two values when they change.

This is one of the things that the Houdini Project is designed to solve, but it is currently Blink-only so that's not well-supported enough for us at the moment. The idea is you specify exactly the type of value a property represents (eg, colour) and the browser can handle interpolating it.

The Animation

I found it difficult to tutorial-ise the animation JS so what I'm going to do is include my commented code. Feel free to go back to the CodePen above and have a dig around yourself, or get in touch if you have any questions!

// Configuration of colours and animation states
const config = {
	// sets the setInterval interval and the progress function for each animation mode
	anims: {
		live: {
			// A high interval as live changes very infrequently.
			interval: 60000,
			getProgress: now => {
				// Current seconds elapsed this day, divided by number of seconds in the day
				const time = (now.getHours() * 3600) + (now.getMinutes() * 60) + now.getSeconds()
				return time / 86400
			}
		},
		cycle: {
			// A low interval as cycle changes in milliseconds.
			interval: 50,
			getProgress: now => {
				// Current milliseconss elapsed this minute, divided by number of milliseconds in a minute
				const time = (now.getSeconds() * 1000) + now.getMilliseconds()
				return time / 60000
			}
		}
	},
	// States with 'at' specifying the time in hours the state should be.
	// 'name' allows referring to it when we add themes later.
	// 'colours' is object with key as custom property name and value as colour.
	states: [
		{
			at: 0,
			name: 'night',
			colours: {
				c0: '#7da5d5',
				c1: '#0c4e8f',
				c2: '#00101f'
			}
		},
		{
			at: 6,
			name: 'sunrise',
			colours: {
				c0: '#fed4d5',
				c1: '#a496c4',
				c2: '#2e2c3f'
			}
		},
		{
			at: 12,
			name: 'day',
			colours: {
				c0: '#ffe2a6',
				c1: '#fc813a',
				c2: '#2f1121'
			}
		},
		{
			at: 18,
			name: 'sunset',
			colours: {
				c0: '#ffad39',
				c1: '#e17b17',
				c2: '#1e0000'
			}
		}
	]
}

const root = document.documentElement

// This changes the interval and progress calculation between
// our dynamic animations 'live' and 'cycle'.
let animMode = 'live'

// Add first element of states to end so we have a seamless loop:
// night > sunrise > day > sunset > night
config.states.push({
	...config.states[0],
	name: 'end',
	at: 24
})

// Declaring our animation loop in a variable allows us to end it when needed.
let animation
function startAnim() {
	// Run our update loop immediately after starting.
	updateAnim()

	// setInterval runs our update loop with a predetermined interval
	// based on the animation mode we are using.
	animation = setInterval(updateAnim, config.anims[animMode].interval)
}

// If we need to end the animation, this function will stop it
// running again using clearInterval
function endAnim() {
	clearInterval(animation)
}

// This runs every update cycle, getting the progress, calculating
// the right colours and applying them to the root element
function updateAnim() {
	// Get the progress through the animation. getProgress returns a number between 0 and 1.
	// To simplify working with time, we multiply this by 24 to get progress through the day.
	const progress = getProgress() * 24

	// Find the next 'state' we are transitioning to based on the 'at' property.
	// The 'at' property sets at what hour that state should be at.
	const nextIndex = config.states.findIndex(frame => {
		return frame.at !== 0 && progress < frame.at
	})
	// The previous 'state' is the one before the next one, so we remove 1.
	const lastIndex = nextIndex - 1

	// Get the onjects for the last and next states
	const lastState = config.states[lastIndex]
	const nextState = config.states[nextIndex]

	// Calculate the difference between the 'at' values of the previous and last states,
	// so we can get our progress between them based on the progress we got above.
	const diff = nextState.at - lastState.at
	const progressCurr = (progress - lastState.at) / diff

	// Loop through all the colours. 'key' is the cutsom property name
	Object.keys(lastState.colours).forEach(key => {
		// We use hex codes for colours for convenience, but it's a lot easier to transition
		// seperate Red, Green, Blue values so we convert them to a [R, G, B] array
		const lastRGB = hexToRgb(lastState.colours[key])
		const nextRGB = hexToRgb(nextState.colours[key])

		// Get the new RGB by using 'lerping' to find the value between the last and next
		// colours based on how far we are through the current animation.
		// The lerp function doesn't necessarily return an int so we round it.
		const currRGB = [
			Math.round(lerp(lastRGB[0], nextRGB[0], progressCurr)),
			Math.round(lerp(lastRGB[1], nextRGB[1], progressCurr)),
			Math.round(lerp(lastRGB[2], nextRGB[2], progressCurr))
		]

		// Apply the custom property to root using the name and our new RGB value.
		applyColour(key, currRGB)
	})
}

// As we have two different animation 'modes', we change the function used to work
// out the progress depending on that mode. See the config above for how they work.
function getProgress() {
	const d = new Date()
	const progress = config.anims[animMode].getProgress(d)

	return progress
}

// A slightly bewildering regular expression that turns a hex code into [R, G. B] array.
// Well-tested though so I don't need to touch it!
function hexToRgb(hex) {
	var result = /^#?([a-f\d]{2})([a-f\d]{2})([a-f\d]{2})$/i.exec(hex)
	return result ? [
		parseInt(result[1], 16),
		parseInt(result[2], 16),
		parseInt(result[3], 16)
	] : null
}

// Using 'linear interpolation' gets the value between the start and end values based on progress
function lerp(start, end, progress) {
	return (1 - progress) * start + progress * end
}

// Uses name of custom property 'key' and [R, G, B] array and applies to root element
function applyColour(key, colour) {
	const colourString = 'rgb(' + colour.join(',') + ')'
	root.style.setProperty('--' + key, colourString)
}

// Round number to 'places' number of figures after decimal.
function round(num, places) {
	const power = Math.pow(10, places)
	return Math.round(num * power) / power
}

// Initialise and start animation.
function init() {
	startAnim()
}
init()

Theme Picker

With the above code, we have an animated live colour scheme and the flexibility to extend it further. Let's do just that by creating methods to switch between 'dynamic' schemes and our named states.

We'll go through the basic code to change, and then a basic 'theme picker'.

Switching between dynamic states

In our configuration, we have set the progress function and interval for each dynamic theme. When we start the animation and when our updateAnim() function run, they use the value of animMode to choose the correct interval and progress function for the current mode.

This means all we need to do is stop the animation, change animMode, and start it again. For example to change to 'cycle':

endAnim()
animMode = 'cycle'
startAnim()

And likewise, to switch to 'live', we would do the same process but instead set animMode to 'live'.

Switching to a static 'named' state

We included the name property within our state so that we can refer to it when setting the theme. First we need to stop the animation, so that the dynamic state doesn't replace our changes when it next runs. Then, we need to find the colours for the state we would like to apply and apply them. We can do that with this short piece of code.

const theme = 'sunset'
endAnim()
const state = config.states.find(item => item.name === theme)
Object.keys(state.colours).forEach(key => {
	applyColour(key, hexToRgb(state.colours[key]))
})

Line 3 uses the handy Array method 'find' which will return the item that matches our condition: where item.name equals our theme name.
We then loop through all the colours of that state and apply them as we did for our dynamic 'themes'.

Theme Picker

It's worth building out a theme picker for yourself, but here's a simple implementation to get us started:

<button data-active aria-pressed data-theme="live">Live</button>
<button data-theme="cycle">Cycle</button>
<button data-theme="sunrise">Sunrise</button>
<button data-theme="day">Day</button>
<button data-theme="sunset">Sunset</button>
<button data-theme="night">Night</button>

const themes = document.querySelectorAll('[data-theme]')
if (themes) {
	themes.forEach(function(theme) {
		theme.addEventListener('click', function(e) {
			// remove active state from old theme buttons
			themes.forEach(theme => {
				theme.removeAttribute('data-active')
				theme.removeAttribute('aria-pressed')
			})

			// add active state to clicked button
			this.setAttribute('data-active', '')
			this.setAttribute('aria-pressed', '')

			// get slug for current theme
			const themeSlug = this.getAttribute('data-theme')

			// end animation
			endAnim()

			// if dynamic theme, set animMode, start animation and return
			if (themeSlug === 'live' || themeSlug === 'cycle') {
				animMode = themeSlug
				startAnim()
				return
			}

			// find theme state and apply the colours
			const state = config.states.find(item => item.name === themeSlug)
			Object.keys(state.colours).forEach(key => {
				applyColour(key, hexToRgb(state.colours[key]))
			})
		})
	})
}

Sun Animation

The final piece to our landscape is a moving sun. You would have thought it would be easy to implement, but it turned out to be more tricky than I first thought.

Lets go over our requirements:

1. A small circle that is on the far left at 6, top at 12, right at 18, and bottom at 24.
2. Respects screen width so it works for wide and narrow screens.
3. Respects screen height so it is positioned in the right place compared to the landscape.
4. Follows an ellipse based on the width and height

Due to all these reasons, my first thought of using animations becomes hard to implement. Respecting width, height and following an ellipse though sounds like a tricky challenge.

The solution ends up using our favourite feature the Custom Property, and exploiting the relationship between ellipses and the Sin function.

We can continue to keep our JavaScript minimal and respect the screen size by using transforms and elements the size of the screen. To our .landscape from the previous post:

<div class="landscape__sunWrap">
	<div class="landscape__sun"></div>
</div>

$sun-size: min(4rem, 10vw);
$sun-movement-v: 30%;
$sun-movement-h: 40%;

.landscape {
	&__sunWrap {
		$distance: 10;

		bottom: 10%;
		height: 75%;
		left: 0;
		position: absolute;
		transform: translateY(var(--scrollPos, 0));
		width: 100%;

		@media (prefers-reduced-motion: reduce) {
			display: none;
		}
	}

	&__sun {
		height: 100%;
		left: 0;
		position: absolute;
		top: 0;
		transform:
			translateX(calc(#{$sun-movement-h} * var(--sun-h)))
			translateY(calc(#{$sun-movement-v} * var(--sun-v)));
		width: 100%;

		// the actual sun element
		&::before {
			background: #fff;
			border-radius: 50%;
			content: '';
			height: $sun-size;
			left: 50%;
			position: absolute;
			top: 50%;
			transform: translate(-50%, -50%);
			width: $sun-size;
		}
	}
}

Using this code the positioning of our sun is based on rails, constrained by the size of our landscape. --sun-h and --sun-v are numbers between -1 and 1 which are used in the calc within our transform property to set how far up/down and left/right the sun is.

The advantage of using an element filling our landscape means that as the element is narrower, the less the sun moves horizontally. This leaves us with minimal JS:

function sunPos(progress) {
	const sunWrap = document.querySelector('.landscape__sunWrap')
	if (sunWrap) {
		const sunH = -Math.sin(2 * Math.PI * progress / 24)
		const sunV = -Math.sin(2 * Math.PI * (progress - 6) / 24)
		sunWrap.style.setProperty('--sun-h', round(sunH, 3))
		sunWrap.style.setProperty('--sun-v', round(sunV, 3))
	}
}

This involves maths that I'm pretty sure I was taught in High School and University, but I am certain I have almost entirely forgotten! For a square element, this would create a circular movement but by splitting it up into separate components we have our ellipse.

We then run sunPos with our progress in our updateAnim() function and using the state.at property after setting a static theme.

Conclusion

If you've gotten this far, congratulations and thank you for sticking with me! Here's our final landscape, as above:

This is not the easiest post to read by any stretch of the imagination, but I wanted to get down a lot of info and I struggled to in a way that felt natural. Initial drafts were tutorial-like before I realised I was writing a 10,000 word tutorial!

I am planning to write more, but will be making them shorter and simpler than this one. Keep an eye out for future posts about:

• The 'hilly' dividers
• Blog setup with 11ty, esbuild and gulp
• Implementing mouse-based painting with canvas and JS
  and a few more I have planned!

If you have any comments or feedback on this article, let me know! I'd love to hear your thoughts, go ahead and send me an email at alistair@accudio.com or contact me on Mastodon.

The post SVG Landscape with live colour theming - new site part 2 appeared first on alistairshepherd.uk.

In the meantime, we can load the WICG focus-visible polyfill to offer improved focus styles in browsers that yet don't support it. Ideally we don't force browsers that support focus-visible to download a polyfill when it's unnecessary - and in future when all modern browsers support the feature, we don't want to ship that redundant code.

Here is a snippet we can use to only load the focus-visible polyfill if it isn't supported! Insert this before the closing </body> and change the script.src to point to your local copy of the polyfill (or use an asset CDN like jsdelivr).

<script>
  try {
    document.body.querySelector(':focus-visible');
  } catch (error) {
    var script = document.createElement('script');
    script.src = "/js/focus-visible.js";
    document.body.appendChild(script);
  }
</script>

CSS

You'll also need to write CSS to handle focus indicators in three circumstances:

1. focus-visible is supported;
2. focus-visible not supported, but polyfill has been loaded;
3. focus-visible not supported, polyfill not loaded.

This is my setup for these cases:

/**
 * My focus styles
 */
:focus {
  outline: 2px dashed currentColor;
  outline-offset: .25rem;
}

/**
 * When focus-visible is supported:
 * remove outline when :focus but not :focus-visible
 */
:focus:not(:focus-visible) {
  outline: none;
}

/**
 * when polyfill loaded:
 * remove outline when :focus but not .focus-visible
 */
.js-focus-visible :focus:not(.focus-visible) {
  outline: none;

Notes

• This does add an additional script to load for browsers without support, but by adding the script as above loads it asyncronously. The browser will prioritise other resources, and the worst case is it isn't loaded by the first interaction and a fallback :focus indicator is shown.
• If you have a build step that minifies/optimises your CSS, you may find that the two outline: none declarations are combined into a single rule. Due to how the browser ignores any rules with selectors it doesn't understand, this won't work. You may need to disable optimisation on this step, or in my case I changed one of the outline: none declarations to outline: 0. This CSS works the same, but means they won't be combined into a single rule by most minifiers.

Further reading

• WICG focus-visible polyfill
• Matthias Ott - :focus-visible is here
• MDN - :focus-visible
• CSS Tricks Almanac - :focus-visible
• CanIUse - :focus-visible browser support
• Igalia - :focus-visible in WebKit - January 2021

If you have any comments or feedback on this article, let me know! I'd love to hear your thoughts, go ahead and send me an email at alistair@accudio.com or contact me on Mastodon.

The post Conditionally loading a polyfill for :focus-visible appeared first on alistairshepherd.uk.

Intro to lazyloading

Lazyloading images has been a good practice for web page performance for some time, and recommended by tools like Lighthouse, PageSpeed Insights and WebPageTest among others. This traditionally had to implemented using a JS library like Lazysizes.

These libraries monitor what is visible within the browser and only when an image is about to come into view is it loaded. This means that browser won't need to download any images that are never seen - reducing data use and potentially improving front-end performance.

Native lazyloading

Given the prevelance of this practice, the Chrome team and HTML Spec folk introduced lazyloading behaviour natively into the browser via the loading attribute on img tags. We can already make our current img tags lazy by adding loading="lazy" to the element like so:

<img src="/assets/example.jpg" alt="Example image" width="200" height="100" loading="lazy">

Browser support is decent at around 70% between Chromium-based and Firefox-based browsers, but it unfortunately isn't yet in Safari or for iOS at all.

As with my focus-visible conditional loading, ideally we load a JavaScript library/polyfill only if the new feature isn't supported.

Loading the library conditionally

The progressive nature of the loading attribute means older browsers without support will still load the images. That is normally great as it keeps the web backwards-compatible and often usable in old browsers and devices. In this case however, it makes it a little tricky for us to prevent the loading of images outside of the current view.

Browsers that don't support the attribute ignore it and will just load the images normally. By the time we've loaded our script, the browser may have already downloaded many or all of the images on the page unnecessarily.

What we have to do is provide our markup in the format of the lazyload library we are using. We then check for support of native lazyloading and either load our library or run some JS to adapt our markup to 'normal'.

Before the closing </body> we include our conditional loading snippet like this:

<script>
  let hasLibLoaded = false;
  // in a function so we cn re-run if data is added dynamically
  window.loadingPolyfill = () => {
    // check if loading attribute supported
    if ('loading' in HTMLImageElement.prototype) {
      // get all <img> and <source> elements
      const images = document.querySelectorAll('img[data-src]');
      const sources = document.querySelectorAll('source[data-srcset]');

      // loop through <img>s setting the src attribute and srcset and sizes if present
      for (let img of images) {
        img.src = img.getAttribute('data-src');
        const srcset = img.getAttribute('data-srcset');
        if (srcset) {
          img.srcset = srcset;
        }
        const sizes = img.getAttribute('data-sizes');
        if (sizes) {
          img.sizes = sizes;
        }
      }

      // loop through <source>s setting the srcset attribute and sizes if present
      for (let source of sources) {
        source.srcset = source.getAttribute('data-srcset');
        const sizes = source.getAttribute('data-sizes');
        if (sizes) {
          source.sizes = sizes
        }
      }

    // if loading attribute is not supported
    } else {
      // check we haven't already loaded the library
      if (!hasLibLoaded) {
        // create script element with src pointing to our library and add to document
        const script = document.createElement('script');
        script.src = '/js/lazysizes.js';
        document.body.appendChild(script);

        // mark library as loaded
        hasLibLoaded = true;

      // lazyloading library has already been loaded
      } else {
        // depending on your library you may need to run findNewItems() or something along
        // those lines to adapt new content. Some libraries including lazysizes don't need this.
      }
    }
  }
  // run our loading polyfill
  window.loadingPolyfill();
</script>

We assign our function globally on the window object so that if any content is loaded via JavaScript (eg AJAX or client-side-routing) you call call window.loadingPolyfill() again and it will re-run including new images.

Notes

• Make sure the script.src points to your JS library - locall or using a CDN like JSDelivr.
• Depending on your lazyloading library, you may need to change data-src, data-srcset and data-sizes. Many use this convention but not all, eg Uncloak uses data-uncloak-src.
• If you need to support older browsers like IE11 then you will need to check your lazyload library and adapt the code above. Alternatively consider including a legacy.js script that has the same functionality as our supporting case, that will fall back to standard image loading for old browsers.

Performance Impact

Despite minimal, this will have a performance impact on both supporting and non-supporting browsers.

Supporting browsers

In theory browsers are able to start downloading high-priority images before the full document is parsed. Because there is no src atribute, our solution stops this from happening until our script runs near the end of the document. Unless you have a very long HTML document though, it's unlikely this will be more than a few milliseconds. Regardless, I would suggest avoiding this practice for your most important above-the-fold images like logos or hero images.

Non-supporting browsers

As we are loading our JS library asyncronously, this generally means it has a lower download priority than it would otherwise. There is no easy way around this, but I couldn't see any conslusive impact when testing on Safari. Take that with a pinch of salt though, it will depend a lot on how your website is built and the visiting device. I don't think this will be very significant however.

Further Reading

• loading attribute on MDN (developer.mozilla.org)
• web.dev lazy loading article (web.dev)
• lazysizes JS library (github.com)
• focus-visible polyfill (alistairshepherd.uk)
• The loading attribute polyfill (github.com) should work with some modifications to the code above, although I haven't used it before.

If you have any comments or feedback on this article, let me know! I'd love to hear your thoughts, go ahead and send me an email at alistair@accudio.com or contact me on Mastodon.

The post Conditionally loading a native image lazyload polyfill/library appeared first on alistairshepherd.uk.

Although all of this innovation is great, it can sometimes be pretty difficult to keep up with. One of the ways I keep on top of the latest changes, trends and new technologies is by following the blogs and newsletters of companies and developers leading the industry.

I'm always on the lookout for more blogs or newsletters! If you have any suggestions I should check out get in touch!

Table of Contents

1. Intro
2. Browser Vendors
3. Company Blogs
4. Development Blogs
5. Developers and Designers
6. Magazines
7. Newsletters

Intro

I thought I'd crack out a post I can point people to with a list of the feeds and newsletters I subscribe to, with a bit of hopefully useful info so you know if you want to subscribe yourself. Most of these are focused on:

• Front End Development
• Full-Stack development
• HTML
• CSS
• JavaScript
• Accessibility
• Web Performance
• Browsers
• 11ty

I find it quite fun that the format for the majority of these feeds about modern web development is RSS, a technology that has existed since 1999! If you're looking for a feed reader I use Feedbin, which is a great cloud RSS and newsletter reader across multiple platforms. You can also find an export of my RSS subscriptions on my Github.

Browser Vendors

Useful for keeping up with changes to the biggest browsers. Topics can be quite technical and writing not particularly approachable, but probably worth a look. I tend to scan the titles to decide if it's something that will likely affect me before reading.

• Google Chrome blog [feed] — Fairly approachable summaries of changes, updates and new features coming to Google chrome and probably other chromium browsers;
• Chromium Blog [feed] — Similar to the Google Chrome blog but more technical, and posts summaries of every major version;
• Mozilla Hacks [feed] — Updates on Firefox and Gecko changes, mixture of technical level, summary of major updates;
• Microsoft Edge Blog [feed] — MS' work on Blink and Chromium, will eventually come to all Chromium browsers so good to follow;
• Planet Webkit [feed] — Very technical updates to WebKit and Safari - useful however due to a lack of official Safari updates. Keep in mind WebKit changes can take months or even years to make their way to Safari;
• Planet Igalia [feed] — The Igalia team have contributed to all browsers, most recently :focus-visible in Safari. Some really deep-dives into very technical topics. Not for everyone.

Company Blogs

Any blogs by development agencies or dev-related products. A few of the agency blogs have some great tips, best practices and open-source tools. I tend to be a bit wary of product blogs as they're always trying to sell but there are some decent ones out there.

• 9Elements [feed] — Agency with some great front-end skills in their team. I particularly like Nils Binder's articles on layout like "The Devil's Albatross";
• Axess Lab [feed] — Accessibility consultants, they have some great articles offering approachable summaries for accessibility topics including "What is a screen reader?";
• Bejamas [feed] — An expert Jamstack agency, if you want more info on Static Site Generators or Headless CMS' their articles are brilliant;
• DebugBear [feed] — DebugBear sells web performance monitoring, I haven't used their product but they write some decent high-level articles about improving web performance.
• Filament Group [feed] — If you've been on the web a while you've probably used a tool made by Filament Group! Authors of Respond.js, Picturefill, LoadCSS and the most common async CSS pattern - they do great open-source work and really interesting articles about them.
• Volument Minimalism [feed] — Privacy-focused analytics, haven't used the product but their insight on analytics and modern development is interesting and straight to the point.

Development Blogs

Blogs generally aimed at sharing knowledge about web development. Separate from Developers and Magazines as they feel somewhere between the two.

• CSS { In Real Life } [feed] — Generally short posts focused on CSS and layout. "Detecting Hover-Capable Devices" is a great recent one to check out;
• Joy of Computing [feed] — More general that most other feeds here. Short daily posts about cool or interesting things going on in Computing, can be pretty fun too;
• Piccalilli [feed] — Piccalilli by Andy Bell has great tutorials and summaries on building modern front ends. Check out "Modern CSS Reset". The Piccalilli community membership is also great if you're into that!
• QuirksMode Blog [feed] — QuirksMode has been writing about the web since 2004, talking a lot about browsers and thinking about how the web as a whole should work. Great thinkpieces.
• web.dev [feed] — Posts mostly by Google Web Developers introducing and covering best practices and new features in the web. The courses on the site are also well worth checking out;
• Web Platform News [feed] — Provides short updates on anything new in the web, including bugs and announcements you might not find elsewhere. Only available as a screenshot unless you pay $2/month on Patreon, worth considering though as I've found it very useful.

Developers and Designers

These are individual devs and designers who are experts in their field. Not as frequent posts, but there are some real gems here. In alphabetical order for simplicity, and just a short summary as there's a few!

• Addy Osmani [feed] — Google developer focusing on performance. Author of great book "Image Optimisation";
• Adrian Roselli [feed] — One of the best writers on accessibility and does loads of research and testing of screen readers etc;
• Ahmad Shadeed [feed] — Dev/Designer who is a master of CSS;
• Brad Frost [feed] — Mostly thoughts on the front end design industry and design systems;
• Bruce Lawson [feed] — Web veteran with a lot of accessibility knowledge. His Reading Lists provide a great ~monthly list of great articles from around the web.
• Bryan Robinson [feed] — 11ty wizard and devrel for Sanity - a decent-looking headless CMS;
• Chen Hui Jing [feed] — Well written articles from all areas of web dev from devops to CSS debugging;
• Christian Heilmann [feed] — Shorter posts and introductions to various front end topics;
• Dave Rupert [feed] — co-host of podcast ShopTalk, most of the blog is more about life as a dev and productivity but has some great dev articles also;
• David Walsh [feed] — One of the longest running dev blogs, David has so many brilliant articles, many of which are short tips with exactly what you need;
• Dmitri Pavlutin [feed] — I love Dmitri's introductions to new JavaScript and React features and patterns;
• Harry Roberts/CSS Wizardry [feed] — Master web performance consultant, great articles providing fairly easy and accessible performance tips and advice;
• Heydon Pickering [feed] — Internet maverick, accessibility expert, design systems writer and author of the brilliant "Inclusive Components";
• Hidde De Vries [feed] — Accessibility, HTML and CSS expert;
• Jake Archibald [feed] — Google developer and co-host of HTTP 203, writes great articles on web performance, images and modern JavaScript;
• Jens Oliver Meiert [feed] — What you didn't realise you didn't know about HTML. Check out "HTML Concepts: Body-Ok";
• Jeremy Keith [feed] — Jeremy has been writing about the web since 2001 and always has interesting thoughts of development and the industry in general. Manages the great agency Clearleft.
• Jeremy Wagner [feed] — Web performance consultant and fan of simple JavaScript;
• Josh W Comeau [feed] — React developer, writes great articles about JavaScript and HTML/CSS from the perspective of a JS dev;
• Kat Maddox [feed] — Internet anarchist and computer/programming comedian.
• Lea Verou [feed] — Works on web standards with the W3C Technical Architecture Group. Blog focused on CSS and JS;
• Malte Ubl [feed] — Web developer and software designer, particularly good articles on web performance;
• Manuel Matuzovic [feed] — Creator of HTMHell, general tips and snippets of HTML, CSS and on accessibility;
• Marcus Herrmann [feed] — Accessibility specialist, writes lots of great articles helping you test for accessibility and digging into testing various practices.
• Marko Saric [feed] — Articles on analytics, web privacy and the state of the web as a whole;
• Max Böck [feed] — Creative front end developer and creator of the Whimsical Web Club;
• Maximiliano Firtman [feed] — Best known for being a PWA expert and a better source of Safari news than anyone who work on it. I particularly love his Image CDN article;
• Nicolas Hoizey [feed] — 11ty plugin author and writes on front end developer topics. He also shares lots of great wee stuff on his "Notes";
• Rachel Andrew [feed] — One of the best technical writers /editors around, working for Smashing, MDN and web.dev. Brilliant writing about CSS Layout;
• Sam Smith [feed] — Great freelance dev, writes about anything relevant to modern web development;
• Sam Thorogood [feed] — Technical articles about JS, HTML and computing;
• Sara Soueidan [feed] — Writes about Accessibility, HTML, CSS and SVG mostly but anything relevant to front end development;
• Sia Karamalegos [feed] — Writes a lot about 11ty, but also more general Jamstack and web performance topics;
• Thomas Steiner [feed] — Google developer working on PWAs and 'Project Fugu', blog is more general explanations of browser features and APIs.
• Tim Kadlec [feed] — Now working at WebPageTest, great writing on web performance;
• Tobias Ahlin Bjerrome [feed] — Writes about JS, CSS and Design. Each post focuses on one a particular topic and explains it really well and thoroughly.
• Zach Leatherman [feed] — Now working at Netlify, author of 11ty, Glyphhanger and has written some of the best Web Font loading articles around;
• Zell Liew [feed] — Brilliant writer whose articles are super easy to understand. Covers so many useful topics including system setup, build chains, technical JavaScript and industry advice;

Magazines

The big blogs that feature articles from many different authors. A few only run for a month a year, others are year-round. If you only want to subscribe to a few blogs, make it these ones.

Year-round

• CSS Tricks [feed] — The big one, possibly the best source for web development articles out there;
• Smashing Magazine [feed] — Generally goes into more detail than CSS Tricks, with longer and more in-depth articles;
• Codrops [feed] — Publishes the 'Collective', a regular summary of great articles in web development. Also has some super cool JavaScript effect tutorials;

Seasonal

• 24 Accessibility [feed] — Advent calendar of accessibility articles;
• 24 ways [feed] — Advent calendar of cool/impressive things you can do on the web;
• JavaScript January [feed] — Features all sorts of JS-related articles throughout January, including vanilla, front end frameworks, node.js and testing;
• Web Performance Calendar [feed] — Advent calendar of front and back end web performance articles.

Newsletters

Some feed readers allow you to receive email newsletters in the same place, I used Feedbin for this. Regardless, these are some great newsletters to subscribe to:

• Calibre Performance Newsletter — Regular summary of web performance articles;
• CSS Layout News — Curated by Rachel Andrew, this is a newsletter with news, articles and tips specifically focused on web page layouts with CSS;
• Fauna Developer Weekly — Developer-focused tips and tricks. Fauna is a database provider so a bit more back end focused;
• Frontend Focus — Weekly roundup of front end news and articles, also includes tutorials, jobs and tool suggestions;
• Frontend Horse — focuses on modern CSS and really dynamic and animated interactions. Not super frequent but each issue goes into so much depth;
• Frontend Weekly — Lots of articles about the JS ecosystem, particularly React tools and libraries;
• JAMstacked — Jamstack news, articles, libraries and platforms;
• Rendezvous with Cassidoo — Weekly newsletter with a few links about the web, a few about other things, an interview question to try and a joke!
• The UI Animation Newsletter — A few links with super cool UI animations to check out;
• Tiny Web Animation — a short email with 3 links to cool web animations;
• Web Development Reading List — as the name suggests, a list of articles to check out about web development. Well curated;
• Web Tools weekly — Weekly newsletter that focuses on tooling rather than articles. Links to libraries, packages, platforms and tools you can use while developing.

If you have any comments or feedback on this article, let me know! I'd love to hear your thoughts, go ahead and send me an email at alistair@accudio.com or contact me on Mastodon.

The post Front End Web Development Feeds and Newsletters appeared first on alistairshepherd.uk.

My first search engine experience came from this when Altavista was going to be the big player in web search (according to the book). The book had everything from the finest web portals, random neocities pages with all sorts of wacky graphics and the early web experiments that captured my imagination.

One of those experiments I remember the best was called "Lost in Translation". Like most of the sites and links I remember it's long dead now, but at the time it was my favourite. Lost in Translation used the then-new Babel Fish Translation (later bought by Yahoo) API to take any input text, translate it through several different languages and return the resulting garbled mess back in English. I couldn't wait to get home after school, pretend I was doing schoolwork and instead try all sorts of sentences and phrases and see how they turned out.

Fast forward 20 years and I'm a web developer myself. It's almost certainly that booklet and those sites that started me on this journey and made me fall in love with the web. Lost in Translation is still something I think about every so often, an example of what the web was in those days and something I'd like a bit more of now.

Anyway, I was asked by some friends to make a quiz round. Inspired by Lost In Translation, I thought I'd make a quiz round where recipe titles were run through several languages and you had to guess which one. I'll be honest - the round was absolute fucking shite. The average score was 1/10 and the very best 4/10 - I had created questions so bad people did worse than random guesses would provide.

The result of it wasn't all bad though. When I was testing using the Google Translate UI I realised some recipes stood unchanged whilst some completely lost almost instantly. (Turns out that translating modern fad-based recipe names into little-known isolated languages doesn't work too well.) I realised I'd need to do this quite a lot, so wrote a small bit of JavaScript using the Google Translate API to make the process a bit easier.

There's nothing special about it, but having some code that replicates that functionality of Lost In Translation turns out to mean quite a lot to me. It's simple, only took me about an hour (most of which was trying to get a free translation API working) and has achieved it's purpose - but I'm unable to just let it go.

Putting it and these words on the internet pleases the archivist in me, the same part of me that is sad I no longer have that booklet and link rot made it practically useless anyway.

I was just trying to write a basic readme when this monologue came, but I guess now there's morals about link rot, web archival, nostalgia and wishes for a better web.

But enough of that, have some fucking code if you want it.

If you have any comments or feedback on this article, let me know! I'd love to hear your thoughts, go ahead and send me an email at alistair@accudio.com or contact me on Mastodon.

The post Web Nostalgia and Lost In Translation appeared first on alistairshepherd.uk.

I've had a very chaotic few months at the end of 2021, with work, moving house and my first steps into giving tech talks! That has meant that all the blog posts and side projects I planned were left behind, but with some free time before Christmas I thought I'd squeeze a quick and easy post out!

I hope 2021 has been kind and merciful to you, and you have a good holiday period if you're taking one! Thank you so much for reading and supporting me/my work, it means a huge amount! ❤️

So I'm finishing off this year with a very festive post... my website tech stack?! 🌲

In about a month this site will be a year old! Recently a few people have asked me about the tech stack so it's about time I put it and my thinking down properly. I'm really enjoying it!

The entire build is designed to make it as easy as possible for me to work on new content and tweaks after months or years of not touching it. It's been great so far and I find it easier to work on when I come back to it than other platforms I've worked on.

Summary / Table of Contents

Here's a TLDR if you're not interested in the reasoning:

• Host — Netlify with Vercel backup ☁️
• Static site generator — Eleventy 🎈🐀
• Tasks/build — Gulp 🥤
• CSS — 'Vanilla' Scss with Gorko 🎨
• JavaScript — Vanilla JS with esbuild and Barba client-side routing ⚡
• Media — CloudImage Image CDN 🖼️
• Fonts — Red Hat Display and Literata, optimised with Glyphhanger 🕴️

Hosting

For Jamstack hosting I really like Netlify. I think their product is brilliant and love how easy it makes deploying and hosting a website. It has tons of features, great documentation and I like their company ethos, principles and staff. My site is primarily hosted with them under the free plan.

However in case they have a major incident or I disagree with their direction, I have a backup copy of my site ready to go with Vercel. If I needed to switch to them, all I'd need to do is update the DNS and it would be done within a few hours if needed. I don't anticipate needing to, but when it's so easy and free to have a backup website I like having the option.

Static Site Generator

I use Eleventy as my Static Site Generator (SSG) for data manipulation and HTML generation. My site is fairly simple, all I really need is handlebars-style templating, markdown support and reusable JS snippets for custom functionality.

This would give me a lot of SSG options but I had a few priorities that were important. I wanted static HTML without any client-side JavaScript, flexibility with data and structure, easily extendable with JavaScript, and to be in full control of the output. Eleventy was the ideal tool for the job here.

At the time of creation it was a year from stable release but already provided a quick, extendable platform that is easy to work on and has been more stable than at least 4 other major SSGs I've worked with!

I write my blog posts in Markdown but the rest of the site uses Nunjucks for templating.

Tasks/build

I use gulp for my build process and tasks as it provides me a lot of freedom with how I want to run tasks and implement builds.

Many people consider gulp to be dated/dead but honestly I much prefer it to many of the big 'build tools' used in development at the moment. Webpack, Rollup and Parcel seem great at first but I've had difficulties with configuration or needed to use gulp alongside them for custom processes.

A year on I would consider simplifying further and using simple node scripts instead of gulp. These would have the benefits of simplicity and stability over time—I would also appreciate fewer dependencies. For getting off the ground quickly though gulp has the edge for me, with a still huge ecosystem and so many previous projects I can pull gulp tasks from.

A key feature is I can write my own tasks in JS and don't need to prescribe to a config system. The tasks for this site are fairly standard but for long-term maintenance it's useful being able to write my own without having to learn a new 'plugin' syntax. I can also implement builds using whatever tools I like—an example being choosing to use esbuild for JS bundles.

It's not as fancy as some of the latest tools like Vite and Snowpack, but in reality I don't need HMR or instant refreshes for a simple site. And although it's not at the cutting-edge, the API and project stability is helpful for coming back to an older project.

CSS

The CSS is mostly handcrafted without any libraries so I can have full control over the structure and performance. I write in Sass (Scss flavour) as I'm used to many of the utilities and conveniences it provides like importing partials, concatenated nesting and variables.

I say 'mostly handcrafted' as I use the utility class generator Gorko to generate classes for spacing, sizing and colours. Utility classes are great for simple rules like changing display or spacing, both for convenience and performance reasons. For anything that has more than a couple utility classes though that becomes a 'layout' or 'block' that is written using BEM-like classes (eg .nav__link).

The structure I follow is a variation of Andy Bell's CUBE CSS with Layout, Utilities and Blocks. For performance optimisation I have a 'critical' CSS file that includes CSS important to display the top of pages correctly, and this is embedded in the head of every page. I use an 11ty transform with PurgeCSS to strip out any unused rules for each page. This makes the first load of each page as fast as possible, and then the rest of the styles are loaded in a 'main' CSS file that is there for lower down the page and cached for subsequent navigations.

JavaScript

As I prioritise performance, almost all JavaScript is hand-written and vanilla — no frameworks. This allows me to include only what is needed, which thanks to the capabilities of modern browsers ends up being pretty small. Not including libraries and frameworks improves performance on all devices and means my code is more maintainable in future.

I really like esbuild for transforming source JS, it's extremely fast, very simple and the gulp-esbuild plugin is easy to use. I have it set up to turn a set of modules into a single bundle for performance reasons, minify for production, generate sourcemaps and transform modern syntax to a list of supported browsers.

The only library I use is Barba for Client Side Routing (CSR) to maintain the state of the landscape and themes seamlessly across pages. Although I don't normally care much for page transitions and client-side navigations, I couldn't come up with a native solution that was quick, wasn't jarring and maintained the effect. I broke my 'no libraries' rule here as client-side routing isn't easy to get right. Barba does a decent job, is fairly small and I load it separate from the main bundle with low priority to avoid a performance hit.

Media

I'm a big proponent of using Image CDNs, it makes the build process simpler and quicker and further development easier. For more of my thoughts see my recent talk Making Assets fly on the Jamstack with Image CDNs.

I use CloudImage for this site as I like it's simplicity and the free tier is generous enough to cover my few images. The performance is good but I'd like to see better, including AVIF support. Imgix and Cloudinary both perform better but I'm happy with CloudImage for the moment.

I've written a custom Eleventy shortcode with a few parameters to generate src and srcset attributes to do what I need. This would make it easy to switch to a different provider if I wanted. To avoid the performance impact of using a different origin I proxy CloudImage requests through Netlify using redirects.

Fonts

I use Red Hat Display for titles and Literata for the body. Both are on Google Fonts and open source so I can download and manipulate them freely.

To mitigate the performance effect of custom fonts I host them myself and preload the font files. I also reduce their size by subsetting them to US ASCII characters using Glyphhanger which cuts their size almost in half. Thanks to Andy Bell for the font combo!

Conclusion

I'm really happy with this stack and I'm hopeful it'll stand the test of time. My previous Next.js personal site was an absolute nightmare of dependency updates a year on from launching so we're doing better than that.

If you're interested in any specific implementations the source code is public on GitHub. Note that it's not open-source and licensed for re-use, but if you're looking for a similar setup I'd encourage taking a look and learning from the code!

Whilst you're here check out my other posts about how I built this site, about the dynamic functionality of the landscape and colour themes:

• Making a Parallax SVG Landscape - new site part 1
• SVG Landscape with live colour theming - new site part 2

Thank you for reading, best wishes to you and yours, and take care!

If you have any comments or feedback on this article, let me know! I'd love to hear your thoughts, go ahead and send me an email at alistair@accudio.com or contact me on Mastodon.

The post Personal site stack for alistairshepherd.uk appeared first on alistairshepherd.uk.

Many websites implement a notice that doesn't allow opt-out, some offer an option that does nothing, whilst others only offer an opt-out solution - conveniently after they've collected all of your data.

Cead (pronounced kee-yed) is a cookie and tracking consent manager that is simple, lightweight, easy to implement and free. It's designed to help you implement a simple Accept or Deny dialog that will actually enable or disable tracking.

Cead is primarily created in response an increase in unsolicited web surveillance, but also to assist with meeting the standards of regulation including the EU GDPR & ePrivacy and California's CCPA. As privacy legislation becomes more strict it's important that solutions offer compliant opt-in and opt-out controls which Cead offers at it's core.

Table of Contents

1. The problem
2. A possible fix?
3. Cead Consent
   1. Using Cead Consent to manage Google Tag Manager
4. Conclusion

The problem

Tracking on the web has long been a difficult topic. The interests of business owners, SEO teams, Ad vendors, site users and lawmakers become almost impossible to resolve and frequently ignore each other.

I'm of the opinion that a site should have no tracking. This site has no analytics or anything, because your browsing is your own business. Check out Jeremy Keith's "Ain’t No Party Like a Third Party" for his insight on third-party scripts.

I find however that is an impossible stance to maintain when building sites for other people. They are often used to tracking metrics to evaluate their success, generate leads or target their services.

I've worked in agencies where I've seen and worked on a lot of websites for a variety of clients. They vary in purpose, build, location, size and much more, but one thing almost all have in common is they handle tracking terribly.

This may be familiar to you, but if not let me demonstrate the situation. We build a site for a client and add Google Analytics to it - pretty standard. Google Analytics has an easy way to allow people to opt-out by setting a global variable so we integrate a wee popup that allows the user to opt out.

That works great until the client gets an SEO expert who wants to track conversions better. They ask you to add a couple more scripts and you dutifully do so, but these have no way to opt out so all you can do is add them.

Later on, they want to add more scripts so they either ask for a text box to add them arbitrarily, install plugins, or install a Tag Manager.

Before long, the site has 5 analytics scripts, 10 conversion trackers and a screen recorder. These may not respect the user's privacy settings or have a way to opt out, and the website could slow to a crawl.

Some developers will give up at the beginning of this process and instead of asking consent put a message saying "This site uses cookies and tracks you. Deal with it or fuck off".

Why this is an issue

There are two reasons why this is a problem. Ethical and legal.

Ethically, if this is your site you are stalking your users - standing 2 metres behind them as they peruse your store. The level of what is acceptable here can be debated, but tracking someones every move without their ability to consent to this is not justified. Place yourself in the shoes of someone who is being tracked across the web by several trackers, without any knowledge that potentially every interaction and details about their computer and location are being harvested and stored. It's hard to dispute in those circumstances.

This is also illegal in many jurisdictions. Consumer privacy laws like GDPR and ePrivacy in the EU, and CCPA and similar in American states requires some level of consent to web tracking. I'm not a lawyer so contact one for proper advice, but this gist is at minimum you need a way for users to be able to meaningfully opt out of tracking.

The opt-out issue

The big problem with the requirement to offer an opt out is that this is very hard to do.

As I mentioned earlier, some scripts like Google Analytics offer a method to opt out. This still isn't ideal as you're loading a tracking script and then checking if you're allowed to run it, but it at least gives you some control.

However that one of few tracking scripts I have come across that allows a way to opt out. Lots of other scripts will happily run as soon as they load, without regard for consequences. Even those that do have methods to opt-out, may be individual for each service and be a nightmare to manage.

Developers can deal with this by dynamically adding scripts under certain conditions, but clients will want to add their own and may not consider the consequences.

As developers we're left in a difficult position. Laws require that tracking can be opt-out, but we have no way to do so.

A possible fix?

The way to fix this is to be in control of all tracking scripts, and then load them ourselves in response to a consent status.

There are many solutions to do this as investors have monopolised on businesses grappling with the issue of tracking and consent.

Some large 'privacy-focused' corporations offer pricey 'hosted consent solutions' that supposedly solve all your problems. However when I load the site of one, my browser tells me it's blocked 14 trackers.
If you've ever been annoyed by a cookie popup, it's probably a solution like this. A big annoying popup that makes opting out difficult and will send all your preferences to a tracking service to track your consent.

My opinion is that some of these companies are morally corrupt. Tracking the consent of users on a remote server is still tracking and they charge extortionate fees to fix a problem their own investors created.

I think the fix is a lot easier. Our webpage only runs tracking scripts when we say so. That's why I made Cead Consent.

Cead Consent

Cead Consent is a small library designed to solve the issue of tracking consent by controlling when scripts can run on the client-side. By making a tiny modification to tracking scripts we can load them on-demand in response to consent status.

It is designed to be extremely simple, easy to use and lightweight, and I'll give you a quick demo of how you would use it to solve the problem of consent.

Check out the GitHub repo for full instructions on installation and usage.

Using Cead Consent to manage Google Tag Manager

First we need to install Cead. It can either be loaded from a CDN or installed via npm, here I'll use the CDN to make it easier. We need to add a CSS file, a JavaScript file, and a little bit of HTML:

<html>
  <head>
    <link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/cead-consent@1/dist/cead.css">
  </head>

  <body>
      <p>Hi! Could we please enable some services and cookies to improve your experience and our website?</p>
      <div class="cead__btns">
        <button class="cead__btn cead__btn--decline">No, thanks.</button>
        <button class="cead__btn cead__btn--accept">Okay!</button>
      </div>
    </div>

	<main><!-- your page content --></main>

    <script src="https://cdn.jsdelivr.net/npm/cead-consent@1/dist/browser.js"></script>
  </body>
</html>

Although Cead consent can be used with all sorts of tracking scripts or pixels, I feel it's at it's best when combined with a tag manager like Google Tag Manager.

We manage tracking scripts (and images) by modifying their code slightly so they'll only run when Cead allows them to. When used with a Tag Manager the client or SEO teams can add as many scripts as they'd like to Google Tag Manager and we need to modify only one script for Cead.

When you copy your script from Google Tag Manager, it will look something like this (with a different GTM_MEASUREMENT_ID):

<script>
dataLayer=[];
(function(w,l){w[l]=w[l]||[];w[l].push({'gtm.start':
new Date().getTime(),event:'gtm.js'})})(window,'dataLayer');
</script>
<script async src="https://www.googletagmanager.com/gtm.js?id=GTM_MEASUREMENT_ID&l=dataLayer"></script>

See that last line, the <script async src="...">? All we need to do is change the src attribute to data-src, and add the data-cead attribute, like so:

<script>
dataLayer=[];
(function(w,l){w[l]=w[l]||[];w[l].push({'gtm.start':
new Date().getTime(),event:'gtm.js'})})(window,'dataLayer');
</script>
<script async data-src="https://www.googletagmanager.com/gtm.js?id=GTM_MEASUREMENT_ID&l=dataLayer" data-cead></script>

And that's it! With the installation of Cead and that small change to the script tag we've made it so users can choose to consent to tracking or not and their choice is respected.

Conclusion

Although the best situation is to avoid adding tracking to sites where possible, it often isn't possible. The best situation then is to use a lightweight, simple consent manager that won't frustrate users, will respect their consent choices and is free and open-source.

Cead has more options including managing inline scripts, tracking 'pixels', an 'opt-out mode', cookie removal and more. Check out the documentation on the GitHub repo to see all it can do!

If you have any comments or feedback on this article, let me know! I'd love to hear your thoughts, go ahead and send me an email at alistair@accudio.com or contact me on Mastodon.

The post Managing tracking consent with Cead Consent appeared first on alistairshepherd.uk.

Today, I wanted to write a little about the section dividers used on my site. These ones:

If you've done any game development they may seem familiar, they're nothing particularly new! They are however a neat thing you can do with SVG and I love those!

For people who just want to dig into a demo, here you go!

If you want more of an explanation then here we go!

Idea: Interesting section dividers

You may have noticed, but this website has a bit of a theme. Pat yourself on the back if you guessed that it's a mountain/landscape theme.

The header and colour changes were the entire basis for my new site, and the colour scheme was to be very simple but impactful. It felt fairly natural that the background of page section should vary between different colours within the theme to separate them. What didn't feel natural though was the hard straight line between them. I played around with curved lines, skewed them, added wobble, but none seemed to feel quite right.

At this point my sister suggested I use a mountain ridge, matching the style of the header. I initially produced a simple SVG manually and inserted it between each section.

I liked how this looked, but when two were visible on screen at once it looked a bit silly them being identical (recreation below).

I didn't really want to manually create more, although it would have been a quick workaround it didn't feel like it was really a solution. My temporary solution was to manipulate the one I did have, using transform to flip, rotate or scale it so it looked slightly different each time.

It bugged me that my site just had the one ridge design, but I didn't really like any of the solutions I came up with.

Terrain Generation

Some time later, I read an article from the Joy of Computing newsletter about terrain generation in game development. I really like the Joy of Computing, although I don't have much time for keeping up with the wider programming industry, their newsletters are cool projects or posts about different areas I don't normally follow like Game Development, DevOps, Hardware or Networking to name a few.

Although the post was not really relevant to me, it made me realise that terrain generation was exactly what I needed! A method to create unique 'ridges' generated every time I needed a new divider.

Working with points

The output format was pretty easy, it had to be SVG. That way I could generate it ahead of time and embed it in the document and not need to rely on client-side JavaScript or outputting a large image file. For my use-case I basically needed a shape with variable top and cover the below area to match the background colour.

I needed a way to convert however I generate the points of the line to an SVG path format. My input array in most cases was in the format [ [ x, y ], ... ], acting as a programmatic dot-to-dot. Turns out that although the path syntax seems a bit complex, when you're building it ends up making a lot of sense. SVG has different 'commands' which do certain things with a few parameteres. Check out the path syntax on MDN for them all, but we're mostly interested in L which draws a line to the specified absolute point. With a viewBox that matches our generation coordinate system we can convert it like so:

// convert points into SVG path
function convertPath(width, height, points) {
  // add first M (move) command to go to the first point
  const first = points.shift()
  let path = `M ${first[0]} ${first[1]}`

  // iterate through points adding L (line) commands to path
  points.forEach(val => {
    path += ` L ${val[0]} ${val[1]}`
  })

  // close path down from the last point to bottom-right, bottom-left, then back to start
  path += ` L ${width} ${height} L 0 ${height} Z`

  return path
}

Attempt 1 — Random

In my keenness, I jumped straight in with my first thoughts. I use Math.random to work out where the next position is and keep going until I've done the whole width:

Ah. Not quite what I was going for, less like a mountain ridge and more like a bed of nails. Maybe the issue is that I'm used fixed intervals, so I tried random intervals too:

Yeah, that looks really cool! Not what I'm wanting though - it has too much randomness and most of the time it just doesn't make sense.

Attempt 2 — Midpoint Displacement

After my first attempt, I actually did some research on terrain generation. I wanted something very simple I could implement myself in JavaScript and very fast.

I discovered the Midpoint Displacement Algorithm which seems to fit the bill perfectly. It's a simple algorithm and isn't very often used in modern games thanks to a lack of sudden steep inclines, overhangs and such, but for a mostly rolling ridge as I wanted it's perfect.

A short summary is how it works is by drawing out a straight line, and then splitting it into two segments at the midpoint. We then take that midpoint and 'displace' it—move it upwards or downwards— by a random amount. We then take the two segments and do the same thing, splitting them in two on a midpoint and displacing that midpoint. Each iteration, we reduce the amount each midpoint can move so as the segments get smaller we get finer and finer detail.

If you're interested in the theory behind it or the implementation I would recommend reading "Landscape generation using midpoint displacement" by Bites of Code. This is a great article about implementing this in Python, and it explains whats happening and why really well. I found it when I was implementing it myself, and most of my code is a JS adaptation of their Python code.

I made a few tweaks and voila! Check out the demo for the code and result:

This works really well, and generates extremely quickly. You can play with the variables at the top of the file to change the dimensions, fiedlity and roughness.

By running the output SVG through SVGO it ends up being pretty small too! This is exactly the method you see around my site at the time of writing.

Attempt 3 — Noise?

I did make a third attempt, using Simplex noise to generate a terrain map with higher fidelity, cliffs, overhangs and flatter regions. I didn't get very far with it however, as I didn't particularly like the effect for the divider—it pulled away too much attention. It was also significantly slower to generate the SVG was quite a lot larger so I ended up ditching it and sticking with attempt 2.

It is very fun to play with terrain generation though so I'd love to play with this some more in future!

Conclusion

Here's the final demo of the divider, as used on my site:

I implemented this server-side with an Eleventy Shortcode, but as it's JavaScript you could easily use it on the client instead. That's what I've done in the demos throughout this post.

There are so many examples of where web designers and developers can learn from game design and development. Video games have so many examples of unique, creative and interesting challenges and solutions in their design and development that we could learn from. This is definitely a case where a fairly standard technique used by game developers can be used for creative result on the web.

Now go have a play and implement something like this yourself! Look at any games you play, or find out a little bit about an industry you aren't as familiar with and see if there's anything you can learn from to make more creative and cool websites!

If you have any comments or feedback on this article, let me know! I'd love to hear your thoughts, go ahead and send me an email at alistair@accudio.com or contact me on Mastodon.

The post SVG generative mountain ridge dividers appeared first on alistairshepherd.uk.

If you want to dive straight in check out the Async Alpine GitHub repo for the docs!

This is a companion post to "Code Splitting in Alpine.js", a post that goes into more depth on why we would want to split up our code more, and the principle on how we do it in Alpine. Check out that for more depth, stay here for how to get started with Async Alpine.

Getting Started

There's a few different methods of installing, depending on how you load Alpine.

If you load Alpine via a CDN script, do the same with Async Alpine:

<script src="https://unpkg.com/async-alpine/dist/async-alpine.script.js"></script>
<script src="https://unpkg.com/alpinejs/dist/cdn.min.js"></script>

For npm installations, install with npm install async-alpine and include it in your bundle:

import Alpine from 'Alpine.js';
import AsyncAlpine from 'async-alpine'
AsyncAlpine(Alpine)
// any components or plugins go here
Alpine.start()

Components

Async Alpine leans into and relies on ES Modules to dynamically import components. This supports all modern browsers and keeps the package fast and lightweight.

An ES Module Alpine component looks like this:

export default function myComponent() {
  return {
    message: 'hello!',

    init() {
      alert(this.message)
    }
  }
}

It's common to write Alpine components like this already, so this might look familiar! The key thing is that the file uses export default ES Module syntax to export the component function.

If you ship handwritten JavaScript then you can write your component similar to above, pop it in your assets directory and you're golden!

If you process JS with a build tool or bundler you may need to do some work to output modules in the right format. This will depend on your build tool, but the majority are easy to set up:

• WebPack — output library type 'module'`
• Rollup — format 'es'
• ESBuild — format 'esm'
• Parcel &mdash: outputFormat 'esmodule'

Importing Components

You write your Alpine components as normal with Async Alpine, and add a couple of attributes to your component root:

<div
	x-data="myComponent"
	ax-load
	ax-load-src="/assets/my-component.js"
></div>

The ax-load attribute declares that this is managed by Async Alpine and declares the strategy—we'll leave that as the default for now.

In ax-load-src you add the public URL of your component module. Here you can use relative URLs (/assets/component.js) or remote full URLs including the domain name (https://example.com/component.js).

Now your component is loaded asynchronously when it is present on the page! No need to load it everywhere in your bundle, it'll only load if it's needed.

Loading Strategies

We left ax-load as the default previously, but we can be more specific than that! By default Async Alpine will load components 'eagerly', that means if the component is used on the page it will be downloaded as soon as it's found.

That's perfect for high-priority components at the top of the page, but for less important components we can use other rules to load them when they're needed. This component will load when it comes into view using the 'visible' strategy:

<div
	x-data="myComponent"
	ax-load="visible"
	ax-load-src="/assets/my-component.js"
></div>

At the time of writing, Async Alpine has six different strategies:

• eager—load the component as soon as it's found;
• idle—waits until the browser isn't busy;
• visible—load the component when the user scrolls close to it;
• media—in response to any browser media query!
• event—use a DOM event to trigger loading at your command;
• parent—for loading nested components smarter.

These can be used as you'd like, and even combined for really advanced loading strategies!

A carousel at the bottom of a page that only displays on small screens? ax-load="visible | media (max-width: 768px)" has you sorted!

An 3D model viewer that runs on a button press but needs to ensure it's parent is loaded first? ax-load="event | parent" will do the trick.

Project Status

Async Alpine is still in development and the API isn't totally stable quite yet. That said, I use it successfully on production sites and would encourage you to give it a try!

There's more information, installation instructions, examples, and advanced settings in the documentation on GitHub.

If you use it or have any questions I'd love to chat with you! I am very keen to see how it can help improve the websites you build, get feedback from people who have used it and make improvements in response!

If you have any comments or feedback on this article, let me know! I'd love to hear your thoughts, go ahead and send me an email at alistair@accudio.com or contact me on Mastodon.

The post Async Alpine — Asynchronous Alpine component loading appeared first on alistairshepherd.uk.

How I use Alpine.js

At Series Eight we love the JavaScript framework Alpine.js. Alpine is a lightweight JS library that allows you to add interactivity and JS to static HTML with attributes using vanilla browser DOM. It makes it easy to add JavaScript to your existing HTML rather than replacing it like more traditional JS, but puts click events and text insertion right where it happens in the markup like more modern.

This post isn't meant as an introduction to Alpine, for that check out Alpine.js: The JavaScript Framework That’s Used Like jQuery, Written Like Vue, and Inspired by TailwindCSS on CSS Tricks.

There are two main ways of writing components in Alpine. For simple components you can write a JavaScript object as a string in the x-data attribute of your component. This is great if there's not a huge amount going on, but you can't import other libraries or transpile modern syntax, and it lacks the syntax and formatting help that writing in .js files provides.
For these more complex components, you can write them as a JS function and declare them with Alpine.data().

I tend to write basic components inline but use JS components for anything with more than a couple variables/methods.

Code loading in JavaScript

Moving away from Alpine for a moment, one area that the entire JS and web industry has been grappling and struggling with is code splitting. When you use libraries or frameworks, the easiest implementation is often bundling everything into a single JavaScript file that has the framework and all your components.

This is simple to build, but in terms of performance can be inefficient and makes little sense. Components appear in different places throughout the site and a user is unlikely to encounter them all. For example, in a typical eCommerce store you might have a static landing page. On the same site the product pages load a 3D model library to show off the products. In a bundling pattern, even though the landing page is static he user has to download all JavaScript required for the entire site—including the 3D library for the product page—even if it isn't needed. This will delay how quickly the page will become interactive on the first load, for a page and features that the user doesn't need yetmdash;and might never need if they don't visit that part of the site.

An alternative to bundling might be to split your application up into several chunks, pages or components. Tools like Next.js will do this for you automatically to mitigate the cost of JavaScript in large sites, but the developer doesn't get much control over this.

Recent tools like Astro and Slinkity take this a step further, allowing the developer to specify when a component should load. In many cases few users will ever scroll down to see a component at the bottom of a long page. We may want to load a component like that only when a user scrolls down far enough to be likely to view it.

Custom implementations have existed for a while, but these tools are the first I've seen to bring it to modern component-based JS libraries.

Alpine component loading

Back to Alpine, when they declare components with Alpine.data() people often bundle them into a single JS file. Alpine needs to register components before it runs, meaning the easiest solution is a single bundle and we definitely don't have the fine control like with Astro/Slinkity. This is back to our issue with loading code that might never be used.

I found that as I worked on Alpine sites the bundle got larger and larger, often with components that were rarely visited or used. One of my sites was 120kB extra for a fancy animation on the bottom of a landing page, that was seen by 0.2% of visitors. This is the easy path with JavaScript frameworks and Alpine, loading that component when it was needed would be tricky and might mean abandoning Alpine.

Code Splitting in Alpine.js

One way we can handle loading components asynchronously in Alpine is by taking control of when Alpine runs components. When it starts Alpine scans through the entire DOM and finds elements with the x-data attribute and runs them. If we rename x-data to something else in our code, then Alpine won't see and run it.

We'd need to consider the other Alpine attributes like x-show, :class and @click and a handful of other Alpine functionalities.

Once we've renamed those attributes and Alpine has started, we can control when we add the components again. We load the component when we'd like to based on certain conditions, use Alpine.data() to prepare it and then rename the attributes back again. Alpine will pick up on the change, see the component and run it as normal.

With that we have a lightweight way to load components on-demand!

Async Alpine

That's a minimal setup that does the basics, but we could go a lot further to add different loading strategies and to support the standard Alpine syntax. I've done that work and released it as a library called Async Alpine!

I've written another post focusing on it more—Async Alpine — Asynchronous Alpine component loading—and you can find more info about Async Alpine on GitHub

It came out of wanting Astro/Slinkity style loading for Alpine components, and I've been working on it the past couple of months. With more control over component loading I could build faster, more efficient websites without changing the syntax of a library I was familiar with. It has advanced loading options including immediately, on idle, when visible, using a media query, DOM events or any combination of those.

It's still in development and will need more testing before I'd consider it stable, but I've used it on several production websites with great success. If you're familiar with Alpine I'd encourage you to give it a try and see how it works for you!

If you have any comments or feedback on this article, let me know! I'd love to hear your thoughts, go ahead and send me an email at alistair@accudio.com or contact me on Mastodon.

The post Code Splitting in Alpine.js appeared first on alistairshepherd.uk.

In response to Competition and Markets Authority’s Mobile browsers and cloud gaming MIR consultation

I am a Front End Web Developer resident in the UK, working for the London-based web agency Series Eight. This response is my personal concerns and comments rather than the position of any of my clients or employers, past or present. Series Eight is a website design and development agency that builds award-winning eCommerce and marketing websites for companies and brands within the UK. As a web developer at Series Eight I work with browsers and websites extensively and my comments come from my experience developing a large number of websites and web apps.

I have previously submitted my experiences and thoughts—specifically in relation to the monopoly of the Webkit browser engine on Apple's iOS—as a response to the Competition and Markets Authority’s Mobile ecosystems market study. My response is available as a PDF on gov.uk

In my previous response I specifically focus on the difficulties I and other developers face due to the lack of browser competition on iOS. Safari is a competant browser but in my experience has a large number of bugs and quirks that are difficult to deal with, and cost me and companies I have worked for a significant amount of time on every project to diagnose and fix. This cost is passed on to the companies and clients I work with, and due to a lack of any competition within the browser space on iOS Apple has little motivation to address these issues. In fact, due to the money Apple makes from native app development, their motivation may be in making web development more challenging on iOS to stifle a competitor platform.

As raised in the CMA's Mobile ecosystems market study, Google also engages in and exploits their entrenched mobile browser monopoly on Android. By utilising their position as the dominant browser, search engine, mobile operating system and email provider, Google is able to ignore the interests of consumers in mobile browser in favour of their own interests. This comes in the form of Google products requiring or 'suggesting' the use of Google Chrome to increase their browser market share, and features and functionalities added to Chrome to support their business interests elsewhere including in Search and Advertising, at the cost of consumer interests like privacy.
Despite Android supporting browser engine diversity and choice on paper, other browsers do not face the same preferential treatment as Google Chrome. Many Google apps will ignore the default browser and instead use Chrome, some APIs and functionalities are only available in Chrome, and features like Progressive Web Apps and Trusted Web Apps in some cases require Google Chrome.
I have spent hours diagnosing issues with websites to find the user reporting them was not aware that Google Search had ignored their default browser and their normal settings were not available, and development of PWAs and TWAs are more challenging when cross-browser development is not possible.

The inability to compete with native apps using Progressive Web Apps fully—particularly on iOS—also has a big impact on my work and the businesses I have worked with. Progressive Web Apps are extremely accessible for development, allowing for the creation of a simple app in a fraction of the time and complexity of a native app. This is fantastic for allowing smaller agencies and businesses to innovate on the web and on mobile devices and to reach consumers. However the poor support for PWA features by Safari and by not allowing them in the App Store, Apple forces app development to be difficult, time consuming and extremely expensive. I have spoken with many companies who would have liked an app to compete with their larger competitors but are unable to afford the huge costs in developing a native app.

I consider the analysis of the features of concern and the reference tests in regards to mobile browsers is correct and accurately reflects my experiences and concerns. Mobile browsers are a key part of participation in modern society and the market being fair and competitive for consumers is vital.

I believe that the opening of mobile browsers will be an almost universal benefit. As we have seen in the industry of web browsers in the past during the mid-2000's for Internet Explorer, a monopoly without reasonable competitor browsers causes progress and standards in web development to fall and negatively impacts developers and consumers significantly. By opening this up consumers can make meaningful choices to respect their preferences towards certain features, companies and privacy. Developers will be able to rely on more competitive browser engines prioritising bugs, security and interopability. In this manner I believe it will also benefit Safari and Chrome, motivating their teams to push for further improvement and innovation.

I broadly agree with the remedies presenting by the CMA in the Mobile browsers and cloud gaming MIR consultation in regards to mobile browsers. I think that removing Apple's restrictions on browser engine diversity and mandating equal functionality for browsers is extremely important to restore competition in the mobile browser ecosystem.

In regards to the suggestion for requiring choice screens, I don't believe that they would be an effective or required remedy. I am not sure they are particularly effective at preventing users from choosing the default browser, and it simply moves the goalposts on what browsers are allowed to 'compete'. When Microsoft implemented a browser choice screen in Windows I saw it pose more confusion to users than help. I am of the belief that a market where all other things are equal besides pre-installation solves the issue without the need for choice screens. I believe that the prevelance of Chrome on MacOS and Windows devices show that good browsers can easily overcome pre-installation.

An additional remedy I think is important to improving competition of mobile devices is in regards to ensuring PWAs are treated equally to native apps. I believe that Apple particularly should be required to allow PWA submission to their App Store so PWAs can compete effectively with native apps. In my experience this would significantly open up access to app development to a huge number of developers and businesses that could not afford native app development or the management of multiple platforms.

It is also extremely important that browser choice is always respected, especially when alternative browsers are available. Google, Apple, and third-parties including Meta are known to ignore default browser choice in some circumstances. A requirement for diversity is not effective when apps can ignore a user's preference, so I think it is important that platforms and apps be required to respect the default browser as a potential additional remedy.

I believe the remedies as proposed and I have mentioned would be sufficient and effective at allowing for competition in mobile browsers and in addressing the entrenched market power of Apple and Google in the mobile browser ecosystem. I have less experience with the cloud gaming industry, however as a consumer the concerns and proposed remedies do seem accurate and appropriate to ensure competition in this area.

My comments are of a personal capacity and do not represent any organisation I work for. I would like my response to be attributed to me by name, and you have my permission to publish or quote from this document with or without attribution.

Best regards,
Alistair Shepherd

If you have any comments or feedback on this article, let me know! I'd love to hear your thoughts, go ahead and send me an email at alistair@accudio.com or contact me on Mastodon.

The post My comments to Competition and Markets Authority on mobile browser competition appeared first on alistairshepherd.uk.

This is a wrap-up of my year, which has been extremely busy for me. It's mostly for myself to look back on, but if you're interested then great!

I didn't used to 'get' round-up/wrap-up posts, but over the past year I've got into journalling and taking note of what I've been doing so I can look back on it. A post like this suddenly makes sense now I realise it's primarily for me to look back on—not to show off!

State of the Browser Conference

The big thing for me was speaking at the State of the Browser conference in London. There I gave a talk called "Creative web: Building dynamic websites for work and play". It was my first experience speaking at a conference, and it was absolutely fantastic. The organisers, other speakers and attendees were so welcoming, friendly and helpful and I owe a massive thank you to all of them.

The recording will be available soon, but my slides are public now if you're interested! I'll also be giving an improved version again in future so watch out for that!

A particular shout-out to Bruce Lawson for his kind and touching advice on where to aim if I needed to projectile vomit. ❤️

My work at Series Eight

It has been a great year for working at Series Eight, I've been involved in some awesome projects, interesting technical challenges, and some really exciting changes in the company. We've got a fantastic team that I am loving working with, and I finally got to meet them for our team trip in Portugal back in September (the disadvantage of working remotely)!

One thing I'm particularly thrilled with about our work over 2022 is how we're really taking the accessibility of our sites seriously. It's a slow process updating old sites and putting a greater priority on it in our processes, but change is coming and I'm so happy to be working somewhere that cares.

At the end of this year I was also promoted to Lead Developer of the team, starting when we return in January! It'll be a new challenge doing a bit more management and admin rather than just coding, but I'm looking forward to working to support the team.

My work - development, speaking and blogs

I've done a bit more open-source and side projects this year than previous, particularly working on my project Async Alpine. Check that out if you haven't already, it's a library for Alpine.js that supercharges component loading and I am so proud of it. Thanks to the SeriesEight team and GitHub contributors for suggestions and feedback!

This year I also built Cead Consent and Sailwind. Cead consent is a GDPR/cookie/tracking consent manager that handles enabling/disabling tracking scripts and pixels for your users. Sailwind is a fluid spacing utility generator for TailwindCSS, I'm pretty excited about the potential it offers for translating designs. Both are open-source and I've got some plans for them both coming up!

Recently with my growing distaste for Twitter I've started helping with and contributing towards Tweetback, a tool to host your tweet archive. I've made a handful fo contributions so far but I'm very keen to continue to help out and make it easier for people to own their content.

In speaking, other than at State of the Browser I've spoken about Image CDNs on quite a few occasions. I did several meet-ups earlier in the year and even a Twitch stream! A big thanks to everyone who hosted events I've spoken at over 2022.

Finally, I've written some blog posts I'm really happy with! Here's the list in reverse order:

• My comments to Competition and Markets Authority on mobile browser competition
• Code Splitting in Alpine.js
• Async Alpine — Asynchronous Alpine component loading
• SVG generative mountain ridge dividers
• Managing tracking consent with Cead Consent

Personal life

Like many people—and the year in general—2022 was a bit of a rollercoaster for me. There's been some rough spots but this post is focusing on the positives!

Although Covid is of course still ongoing, with some care I've managed to meet up with friends I mostly hadn't seen since pre-pandemic which has been the highlight of my year. We went on a holiday to Dubrovnik, Croatia together and when this post is published I'm hosting people for a new years party.

Earlier this year I made myself a goal to climb every hill in the Pentlands over 400m, a range of hills near Edinburgh. There's 52 in total and I've managed to get through 24 this year. Those are the easy ones though, getting many of the remaining ones will end up being a bit tricky!

Despite not going abroad I've managed to get out skiing a fair bit this year! I went up to Glenshee several times at the end of last season and managed a day before christmas this season. So excited to get up there more this year!

This is the obligatory note that I've moved from Twitter to Mastodon which has been a breath of fresh air. I'm really enjoying the 'Fedi-verse', if you haven't switched already come join us!

Also I'm dying my hair blue now, why did no one tell me it was this easy before?!

Music, Games, Books and Podcasts

I've watched, played, listened to and read so much great stuff this year I want to share!

Music

It's been a brilliant year for music for me! These are releases I've loved that came out in 2022:

• Night Flight: Crazy (Work On Me) — I utterly adore Night Flight, they're probably my favourite band ever and the two songs on this release are brilliant. I can not be more excited for their next album!
• Yumi Zouma: Present Tense — Fantastic chill indie pop, seeing them live in King Tut's in Glasgow was one of the best gigs I've ever been to;
• Gang of Youths: angel in realtime — this one took me by surprised, becoming one of my favourite albums this year in a matter of days;
• Barrie: Barbara — I love chill indie pop, and Barrie nails it perfectly;
• White Lies: As I try not to fall apart;
• Pale Waves: Unwanted;
• Everything Everything: Raw Data Feel;
• Conan Grey: Superache.

Games

I played a bunch of short indie games this year that were astounding. I'll save the commentary for only the top few but I'd love to speak about any with you if you'd like! Not all of them were released in 2022 but I played them all for the first time this year:

• Strange Horticulture — I'm a sucker for a story-heavy occult game, add mystery elements and set it in the lake district? One of my favourite games ever made;
• The Case of the Golden Idol — whodunnit mystery that's genuinely challenging with beautiful pixel graphics;
• The Stanley Parable Ultra Deluxe — I loved the first game and this adds a similar experience but totally new. Perfect;
• Hades;
• Behind the Frame;
• I am Dead;
• The Artful Escape;
• Genesis Noir;
• Grand Mountain Adventure;
• Superliminal;
• What remains of Edith Finch;
• Gorogoa;
• Valheim;
• The Vanishing of Ethan Carter.

Books

I mostly consume books in the form of audiobooks, but I'll put them in one list with physical books! The top couple are work-related, the rest my normal reading. Again, not just books that came out this year but just ones I read this year.

• Engineering Management for the rest of us: Sarah Drasner;
• Understanding Privacy: Heather Burns;
• The Spy and the Traitor: Ben MacIntyre;
• Circe: Madeline Miller;
• The song of Achilles: Madeline Miller;
• Storyland, A New Mythology of Britain: Amy Jeffs;
• Persian Fire: Tom Holland;
• The Anarchy: William Dalrymple;
• Dominion: Tom Holland.

Podcasts

Only a couple new ones so here's all of the podcasts I've been listening to, new and old:

• Shop Talk;
• No Such Thing as a Fish;
• The Rest is History;
• Song Exploder.

Photos

If you have any comments or feedback on this article, let me know! I'd love to hear your thoughts, go ahead and send me an email at alistair@accudio.com or contact me on Mastodon.

The post My 2022 round-up appeared first on alistairshepherd.uk.

I had already been considering getting a new phone for a bit however, as my trusty 9T certainly had it's problems. I'll get onto some of the software issues later, but also the pop-up selfie camera only popped up about 30% of the time (thanks to a Snowboarding accident). I regularly got strange looks as my phone whirred unhealthily and I shook it upside-down to try to get the camera out.

So at this point I was looking for a new smartphone, and for anyone who isn't a big fan of either Apple or Google as I am you'll be familiar with the dilemma. Android is a privacy and security hell-hole where you're expected to get a new phone almost every half an hour. iOS is possible slightly better for privacy but expects you to sell at least 3 organs to get the cash to buy a phone. Also fuck the browser ban.

Thanks to Neil Brown, I found GrapheneOS, a mobile OS which promises to solve all my problems. I've since been using it for a couple months on a Google Pixel 6 and it's been fantastic. This post is about my experience with it to share the love!

What is GrapheneOS?

So GrapheneOS is Android... kinda. It's basically the open-source version of Android but with loads of added security and privacy functionality. It's open-source, officially supports all the most recent Google Pixel devices and can be fairly easily installed to replace the default Pixel Android.

By default it doesn't include Google apps or services for security and privacy reasons, so Google doesn't have constant access to your device for their nefarious purposes. It does however support android apps, and you can install Google services in a limited way to ensure maximum compatibility while ensuring it doesn't have full control/access.

It sounded fantastic, Android app compatibility including for apps that need Google services, whilst a priority on security and privacy. That's exactly what I want from my phone.

My previous mobile OS

So on my previous couple of phones I tried to do something like what GrapheneOS promises. I had a de-googled version of Android, with the microg project adding support for apps that needed Google services.

Unfortunately in practice it didn't work great. Props to all devs involved in making it happen, but so many apps didn't work on it. Some intentionally: "Your phone is insecure, fuck off", some just crashing.

I had to carry a second phone with me that had 'normal' Android on it for my banking apps, most takeaway/food delivery apps, on holidays I was relying on others to order an Uber for me, and mobile gaming was pretty much completely out. There were often workarounds and alternatives for some of these but it was regularly a huge effort just to install an app.

GrapheneOS installation and set-up

Graphene has a very fancy web-based UI for installing itself onto devices and extremely good instructions and documentation. It was probably the easiest OS install/flash I've ever dealt with, mobile or otherwise.

Compatibility with different computers seems a bit iffy, I couldn't get it working on my Windows 11 desktop (driver issues probably) and work Macbook (USB C-C cable not being right maybe?) but it worked fine on my personal Windows 10 laptop. If you have issues try different computers you have access to and different cables.

You basically just go through all the steps, doing what you're told and clicking the buttons when prompted. I did have some cases where it seemed to stop at random points so I had to re-do some steps when they didn't finish but eventually they all worked and I got it installed.

Set-up was pretty standard Android, minus all of Google's shitty questions about tracking and such. Overall very easy to get installed and set up.

Multiple Profiles

GrapheneOS has full separate user profiles and encourages users to utilise these to isolate different apps from each other to increase privacy and security. On Android every app can see what other apps you have installed on that user and potentially interact with them, so if you split your apps across different users it limits how much each app knows and can potentially affect.

It also allows you to more easily control what apps are running when. If a user is not 'logged in', none of the apps in it can run in the background.

I got really confused about how to set this up at first. I understood the concept but didn't really get the details about what was being suggested? Looking at what other people did confused me further as it varied so much. Some people would have an 'Instagram' user, others would not use the default user at all, I didn't really get what extent I should be using user accounts.

Once I played with it a bit it started to make more sense. I'd suggest thinking about them as different 'contexts'. I ended up with this user structure:

• Main profile — my 'normal'. Has stuff I use often and anything I want running in the background;
• Social Media — social media apps, allowing me to only engage with them when I explicitly want to;
• Google Services — this is where I have Google Play services installed for apps that need it. Food delivery apps, games and misc apps I need that can't run in my main profile;
• Work — I like being able to have easy-access to my work email and Slack, if I'm out and running late for example. This allows me to keep it out of mind unless necessary;
• Private — stuff that I want behind an extra later of security and a different PIN code. Includes banking apps and anything I wouldn't want my parents to be able to switch to!

My thoughts on Graphene after a few months

I really like GrapheneOS. Quite often software intended for people who are security/privacy minded compromises a lot on usability but the user experience of Graphene is fantastic. It has a handful of issues—more on that in a sec—but none are major enough to override all of the problems it solves with the mobile OS market.

Some of the things I love about it:

• The user profiles are fantastic for app control;
• Flawless compatibility with almost every android app I've tried;
• Improved security;
• Nice additional android settings and controls;
• OS updates that happen in the background that have never had an issue or changed anything unexpectedly (more than I can say about Google and Apple);
• Far better privacy—I noticed how Google ads knew considerably less about me and my life after switching;
• The camera works as well as stock;
• Automatic fully-encrypted app backups;
• Gesture-based navigation works brilliantly.

In terms of battery life and performance, it's been pretty much exactly as normal Android when I tried it before installing Graphene. Performance seems the exact same, and the battery life might even be a bit better with less tracking and more control over background apps.

Issues with Graphene

There's not many issues, but as I said it's not perfect.

The most notable for me is that Facebook Messenger calls often don't come through to me. Even if I have the app open, someone will call me and nothing even comes up until the 'didn't answer' message appears. Messages work and I can call people fine, but until I come up with a solution I have to occasionally check my missed calls. It's not a terrible arrangement, my friends and family know to phone me if it's urgent.

I've also found a handful of apps that don't work, with Google Play Services or without. So far there's been three, all random games from the Play Store that crash on startup. None I'm that fussed about yet so I haven't done any debugging. It is a very small number compared to the total number of apps that work great.

I normally have an always-on VPN and have occasionally had issues with connecting to the internet with it on. This might be my Wireguard VPN client but I didn't have any problems on my last phone. Toggling it off and on tends to sort it out.

Google Pixel 6

This post is mostly about GrapheneOS, as the software is what I really care about. If you're planning on buying a phone for Graphene though, I'll mention my experience with the Pixel 6.

I bought a refurbished device rather than new for climate reasons and to not give money to Google directly. After the first device being a store model stolen from an o2 store and unusable, the second one was in perfect nick and as new.

It's a bit big, I think I maybe should have gone for the Pixel 6a as that's slightly smaller, but I manage it okay with fairly big hands. It is slippy so I'd suggest getting a skin or case for it. I've got a Spigen Liquid Air which isn't too thick and offers a bit of protection whilst still feeling pretty premium. I don't like the shape of the back with the big raised camera, but the case makes that a bit less major.

The camera quality is good, I'm not sure it's up to all the hype from the many adverts I've seen but it's better than my previous phones.

The fingerprint sensor is pretty crummy unfortunately, the worst I've used before. It works, but fairly often I have to try multiple times to get in. I originally wondered if this was Graphene, but from some searching it seems to be the phone hardware.

Overall, it's a decent phone for a decent price. A good one to go for if you're buying a new phone for Graphene. I wouldn't recommend it without Graphene though, it's not worth the Google spyware.

Conclusion

I'm a big fan of GrapheneOS and it's pretty much nailed the perfect mobile OS for me at the moment. I've got more control over my phone, how I use it, how apps run on it, and who it reports back to than I ever have before.

I would highly recommend it for anyone considering a new phone, especially if you're considering privacy, security or control over your device.

Feel free to message me or email me if you have any questions about it! I'd be happy to help. 👋

If you have any comments or feedback on this article, let me know! I'd love to hear your thoughts, go ahead and send me an email at alistair@accudio.com or contact me on Mastodon.

The post GrapheneOS as my daily-driver mobile OS appeared first on alistairshepherd.uk.

I track my routes for posterity so I know how long particular walks have taken for if I come back to them again some time. I don't really do much else with them though, and with an itch to build a new site for myself I wondered if I could do something with the route files.

Enter Leaflet

Leaflet is a fantastic open source JavaScript library for displaying and interacting with Open Street Maps on the web. Think of it like the Google Maps JS API but totally free, lacking the horrendous tracking, and more customisable.

Leaflet is pretty easy to get started with, I'm going to use the CDN url:

In the HTML I'm loading the script and CSS for Leaflet and have an HTML element for the rendered map. In the CSS I'm just displaying that map fullscreen.

In the JavaScript we initialise a map on the #map element and set the starting co-ordinates and zoom level. We then add a Tilelayer, which is basically the images that make up the map, along with credit details and then add it to the map.

There we go! We've got a simple map.

GPX Route Files

I can export my routes from OsmAnd in the format GPX. GPX is short for "GPS Exchange", and it's an open standard that's used by lots of different GPS devices and programs for sharing data about routes. It's pretty standard and many GPS and tracking apps will be able to export to it.

I've exported a GPX file to try, and the first thing I notice is it's over 600kB! I'm pretty particular about web performance but I think it's fair to say that is far too large if I can do anything about it.

Thankfully there are various tools to help reduce that filesize. My route tracker is set up to log every 5 seconds so I guess over a 4 hour walk that is a lot of data points, but in reality I don't need nearly that many to show the rough route online. I found gpx studio to be handy for editing GPX files, it allows you to import and export, has some handy tools and importantly allows you to view the route on a map. I used the "Reduce number of tracking points" option (the two diagonal arrows) to reduce the number of tracking points from 2,300 to 390 which reduced the file size a lot. I chose that number by cranking it down until I started to lose some of the fidelity I wanted in the route line.

After reducing the points we got down to 36kB. A lot better!

Displaying the route on the map

The next step was getting the route onto my map. It turns out there's a plugin called leaflet-gpx that makes that really easy. I upload my GPX file somewhere, include the plugin JS in a script tag and can then use new L.GPX to create the route:

I've also got an event listener after this to fit the map to the route when it's loaded. This means I can remove the .setView() when creating the map and not worry about the latitude, longitude or zoom level, Leaflet will handle it for me.

When loading the plugin over a CDN I found the included icons didn't load by default, and I had to add the below code to make them work:

new L.GPX('...', {
  async: true,
  marker_options: {
    startIconUrl: 'https://cdn.jsdelivr.net/npm/leaflet-gpx@1.7.0/pin-icon-start.png',
    endIconUrl: 'https://cdn.jsdelivr.net/npm/leaflet-gpx@1.7.0/pin-icon-end.png',
    shadowUrl: 'https://cdn.jsdelivr.net/npm/leaflet-gpx@1.7.0/pin-shadow.png'
  }
})

This is fantastic and is almost exactly what I'm looking for! How the map looks isn't ideal though, the default Open Street Map tiles aren't very relevant for hillwalking, prioritising roads and the golf course in this example. Ideally I'd have it highlight the different terrain, walking paths, fences, and feature contour lines at the very least!

Tilelayers

Earlier we added a Tilelayer to Leaflet, which I said was basically the images that made up the map. In that example we used the tiles provided by OpenStreetMap, the, 'official' and recommended default of Leaflet. That's just one option however, and anyone can use the data from OpenStreetMap to make their own map tiles looking however they'd like.

Turns out there's a bunch of different Tilelayers out there for all sorts of different purposes, and Leaflet supports lots of them! There's a mixture of open-source, free, and licensed tile providers, with many listed in the Open Street Map Wiki. By finding a tile provider that is more focused on hiking and outdoor pursuits I could get a map that was a lot more suitable for my purpose.

I managed to find Thunderforest, which is a company that offers a range of maps, and crucially an "Outdoors" map that has contour lines, forests, walking trails and hillshading—perfect for my hillwalking maps! They run their maps as a commercial product with API keys, but have a generous free "Hobby Project" tier that is perfect for my use.

We can switch it out really easily by changing the URL used in the L.tileLayer function. Thunderforest also requires us to update the attribution in the bottom-right corner of that map so I've done that here too.

new L.tileLayer(
  'https://tile.thunderforest.com/outdoors/{z}/{x}/{y}.png?apikey=xxx',
  { attribution: 'Maps © <a href="https://www.thunderforest.com">Thunderforest</a>, Data © <a href="https://www.openstreetmap.org/copyright">OpenStreetMap contributors</a>' }
).addTo(map);

Result

Put that all together and we have a handy little widget that allows me to view and display my walking routes on the web!

This was a fun little experiment that was to test the waters for a potential future project. If you're interested to see what I do with this (no prizes for guessing) then follow me on Mastodon!

If you have any comments or feedback on this article, let me know! I'd love to hear your thoughts, go ahead and send me an email at alistair@accudio.com or contact me on Mastodon.

The post Displaying Hillwalking routes on the web with GPX files and Leaflet appeared first on alistairshepherd.uk.

You can find me at accudio@mastodon.scot and if you're not on the Fediverse yet come join us!

Now onto the actual topic of this post, trying out various Mastodon or Fediverse apps for Android! I've been using Twidere since I started, originally because it supported both Twitter and Mastodon and therefore allowed me to transition slowly. I removed Twitter after a few weeks but kept the app as it's decent. Unfortunately however lately I've had it crashing upon seeing particular posts. That means I have to clear the cache and data before re-using it — not ideal!

Hence my search for a new app, but first...

How I use social media and 'must-haves'

I used Twitter — and use Mastodon — in a very particular way. Normally I check in maybe 2-3 times a day, depending on how busy I am. When I start my app, I want it to be exactly where I left off when I last used it. I then go through 'catching up' on what's been posted since I last checked, and once I'm done I finish and get back to work/play. When I next check it I continue from where I finished.

I have a pretty curated feed so this doesn't tend to take me very long and means I don't miss anything from the folks I really care about. I use mutes, hide retweets and separate RSS feeds to keep track of others in a less instant form.

This way of using Twitter and Mastodon is ideal for me, and is the most healthy relationship I've had with Social Media as once I'm 'caught up' there's no more scrolling to do!

I have just one 'must-have' for a Mastodon app (beyond the very basics of loading posts) and from how I use it that'll probably be pretty clear! I need the app to keep track where I am in my feed, no exceptions. I don't mind if loading more posts is automatic or manual, but it has to happen around my scroll position so I don't lose track of where I am. Any other features are a bonus!

The contendors

First, thank you so much to everyone who gave me recommendations when I asked last week, most of these suggestions came from those recommendations.

If there are any good ones you know of that I haven't mentioned then please let me know!

Tusky

Tusky was the most common recommendation I got and it's pretty good! Modern design, very quick, great support for Mastodon features like Polls, editing, displaying of alt text, all of which is beyond Twidere.

Unfortunately, when I'm scrolling up and tap "Load More" it pins me to the top of the new posts rather than the bottom, requiring me to scroll back down to find where I was beforehand. I tried to stick with it for a bit because I really like the other features but it just frustrated me unfortunately.

Husky

Husky is a fork of Tusky and has pretty similar features, mainly focused around Pleroma servers. I don't use a Pleroma server so most of these aren't too major for me as a Mastodon user.

Sadly it faces the same issue as Tusky with loading new posts

Official Mastodon app

I like the design and feel of the official Mastodon app but compared to Tusky and Husky the comparitive lack of customisation kinda sucks. That said, if it can load posts in the way I want it to then that's nothing...

Once again, no it can't. Tapping "Load more posts" pins you to the top (newest) of the loaded posts rather than the bottom (oldest). Another fail :(

Megalodon and Moshidon

Megalodon is a fork of the official Mastodon app that adds support for some pretty handy features like a Federated timeline, more control over posting and image descriptiong viewing. Moshidon is a fork of Megalodon which also adds support for remote local timelines.

Both are cool but suffer from the same issue as the official app when it comes to loading posts.

Mastodon website

I don't necessarily need an app really, I'm perfectly happy to use a website or Progressive Web App instead if that works better. That said, thanks to Gogle being anti-competitive, monopolistic jerks my phone doesn't support Progressive Web Apps properly. So I'm restricted to the Mastodon website of my server as viewed through my browser, no PWA install superpowers.

And this ends up worse than the apps unfortunately! If I load it up having not used it in a few hours the page loads fresh and I'm placed at the top of my feed with the latest post. Absolutely no can do unfortunately.

I can't test how it works as a proper PWA, but giving it the benefit of the doubt I'm blaming this one on Google.

Elk

Elk is a third-party website and PWA for a few different Fediverse servers that is pretty great for customisation and accessibility.

It's another casualty of Google it seems, loaded at the latest post losing track of where I was. It's a great website though so I might switch my desktop use to it, but it doesn't work for my mobile use.

FediLab

FediLab is the best shot yet. It seems a bit rougher than the other apps but works extremely well, with most of the customisation I'd want and loads of super handy features like showing Alt text, automatic privacy-friendly translation, and support for alternative frontends for sites like YouTube, Twitter and Instagram.

This is the first app that copes with my style of browsing the feed! It keeps track of my place in the feed and when I scroll up there's a "Fetch more messages" button that lets me choose whether I want to be placed at the newest first or the oldest — ideal!

I've been using FediLab for about a week, and it's sadly not the success story I hoped it would be. In theory it handles keeping track of scroll position fine but in practice it's not perfect. One in every 3 or 4 opens of the app it will misplace me by a certain amount up or down, making me spend time working out where I was before. Sometimes I think it's just not saving my position during an entire session and the next time I'll be back to where I started.

I really want to stick with it because it's a really solid app and nice experience but after a week of use I don't think I can.

Twidere

So that leaves me... exactly where I started? Even with the crashing and all of the Mastodon features it's missing, Twidere meets my requirement of how I use the app the best. It's tracking of scroll position is rock-solid and that part of it hasn't had any issues at ll whilst I've been using it.

In terms of the crashing, it seems to happen about once every 4-5 days on average, and I haven't put the time into working out exactly what's causing it. To fix it, I need to clear the data and cache of the app and restart it. I'm still logged in at that point, but it's lost all of my customisation. However, there's a way to export your settings to a file so I can re-import that after it's crashed to fairly quickly get back to where I was.

It's a faff, and means when it does crash I lose where I was but that's a lot less frequently for any of the other apps.

I'll miss all of the features of the others, when I want to vote in a poll for example I have to open the post in my browser, copy the URL and paste it into my home server. A bloody pain, but I don't use polls that often. I think the thing that I miss the most is not being able to see an image's alt text within the app, making it hard to keep my my policy of "No alt no boost".

Finally

So there we go, that's a summary of how I switched my Mastodon app usage from Twidere to Twidere! If I've missed a setting on any of the apps that would make them work better, or you have any other suggestions then please let me know!

And once again, join me on the Fediverse at accudio@mastodon.scot, and if you aren't on the Fediverse then come join us! joinmastodon.org is a great place to get started.

If you have any comments or feedback on this article, let me know! I'd love to hear your thoughts, go ahead and send me an email at alistair@accudio.com or contact me on Mastodon.

The post Searching for a Mastodon app for Android appeared first on alistairshepherd.uk.

Turns out that Vercel makes it super easy to set up a simple GeoIP service for yourself!

If you just want the code you can find the repo at github.com/Accudio/vercel-geoip and demo at accudio-geoip.vercel.app. You can fork that repository and deploy it to your own Vercel account to use yourself!

I have also published a very similar post (almost identical to be honest, it's mostly copied) about how to do the same with Netlify.

Read on for a deeper explanation, and let me know if you have any thoughts or issues!

Background

For a couple projects I'm currently working on, recently I had need for a Geolocation API. Nothing too major, just getting a users very rough location based on their IP address, to tailor their default experience of language, currency, or laws.

There are a TON of Geolocation API services with various pricing, trustworthiness and privacy/tracking policies. I looked at a few, but the per-lookup pricing and lack of certainty around trusting a third-party with our users' IP addresses was a bit of a deterrent.

Vercel and Geolocation Headers

If you haven't heard of Vercel before, it's a hosting company that specialises in JAMStack sites, similar to Netlify. It's a good platform for static sites, JavaScript-based frameworks and serverless/edge functions.

It's the serverless and edge functions that are the key to this setup. Serverless and edge functions allow us to run a node.js script on each request, responding dynamically. Serverless functions run on centralised servers (they're pretty badly named!), Edge functions are a bit more restrictive and run directly on the CDN nodes allowing for a potentially faster or lighter response.

These functions can be combined with Vercel's HTTP headers with geolocation information. We can send that data back on the request in a JSON format, and then use that within our front-end JavaScript.

The code

As most of the examples of Vercel's functions rely on Next.js, it's a bit tricky to find how to set up functions without it. For my own later reference and to avoid you having to go through the same research, I'm going through the full process!

1. Initialising

First we need to initialise our repo, npm project and install the Vercel packages.

mkdir vercel-geoip && cd vercel-geoip
git init
npm init -y
npm i -D vercel
npm i @vercel/edge

2. Trying out an edge function

In Vercel projects functions are placed within an api/ directory, so let's create an api/index.js file. This would run on any requests to /api/. Within it, we're going to put the very basics of a edge function that has a basic text response:

// api/index.js
export const config = {
  // Specify this function as an edge function rather than a serverless function
	runtime: "edge"
};

// We export the function that runs on each request, which receives the `request`
// parameter with data about the current request. We'll use this later
export default function (request) {
  // respond to the request with the content "hello world!"
  return new Response('hello world!')
}

To test our function, we can run npx vercel dev to run the Vercel development server. This will ask you to link the project to your Vercel account and some details about the project. You can leave those details as default.

Now, if you visit the dev URL in your browser and add /api — probably localhost:5000/api you should see "hello world!".

3. The Geolocation bit

Now let's amend our index.js file to include the Geolocation bits:

// api/index.js
// Import the geolocation and ipAddress helpers
import { geolocation, ipAddress } from "@vercel/edge";

export const config = {
	runtime: "edge",
};

export default function (request) {
	// The geolocation helper pulls out the geoIP headers from the
	const geo = geolocation(request) || {};
	// The IP helper does the same function for the user's IP address
	const ip = ipAddress(request) || null

	// Output the Geolocation data and IP address as a JSON object, and
	// set the content type to make it easier to handle when requested
	return new Response(
		JSON.stringify({
			...geo,
			ip,
		}),
		{
			headers: { "content-type": "application/json" },
		}
	);
}

Now this won't work in the dev server as Vercel doesn't inject the geolocation headers there, but if you open the function at least it shouldn't error. You can get a preview deployment to test it on the Vercel servers by running npx vercel.

If you visit the /api route on your preview URL you'll get the Geolocation data of your IP address! Neat!

4. Cross Origin Resource Sharing

If we try to call this on a different website with JavaScript, we're going to run into CORS issues. CORS — Cross Origin Resource Sharing — is a way browsers prevent websites from using a browser to access content they shouldn't have access to, like resources from a local network. This means as things currently stands, a browser won't let us access the content from our API request with fetch.

To allow us to use the API within JavaScript in a browser, we need to tell the browser to allow CORS. We can do this by adding some HTTP Headers, via a vercel.json config file in root of our project:

// vercel.json
{
  "headers": [
    {
      "source": "(.*)",
      "headers": [
        { "key": "Access-Control-Allow-Origin", "value": "*" },
        { "key": "Access-Control-Allow-Methods", "value": "GET,OPTIONS" }
      ]
    }
  ]
}

This is taken from Vercel's "How can I enable CORS on Vercel?" guide. Since this is a relatively straightforward API we don't really need a lot of the parameters in that article, so I've simplified it to allowing all origins, and only the GET and OPTIONS methods.

There is one thing to note with the above code however, the Access-Control-Allow-Origin header allows all origins to make a request to the API. In most cases that might be okay, but you may want to prevent other sites from using your API, especially if you start hitting Vercel's usage limits.

You can whitelist a single origin by adding it to the Access-Control-Allow-Origin header instead of *. You could also include the CORS headers within the edge function depending on the requesting Origin for multiple origins. I haven't run into that problem yet though, so consider that a further exercise for the reader!

5. Root rewrite (optional)

The final touch is a rewrite so we can hit our API at the root URL /, instead of having to include api/ on every request. With Vercel we can do that with a few more lines to vercel.json:

// vercel.json
{
  "headers": [],
  "rewrites": [
    { "source": "/", "destination": "/api/" }
  ]
}

6. Deploy and test!

We can deploy the API to Vercel with npx vercel --prod, or link the project via the Vercel website to a Git repo on GitHub, GitLab or similar. Access the API at the Vercel URL, for example accudio-geoip.vercel.app and there we go!

This is the result I get when visiting that URL (IP obfuscated for privacy):

{
  "city":"Loughborough",
  "country":"GB",
  "countryRegion":"ENG",
  "region":"lhr1",
  "latitude":"52.7681",
  "longitude":"-1.2026",
  "ip":"XX.XX.XX.X"
}

It's definitely not perfect, to start I'm in Edinburgh, Scotland not Loughborough, England! City and Country Region should maybe be taken with a pinch of salt, but that's something I run into with GeoIP systems all over the web so it's clearly not just Vercel. (interestingly, my Netlify post had similar but slightly different results)

For the purposes of country though it's accurate, and the City and Region may be helpful to set a default that a user can later change.

7. Using the API within JavaScript

We can use this within JavaScript on another website like so, but keep in mind you may need to switch from using await to .then() depending on your setup.

const geoRequest = await fetch('https://accudio-geoip.vercel.app')
const geo = await geoRequest.json()

console.log(geo.country)
// GB

If you have any comments or feedback on this article, let me know! I'd love to hear your thoughts, go ahead and send me an email at alistair@accudio.com or contact me on Mastodon.

The post Simple, cheap GeoIP API using Vercel Edge functions appeared first on alistairshepherd.uk.

Turns out that Netlify makes it super easy to set up a simple GeoIP service for yourself!

If you just want the code you can find the repo at github.com/Accudio/netlify-geoip and demo at accudio-geoip.netlify.app. You can fork that repository and deploy it to your own Netlify account to use yourself!

I have also published a very similar post (almost identical to be honest, it's mostly copied) about how to do the same with Vercel.

Read on for a deeper explanation, and let me know if you have any thoughts or issues!

Background

For a couple projects I'm currently working on, recently I had need for a Geolocation API. Nothing too major, just getting a users very rough location based on their IP address, to tailor their default experience of language, currency, or laws.

There are a TON of Geolocation API services with various pricing, trustworthiness and privacy/tracking policies. I looked at a few, but the per-lookup pricing and lack of certainty around trusting a third-party with our users' IP addresses was a bit of a deterrent.

Netlify and Geolocation

If you haven't heard of Netlify before, it's a hosting company that specialises in JAMStack sites. I use it for this website and a lot of my personal projects, and it's a great platform for static sites, JavaScript-based frameworks and serverless/edge functions.

It's the serverless and edge functions that are the key to this setup. Serverless and edge functions allow us to run a node.js script on each request, responding dynamically. Serverless functions run on centralised servers (they're pretty badly named!), Edge functions are a bit more restrictive and run directly on the CDN nodes allowing for a potentially faster or lighter response.

These functions can be combined with Netlify's context object for geolocation information. We can send that data back on the request in a JSON format, and then use that within our front-end JavaScript.

The code

For my own later reference and potentially yours, I'm going through the full process of setting up a simple Edge function on Netlify!

1. Initialising and installing Netlify CLI

First we need to initialise our repo, npm project and install the Netlify CLI for local development.

mkdir netlify-geoip && cd netlify-geoip
git init
npm init -y
npm install netlify-cli -g

2. Trying out an edge function

In Netlify projects edge functions are placed within the netlify/edge-functions/ directory by default, so let's create an netlify/edge-functions/geoip.js. Within it, we're going to put the very basics of a edge function that has a text response, and specify Netlify should serve it as the root request /:

// netlify/edge-functions/geoip.js
// Specify that this function should run on the path `/`
export const config = { path: '/' }

// We export the function that runs on each request
export default () => {
	// Respond to the request with the content "hello world!"
	new Response('hello world!')
}

To test our function, we can run netlify dev to run the Netlify development server. Now, if you visit the dev URL in your browser — probably localhost:8888 you should see "hello world!".

3. The Geolocation bit

Now let's amend our geoip.js file to include the Geolocation bits:

// netlify/edge-functions/geoip.js
export const config = { path: '/' }

export default async (request, context) => {
	// The context parameters includes details about the current request,
	// including the geolocation information and client IP address
	return Response.json({
		...context.geo,
		ip: context.ip
	})
}

Once again we can test this with netlify dev, you may need to restart the development server to get the latest changes. If you visit the preview URL you'll get the Geolocation data and your IP address in a JSON format! Neat!

4. Cross Origin Resource Sharing

If we try to call this on a different website with JavaScript, we're going to run into CORS issues. CORS — Cross Origin Resource Sharing — is a way browsers prevent websites from using a browser to access content they shouldn't have access to, like resources from a local network. This means as things currently stands, a browser won't let us access the content from our API request with fetch.

To allow us to use the API within JavaScript in a browser, we need to tell the browser to allow CORS. We can do this by adding some HTTP Headers via the second argument of Response.json:

export const config = { path: '/' }

export default async (request, context) => {
	return Response.json(
		{
			...context.geo,
			ip: context.ip
		},
		// Add a second parameter to `Response.json`
		// where we can provide our CORS headers
		{
			headers: {
				'Access-Control-Allow-Origin': '*',
				'Access-Control-Allow-Methods': 'GET,OPTIONS'
			}
		}
	);
};

You could be more specific with your CORS headers, but for a simple API like ours this will do fine. These two lines allow all origins to access the API, and only the GET and OPTIONS methods.

That is one thing to note however, the Access-Control-Allow-Origin header allows all origins to make a request to the API. In most cases that might be okay, but you may want to prevent other sites from using your API, especially if you start hitting Netlify's usage limits.

You can whitelist a single origin by adding it to the Access-Control-Allow-Origin header instead of *. For multiple origins you could also dynamically read the Origin header and use that to allow or disallow a request. I haven't run into that problem yet though, so consider that a further exercise for the reader!

5. Deploy and test!

We can deploy the API to Netlify with netlify deploy --build --prod, or link the project via the Netlify website to a Git repo on GitHub, GitLab or similar. Now access the API at your Netlify URL, for example accudio-geoip.netlify.app and there we go!

This is the result I get when visiting that URL (IP obfuscated for privacy):

{
  "city": "Newbury",
  "country": { "code": "GB", "name": "United Kingdom" },
  "subdivision": { "code": "ENG", "name": "England" },
  "timezone": "Europe/London",
  "latitude": 51.3195,
  "longitude": -1.4146,
  "ip": "XX.XX.XX.X"
}

It's definitely not perfect, to start I'm in Edinburgh, Scotland not Newbury, England! City and Subdivision should maybe be taken with a pinch of salt, but that's something I run into with GeoIP systems all over the web so it's clearly not just Netlify. (interestingly, my Vercel post had similar but slightly different results)

For the purposes of country though it's accurate, and the City and Subdivision may be helpful to set a default that a user can later change.

6. Using the API within JavaScript

We can use this within JavaScript on another website like so, but keep in mind you may need to switch from using await to .then() depending on your setup.

const geoRequest = await fetch('https://accudio-geoip.netlify.app')
const geo = await geoRequest.json()

console.log(geo.country.code)
// GB

If you have any comments or feedback on this article, let me know! I'd love to hear your thoughts, go ahead and send me an email at alistair@accudio.com or contact me on Mastodon.

The post Simple, cheap GeoIP API using Netlify Edge functions appeared first on alistairshepherd.uk.

I used to be thrilled over everything new, but in the past decade or so it's just faster, smaller, higher pixel density. VR got kinda close but still feels a bit like strapping a phone to my face.

That's why I was so surprised when a new pair of earphones completely blew my fucking mind. Those earphones are the Aeropex by Aftershokz and they're a pair of fantastic bone conduction earphones. I don't do reviews but my amazing experience with these meant I had to share it.

Previously when on video calls at work I used a pair of open-backed headphones or a pair of fairly standard earbuds. Now I'm quite a loud person normally, and it turns out that when I talk with headphones/earbuds in I get even louder, almost shouting. Enough that when I starting having more calls my partner complained and a neighbour mentioned it. 😬

I'd heard of bone conduction earphones before and they seemed like a decent option. If you're not familiar with them, they have a couple of pads that sit against your temples and get sound into your brain by 'conducting' it through the bone. It then travels to your eardrum through the bone and you hear it as if it was normal sound coming through the air. This leaves your ears and ear canal clear for environmental noise and for your own voice, importantly for me.

TLDR: the Aeropex are amazing, blew my mind when I first started using them and would recommend them to everyone. They're comfortable, sound great, are easy to use and hold a decent battery. I've used them for about 4 months now, they've replaced all of the other earphones/headphones I had previously, and I don't think I'll ever go back to other headphones/earphones.

Buying, unboxing etc

I bought them on discount for £90 from Amazon, the Aeropex no longer seem to be on Amazon but they're available for similar prices elsewhere and the OpenRun on Amazon looks pretty similar.

It was in very professional and nice packaging, although a bit on the over-engineered side. Standard sort of thing for tech products. The box included the earphones themselves — pre-charged to a pretty full battery — a silicone carrying case I'll never use, disposable foam earbuds (I guess for if you actually do want to block out noise?) and two charging cables.

The earphones themselves are pretty small and light, so don't have a USB or whatever port and instead has a custom magnetic two-contact charging connection. The charging cable is USB A on one end and just snaps in place when close to the earphones. Having a second cable is a nice touch, I wouldn't want to lose one and not be able to easily get a replacement.

Setting up, using them, and the fit

They pair via Bluetooth, a pretty standard 'hold the button til you hear the beep' sort of setup. They seem to be able to pair with any number of devices — so far I'm at 7 — and to switch you just disconnect from one device and reconnect to another. They'll automatically connect to the last device used which can sometimes be annoying — my laptop on sleep the other side of the house will connect to it instead of my phone right next to me. The connection is really solid and has never really had issues except when the device and earphones have been separated by a good 10m or a few walls.

Aftershokz claim the battery life is 8 hours but I found it was consistently a lot better than that. For me they last about 10-15 hours of near-constant use, and generally does me 2-3 days before needing a recharge. They recharge very quickly, needing only 30 mins or so from dead to full.

On battery, there are audio warnings about the battery level when you turn on/off and as you approach empty. They're not super useful though really, I find "High" lasts a couple hours, "Medium" lasts ~5 hours and "Low" lasts 5+ hours. So I hear "Low" and have no idea if that means 'need to charge tonight' low or 'about to shut down' low. Android, Windows and Mac all report the percentage in increments of 10% pretty accurately though so check that instead.

They go easily over your ears and behind the back of your head, holding themselves pretty well but not tightly. They're very flexible so will likely fit most heads okay. They're super easy for me with fairly short hair, but as a friend discovered they're a bit trickier for longer and curlier hair — you may need to put them between your hair and back of your neck.

They're probably the most comfortable personal audio device I've had, as they're very light and just rest on your ears with no pressure. They do compete for space above my ears with my glasses but not enough to be uncomfortable, I just need to make sure they're on the outside otherwise my glasses fall off. I fairly regularly leave them on even if they're turned off as I either forget I'm wearing them or it's more convenient than carrying them.

Buttons are fine, a simple play/pause on the left side makes it super easy to pause if needed and volume+power controls are tucked behind the right ear. The buttons have multiple functions depending on how you press them but all I really use are power on/off, volume, and play/pause.

The sound and in different uses/environments

How good do they sound? Great. A lot of criticism of bone conduction earphones is that they typically don't sound amazing. Bone through skin is harder to vibrate than air I guess!

But these really do sound good. I'm quite into music and have some decent audio kit, talking a few hundred quid of DAC, AMP and speakers at both my desk and living room, some studio-quality headphones and ~£200 wireless earbuds. Even then I can only really critique the quality of the Aeropex when directly comparing them. They're not going to win awards for best sound, but in isolation I find it quite difficult to judge. I've heard many 'traditional' earbuds and headphones from audio companies that sound worse despite costing more.

Getting into more detail, they sound even and well-balanced but lacking some bass. The high frequencies aren't sharp which I love as I'm quite sensitive to high frequencies. Lower frequencies apparently don't conduct as well from the bone to the eardrum which is why they don't come through as well. It's not bad or very noticeable a lot of the time, but for some bass-heavy songs they do lack a bit of oomph.

The way my brain placed sound coming through bone did take some getting used to. Rather than coming from my ears/externally it sounds a bit like the music is actually coming from inside of my head, somewhere between my eyes. It didn't take long for that to be normal however. I suspect this actually helps with my auditory processing issues as it means external noise very obviously comes from a different direction!

The volume controls are just right, the top end is loud but not extremely so. You wouldn't want full volume all the time but are okay for a short period in a loud environment. It can go very quiet if you're sensitive to loud environments and are in almost-silent environments. There's 15 different volume levels so a good amount of control, I tend to keep mine around 7-8 depending on the environment.

The way they sit next to your ears means the pads are sitting right on top of my sideburns. Amusingly that means I do notice a difference in audio quality depending on how unruly my sideburns are! If they have worse contact the quality isn't quite as good so keep that in mind if you have crazy sideburns. My mother would be thrilled to hear I have to keep them better trimmed.

As I mentioned earlier, I use these basically everywhere now. Since I've had people ask 'how do they manage in <circumstance>', here's a summary for you:

Work video calls

Great. I can manage my voice volume and hear my doorbell fine better than open-cup headphones and without speakers. No more complaints from my partner about shouting when on a call!

Around the house

I love them whilst cooking in particular, can hear my environment perfectly yet still listen to music/podcasts. Have to crank them up when the extraction fan is on.

Very loud activities

One area they do not do well. I bust out my old earphones for music whilst I hoover or use loud equipment.

Out and about

Generally good in all but the busiest and loudest circumstances. Music works fine but sometimes I need to rewind an audiobook/podcasts when next to a very busy road or on a Saturday afternoon in Edinburgh centre.

Hill walking

Ideal! As it's generally a pretty quiet environment they do well, and as my ears are still free I can still hear people, vehicles and animals with no problems. I used to have only one earphone in but now I get stereo music and stereo environment!

Exercise/activity

They sit securely (even when I shake my head) and are IP67 water-resistant so you don't need to worry about rain or sweat. I don't run but lots of reviews say they're fantastic for running.

Similarly to hill walking, it's very handy being more aware of your environment and people around you. When using them skiing I really appreciate not having to rip out an earbud when about to hop on a lift!

For activities with a helmet the main thing to be concerned about will be the way they go around the back of your head. For me it sits pretty low, hovering around the back of my neck and works fine with my ski helmet, but something to keep in mind if you wear a bigger helmet.

Microphone

The microphone definitely isn't anything to call home about 😉. I tend to use the mic of the connected device as it tends to be a bit better, but the in-built one does work if needed.

One issue I've had is when used with Windows or MacOS the headphones go into 'headset mode' when a call software uses them for audio output and input. This reduces the output quality significantly and stops the mic from working completely in Google Meet. The easiest solution I've found for this is to use a different mic. In Windows you can set something else as default, in Mac you have to create an 'Aggregate device' using your other mic as otherwise the headset is set to the default every time it connects.

Final thoughts

Honestly I'd recommend these to everyone but the most particular of audiophiles. Many people say these are particularly for running or whatever but I think these are perfect for so much more. On some days I am wearing them about 75% of my waking hours and they continue to be comfortable, great to listen to and keeping me aware of my environment.

If I was scoring it I would give it a 9/10, just missing a 10 thanks to the vague battery level warnings and issues with the microphone on calls until I worked that out. Thank you for reading the first and possibly the last of my tech review series!

If you have any comments or feedback on this article, let me know! I'd love to hear your thoughts, go ahead and send me an email at alistair@accudio.com or contact me on Mastodon.

The post Bone conduction earphones revolution — Aftershokz Aeropex review appeared first on alistairshepherd.uk.

Unfortunately, it doesn't have any alternative text on any of the images so is inaccessible. To make this accessible to more people and with Tom Humberstone's blessing, I've written out the alternative text here. I've written it as one list item per panel, please see the original comic for the images.

Alternative text

1. Two people using sledgehammers to break a laptop, with keyboard keys flying everywhere. One is wearing an apron, the other a waistcoat.
2. Background of futuristic city. "The future is here already. AI art has arrived. Simply write a prompt..."
3. Selfie above Upload file button. "Or allow a company unrestricted access to your likeness..."
4. The same selfie but transformed by AI, has lots of fingers, face with horrible teeth and many eyes, a ridiculous number of fingers and buttons on shirt and a patterned background. "...And ta-da! Some absolutely serviceable hotel lobby art. But calling this 'AI art' uncritically buys into the AI hype machine."
5. A digital hand stealing a piece of art from the wall in front of two alarmed people. "'Algorithmically generated art theft' might be more accurate."
6. Nonsensical pen scribble. "Machine-learning software is 'taught' by feeding it existing art without consent, credit, or compensation. To the extent that mangled signature remnants remain visible on AI art."
7. Protest of people with signs with AI crossed out. "Artists have begun to push back". Man saying: "Everybody who creates for a living should be in code red." "Matthew Butterick, co-counsel in a class action lawsuit brought against AI art by artists"
8. caption: "A common refrain from defenders of AI art has been to label these naysayers:" with four speech bubbles: "Luddite!", "Luddites!", "Luddite!", "Luddism!"
9. Four people having a meal around a table. "---a term synonymous with technophobia, anti-progress and reactionism. It's even used to describe being hapless with new tech." One of the people says "Oh, I can't use TikTok! I'm such a Luddite!" Further caption: "In truth, the Luddites were skilled with machines. They were simply fighting for better works rights."
10. "In 1799, the British government passed legislation that prohibited trade unions and collective bargaining." a old-timey-looking aristocrat signing with a quill with mill-workers in the background looking at a mechanised loom. "Mill owners introduced more machines in their factories, reducing wages"
11. Man swinging a sledgehammer. "And so, in 1811, after years of frustrating negotiations, a spate of coordinated attacks on mill frameworks erupted across the United Kingdom, lef by 'King Ned Ludd'".
12. Warrior with a stick, protests and burning buildings in the background. "Ludd was an elusive figure, spotted with 'a pike in his hand' and a ghostly pale face. Which is surprising. Because Ned Ludd didn't exist."
13. "He was a fiction. A symbolic figure whose 'existence' made it hard for the authorities to target leadership and encouraged decentralized campaigning." Two grinning men cheers a drink.
14. "The Luddites' methods included letter-writing campaigns petitioning for better wages and the end of child labor." An older man with white hair sits between two huge stacks of letters.
15. "Their concerns earned them solidarity from local communities." Well-dressed man in front of large crowd of people saying "You may call the people a mob, but do not forget that a mob too often speaks the sentiments of the people." Captioned "Lore Byron in his first speech to Parliament. Mill owners were terrified. Wages rose. Conditions improved."
16. Soldiers with muskets, papers strewn everywhere, a gallows ominously slightly off-frame. "But then 14,000 soldiers were sent to protect the mills and quash riots. New legislation made frame-breaking a capital offense. Eventually, Key Luddite organizers were identified, arrested and executed."
17. "Yet the movement lived on, Outbreaks of machine-breaking continued for years in the UK and beyond." Man saying "This is dew, Which the tree shall renew Of Liberty, planted by Ludd!" Captioned "Lord Bryon, 'Song for the Luddites'"
18. Woman swinging sledgehammer and breaking something. "In 1837. a spinning jenny in Chalabre, France, was destroyed by workers. The women workers 'made themselves conspicuous by their fury and violence.' From local newspaper L'Aude"
19. "In the 1870s, English textile designer, author and socialist William Morris began taking an interest in the production process of his designs. he was disgusted by the poor living conditions of workers and the pollution caused by the textile industry." A man in a suit says: "Why does a resonable man use a machine? Surely to save his labour. Under capitalism, machines were primarily used to increase production, thereby increasing the worker's drudgery."
20. "People has been making similar arguments against AI art." Tweet from "Cat Bastard Quinn @QuinnCat13": "We could automate menial jobs so people have time to make art and music but apparently we'd rather automate art and music so people have time for menial jobs."
21. "Likewise, Morris was interested in what he called 'worthy work'. he wanted people to take pleasure in their work rather than 'mere toiling to live, that we may live to toil.'" Woman frowning in front of a laptop and a man working in an Amazon warehouse.
22. "He understood that machines were only as progressive as the people who used them." Man in suit in front of loads of notification badges says "[An unfree man is a] slave the machinery; the new machine MUST be invented, and when invented he MUST - I will not say se it, but be used by it, whether he likes it or not."
23. Workers working on a car engine, man in suit looking at pocket watch in front. "In America, mechanical engineer Frederick W. Taylor began using what he called the 'Scientific Management' in his factories. Taylor timed each worker's every movement, breaking down their work into a set of discrete tasks. Then demanded workers speed them up."
24. "Taylorism," as it became known, was less a science than a political ideology concerned with remolding workers into pliant subjects." Workers on production line looking frustrated, Taylor in front says "A complete mental revolution on the part of the workingman... toward their work, toward their fellow men, and toward their employers."
25. "But the spirit of Luddism lived on. Seemingly out of nowhere, there was a rash of mechanical breakdowns at Taylor's factories." Two workers shrug in front of smoke. Taylor, looking angry, says "These men were deliberately breaking their machines."
26. "Despite setbacks and intervention from Congress, Taylorism spread." Pictured is a book "Sabotage, it's history, philosophy and function" by Walker C Smith, with the cover of a black cat opening a bag of money. Captioned "The Industrial Workers of the World responded by publishing two tracts on the topic of sabotage in 1913. 'The aim is to his the employer in his vital spot, his heart and soul, in other words, his pocketbook.'"
27. Hands on a conveyer of plates, written on each: "'Automation' — as it was later dubbed by Delmar Harder, vice president on Ford Motor Company, in 1947 — continued unabated."
28. "The legacy of the Luddites lived on in the latter half of the 20th century. Confined to the lowest-paying jobs, black workers were the first to be targeted by the midcentury push for automation." Two black woman work on riveting a piece of metal. A black man in the foreground says "Not only is the economic situation of the masses of blacks grim, but the prospects are that it wil not improve, rather it will deteriorate. This is due partley to the unregulated impact of automation." Captioned "Robert L. Allen, Black Awakening in Capitalist American (1969)"
29. "The Black Panthers" were also quick to recognize technology and automation were not politically neutral." A black man at a microphone says "If the ruling circle remains in power it seems to me that capitalists will continue to develop their technological machinery because they are not interested in the people... Every worker is in jeopardy because of the ruling circle." Captioned "Huey Newton, cofounder of the Black Panther Party"
30. "The Black Panether Party's Ten Point Program was updated in 1972. 'People's community control of modern technology' was added to the demands for 'land, break, housing, education, clothing, justice, peace'". A group of black people and workers stand in the background.
31. "In 2019 McKinsey Global Institute found that: 'African Americans are overrepresented in occupations likely to be most affected by automation.'" A chart titled "Overrepresentation of African Americans in 3 occupation categories with the highest expected displacement, %" shows: Office support eg secretaries 36%; Food services eg fast-food cooks 35%; Production work eg machinists 34%. Captioned "And the 2030 outlook doesn't look much better."
32. "The introduction of the computer in the 1970s only exacerbated growing tensions. Punch cards used in universities, similar to cards used for drafting recruits for Vietname, were seen as a symbol of bureaucracy and alienation. Students burned, vandalized, and otherwise destroyed punch cards for course registration."Pictured is a woman using a machine, a protext of students, someone holding a punch card labelled 'STRIKE' and a badge saying "I am a human being: do not fold, spindle or mutilate"
33. Person saying "Many people simply stopped drawing distinctions between one card-enabled system and another. Whether the cards registered draftees or pupils, they helped 'the system'." Captioned "Lisa Gitelman, author of Always Already New: Media, History, and the Data of Culture (2008)"
34. "Vietnam had become the first computational war, bringing a shift towards strategies rooted in quantitative data collection and automated analysis." pictured are some men working computer terminals and banks of controls with large screens.
35. "Sensor arrays and unmanned drones became a big part of the war. An ongoing experiment with the intention of the eventual replacement of human pilots. American soldiers were sabotaging equipment, staging protests, and refusing to fight. 'Automation of war', as with the automation of industry, was a political strategy designed to, once again, reassert control over rebellious workers." pictured alongside a Tom Cat drone
36. "Now as more of our daily lives are automated, people are finding that it doesn't always make our lives easier." A man looks confused at a self-service supermarket till as it has a big red X and says "Unexpected item in the bagging area!"
37. "In 2016, a study revealed that physicians spend two hours of computer work for every hour spent speaking with a patient face to face." Two medical works in the background are frustrated at a computer. In the foreground a man says "I'e come to feel that a system that promised to increase my mastery over my work has, instead, increased my work's mastery over me." Captioned "Atul Gawande, surgeon and public health researcher"
38. "In the rush to claim success with new AI software, this invisible human work becomes even more insidious. Researcher Jathan Sadowski calls it 'Potemkin AI'." Three people use computers with red screens, man in foreground says "There is a long list of services that purport to be powered by sophisticated software but actually rely on humans acting like robots."
39. "Writer and filmmaker Astra Taylor calls these modern-day Mechanical Turks an example of 'fauxtomation'." A woman says "[Fauxtomation] reinforces the idea that work has no value if it is unpaid and acclimates us to the idea that one day we won't be needed."
40. "As a 2019 report by the think tank Data & Society concludes: Automated and AI technologies tend to mask the human labour that allows them t obe fully integrated into a social context while profoundly changing the conditions and quality of labour that is at stake." Pictured alongside a woman taking off a robot-like mask
41. "Opposition to 21st-centure tech can be found in unlikely places. Silicon Valley executives are restricting their own children's screen time and sending them to tech-free schools." A quaint small "Waldorf School" has greenery outside it and a man says "You can't put your face in a device and expect to develop a long-term attention span." captioned "TaeWoo Kim, chief AI engineer at maching learning startup One Smart Lab."
42. "In San Francisco, security robots sent to harass the homeless has been repeatedly assaulted, with one being covered in BBQ sauce and wrapped in tarp." A round, pillar-like security robot is covered in a dark liquid.
43. "In Arizona, people are slashing the tires of driverless cards after a driverless Uber struck and killed a woman in Tempe." A driverless car has a smashed window. "People are lashing out justifiably. There's a growing sense that the giant corporations honing driverless technologies do not have our best interests at heart." by "Douglass Rushkoff, author of Team Human (2019)"
44. Pie chart showing 85%. "A Pew research poll found that 85% of Americans favored the restriction of automation to only the most dangerous forms of work."
45. "We're all living through an era in which we have become the product." People in the background are on phones and have $ signs above their heads. A woman in the foreground says "The age of surveillance capitalism is a titanic struggle between capital and each one of us. It it a direct intervention into free will, an assault to human autonomy. To tune and herd and shape and push us in the direction that creates the highest probability of their business success. [There's no way] to dress this up as anything but behavioural modification." Captioned "Shoshana Zuboff, author of The Age of Surveillance Capitalism (2018)""
46. "Many are also drawing attention to the biases of software made by an almost entirely male, predominantly white workforce" A black man's face is being scanned and there's a big red "Error" sign next to him. "I'm worried about groupthink, insularity, and arrogance in the AI community. [...] If many are actively excluded from its creation, this technology will benefit a few while harming a great many. Timnit Gebru, Black in AI cofounder"
47. "VPNs, the dark web, and plugins like RequestPolicy are arguably Luddite responses to new technology". A man says in front of set of red security symbols: "A retrograde attempt to rewind web history: a Luddite machine that, as they say 'breaks' the essential mechanisms of websites." Captioned "Computer science students have already developed Glaze - a tool to precent AI models from mimicking artist styles. Maxigas, Resistance to the Current: The Dialectics of Hacking (2022)"
48. Man saying "Luddism contains a critical perspective on technology that pays particular attention to technology's relationship to the labour process and working conditions. In other words, it views technology not as neutral but as a site of struggle, Luddism rejects production for production's sake: it is critical of 'efficiency' as an end goal." Captioned "Gavin Mueller, Breaking Things as Work (2021)"
49. "Degrowth, Slow Living, Quiet Quitting and the I Do Not Dream of Labour movements could all be described as forms of modern neo-Luddism." Someone tears apart a sheet showing an upward-trending graph. "Lashed to the growth imperative, technology is used not to do the same amount of stuff in less time, but rather to do more stuff in the same amount of time. Jason Hickel, author of Less Is More: How Degrowth Will Save the World (2020)"
50. A man rests a sledgehammer on one shoulder, looking away with trees and rolling hills in the background. "Questioning and resisting the worst excesses of technology isn't antithetical to progress. In your concept of 'progress' doesn't put people at the center of it, is it even progress? Maybe those os us who are apprehensive about AI art are Luddites. Maybe we should wear that badge with pride. Welcome to the future. Sabotage it."
51. "From the Future Issue"

If you have any comments or feedback on this article, let me know! I'd love to hear your thoughts, go ahead and send me an email at alistair@accudio.com or contact me on Mastodon.

The post Alternative text for "I'm a Luddite (and So Can You!)" appeared first on alistairshepherd.uk.

It's Interop 24 planning time! Let's play a game: Tell me what you prioritize, or don't and why?

The Interop Project is an collaboration across the browser communities to focus on making various web APIs interoperable, standard, and bug-free across the Blink, Webkit and Gecko engines. It's been very productive over the past few years to fix interop bugs and to release new features like container queries and subgrid in a co-ordinated way.

Each year, the Interop Project accepts proposals for what should be included in the project, and once whittled down carefully considers how to prioritise working on these various important or exciting proposals.

So Brian has come up with a game! Ask developers to look through the full list, sort some of them and maybe explain a little bit of why they made the decisions they have. I found this a really interesting exercise and a great way of getting up-to-date with some of the things upcoming to the web platform. Please consider looking at the proposals, voting to what you like the look of and maybe doing your own prioritisation like this!

My top fifteen interop proposals

My order comes from my personal priorities, which are in Accessibility, Performance, and making the kind of websites I work on easier/more fun to build. Those are mostly public, lightweight websites with a bit of creativity. I don't know all the proposals super in-depth but I think enough to make a quick judgement of "oh yeah I want that".

There are over 90 proposals in total and pretty much all of them seem like they would be useful — it makes sorting them tricky! The "game" is to prioritise them to your own order, and if you have your own opinions make your own list!

1. display: contents accessibility

All of the accessibility-related improvements and fixes hit the top of my list. I work in accessibility, that was always going to happen and I personally feel like stuff that is "nice to have" for developers should come after reducing barriers and making the web more accessible. This one is both nice to have and an accessibility improvement so tops the list.

display: contents is a very useful CSS property that allows an element to basically remove it's own element box and allow it's child nodes to participate in a higher level. That's particularly handy for wrapping an element in a semantic container—like li—but allowing children to sit within the grid or flex layout of the parent.

Unfortunately, it's hampered by buggy and unreliable accessibility. In several browsers using display: contents will remove an element from the accessibility tree and therefore is best to avoid. It's my first priority as it's a great feature that is currently unusable, and an accessibility issue.

2. Accessibility issues with display properties

Another accessibility one, and this is related to setting display properties on particular elements. In some circumstances changing the display property of certain elements can remove or break accessibility for those elements. These circumstances are all over the web, and it would be good to ensure people relying on accessibility technology aren't impacted negatively.

3. Accessibility (computed role + accname)

The final accessibility proposal in Brian's list, this is standardising and making accessibility roles and names more consistent. It'll make it easier to build complex interfaces in an accessible way, and improve the experience for people using accessibility technology. Sounds great.

4. View Transitions Level 1

View Transitions are absolutely amazing, and I think they're going to a monumental addition to the web. In short, page transitions but also so much more! Particularly for building flashy, creative websites it makes it easier to produce something that feels great without needing to ship a huge amount of JS to do so.

Now this proposal is for Level 1, so only the 'SPA API' that does same-document transitions. Cross-document transitions are in the Level 2 module which is still in draft. That said, there's a lot of amazing things you can do with the SPA API and by getting Level 1 out it'll encourage work on Level 2 and I want that as soon as possible!

5. JPEG XL image format

JPEG XL looks to be a fantastic upcoming image format with great high-fidelity compression, fast encoding/decoding, backwards compatibility with JPEG, and lots of great image format features that make it look like a great candidate for the canonical image format for most-use cases.

From the perspective of web performance I'm really excited for the potential of JPEG XL.

6. Scroll-driven animations

I've been playing with Scroll Driven animations recently and found them a great API that makes it super easy to implement really cool animations linked to the scroll, with performance that's almost impossible to achieve otherwise and only a handful of lines of CSS.

I've worked on projects with complex scroll animations that are basically impossible to maintain. The mess of timelines in JS are a nightmare, and the CSS API and use of native @keyframe animations is fantastic in comparison. From a performance perspective it also removes the need to reach for a 100+kB JS library for a simple scroll effect.

7. Text fragments

Now this one is surprisingly high! Text fragments make it possible to link to certain text from a page and highlight it, using a format like #:~:text=Now%20this%20one%20is%20surprisingly%20high!. Fairly regularly I want to link someone to a specific part of a page/article, but there are no in-built ID anchor links nearby. With this I can manually construct a URL that links straight to where I want it.

I already use it to link people who I know are using chromium-based browsers, but would love for it to be possible in all browsers.

8. CSS Multi-Column Layout block element breaking

I feel like issues and bugs with multi-column layout have been a constant through my career in web since Chrome added support in 2016. Every other time I try and use them I give up and instead use a less ideal Grid, Flex or JS-based layout. Or tell the designer "Sorry, the web can't do columns properly" which is completely ridiculous.

It's about time CSS multi-column is sorted so it's reliable enough to use consistently.

9. Unit division and multiplication for mixed units of the same type within calc()

Currently in the CSS calc function division can only be done by unitless numbers. If we were able to divide by value with a unit it would open the way to strip units and to compare the scale of values with different units.

This isn't one I run into often—hence it's position at 9 there's been a handful of times it's come up as something that would make CSS SO much easier. There is a cool but nasty hack using tan(atan2()) but otherwise the workaround are annoying and either involve duplication or JS.

10. text-box-trim

Text box trim allows trimming the space around text, so you can rely on padding and margins to sit flush with the text glyphs. In some designs you want a really neat alignment between a heading and graphic, currently that's tricky without resorting to fiddling with line-heights or "magic numbers".

In a design-led agency, this is definitely something our designers are looking forward to and would make heading design more flexible and easier.

11. CSS style container queries

If you need to change multiple properties in CSS at once with something manual, your best bet is adding or removing CSS classes. Which requires server-side or JS logic, and can get a real mess. Style container queries allows modifying CSS properties depending on the value of a single custom property. Basically a custom if statement within CSS.

This is an awesome feature and super handy. Despite that, it's lower down this list for me as it doesn't really solve problems I have with the utility-first CSS methodology I use at work.

12. CSS Nesting

This is another one that is super exciting for certain methodologies and ways of writing CSS, but it doesn't really match up with how I do. At work I write utility-first CSS that doesn't really benefit from nesting, and on my own projects I lean hard into BEM-style nesting which needs pre-processed. Ah, how I wish they'd added BEM-style nesting natively but no cigar.

It's extremeley powerful, a great addition to the language, and I know some people super excited for this. Maybe I will be if I have another look at how I structure CSS, but that's why it's not top of the list.

13. CSS background-clip

This is particularly around inconsistencies with how clipping text works with background-clip. Clipping backgrounds to text is a super neat feature that can produce some really cool looking effects, particularly combined with images. It can be pretty finicky though so it would be great if it were more consistent.

14. text-wrap: pretty

A way of preventing widows and generally improving readability across lines in paragraphs. Sounds good, and people who care about typography will love it. Definitely handy, I'll use it when it's available, but it's a relatively minor issue to me.

15. text-wrap: balance

Finally we have text-wrap: balance, which provides a better layout for short blocks of text considering where to break lines. Just adding it to major headings can easily make them look a little nicer. Like text-wrap: pretty, it'll be handy and I'll use it but I'm not clamouring for it!

Honourable mentions

These are all on my radar and of interest, but less of a priority. That may be because I don't know enough, I don't use them, am unsure quite where to place them, or they have less convenient but full-featured alternatives:

• requestIdleCallback
• Declarative Shadow DOM
• attr() support extended capabilities
• Web Share API
• details and summary elements
• CSS element() function
• scrollbar-width, scrollbar-color, scrollbar-gutter
• font-size-adjust, size-adjust

Notable items low on my list

The point of the "game" is prioritisation, and I thought it would be interesting to look at what proposals are popular that I don't prioritise. Clearly lots of people want them so it's definitely not a case of them not bing valuable, just not relevant to me for whatever reason!

• Popover — honestly, I've never had difficulty implementing "popovers" and I'm not sure I love the API.
• WebXR — Nothing on the API, I've just gone off VR and never really 'got' AR.
• Custom Media Queries — I actually prefer the API of the style queries 'workaround'.
• Allowing <hr> inside of <select> — Kinda just a meh version of optgroup? See Adrian Roselli's Splitting within Selects

If you have any comments or feedback on this article, let me know! I'd love to hear your thoughts, go ahead and send me an email at alistair@accudio.com or contact me on Mastodon.

The post Interop Priority Game 2024 appeared first on alistairshepherd.uk.

Available in full on the HTMHell Advent Calendar

If you have any comments or feedback on this article, let me know! I'd love to hear your thoughts, go ahead and send me an email at alistair@accudio.com or contact me on Mastodon.

The post HTMHell Advent Calendar — Getting started with Web Performance appeared first on alistairshepherd.uk.

Available in full on the Web Performance Calendar

If you have any comments or feedback on this article, let me know! I'd love to hear your thoughts, go ahead and send me an email at alistair@accudio.com or contact me on Mastodon.

The post Web Performance Calendar — Ten optimisation tips for an initial web performance audit appeared first on alistairshepherd.uk.

Work

I started a new job at the beginning of 2023, taking on the position of Lead Developer at Series Eight. It's been a really interesting and challenging year, going from being mostly focused on code to instead people and processes. Although I haven't yet achieved everything I set out to, I'm happy with the work I've done and the impact I've had. There's still a lot for me to work on, particularly my stress levels! This year I'm making my goal to be more relaxed and rely on the team more.

Some of the this I'm proud of myself for at work:

• A major focus on accessibility, training the team from little accessibility knowledge to consistently close to WCAG AA conformance;
• Improving consistency in builds with starter projects;
• Overhauling our hosting setup for much better performance with a CDN;
• Being involved in some pretty cool and tricky websites including Smile Makers, Pruden & Smith The Wood Veneer Hub and Viatu

Conferences

I spoke at one conference this year and attended a couple further. I intended to speak at and attend more this year, but focusing on my new job and life got in the way of that.

If you're involved in a conference or meetup for 2024 then please get in touch! I'm updating my current conference talk "Creative Web: Building dynamic websites for work and play" with some exciting new CSS functionality, and also working on a web performance talk called "Making websites fly with web performance for all" for this and next year.

• In early May I was once again attending All Day Hey! which was fantastic as always. Alongside a couple colleagues I wrote about my thoughts on the Series Eight blog.
• State of the Browser in September is one of the highlights of my year. The talks are always top quality, the event is fantastically organised (❤️ Dave), and I see so many friends each time! As with Hey, I wrote a little about each talk on the S8 blog.
• In November I spoke at Halfstack Conf London, giving my Creative Web talk. It went really well and I'm really happy with how smooth and natural it felt, definitely the best I've felt speaking. It was a different crowd from what I'm used to and really nice to meet lots of new people.

Side projects

Async Alpine has done well this year and really taken off into something of it's own! There's been a couple of small releases, including contributions from others, inclusion as a dependency for bigger projects, and had almost 20,000 downloads from npm over 2023.

I experimented a bit with "AI" earlier this year and made Wacky Horoscopes, a site that gives silly daily horoscopes that were generated by an LLM. I'm not entirely comfortable with a project using an LLM to be honest, as is extremely obvious from my writing on the "About" page! I really like the concept, find the result funny, and am extremely happy with the frontend and 11ty build, but in hindsight my current stance on LLMs makes me regret it. That said, the horoscopes have been generated now and there's no further LLM involved so it would be a shame to take it down I think? I'm still not sure.

Near the end of the year I wrote Ridge Map, a node library to generate cool visualisations of elevation data in SVG. I thought it would take a couple hours and it ended up taking me 4 days — it was so much harder than I expected! Check out my "Arts and Crafts" section below for more photos of the results.

Writing

2023 was a huge year for writing for me, with two articles published somewhere that wasn't my blog (or my work's), and went through an editor who really knew their stuff!

Getting started with Web Performance 🚀 was published by Manuel Matuzovic in the HTMHell Advent Calendar and I am thrilled with it. My goal was something that any web developer of any level can use to familiarise themselves with the motive, concepts, jargon, and tools of web performance, and also include some suggestions of things to check first to get started. I feel like I managed to deliver that pretty well, the reception was great, and I'm also working on turning it into a conference talk. A huge thank you to Manuel and the other reviewers for helping me out with it.

I also wrote Ten optimisation tips for an initial web performance audit for the Web Performance Calendar which slightly blew my mind to be honest. I've followed the calendar for a while and I still can't really believe I am of the standard to have an article published there! This and the HTMHell articles are based on the same initial plan but focused on different audiences. If you want to go in-depth into those suggestions this article has more research, details and references.

I've also written quite a bit this year on my own blog:

• GrapheneOS as my daily-driver mobile OS
• Displaying Hillwalking routes on the web with GPX files and Leaflet
• Searching for a Mastodon app for Android
• Simple, cheap GeoIP API using Vercel Edge functions
• Simple, cheap GeoIP API using Netlify Edge functions
• Bone conduction earphones revolution — Aftershokz Aeropex review
• Alternative text for "I'm a Luddite (and So Can You!)"
• Interop Priority Game 2024

And a handful of posts on the Series Eight blog:

• Our biggest takeaways from Hey! All Day 2023
• Shopify’s Winter ‘23 release in action
• Shopify Summer ‘23 Editions: first impressions and best additions
• What we learned at State of the Browser 2023

Travel and holidays

I had a few holidays this year, mostly pretty domestic. I went on a group holiday with university friends to the Peak District, England in June, and to Bridlington, England in December (which has a wonderful zoo with ducks in it turns out).

My dad moved from the Isle of Skye down to south Wales so I went for a final easy visit to Skye and visited his new house in Wales. I've only been to north Wales a couple of times so I'm keen to explore it a bit more! When we visited was a heatwave so the temperature, lovely golden beaches, surfing and non-English street signs made it feel like the Mediterranean!

In October I went to Prague with work for a short get-together and socialise. It's a beautiful city and it was fantastic to meet up with the team in person again, even if I don't yet forgive my boss Mario for the amount of Absinthe I drank on the final night.

Arts and crafts

I'll remember this year for the fact that after about 5 years my design burnout has faded enough for me to finally enjoy designing again! In the summer I started to get into sticker making, and ended up buying myself a Silhouette Cameo 4 cutting machine to more easily produce stickers. I've designed and printed a handful of stickers related to Scotland, development and silly stickers for friends.

It's been good fun to experiment with and make things!

What has really inspired me however is using the cutting machine instead as a pen plotter. You buy an adaptor and some nice pens, and you can have the Cameo draw out the SVG you've designed onto paper. This is right up my alley because it makes art more accessible to me — I can design and draw digital art using code or a graphics program and have the machine put it right onto paper at really nice quality!

Contour prints were where I got started with this but I then wrote Ridge Map in order to generate 3D elevation visualisations to plot. They were my go-to Christmas gift this year, and I even did some of Mars landmarks with watercolour highlights.

I'm keen to keep making things! I'm not sure how 'professionally' I'll do it, on one hand it could be nice to sell art to people who like it online or at local design stores, on the other hand I don't want yet another full-on job! If you do want any of my stickers, prints or want a commission however let me know and I'd love to do so for internet pals!

Media

I didn't play, watch, read or listen to as much this year, instead focusing on blog posts, side projects and arts & crafts. Because of that I'll do short paragraphs about the media I don't have many things to note for, but proper sections for Games and Music.

Getting movies and TV out the way, the only release worth mentioning for me is Barbie — obviously I adored it! I did also go see Rocky Horror Picture Show for a late screening on the day of Edinburgh Pride with free wine and I tell you what that was amazing.

This year I saw more at the Edinburgh fringe than normal, my favourite show was The Tragedy That Befalls the Dastardly Crew of the Kakapo, a perfect example of a Fringe farce with no budget that was side-splittingly hilarious. On live theatre, I also saw Sunshine on Leith at Pitlochry Theatre in November which was fantastic and made me feel extremely patriotic of Scotland, Edinburgh and Leith.

I don't read a lot, but if you're interested in my reading then check out my Literal account (similar to Goodreads). Highlights are The Theory of Everything Else by Dan Schreiber, and Sistersong by Lucy Holland.

On podcasts there was nothing new for me, more Rest is History, No Such Thing as a Fish, The F-Word and The Vanilla JS Podcast.

Games

I didn't play much but there were a few games worth noting! This list is specifically the games I started in 2023, you can instead check out my favourite games ever.

• The Case of the Golden Idol DLC: The Spider of Lanka is a fantastic DLC to one of my favourite games of all time. It's a genuinely tricky detective mystery set in a weird and beautiful pixel world. It's similar to the original in feel, but unique enough to pull it off.
• Yonder: The Cloud Catcher Chronicles is a relaxing open-world game where you explore, Craft, do quests and farm. Really nice chill gaming that I really enjoyed! Also one of the collectibles is cute cats.
• In Terra Nil you use machines to restore nature to a dead world and then clean up after yourself and leave. A short but lovely strategy builder game I'd highly recommend.
• Shadows of Doubt is a randomly-generated open-world detective game that is really cool. Murders happen in a dystopian sci-fi voxel-based city and you have to work out who dunnit. I really enjoyed it but found it pretty buggy so will be coming back to it in a year or two when they've polished it a little more.
• Borderlands 3 is pretty fun action shooter with silly mechanics and writing. It's not the best in the world. but good fun, particularly with friends.

Music

Due to the increased number of calls I'm in at work now, the amount of music I listen to has decreased a fair bit but it's still a lot. Working from home I guess! I listened to a lot of artists and albums from the past few years rather than 2023 releases, so these are artists and albums that I particularly enjoyed in 2023.

• MUNA's self-titled album came out in 2022 but I really got into it this year. That album was 5 of my top ten songs this year. I love Silk Chiffon and Kind of Girl.
• Until this year Portobello had only five songs and one was my favourite ever. This year they released two new singles, Dance (In the City) and Lose My Mind which are both bops I played the shit out of.
• I got into Claud this year, particularly enjoying their 2021 Super Monster but also this year's Supermodels.
• Wild Party has a nice new album with Get Up satisfied my confusing but undeniable taste for very indie bands from southern US that no one has heard of.

If you have any comments or feedback on this article, let me know! I'd love to hear your thoughts, go ahead and send me an email at alistair@accudio.com or contact me on Mastodon.

The post My 2023 round-up appeared first on alistairshepherd.uk.

Context

Yesterday I started a new project for a family member, a simple WordPress website built with a custom from-scratch theme. One of the first thing to sort out is build tooling to bundle my CSS and JavaScript.

Most build tools now seem to be geared around the 'in fashion' technologies like React, Vue etc. I come back to build tooling relatively often, wondering if the tech world has understood yet that making 'index.html' a requirement for your build tool to work makes it useless to a huge number of developers.

If you weren't aware, many build tools want to own your entire website build including HTML and all assets. That works great when your whole website runs through your build, but for dynamic sites that have their own asset loading systems — like WordPress and countless other CMS' — that just doesn't work. Whilst many build tools do offer an alternative it is often second-rate, complex or doesn't have the same functionality I expect from a modern development setup.

That leads me onto my day yesterday. I wanted to work out finally how I can get a good modern development setup on this WordPress site. My requirements:

• Bundles my Scss, JS, inlines small images, imports from npm with tree-shaking. Standard build stuff.
• Uses versioned/hashed asset names to make caching easier and gives me those names in a way I can use in PHP.
• Fast. I don't want to wait for builds.
• Instant hot switching of CSS without need for a reload.
• Automatic reloading of my browser when JS, HTML or PHP changes.

Turns out this was harder to achieve than I expected. Let's go through the candidates:

Laravel Mix is what I'm used to from work and is what a lot of the PHP community uses. Simple, declarative way of bundling assets based on Webpack. It does have Browsersync out-of-the-box for automatic reloading, but it need to proxy your site to do that and I've found it a bit inconsistent. When using Mix I generally manually reload as it's more reliable.

Webpack is awful and I hate it. The configuration system is terrible and indecipherable and in my opinion it is always the wrong decision for a build tool.

Vite is the hot new kid on the block. It's very much designed for frameworks or for if it's also handling your index.html. It is possible to make it work with WordPress etc, but I haven't seen a setup that looks great and their documentation is pretty poor if you opt for that route.

RollUp looks good and I'd like to try it, but I find it quite difficult to actually get what I want from it. I've played with it a few times and just couldn't find a setup that was as flexible as I wanted. That may just be me not understanding right but that I can't work out how to get a simple CSS/JS bundler set up is not a good sign.

A custom system with node scripts and importing packages? It would probably work but there is a lot to deal with that build tools have already been through. Inlining a 600byte SVG into my CSS file is something I want but don't want to have to build myself.

Parcel was what I ended up settling on. It's a little like Vite where it's built for the simple, no config, index.html setup, but I find it's a lot more versatile and easy to use in other circumstances, and it's docs are a lot better for non-standard usecases.

The set up

Step 0. Installation

If you're following along with implementing this yourself, you'll need:

npm install -D parcel livereload pug

For the commands below you'll be able to use them from npm scripts no problems, but if you're running on the command line yourself add npx in front of each.

Step 1. Asset bundling

Parcel handles compilation of most stuff pretty easily and out of the box using link and script tags, so I'm starting there:

<!-- src/assets.html -->
<link href="./css/main.scss" rel="stylesheet" />
<script type="module" src="./js/main.js"></script>

You can run the production build with parcel build ./src/assets.html --public-url /dist/. This will bundle and import my main.scss and main.js files, and output dist/assets.html that includes the HTML to those versioned assets, which looks like this:

<link href="/dist/assets.50a966ac.css" rel="stylesheet">
<script src="/dist/assets.fd9c92df.js" defer=""></script>

I can import /dist/assets.html into the output of my page — for example using PHPs file_get_contents. We can change the path used in the output URLs if needed with the --public-url parameter — for my WordPress theme I use --public-url /wp-content/themes/theme/dist.

Now we have asset bundling with URL hashing that we can import into our templates. The build is also really fast. Nice!

Step 2. Parcel reloading and dev server

Okay so we've got a build, but it's one-off and doesn't do anything about reloading. Next step is setting Parcel up to reload. Although most guides will push you down Parcel's serve mode to serve your assets here, the way to go is actually using watch mode, with this script:

parcel watch ./src/assets.html --public-url /dist/
  --hmr-host localhost --hmr-port 1234

This will run a watcher that compiles the assets and html file whenever CSS or JS files change. It also runs an HMR (Hot Module Reloading) server on localhost:1234 and injects some code into main.js that will check if any assets or the page needs reloaded.

As we're importing assets.html into our site which Parcel is auto-generating, this will pick up the changes between build and dev mode with no further changes. Run the dev parcel command, refresh the page and now we have hot CSS replacement and reloading on JS changes.

Step 3. Livereload for HTML and PHP changes

Whilst Parcel is handling the reloads of CSS and JS nicely, it doesn't do any updates when the HTML or PHP changes. I spent a while going down a rabbit hole of trying to work out if I could piggyback on Parcel's HMR system but found no way of doing that so we're using livereload instead.

Run livereload with this command, which watches HTML and PHP files for changes and triggers a reload. I'm also excluding the dist directory as that would result in a double refresh when Parcel builds assets.html. You can add other extensions here like your templating language.

livereload -e 'html,php' -x dist/ -p 1235

You'll also need to add the below script to your page to communicate with livereload:

<script src="http://localhost:1235/livereload.js?snipver=1"></script>

When we have both Parcel and livereload running we have a hot replacement of CSS and a page reload on JS, HTML and PHP changes! All very fast and works pretty well. One final thing...

Step 4. Automatic addition of livereload script

One problem with what we have now is we need a way to include the livereload script when it's needed in development, but not in the live site. This seemed tricky at first, perhaps we change an environment variable or something we can pick up in the site code? Turns out there's an easier way!

We're likely going to want to run Parcel and Livereload together during development, and Parcel is already building the assets.html differently depending on dev/production. So we can use Parcel to inject the livereload script only in development.

Parcel can't use functional logic in HTML files, but it can use it in files that build to HTML, most notably Pug! Pug is a templating language that compiles to HTML and includes stuff like if statements etc. So we can rename src/assets.html to src/assets.pug and add to our asset markup:

<link href="./css/main.scss" rel="stylesheet" />
<script type="module" src="./js/main.js"></script>
if process.env.NODE_ENV !== 'production'
	<script src="http://localhost:1235/livereload.js?snipver=1"></script>

This will only include the livereload snippet if the NODE_ENV environment variable is not production, which means it won't be included in our production build when we run parcel build ....

Final thoughts and the complete code

I'm really happy with this dev setup! It ticks all of my boxes from earlier, it's relatively simple and flexible, and brings a really nice modern dev setup to sites like WordPress or other CMS builds.

There are definitely some limitations, beyond the standard ones when you don't process HTML with your build tool. The main trickiness I've found is that whilst CSS and JS in the head works great it's a bit faffy to have more structure. You can generate more html files with alternative assets so you could have head.html, footer.html, about-page.html. That does get a little messy and verbose however, and image processing within the build would also require the same treatment.

However, I don't believe I've seen a good development setup with this kind of website that handles this better. A purely up-front build tool like Laravel Mix has the same problems, and none of the 'fancier' tools seem to have a better solution either.

So yeah, I think this is what I'll be using for my own sites going forward, certainly with CMS', I'll see how it compares against my other methods for 11ty sites in future!

If you're just looking to copy+paste, run the npm install command and copy the assets.pug from above. This is my package.json scripts, with npm-run-all for running both Parcel and livereload at the same time:

{
  "scripts": {
    "dev": "run-p dev:*",
    "dev:parcel": "parcel watch ./src/assets.pug --public-url /dist/ --hmr-host localhost --hmr-port 1234",
    "dev:livereload": "livereload -e 'html,php' -p 1235",
    "build": "parcel build ./src/assets.pug --public-url /dist/"
  }
}

If you have any comments or feedback on this article, let me know! I'd love to hear your thoughts, go ahead and send me an email at alistair@accudio.com or contact me on Mastodon.

The post Simple, fast build tooling with live reload for a non-framework website appeared first on alistairshepherd.uk.

I have a few JS libraries that are shipped via npm, and can be used with an ESM import, CommonJS require, or a browser script element. I've found it pretty tricky in the past working out how to compile to all of these correctly from my ESM source, and the internet hasn't been very helpful either.

What I want is a setup that will produce all three of those with no huge legwork, handle bundling, sourcemaps, minification for me, convert modern syntax to es6, and have a dev mode that will re-compile on source change.

Esbuild is ideal for this circumstance as it has a simple API, all of those features and is extremely fast! I'm not saying this is the ideal setup but it works pretty well for me.

build.js

This is the build script, called with node build.js for a production build and node build.js --watch for dev mode. Pop these in your package.json scripts if you like.

You define the formats you want and the esbuild options within buildAll, I find this works well in most instances. This will get src/index.js and src/script.js (for browsers, imports index and runs it) and output to the dist/ directory.

import esbuild from 'esbuild'

buildAll()

async function buildAll() {
	return Promise.all([
		build('script', {
			entryPoints: ['src/script.js'],
			platform: 'browser',
			minify: true,
			target: ['es6'],
		}),
		build('esm', {
			entryPoints: ['src/index.js'],
			platform: 'neutral'
		}),
		build('cjs', {
			entryPoints: ['src/index.js'],
			target: ['node10.4'],
			platform: 'node',
		}),
	])
}

async function build(name, options) {
	const path = `${name}.js`
	console.log(`Building ${name}`)

	if (process.argv.includes('--watch')) {
		let ctx = await esbuild.context({
			outfile: `./dist/${path}`,
			bundle: true,
			logLevel: 'info',
			sourcemap: true,
			...options,
      minify: false
		})
		await ctx.watch()
	}
	else {
		return esbuild.build({
			outfile: `./dist/${path}`,
			bundle: true,
			...options,
		})
	}
}

package.json

To deploy this via npm and potentially load the browser version from a CDN like JSDelivr, we need to set up our package.json correctly. The following snippet is what I've found works well for modern versions of node. exports defines which version of the file to use based on how it's imported, Node will change which version is used based on whether we require or import. We set main to the script.js file so it's picked up by all major CDNs I've tried.

{
  "main": "./dist/script.js",
	"exports": {
		"require": "./dist/cjs.js",
		"import": "./dist/esm.js",
		"default": "./dist/esm.js"
	},
}

If you have any comments or feedback on this article, let me know! I'd love to hear your thoughts, go ahead and send me an email at alistair@accudio.com or contact me on Mastodon.

The post JS library compilation to browser, esm and cjs using esbuild appeared first on alistairshepherd.uk.

Why

CDNs are extremely good for web performance, and if you can deliver your HTML via a CDN you can benefit from extremely fast from-cache load times and rely on a smaller server.

Cloudflare is not without it's problems, but it offers a free tier that gives you extremely good CDN capabilities for zero cost. In my opinion there are better options for bigger usecases, but for a small site the free Cloudflare tier is great.

One thing notaby absent from Cloudflare's free tier is image transformation. I find that super frustrating because loads of companies offer a free tier of image transformation but not Cloudflare, so if you want to keep costs down you're going to have to use a different company. If you're not familiar with Image CDNs and why you should use one, check out my talk on the subject.

With an Image CDN you will probably get a URL something like kdnfwe948owqq.example.com that you can load your images through. Now you're loading your images through a different origin however, there is a performance implication where a new connection has to be established to that origin which may delay image loads.

Wouldn't it be great if we could use our image CDN, but make it use our primary origin that matches our website? It's a little tricky but turns out that's possible to do in the free tier of Cloudflare using Cloudflare workers!

How

This code is mostly taken from Wes Bos and Wilson Hou on GitHub, thanks to them for their work.

First thing is to set up a Worker. You can do this via a command-line but to be honest for this I just use the admin.

1. Go to your Cloudflare Dashboard and "Workers & Pages"
2. "Create", "Create Worker", name it, and then "Deploy"
3. Now lets' assign and test it
4. Assign it to a URL by going to your cloudflare zone/website and to "Workers Routes"
5. "Add Route", choose the worker you've just created and create a route pattern
   • This needs to include the domain name and uses regex to specify patterns
   • www.example.com/images/* will make the worker serve all requests under the /images/ path
6. "Save" and confirm requests to /images/whatever return "Hello world!"

Now we need to add the proxying code. To add this we go back to the worker we created and click "Edit code". This opens an online editor with text field, debugging tools and the "Deploy" button in the top-right.

Add the below code, customise the destination variable and add any path manipulation you need. Then deploy and you should be golden!

const destination = 'https://kdnfwe948owqq.example.com'

async function serveAsset(request, event, context) {
  const url = new URL(request.url)

  // if this is already in the cache return that
  const cache = caches.default
  let response = await cache.match(request)
  if (response) return response

  let path = url.pathname
  // make any path manipulation here, eg removing a prefix
  // path = path.replace('/images', '')

  // request the URL with path and URL params
  // include request headers for content negotiation/auto-format
  response = await fetch(
    `${destination}${path}${url.search}`,
    { headers: request.headers }
  )

  const headers = new Headers(response.headers)
  // add caching header, configured here for 1-year
  headers.set("cache-control", `public, max-age=31536000`)
  // vary header so cache respects content-negotiation/auto-format
  headers.set("vary", "Accept")

  // create response and add to the cache if successful
  response = new Response(response.body, { ...response, headers })
  context.waitUntil(cache.put(request, response.clone()))

  return response
}

export default {
  async fetch(request, event, context) {
    // get the response
    let response = await serveAsset(request, event, context)
    // if not a successful status code return response text
    if (!response || response.status > 399) {
      response = new Response(response.statusText, { status: response.status })
    }
    return response
  },
};

Things to note

This works pretty well, there are a couple of things to note however.

The free Cloudflare tier includes limits on Workers, so depending on the size of your site you may run into these. It's also account-level not website-level so keep that in mind. At time of writing it's pretty high at "100,000 requests/day, 1000 requests/min". You'll likely run into that only if you have a busy site or many using this technique.

This also creates another layer of caching in your image chain, which depending on your setup and if your images are mutable could be tricky. This would probably already be the case for the image CDN however, so you'd be needing to clear two caches instead of one. Using permanent image URLs and ensuring modifications create a copy instead of modifying the original is a great way to avoid this being an issue and better for client caching also.

If you have any comments or feedback on this article, let me know! I'd love to hear your thoughts, go ahead and send me an email at alistair@accudio.com or contact me on Mastodon.

The post Proxying an Image CDN with Cloudflare workers appeared first on alistairshepherd.uk.

In response to Competition and Markets Authority’s Mobile browsers and cloud gaming market investigation potential remedies.

I am a Web Developer resident in the UK, leading the development team for the London-based web agency Series Eight. This response is my personal concerns and comments rather than the position of any of my clients or employers, past or present. Series Eight is a website design and development agency that builds award-winning eCommerce and marketing websites for companies and brands within and outwith the UK. As a web developer at Series Eight I work with browsers and websites extensively and my comments come from my experience developing a large number of websites and web apps.

I have previously submitted my experiences and thoughts to the Competition and Markets Authority, and my responses are available in full on gov.uk:

• Mobile Ecosystems Market Study — February 2022
• Mobile browsers and cloud gaming MIR consultation — July 2022

These responses detail the difficulties that developers like myself face when working with Safari, the impact that the lack of iOS browser competition has on developers and businesses, and the importance and current limitations of Progressive Web Apps on Android and iOS.

I commend and appreciate the work and remedies proposed by the CMA, and believe they make a significant impact towards reducing monopolies by device vendors and opening up web access and capabilities.

I am however concerned by an area not covered by the proposals which may provide a way for Apple to follow the proposals whilst violating their intention.
The proposals make the recommendation that Apple opens up equivalent access to other browsers equal to their Safari browser. My concern with this is that Apple has regularly shown that it it willing to hamper the functionality of Safari browser if it suits their other interests. We saw this earlier this year, where for EU users Apple disabled progressive web app installation within Safari for all users, before eventually backtracking due to public pressure.

This is commonly thought to be due to Apple's conflict as a browser vendor and also an app store provider. By limiting the functionality available to web software via Safari, it encourages developers to build iOS-specific apps sold and distributed via the App Store where app-store fees can be imposed.

My concern is that if browser functionality is pegged against Safari functionality, Apple will effectively kill Progressive Web Apps by hampering Safari rather than allow third-party browsers to enable more competition against native apps from the web. Apple could prevent other browsers from installing web apps to the home screen, or limit the access to Software and Hardware APIs to significantly weaken the capabilities and usefulness of web apps.

The success of Progressive Web Apps is in my opinion essential to opening up access and competition to mobile devices. Progressive Web Apps would all app creation to have a lower barrier to entry, lower fees, and allow for more interoperability between devices.
In my capacity in working for the web within a small agency, Progressive Web Apps are a vital tool allowing businesses and agencies to produce better user experiences at a more affordable cost than native apps. The success of Progressive Web Apps through both Safari and third-party browsers would be hugely impactful to web developers, agencies and businesses where native app development would be prohibitively expensive. This allows big international companies with higher budgets to maintain entrenched advantages on iOS via the app store.

Open Web Advocacy — a group I am a member of — has proposed four additional remedies focused on ensuring that the web can compete fairly on iOS and that Apple is unable to get around the proposed remedies as I have described:

1. "Apple shall allow third-party browsers to install and manage Web Apps using their own browser engine."
2. "A requirement for Apple to implement Install Prompts for iOS Safari."
3. "A requirement for Apple to grant all software and hardware access to APIs to browsers using alternative browser engines that they require to port their engines and implement stability, functionality, security and privacy. Restrictions on this can be subject to only strictly necessary, proportionate and justified security grounds."
4. "Where feature parity between Web Apps and Native Apps is possible, Apple must technically enable it and it should not be artificially prevented either by OS rules or OS design. Apple must not self-preference their own Apps, Apps sold via their App Store or their own Services over Web Apps."

I believe these remedies would be sufficient to ensure iOS is a platform that does not limit and hamper the web. Particularly remedies 3 and 4 I think are vital to ensuring it is extremely clear that Apple must provide equal access to web apps and cannot continue to limit them in order to prefer and push their app store and native apps.

My comments are of a personal capacity and do not represent any organisation I work for. I would like my response to be attributed to me by name, and you have my permission to publish or quote from this document with or without attribution.

Best Regards,
Alistair Shepherd

If you have any comments or feedback on this article, let me know! I'd love to hear your thoughts, go ahead and send me an email at alistair@accudio.com or contact me on Mastodon.

The post My response to UK CMA's potential remedies for mobile browser competition appeared first on alistairshepherd.uk.

Earlier this year someone reached out to me asking about my plans for the project and whether I would be interested in selling it. Fast forward a few weeks and I have sold my first web project and learnt a lot in the meantime!

I didn't find much information online about the process of selling a project, particularly one without any monetisation and at a small scale. This is my attempt at helping others who may end up in this position.

That's the TLDR; stick around for more detail!

About My Top for Spotify

So the project is called My Top for Spotify. It's a pretty small web app built on React that allows a user to connect their Spotify account and see what the Spotify API says about their top artists and songs over a few different time periods.

In early 2017 I was looking to move from freelance development into a permanent role, and loads of jobs were looking for React experience. I'd done the standard hello world and to-do app, but wanted something live, real-world, and app-like for the experience and a portfolio piece. I built it with Create React App and a server based on AWS Lambda and Serverless. To be honest I really don't like the tech stack, and it was the start of my dislike of those two products — but that's not what this post is about!

I cracked it out in a few weeks, the functionality is pretty straightforward and the design has some cool CSS details but overall unpolished. But it was just a demo for me and a few friends so who cares right? I named it My Top for Spotify, purchased a .com and .io domain and deployed, shared it around some friends and family and that was that.

Quite quickly it started to get quite a lot of traffic, ranking highly on search engines, and being mentioned in blogs and YouTube videos. I believe this is because just a few months earlier Spotify released their first Spotify Wrapped — an annual review of your Spotify listening. This seemed to drive loads of interest in seeing this kind of data, and my little experiment ended up top of the search results for queries like "See top Spotify tracks".

And then I basically did nothing! The app got about 4 million annual visitors in those first few years, and I just left it. I considered further work and monetisation but didn't have much interest in that — particularly not in turning it into a business. I paid the hosting and domain costs for it myself, did the odd urgent fix or upgrade and otherwise let it be. After that initial deploy I probably spent about 10 hours on it total over a period of 7 years.

That's where it sat as of May 2024, getting about 1–2 million views a year.

Thinking about selling

I received an email out of the blue earlier this year, asking if I had any plans for the project and if I would consider selling it. I was pretty confident this was a spam email to be honest — perhaps I'm too suspicious! Regardless, I replied with mild interest and frankly saying it was something I hadn't even considered.

What followed was a lot of emails back-and-forth, discussing the project and their interest. The whole process went pretty quick, even despite a time difference between the me in the UK and the buyers in Australia. Within six weeks of that initial email we were making the transfer.

After those first few emails I became very aware I had no idea what I was doing. Searching online brought up some guides and articles, but only a handful that were relevant to a small-scale project that doesn't earn any money. Patrick McKenzie has a good article which I would suggest reading, especially for selling a small SaaS.

I am also fortunate to have some great people in my 'network' that gave me advice, including my parents, folk I work with at Series Eight, and online friends on Mastodon and Discord. A particularly huge thank you to Jan Lehnardt, who kindly spent some time on a call taking me through his experience and helping me work through my priorities and the risks involved. Kilian Valkhof also gave me much-appreciated advice from selling a similar size of project.

Why sell, and my priorities

The main reason I was willing to sell My Top Spotify was because it was going to waste under me. I invested close to nothing into it — AWS and domain costs and the odd hour when there was an SSL cert issue or Netlify needed an update.

I had no intention of doing anything further with it, and there is now more competition in the area — companies actually investing in their products to add new features and gain more visibility. That resulted in a decline in popularity to other tools investing in features and marketing. Ultimately I didn't give or receive much value, and people willing to invest time and money could do a lot more with it.

Because I wasn't planning on selling it originally, that gave me a bit of power over negotiations and the decision — at least in my head. If I decided that I wasn't happy with the arrangement I wouldn't be any worse off — so I could be picky.

On being picky, it was very important for me to consider my priorities for the project and for the sale:

• The buyer should appear to care about the project;
• I had to be confident it wouldn't be immediately strip-mined of value or users exploited maliciously;
• A fair offer (more on that shortly);
• No major risk from me — money before permanent transfers;
• Any additional fees covered by the buyer – common but not standard.

Those were the principles I decided I wasn't willing to compromise on, and I think that was extremely helpful for me to focus on.

I've seen and heard of web projects being strip-mined of value, becoming riddled with ads, or even injecting malware. I really worried about that, and it was the main thing that held me back.

As for the money and risk, as someone new to all this making sure I wasn't about to screw up was really important. Jan was fantastic helping me work through the risks I was and wasn't comfortable with.

How do I value an unmonetised side project?

Okay so I had a stable project with lots of visitors, great search engine ranking, low outgoings, and a pretty promising future.

So what is it worth?

Wherever I looked online, the first step to answering that was "how much does it earn?". At a big fat zero that makes it tricky! I tried loads of domain evaluators — ranging from $100–$100k — and the calculators of various project 'marketplaces' do not handle that situation well at all. I could find essentially no good blogs or details that accounted for selling a free project based on potential rather than revenue.

Eventually I gave up and decided to ask the buyer "How much are you going to pay for it?", and see what happens. Their suggestion was what we based our final amount on — assuming the site become advertising-funded and basing the value on Google's AdSense estimator. With some negotiation we agreed on how many years to include, and to using an average monthly pageviews from the previous year of my analytics to account for seasonal shifts.

I'm not a salesperson or valuator so I'm sure others would use a different method accounting for repeat visitors, SEO potential, backlinks, domain value and much more. Probably with WAY different numbers. Crucially however I am really happy with this method. The key thing for me is that it's very clear, independent, and objective.

We negotiated details but in the end with the AdSense estimator I could easily weigh up the comparison between implementing ads myself and receiving ongoing funds, or receiving them up-front without the need of ongoing maintenance. I'm sure that there was potential for further valuation but this method felt fair to me and the buyer.

I'm not going to detail any of the final numbers we agreed as that's not the point of this. If you're selling something similarly unmonetised then I'd recommend having a discussion with the buyer and see where it goes. The AdSense tool could be handy to reference if that fits the project.

The mechanics of selling

I've decided I'm selling, we've agreed a price, what happens next?

There were a few things I was unsure about at this point: do we need to use a broker; do I need a solicitor to review contracts; how do we handle AUD → GBP payment?

I had absolutely no idea if a broker would be needed, what it costed and involved, but lots of places online swear by them. Both Jan and Kilian talked to me about the risks vs costs, so combined with the principles I detailed above there were a couple options:

• We use a broker for the domain names, but the buyer pays for it;
• I transfer everything non-permanent — codebase, re-assign DNS, environment variables — and then only transfer permanent domain ownership once I've received payment.

Obviously this depends on the buyer but this second option worked out great for us. It reduced the complexity and fees whilst giving me control and some protection against the risk of things going wrong. From the buyer's perspective there was still some risk but by transferring everything non-permanent I'd proven I was serious about following through.

The contracts discussion was pretty easy also, I didn't need a solicitor and went through it myself — asking a couple friends to check there wasn't anything I was missing. Once again your mileage may vary.
I asked for a few additions — making it clear I wasn't liable for future support, clarifying trademark details, and making sure I was able to write this blog post! All were agreed and easily added.

And finally for international payments, turns out that's an easy one. The buyer took my UK bank account details and used Wise to transfer the amount agreed over at the market exchange rate. Nice and easy!

Once those questions were worked out it went pretty smoothly — the code was already open-source so I had no issue handing that over before we'd signed, what had real value was the domain name. I detailed the tech stack and how it was built, wrote some documentation and tips on ongoing maintenance.

We hopped on a call to finalise the tech setup, answer any technical questions, share environment variables, sign the contract, and finally switch the DNS. Once that was all sorted they sent the payment, and when I confirmed that in my bank account I started the domain transfer.

And that was it! We had a few emails in the following weeks to confirm everything was going well, share Google Search Console and Analytics access and that was that.

How does it feel?

It feels good! It was a good experience to go through, I feel like I'm doing good by the project that I had basically abandoned, I appreciate the money of course, and it's also a much appreciated new marker of success for me. I'll be sewing on my "website sale" scout badge and putting "Founder with one major exit" on my CV now 😉.

I feel quite fortunate that the people who have bought the project were very helpful and friendly throughout, and seem genuinely keen to develop and improve the project. I'm sure that not all sales go as well and smoothly so I am thankful for that.

My key takeaways

If you take anything from this post — and for my own future reference — here are my takeaways:

• Work out your priorities, they help you make judgements about process and value;
• You don't necessarily need a broker, you may be able do it without one;
• Unmonetised projects are hard to value, ask for offers. The AdSense Estimator may be helpful;
• Consider adding analytics to projects. It doesn't have to be GA, but page views at minimum are essential for a sale;
• Make sure contracts make clear your support/responsibility post-sale;
• Remember that ultimately as soon as it's sold it's out of your control;
• Don't use an io domain! Read .io considered harmful, but also they're more expensive than they're worth for side projects.

What now?

For My Top for Spotify, I don't really know! There has clearly been some hard work and new functionality like global stats already, and I've been told that they're working hard to evolve and improve it.
I think I'll check in once in a while for the sake of curiosity, but I'm happy to otherwise move on. I wish the new team working on the site all the best with it. If you use Spotify I'd encourage you to check it out at mytopspotify.com if you're interested.

For me nothing changes. I have no interest in building things with only value in mind, so it'll continue to be things for myself and for fun!

If you have any comments or feedback on this article, let me know! I'd love to hear your thoughts, go ahead and send me an email at alistair@accudio.com or contact me on Mastodon.

The post Selling a small front-end web project — what I learned appeared first on alistairshepherd.uk.

Sustainable Futures: Funding the Web Ecosystem

The first talk of the day was from Stephanie Stimac, discussing how the browser and web ecosystem is perhaps a little more fragile than it would at first appear. My job, our entire industry, and in fact pretty much everyone’s lives all rely on web browsers. These browsers are developed, owned and funded by mega-corporations like Google and Apple. Even Mozilla with Firefox is mostly funded by Google.

Stephanie took us through a thought experiment — what would happen to Chrome if Google disappeared? It may be open-source but it turns out browsers are extremely complex and difficult to make!

It’s a scary thought that the basis of the web is all funded by hyper-capitalist corporations. The key takeaway was to encourage us to have discussions over how we can fund browsers — and open-source software more generally — in a more sustainable way.

It was a great start for the day, criticising capitalism and a couple Dune references!

No industry for old men

Steve Faulkner followed, with an extremely funny and chaotic run-through of the process of Accessibility standards. The accessibility issues in question were interesting to hear about, but my main takeaway was an insight into the history of web standards, and some really fascinating insights into the web industry in its early years. He gave some great advice and detail over how the W3C works and how anyone can contribute to web and accessibility standards. He also made many jokes at the expense of his friends in the industry — “without naming any names… Joe” — which was very entertaining!

The mazy web she whirls: starting Open Web Advocacy

Stuart Langridge took the stage next with a talk about Open Web Advocacy, speaking with legislators to hold big tech companies to account.

I’ve seen a fair few conference talks and let me tell you — this was one of the best. Stuart did an absolutely beautiful job ‘weaving’ together the normally quite dry topic of web legislation, with the Lord Tennyson poem “The Lady of Shallot”:

Out flew the web, and floated wide, The mirror cracked from side to side, "The curse is come upon me," cried The Lady of Shalott.

I almost don’t want to spoil how he does it, because it was an absolute delight you should experience yourself when the recording comes out! He was opening up the quite inaccessible topic of browser competition and functionality restriction to be more entertaining and understandable, which is the goal of Open Web Advocacy.

The development side of the talk was sharing the story of how Open Web Advocacy came to be, and how it ended up representing a huge number of independent developers and speaking to governments about web competition. Lots of gems like how all iOS browsers are actually Safari, how Android limits certain functionality to Chrome, and how Apple is fighting against the power and independence of the web.

Check out the talk when it comes out and give your support to Open Web Advocacy!

Web Components: Little Bits

Our final talk of the morning was from David Darnes, about implementing Web Components. It was a great introduction to how Web Components can be used to implement small functional pieces of JavaScript on a page. I’m a big fan of this kind of talk (I’ve done one myself!), as it adds a bit of code to the day that’s really easy to follow along, and super practical to our work. Dave’s example was about the little speaker on his website that says his name — often by his dad.

After the talk I’m excited to use Web Components a little more!

Around the wwworld: Web MIDI, Web AUDIO and what the web does best

Oh my goodness Katie Fenn’s talk was such good fun! She used web APIs like WebMIDI and WebAudio to interact with a MIDI-enabled synthesiser to recreate Daft Punk’s “Around the world”. Using a browser!!!

It was a great talk, we were all bopping away to the music, learning about how to make EDM, synthesisers, MIDI, and audio on the web.

I’d recommend watching the talk when it comes out, but Katie has recorded it on YouTube also. Just remember this is all controlled and produced by a browser! Katie also has a recording on YouTube.

Code Your Future

Gayle Ngozi took to the stage to talk about Code your Future, which works with disadvantaged people and refugees to teach skills in development. It was a great talk, focusing on how difficult it can be in those situations to get a job and how tech and coding can be a way out of that. The takeaway was how we can all help make an impact by contributing time, resources, and hiring these fantastic developers.

Improving Accessibility with ARIA-AT: A Web Standards Case Study

Our second talk of the day about web standards, Lola Odelola took us in detail over how the W3C operates including Working Groups and Community Groups. This was in the context of working through a standard for automated testing of Accessibility Technologies. It was really interesting hearing about how the W3C works, and about such an important topic also.

Fluid typography (and its role in design systems)

Richard Rutter — founder of the wonderful Clearleft — finished the day with a slightly more design-focused talk. His talk was about fluid typography, how you can use fluid type systems to build a more consistent type experience based on screen size without harsh breakpoints.

We use fluid typography in our work already when appropriate, but Richard presented some really interesting tools and best practices — see utopia.fyi — which I’m excited to share with the rest of the Series Eight team!

Summing up

It was an absolutely brilliant day, and flew by. The State of the Browser team always puts on a fantastic event, and a big thank you to them and the speakers for such a high quality conference. So my key takeaways:

• Discuss alternative funding models for browsers;
• Participate in web accessibility standards (chaotic);
• Join Open Web Advocacy and claim the web for us;
• Build web components;
• Make music with browsers 🎶 and try not buy a synthesiser — seriously Alistair, you don’t need one;
• Support non-profit organisations making the tech industry more accessible;
• Participate in web accessibility standards (serious);
• Use fluid type!

If you have any comments or feedback on this article, let me know! I'd love to hear your thoughts, go ahead and send me an email at alistair@accudio.com or contact me on Mastodon.

The post My day at State of the Browser 2024 appeared first on alistairshepherd.uk.

Anyway, wanted to do a wee summary of what I've been up to, blog posts I've written and read, and media!

Life

Work recently has been pretty busy. We've had a big new job come up that's a lot more technical and involved than most of our work, so that's taken a lot of attention. I've also been getting more into dev management — performance reviews, hiring practices, standards, etc.

I've also dedicated a lot of attention to selling My Top for Spotify, a project I built a few years ago. Check out my blog post "Selling a small front-end web project — what I learned" for more info on that. The short version is that it was exciting, new, and took a lot of my focus for about 6 weeks!

Personal life and hobbies have taken more of a backseat than I'd have liked.

• We've had friends come to stay a few times — I love hosting people;
• Saw Night Flight and The Japanese House — live
• Went to Edinburgh Pride;
• Did a few hillwalks — less than I'd like but it's tricky without a car;
• Sat on a mountain with some friends for hours watching the perseid meteor shower;
• Spent a few days visiting family in the Highlands;
• Had a good Edinburgh fringe with 5 shows, a couple great ones;
• Went to the south of France near Marseille for a week.

I launched my ko-fi page selling stickers and my art prints. The stickers have done well but the art prints less so. I'm not surprised, I haven't really pushed those much so need to do more.

I'm also regularly attending the Homebrew Website Club meetup in Edinburgh. It's a good small group and a great chance to casually chat and catch up about the web!

Last weekend I went to the State of the Browser conference down in London which is always fantastic. The talks were exceptional this year and I have great fun meeting up with and making new friends.

Posts from me

I've had a pretty good few months for blogging! What a great opportunity to encourage you to read and share those!

• Simple, fast build tooling with live reload for a non-framework website
• JS library compilation to browser, esm and cjs using esbuild
• Proxying an Image CDN with Cloudflare workers
• My response to UK CMA's potential remedies for mobile browser competition
• Selling a small front-end web project — what I learned
• My day at State of the Browser 2024

Posts from others I've enjoyed

I recently got back into RSS and reading blogs! I had 2500+ unread articles in my feed reader so declared RSS bankruptcy back in July, but have been keeping up since. It's been great to be reading more and I feel more creative, inspired, and excited about the web thanks to it!

Here are a list of some fantastic articles I've read since May, in order of when they were posted:

• Font with Built-In Syntax Highlighting — Glyph Drawing Club
• 12 Map Happenings that Rocked our World: Part 10 — James Killick
• Heydon Pickering's HTML element descriptions
• Partial Feature Queries, Relaxed Layout Containment, and More — Miriam Suzanne
• blocking=render: Why would you do that?! — Harry Roberts
• There are two kinds of advertising — Chris Coyier
• Cache Grab: How Much Are You Leaving on the Table? — Harry Roberts
• Some Git Tips — Evan Sheehan
• Day 109: the animation-composition property — Manuel Matuzović
• My first week in the CSS Working Group — Josh Tumath
• Can you convert a video to pure css? — David Gerrells
• Web Apps on iOS: is the CMA missing the point? — Bruce Lawson
• The secret inside One Million Checkboxes — Nolen Royalty
• Mountain Chicken! — Adrian Roselli
• Under-Engineered Estimated Reading Time Feature — Adrian Roselli
• The Dev Tools Performance Monitor Panel — Dave Rupert
• How to Monetize a Blog — modem.io
• Going Buildless — Max Böck
• The State of ES5 on the Web — Philip Walton
• What price? — Jeremy Keith
• Open Source Needs to be Financially Symbiotic — Zach Leatherman
• Good forms — Dave Rupert
• Limitation Breeds Creativity: A Study in Composition with Custom Properties — Michelle Barker
• Making Orbit Animations with CSS Custom Properties — Will Boyd
• Optimising for High Latency Environments — Harry Roberts

Media

I felt like I hadn't [read|watched|listened|played] as much media as I would've normally, but actually listing them out is quite a few! It didn't feel like much though!

Music

• Chappel Roan — The Rise and Fall of a Midwest Princess
• HONNE — OUCH
• Cage the Elephant — Neon Pill
• Night Flight — English Noise
• Bleachers — Bleachers

Movies/TV/YouTube

• Challengers
• Jet Lag: The Game
• Om Shanti Om
• The Boy and the Heron
• Theater Camp
• Death in Paradise

Games

I also now track my games on Infinite Backlog if you're interested or on there! I also ranked every game I've ever played* and produced a top 100** which was good fun! Here's the recent ones:

• Agatha Christie: Murder on the Orient Express
• Pentiment
• Nuts
• Sherlock Holmes: Chapter One
• LEGO Builder's Journey
• The Room
• Cultist Simulator — it's finally clicked after 6 years!
• One Night Burlesque

* at least as far as I remember
** not quite 100 but close enough!

Photos

If you have any comments or feedback on this article, let me know! I'd love to hear your thoughts, go ahead and send me an email at alistair@accudio.com or contact me on Mastodon.

The post Spring and Summer 2024 — Life, links and lmedia appeared first on alistairshepherd.uk.

I despise accessibility overlays, and get really quite upset when they're mentioned in a serious context. Unfortunately, getting increasingly upset and angry doesn't do a very good job of informing clients about why they're often a bad idea and why they shouldn't be trusted.

In many cases I can explain fairly succinctly the issues with overlays and that’s where the conversation finishes. Sometimes though the conversation escalates and my initial advice is ignored. For those circumstances I’ve put together a ‘serious letter’ that is designed to put all our cards on the table and have a serious tone.

It’s a carefully considered, standardised letter to explain why we don't like overlays, list some of the facts, and to try to convince a client that they're rarely a good option for them. I'm publishing this as it may be helpful to others in the same situation! Read to the end if you want a bit more context/explanation.

Hi [client name],

We strongly recommend against trying to solve accessibility issues on websites using 'accessibility overlays'. This will be a slightly long email to explain why that's the case and to make you aware of the risks. If you have any questions or want to discuss further then let me know and I'd be happy to do so.

An 'accessibility overlay' is a product that typically provides JavaScript code that you install on your website with the goal of improving accessibility. These services can provide various functionality, including the promise of automatic fixes and widgets with user controls. In rare cases they can be helpful tools, but evidence shows that they are generally not sufficient to substantially improve website accessibility, and cannot replace making sure a website is built accessibly. Web accessibility is a complex field and at the moment there are no tools or services that can reliably fix all issues. Believe me, I'd love it if there was! Evidence shows that even with cutting-edge technology (including AI) only about 30% of accessibility issues can be found without human intervention.

Some overlay companies often claim "ADA compliance" or "complete accessibility", making false claims that their tools can fix website accessibility completely but that is not the case. They are often marketed as a quick-fix solution to avoid legal risk, or to avoid spending time on website accessibility.

From a user accessibility perspective, many of the representations of 'fixing' problems some of these solutions claim to do are misconstrued, false or greatly exaggerated. As someone who works in the accessibility field I know more disabled users who intentionally block these solutions than rely on them, thanks to many cases of them causing more harm than good.

From a business and reputational perspective, many of the big accessibility overlay companies are considered bad actors within the accessibility industry. Many companies have established history that can include untrue claims, falsifying evidence, paying for praise and reviews, and for silencing critics via 'SLAPP' lawsuits. Some of the largest companies in the industry have or continue to engage in some of these.

The legal protection promises are why many people look to and consider accessibility overlays. I would first clarify that I am not a lawyer, do not have legal experience, and this is not legal advice. Accessibility laws exist to provide equal access and to prevent companies from discriminating — intentionally or not — against those with disabilities. Examples include the Americans with Disabilities Act, and the European Accessibility Act. In many countries there is accessibility legislation that applies to websites, and requires websites to meet a certain level of accessibility.

Particularly in the USA, people can sue website owners for not providing equal access, which the ADA provides precedence for. This has become more frequent in the previous few years. Whilst many lawsuits are from individuals genuinely seeking equal access, you will find these don't come 'out of the blue' and people will seek assistance and make complaints first.
Extremely unfortunately, there is also a large industry of 'malicious' accessibility lawsuits. These come from law firms targeting small companies in bad faith to exploit accessibility legislation for their gain. The purpose of these malicious accessibility lawsuits is to find anything that can be described as an accessibility issue in your website, regardless of how valid that is. Typically these law firms offer to settle, almost immediately, for a substantial fee.

As accessibility overlays cannot detect and fix all accessibility issues, they cannot prevent the circumstances that fuel these lawsuits. This means that regardless of your overlay, malicious law firms can definitely still find issues to sue you for, including violations caused by the overlay itself. I have seen no real evidence that an accessibility overlay genuinely reduces the likelihood of an accessibility lawsuit. In fact, some early research seems to suggest a potential increase in accessibility lawsuits following installation of a handful of particular accessibility overlays as their weaknesses and limitations are well-understood and easily identified. You will also find that several overlay companies have been cited in lawsuits as a reason for worse accessibility, and even caused issues that weren't present before installation.

Ultimately it's up to you, but our suggestion is that accessibility is always best solved at the source, and audited by a full manual accessibility test. If accessibility is considered during design, development and content input then not only are you providing the best experience to your users, but also your website is in the best state it can be for accessibility. This reduces legal risk, your reliance on third-parties and in many cases cost. By providing an "Accessibility Statement" page you can also allow people to contact and inform you of issues without escalation. The W3C provides an Accessibility Statement generation tool.

Regardless of what you opt for, we will continue to implement accessibility in our designs, development, and content input as is our best practice. We would encourage you to also consider accessibility when inserting content, and we are more than happy to support you and your team with that. We can offer training, accessibility testing, and recommend trustworthy third-parties who can provide audits or legal support.

We can add the code for an overlay to the website if you provide it and instruct us to do so, but this would be against our advice. If you choose to do so, we will discuss next steps including steps to ensure legal responsibility is clear.

Here are some resources that may be of interest to you regarding this, additionally I'd be happy to answer any questions you may have.

• Include relevant sources here. More details and examples below.

Let me know how you'd like to proceed, if you have any questions, or if we can provide any support in the accessibility of your website.

Best regards

The first thing I want to say is that you and I are not the intended recipient of this email. It's unemotional, business-y, overly focused on legal risk and business practice, and not very focused on the difficulties that disabled users actually face using the web.

Most of the clients who speak to me about accessibility overlays are founders of mostly ecommerce startups in the US so the tone and wording of this email is focused on what works for them. Before this point there's likely been conversation and discussion that is a lot more casual and focused on the benefits of accessibility. But when I'm sending this email, I want to get serious and convince them against the route they're thinking of, appealing to the business and legal side to get the message really heard.

I've found that for most of the clients I’ve worked with, explaining overlays in unemotional detail, justification, and evidence has the best success. That's also why there's a lot more of a focus on the legal side than I would like. You shouldn't be using these things because of the harm they cause, but when their legal counsel or other company founders say they need this, I find going for this kind of email works much more effectively.

It is very long, and that’s something I’ve struggled a little with. I would prefer to be more succinct, but for me I’ve had the most success putting everything on the table in clear detail, despite the length. The focus is to get all the information needed in there and then the ball’s in the court of our client.

I think most of the email is pretty self-explanatory, but there are a few other things I've put attention into that I want to explicitly call out.

You'll notice that I don't refer to any specific overlay companies anywhere in this post. I do generally customise this email more, focusing on the track record of any companies that have been mentioned. For posting this publicly however, I want to be quite careful on what I say against any companies in particular. If any specific overlay companies have been mentioned to you, I would suggest doing some research and tailoring the email more.

Something I think is crucial is a list of sources at the end of the email. Whilst earlier drafts of this post included some of my go-to links, these all reference particular companies and to be quite honest, SLAPP tactics work. I have faced legal threats about my blog before, and I’m eager to avoid it again. That really sucks, but the key point is I’d recommend doing some research and finding articles that are relevant. I’ve read some interesting articles from big publications like The New York Times, Forbes and Wired that you may consider. Adrian Roselli also has some very detailed articles about potentially poor practices and analysis about particular overlay companies. I also often include links to ongoing or past lawsuits — often class action — to show this is a very active topic.

Anyway, if you got this far I hope this is useful to you! Keep up the good fight against Accessibility Overlays, and make sure to add your signature to the Overlay Fact Sheet if you haven't already!

Thank you so much to Adrian Roselli who kindly took some time to review this article and give me some of his thoughts and advice. I cannot thank him enough for helping me with it.

If you have any comments or feedback on this article, let me know! I'd love to hear your thoughts, go ahead and send me an email at alistair@accudio.com or contact me on Mastodon.

The post My anti-overlay client letter appeared first on alistairshepherd.uk.

Available in full on the HTMHell Advent Calendar

If you have any comments or feedback on this article, let me know! I'd love to hear your thoughts, go ahead and send me an email at alistair@accudio.com or contact me on Mastodon.

The post HTMHell Advent Calendar — Preloading fonts for web performance with link rel=”preload” appeared first on alistairshepherd.uk.

Why did you start blogging in the first place?

Work mostly! In 2017 I dropped out of university and was attempting freelance web development as a career, trying to make something out of the hobby I had for a few years.

My first few clients came pretty easily through friends, former colleagues and neighbours but after a few months the leads started to dry up.

To try and get more work and get my name out there I wrote several blog posts targeted to small business owners. The goal was to convince them to upgrade/improve their website and introduce them to some of the concepts.

Here are some of those early blog titles:

• The Web in 2017 and what it means for your Website and Social Media!
• Introducing: Responsive and Mobile-Focused Web Design
• Introducing: Content Management Systems

And they worked! Friends, family, and clients shared them mostly on Facebook and got me a handful more projects, including the big break that really drove my early career.

What platform are you using to manage your blog and why did you choose it?

Currently my website is built with 11ty, a wonderful static site generator based on node.js. Reasons why I chose it:

• It's really simple
• Generates static HTML — easy and cheap to host and secure
• I'm in full control over the page content
• Blog content can be in markdown — super portable

Have you blogged on other platforms before?

My very first post was written on WordPress but never published on it. I'm a bit too extra sometimes so found that too mainstream for me.

I briefly used Subrion CMS for my first few posts as I was trying that out for the rest of my site, but quickly realised it wasn't great for blogging.

I then used PageKit CMS, a PHP+Vue-based CMS that hasn't been touched in about 9 years. No particular reason for this one in particular really, I just liked it and it was niche and a little weird.

From 2018 to 2020 I didn't have a blog, and then for a brief period I used dev.to before switching to my current stack in 2021. My blog posts are still cross-posted over on dev.to, hello if you're reading there!

How do you write your posts? For example, in a local editing tool, or in a panel/dashboard that's part of your blog?

Always local, the tool itself varies though. This post right now I'm writing in AnyType which I'm trying as a local note-taking tool, but I've also used iA writer, word documents, or just writing markdown straight into my code editor.

When do you feel most inspired to write?

Currently Sunday mornings end up being my writing time. Sunday tends to be my chill day and my partner gets up a bit later so I do an hour or two of writing with a tea after breakfast.

Previously it has been Friday afternoons with my work 'Personal development time', but that's been taken up by other stuff more recently.

Do you publish immediately after writing, or do you let it simmer a bit as a draft?

Generally immediately. My partner is a great proofreader and editor so for some posts I may ask him to proof and give me some feedback, in which case it simmers for a few days. If I'm not getting it proofed though it goes live immediately.

What are you generally interested in writing about?

Front-end web stuff mostly, but I've done and will do some non-web posts when something interests me enough.

Who are you writing for?

Hmmm that's a tricky one!

I want to say it's all for myself and often it is, to put down my thoughts somewhere permanent so I can reference them later.

I enjoy sharing my knowledge and experience with others — it may be helpful and I tend to assume what I know everyone else does so it helps me stay on top of that assumption.

There's definitely a little bit of attention seeking, wanting people to see and recognise me. Also in my work it just makes good sense for my career — many of the people I want to network with, work with and be employed by care about blog posts. It's a good selling point!

What's your favourite blog post?

My all time favourite is probably SVG generative mountain ridge dividers, as thanks to Dave Letorey from State of the Browser it opened up the world of Conference talks to me.

Other top contenders for various reasons:

• Selling a small front-end web project — what I learned
• My response to UK CMA's potential remedies for mobile browser competition
• GrapheneOS as my daily-driver mobile OS

Any future plans for your blog? Maybe a redesign, a move to another platform, or adding a new feature?

I currently have a complete redesign and rebuild in very early design stages. It has been there for about 14 months so far though so slow progress!

I'm struggling a little with the design but once I have that nailed it'll be all new gimmicks, themes, and features!

Whether it's a new platform I'm not yet sure, I love 11ty and it's super simple but have been considering a CMS for easier writing and editing on the go. I'm not convinced if I'm willing to give up the portability of markdown for that, we'll see!

Who's next?

I've seen loads of people doing this and honestly have no idea who has and hasn't. If you're reading this though and haven't written one then I tag you! I did it based on Sophie Koonin saying the same thing at the end of hers.

If you have any comments or feedback on this article, let me know! I'd love to hear your thoughts, go ahead and send me an email at alistair@accudio.com or contact me on Mastodon.

The post The Blog Questions Challenge appeared first on alistairshepherd.uk.

I'm fairly technical, and make a lot of my own little things. Small apps that do what I want, integrations and such. Because I work with web, they're all little web apps. Sometimes what I need is a way to send a notification to my phone. I don't need a PWA or native app or anything like that, just a notification with some custom content, and I can tap it to go to a website.

ntfy is just that. On my phone I install the app and subscribe to a 'topic' (which is basically just a named event stream). Then I can send notifications to my device simply by making a web request to the ntfy service with that topic name. The topic could be secret — like a long secret key that no one else knows — for private notifications, or it could be public — a notification channel that anyone can subscribe to!

Sending a notification with NTFY

For the purposes of this blog, let's call my topic "alistair-blog-demo". I can send a notification to folk who are subscribed to that topic with just:

await fetch('https://ntfy.sh/alistair-blog-demo', {
    method: 'POST',
    body: 'Hello! This is a test notification'
})

And get the following notification a few seconds later!

You can get fancier with it with more parameters, all are documented super well including which platforms support what parameters.

await fetch('https://ntfy.sh', {
  method: 'POST',
  body: JSON.stringify({
    "topic": "alistair-blog-demo",
    "message": "Alistair has posted a new blog post: Device notifications via HTTP with ntfy",
    "title": "New blog post from Alistair",
    "tags": ["rocket"],
    "click": "https://alistairshepherd.uk/writing/ntfy/"
  })
})

BeReal NTFY

I've built a handful of private little apps that notify me using ntfy, one public topic I've set up is ntfy notifications for the app BeReal, on BeReal ntfy (I know, imaginative).

BeReal is an app that gets everyone to take a photo of themselves and what they're doing once at the same time every day (timezone dependent). You can then see what your friends are up to at that time!

For an app that has like three functions — notification, photo, view — it does the notification bit miraculously badly. It's pretty inconsistent, and when I have it on a separate GrapheneOS profile, I wanted to build my own notification system.

ntyf made that easy and it look like 30 lines of code — receive a webhook when it's BeReal time, send a POST request with ntfy.

Limitations and thoughts

ntfy is pretty basic, despite how handy it is! It's definitely the type of tool for a little cheap fun tool, rather than a proper app but honestly that's exactly what I want. It gives me more agency with my devices and more I can do without needing to learn new technology I don't need to or spend a lot of time on it.

The main thing to keep in mind is that ntfy topics are public. I can send notifications to that URL but so can anyone else! My secret topic for private is all very well until someone finds it and can subscribe to my stuff without me knowing. You can pay to reserve a topic to prevent people posting but it would be visible to anyone so don't use it for anything super secret. My "server under increased load" notification isn't a big deal if someone else sees it.

Anyway, wanted to share a handy little tool that others may find useful!

If you have any comments or feedback on this article, let me know! I'd love to hear your thoughts, go ahead and send me an email at alistair@accudio.com or contact me on Mastodon.

The post Device notifications via HTTP with ntfy appeared first on alistairshepherd.uk.

In April 2025, I received an email from an image licensing company (hereby "licensor") regarding an image used on my twitter archive. That image was owned by them, but used as the Open Graph image for a news article. They demanded I purchase a license or face consequences for the infringement of their copyright.

I ended up purchasing the license to make it go away. Although I'm unconvinced I was at fault and it's certainly not a standard copyright case, it was not clear enough for me to risk those consequences. It really doesn't feel right, makes me wary of the Open Graph standard, angry about copyright on the web, and generally pissed off.

It also raises questions about the potential risks of displaying open graph images on the web.
That's the short version, the TLDR. What will follow is me going a bit more in-depth with some of the specific communication and my thoughts.

Short disclaimer

What I need to make clear from the beginning though is I am not a lawyer. Very far from it, so if you're in this same situation (I feel for you) please just take this as my experience and do your own research and find what works for you. I paid the fee so I also don't know how this would have gone in a court.

I've removed anything identifying — including details about the image itself and company, and paraphrasing all communication. I don't want to get into any further trouble by identifying companies — I've already had the displeasure of that experience before.

The rough context

I left Twitter in November 2022, moving over to Mastodon as my main source of Social Media. At that point though I enjoyed my digital footprint and wanted to retain a record of my history on Twitter. I used Tweetback to do this, it's an open-source tool written by Zach Leatherman and maintained by some good folk who were in a similar situation to me. You feed it your twitter archive export and it generates a static website showing off your tweets, including some extra functionality like frequency graphs and such. It's a really cool tool for that purpose!

More specifically, it generates listing pages and a page per tweet, with the same URL format as Twitter so you can easily turn one into the other. It acts independently of twitter, downloading the images you've uploaded, and hosting the content directly. Like most social media sites and Twitter itself, when you include an external URL it displays the Open Graph image for that URL.

I published my Tweetback archive online with a robots value of 'noindex' so it wouldn't be indexed by search engines, and basically completely forgot about it. I'd reference it every few months maybe and occasionally added new functionality, but as far as I can tell based on traffic info basically no one ever looked.

The initial email

Okay, that's all the context you need to understand where we're at come April 2025. That's when I received an email in my inbox from an image licensing company which went something like this:

We have found one of the images from our collection on your website. We own the copyright to images taken by our photographers and add them to a web crawler to scan the web.

We can't find a license from your organisation, so are checking you have a valid license. Please send us a copy.

If you don't have one, this would be a copyright infringement and you must purchase a license for £800 to cover your use in the past. [link to website to manage+pay]

You must also remove the image immediately until you have purchased but that would not be sufficient, you must pay for your previous use also.

[specific details including screenshots, links, etc]

(once again, heavily paraphrased to just give the right impression)

Obviously whilst reading this I shat myself. The price they wanted was pretty damn high (approx £800/€900/$1000), and the language strong. It wasn't mailicious nor did it make direct legal threats — which I do appreciate — but certainly setting a clear impression of "don't mess with us, we're serious like".

The detailed context

I've explained enough about the setup, so let's go into this specific use and this page.

In 2021 I made a tweet about UK politics, linking to an article from a national newspaper website. Not necessarily one of the bigger ones, but certainly one that most brits would know. It was a classic tweet sharing an article I enjoyed, about how a politician I didn't like was doing something I really didn't like.

That article included an Open Graph image, a photo of said politician speaking. On the twitter archive the page included my tweet — a short statement that summarised the article and my thoughts, and a link to the article. As Twitter would directly, Tweetback displayed the open graph image for that URL below.

That's the image that the licensor was referring to. The newspaper included it in a protocol designed to allow for the showing and sharing of images alongside their links, and then separately the licensor found my use of said image and demanded a license fee.

On hosting and "use"

One detail I missed from the initial version of this post was the hosting situation, which was a big omission! It was in an earlier draft but I must have cut it and not realised. I don't know how much of an impact where the image is hosted legally, but it certainly makes for a different perception and understanding as many people in my mentions questioned it.

I did not download and re-host any open graph images, including this one. Tweetback uses the 11ty OpenGraph Service, which is a third-party service run by the wonderful folk at 11ty. It accepts a URL and optional width and format, and will request the open graph image for that URL, cache it, and convert it to the specified width and format.

So just to make that very clear, I did not host the image myself and instead relied on a third-party service that requested it for me. That works in a similar way to other social media sites who use open graph — you wouldn't want every client requesting it direct from the server, that's a nightmare in terms of traffic and presents privacy issues too. So instead you have a server that caches it for several days.

That said, my research (more on that in a mo) suggests it may not matter from a legal standpoint. Copyright legislation doesn't make any stipulations about hosting — it's about "use" of an image and that's what the email I received focused on also. This makes sense, if they were addressing hosting then they would have gone to 11ty and not to me. As you'll see below, I asked a follow-up question about hosting, to which they suggested it was the "use" of the image on my site that was the infringement. That would be the same had I hotlinked directly to the newspaper.

There are also countless copyright infringement cases where people have 'hotlinked' images hosted on another site, which is functionally equivalent to linking directly to the paper's copy of the image pulled from open graph. So that precedent makes me dubious that linking directly to the OG URL would have been legally different.

Whether that difference would change the actions of the licensor is a different question entirely however!

Immediately actions and research

I'd been told if I paid the fee within 7 days, I would get a 10% discount so I had a week to decide if I was going to pay up or not. Waiting wasn't a good option, the price was high enough that the 10% off was significant enough to me if I decided I needed to pay.

So I researched copyright law, tried to find any historic precedent, and asked for help on social media. Thank you so much to everyone on Mastodon and Bluesky who lent me your thoughts or pointed me in helpful directions!

I also confirmed the copyright holder was who they claimed to be and that they genuinely held the license to the image. Regardless of how "good faith" this was, they definitely had the rights to the image!

The key thing I kept coming back to was that it's not like I 'took' this image, it was provided by a newspaper that had presumably properly licensed it and intentionally declared in their markup that this image could be used alongside that link. It's not like there is another use of the open graph protocol, that is it's purpose. But if there's a case around open graph then that's with the newspaper, not with the licensor, which would complicate things.

Looking through legal guidance it became very clear to me that there was not an easy answer here. The justification and explanation used in the email I received seemed correct, and a simple reading of the laws did not immediately identify an exception that my use would come under.

In the UK were this to go to court I understand it would be a small claims court where I would expect to be able to represent myself so I was not immediately looking for a lawyer like you may need elsewhere.

Based on the reading I had done, advice I was given from people in similar situations and my explanation of how open graph worked, I had a short further conversation with the the licensor. In summary:

Alistair: explains open graph, how I wasn't hosting the image myself, how the site is not public and how I would not have purchased the license had I knew so potential losses are little to none.

Licensor: it's our copyright and we choose to impose a license fee for use. You used it on your site, therefore you owe a fee. We don't care about hosting, we see the image on your site so you need a license. Feel free to raise the open graph discussion with the website you sourced the image.

Alistair: I've found your subsidiary licenses the exact image for £20, I'd happily pay that. That's the price I would have paid if I had intended to license it.

Licensor: that's a different company, they can choose their prices and we choose ours. Either pay the fee we've asked for or not.

What did I do?

As you'll know if you read the short version, I decided to pay up within the 7 days to at least get that 10% discount.

I believe fairly firmly that had they taken me to court over it it would have been favourable to me — at least more favourable than paying the full license fee. Considering many details — a subsidiary charged much less for the same image, I wouldn't have paid for the license in the first place, the estimated viewership of 0 people, the use of the Open Graph protocol — and looking at previous image copyright cases I was relatively confident of my side of this.

But ultimately, the easiest and cheapest option for me was still to pay. The chance that it was taken further and the potential cost in terms of money, time, energy from me was too high, higher than the license fee — even if I didn't feel it was justified. So I paid the fee and moved on.

Open Graph images and copyright

Okay so let's simplify and recap my experience:

• An organisation licenses an image from an image licensing company
• They add it to the open graph markup of a webpage
• Another webpage uses the open graph standard to display said image
• Image licensing company then demands a high licensing fee

Frankly, this is so fucked up. But I couldn't find a scrap of information anywhere on the web about the open graph protocol and copyright and the legal picture seems to suggest that's fine. It seems mad to me that there's no existing writing on this — open graph has been around for years and was created by Facebook, but it feels like I'm the first person to run into this as a concern?

I think it raises some serious questions about the risks of using open graph images on the web as an individual or small 'publisher'. According to the licensor, before displaying it I had an obligation to check with the newspaper the license used for the image and obtain one for myself.

This undermines the entire point of the open graph protocol (at least for images). If you have to manually review every image that you include then what's the point in it being a machine protocol?

Obviously, I didn't test this by letting it go to court. As previously mentioned I felt a fairly strong case for myself, but by paying up I've continued to let this be a question instead of being answered. If you're a lawyer who has an answer, or encounter a similar situation and want to stand your ground, please let me know. I'd be really interested to hear anything more solid from people who know more than I.

For me, I am no longer confident in open graph images being trustworthy, and I would not display them on any of my own sites. There is no circumstance where including open graph images is worth the cost I felt forced to pay in this instance.

Who do I blame?

This was an interesting question a friend asked me about this situation, and made me realise it's more fucked up than I thought. Here are my thoughts about where I would put the responsibility:

Me

Sure I'm a little biased, but nope. I used an extremely common web standard the way it was intended.

The photographer

Definitely not, they absolutely should have control over their photo and be able to sell it to a company to license on their behalf.

The image licensing company

I don't think I even blame the licensor, they owned the image and it's perfectly reasonable to search for misuse of your image and seek unpaid license fees. I do think they should have taken a much more nuanced approach and accounted for the circumstances however.

The newspaper

I would lay some blame here, they added an image without license for reuse to the open graph meta of their article. However there is no convention or rules that say you can't do that, and I imagine those who did so are completely unaware of the implications.

Copyright laws

Classic case of blaming the legislation? I don't think so, at least in the UK copyright law and guidance is surprisingly clear and easy to understand. It makes sense to me, and one technical edge case shouldn't need law changes.

Facebook

Maybe Facebook for not considering copyright within the open graph protocol? With this context I do think it was short-sighted to not account for or be explicit licensing in the protocol documentation. For example making it explicit that providing open graph images comes with a license for re-use in limited context of displaying the URL.

Copyright on the web

This whole ordeal has made me so fucking pissed off about copyright on the web in general.

At the same time that I'm having to pay far too much money on an image someone provided me implicitly for re-use, people like Nick Clegg are telling the world that AI companies need copyright exceptions. All my writing and images on my site and social media have been slurped up by AI companies and like fuck are they paying me a license fee for any of it.

This image was the open graph image of a front-page story for a major news publication. That article was shared hundreds to thousands of times on social media — do those companies also have to pay a license fee? Did Twitter, Facebook, Reddit etc have to pay the same fee I did if a single person shares that URL? I suspect not.

So it's a classic case of letting the big tech companies and their billionaires do whatever the fuck they want whilst extracting cash out of the people who can't protect themselves as well.

What a cheery note to wrap this up with!

Re: the clickbait title and image

Finally, I insincerely apologise for the clickbait-y title and accompanying open graph image of this post. When trying to come up with a serious title I came up with the clickbait-y version and knew it just had to be this way.

What's that? You're one of the delightful folk who subscribe via RSS and didn't see the open graph image? Well I wouldn't want to deprive you of the 5 valuable minutes I spent putting this together so here you go, as a little treat:

Update 23/07/25

Based on questions I got via social media yesterday evening, I've added a section above about how the image was hosted and asserting that I researched the company in question.

The hosting particularly was a big omission, I meant to include it but I must have accidentally removed it when editing or copying it onto my website. Oops!

If you have any comments or feedback on this article, let me know! I'd love to hear your thoughts, go ahead and send me an email at alistair@accudio.com or contact me on Mastodon.

The post I displayed an open graph image and had to pay how much?! appeared first on alistairshepherd.uk.

But having some idea of what pages are being visited, how people are using the website, and who is linking to me is helpful information! With that I can learn from what posts did well, put my attention for improvement where it matters, and understand how people use my site so I can make a future redesign and build better!

I have a few requirements for an analytics tool I'd be happy with:

• Privacy-preserving — collect only the information I use, and it shouldn't be used for any other purpose
• Lightweight — no real impact on users
• Simple — I should be able to quickly see the information I need without wading through menus
• Cheap — I don't want to pay more than about £5 a month for it, it's not worth more than that to me
• Self-hosted or a company I trust — either I control the hosting or trust who does to do the right thing

Analytics options

I had a look into analytics options for a client a wee while ago and judged them against my requirements:

Plausible and Fathom both seem like great options, but for a personal site, small hobby project, or small business they are just too expensive for me. Analytics are helpful and I don't want to diminish the value of the work these companies do, but I don't personally put enough value in analytics to be worth paying for these services.

I mostly host on Netlify at the moment who have a server-side analytics offering but it's expensive and would lock me in with them instead of being able to switch hosting so that's not an option for me.

Countly and Umami seemed pretty cool, both can be self-hosted and I gave them a try for a couple months. Countly I found a pain to maintain — upgrades and maintenance took a lot of work. Umami seemed really cool but a little rough and slightly buggy when I last looked at it.

I ended up settling on Goatcounter!

Introduction to Goatcounter

Goatcounter is a super simple analytics tool that is open-source and can be self-hosted. There's a public instance that you can use for free, supported by donations.

It collects the bare minimum of data (and allows you to customise that), is lightweight, you can export data, and even has no-JS options!

It is also really not a pretty interface! 😅

Setting up and using

But it doesn't need to be! It's just an analytics tool lol.

I haven't self-hosted but setting up via the public instance is easy — sign up via the website, it gives you a script to embed into your site, pop that in and you're good to go!

There are a lot of settings you can use to tailor exactly how it should behave. I've customised the data collection to disable "Individual pageviews", "Session", "Region", and "Language" as it's not information I'm very interested in. You can even "Show fewer numbers" if you're just interested in general trends and don't want exact numbers!

In terms of using Goatcounter it's pretty straightforward. In the Dashboard interface you can filter the view by date or path from the top bar and then below you get widgets showing you the key information about:

• Page views
• Referrers
• Browser and OS versions
• Countries
• Screen sizes

The interface isn't pretty but it's very functional and actually does the job really well. I've considered doing a custom theme for clients as I think they'd shy away from Goatcounter purely due to the interface design, but not quite yet.

This has everything I want from my analytics in a single page I can check in the time it takes the Google Analytics dashboard to even load, let alone work out how to find the information I'm looking for!

On privacy

As mentioned at the beginning of this post I'm not a big fan of analytics in general, but there is a huge difference between the likes of Google Analytics and Goatcounter, Plausible and friends.

My line sits much closer to the Goatcounter end. I understand the value in website owners knowing who is visiting their website and being able to use that information to improve their website and writing. But that shouldn't come at the cost of tracking individual user behaviour and selling it to third-parties.

I also don't like the absolutist view that server-side logs are the only reasonable source for analytics. Relying on server-side logs only ties you to specific hosts and tools, limits you in hosting choice and performance, significantly complicates offline-first or distributed CDN architectures, and are typical much weaker at identifying bots.

I'm happy with a JS analytics provider that has a solid privacy policy, only collects and stores what's needed for aggregate reports and is open-source. Ideally I would self-host it also, and that's something I'll be looking into.

Finally, the ePrivacy directive and consent. I'm currently not including an opt-in consent dialog and instead focusing on making sure the analytics are as friendly and minimal as possible. I do believe that there is a strong case for ePrivacy requiring opt-in consent for even "cookieless" analytics (see Neil Brown's fantastic post on decoded.legal). For my work though I want to strike a balance between collecting some useful data, respecting privacy as much as possible, whilst also avoiding a consent banner.

If you wish to opt-out of analytics on this website you can enable Do Not Track, the Global Privacy Control, or toggle analytics.

Final thoughts

Goatcounter is a fantastically simple analytics tool that lets you get the key data you need to see how your website is doing. In terms of privacy it's pretty good, it's cheap, lightweight, and you can self-host it.

I'm really happy with it, and will consider self-hosting and using on most of my personal projects going forward!

If you have any comments or feedback on this article, let me know! I'd love to hear your thoughts, go ahead and send me an email at alistair@accudio.com or contact me on Mastodon.

The post Simple website analytics with Goatcounter appeared first on alistairshepherd.uk.

If you aren't familiar with Loop, they make a range of different earplugs for different circumstances, and present themselves as a fancy new startup that leans heavily on social media, influencer sponsorships, and media collaborations.

I went for it and bought a pair of their Switch 2 earplugs in October 2024, and have been using them for almost a year and half now — time for a review and you can't claim my testing process is too fast! The question is do I like them? (as if the 18 months hasn't given it away!)

Caveat — my hearing and ears

Getting the caveat out the way — my ears and hearing is different from yours. There's the standard normal variation among folk, but I also have issues with my hearing — likely coming from auditory processing issues. Also for some reason my right ear canal is a weird and different shape from my left so that's fun! (it makes finding nice IEMs that fit an absolute nightmare)

My main issue with auditory processing is trouble differentiating foreground noise — someone's voice — from background music, other conversations, hubbub etc. I've had several hearing tests but nothing that comes up so it seems likely to be a mental disorder/issue. I mention it so you can use that as context with the rest of my thoughts.

So take everything here with a pinch of salt, what may work for me may not for you. this especially applies to the 'modes' of the Switch, which may make more sense for others than for me — but more on that in a bit.

How I use earplugs, and what I used before

I initially got earplugs for music concerts, when standing too near a speaker caused a month of ringing in my ears. PSA: if you go to live music you should have hearing protection!

I now use them for quite a few different circumstances:

• Music gigs
• Reducing traffic noise when walking around a city
• Blocking transport noise — trains, planes, buses
• Loud neighbours or street parties preventing me from sleeping
• Focus while I work

Previously I've used disposable foam earplugs — cheap (free at music venues in the UK), easy, sound like shit — and Alpine MusicSafe Pro — professional kit, recommended by experts. Unfortunately I didn't really get on with the MusicSafe Pro's — I used them for a while but they didn't fit my ears very well, and for music I felt like the energy and excitement was taken out by them.

Enter the Loop Switch 2

I actually bought the Loops originally based on their heavy advertising towards people who get sensory overload, and ads that showed people struggling to hear others in loud environments. They put in some Loops and suddenly the background noise was gone but they could still hear foreground noises easily. That sounds perfect for me!

Loop has a range of different earplugs with different noise levels for different circumstances. The Dream is for sleeping, Quiet is for focusing and travel, Experience for concerts, and Engage for conversation and socialising. The Switch is more expensive, and they claimed it combines Quiet, Experience and Engage behind a single switch that allows you to 'switch' between them — while the earplug is still in your ear.

I went for the Switch because I would use all three modes for my earplug use-cases above, and I can keep track of one pair of earplugs more easily than if I got several different pairs (I would definitely lose a pair within a month).

Ordering from their website, delivery, packaging etc all good, no major comments there. They feel premium and have a nice small carrying case.

In terms of fit, they're okay. They're a bit chunky and hard so you do definitely feel them if you wear them for a while (6+ hours for me), but most of the time I don't notice. You probably want to avoid other ear pressure for long periods, I found wearing them with my glasses and a mask around the back of my ears did make them quite sore after an hour or so.

They have replaceable tips like silicone earphones so you can get a good fit regardless of the size of your ear canal. Handy for me, my ears need different sizes!

How do they sound?

The big question is how they sound wearing them!

When I started using them initially, I was extremely disappointed. There were all those ads I mentioned and Loop talks big about the different modes for different circumstances. I had been led to expect the Engage mode would help me hear voices over background noise and that definitely wasn't happening. I was really not happy with them after a few days.

At some point when trying to work out my thoughts, I started thinking in terms of volume instead of modes. Forget about modes, with the Loop Switch you can choose how much volume the earplugs blocks by 'a bit', 'a decent amount', or 'quite a lot'. (I'll refer to them in amount of blocking, so higher is more blocking, lower is less)

When I adjusted those expectations I got along a lot better with them! I could put them in and instead of thinking about what circumstance I was in I could simply choose whether I wanted more or less blocking. At a gig that was particularly loud? I'll pop it up one. Want to be a little more aware of my environment when I'm out? Switch it down one so I can hear more.

The MusicSafe Pro has multiple inserts with different levels, but the ability to change without removing them is a game-changer. At gigs in particular I frequently find myself reducing for acoustic songs or my favourite tracks, increasing for heavier and louder songs.

In terms of the audio quality, they dull sound pretty equally across the spectrum and don't affect what you hear a huge amount other than volume. Listening to music you do lose detail in the top-end whilst bass gets through more easily, similar to other earplugs I've used before. I do much prefer them to the Alpine MusicSafe Pro however, and feel like live music still retains a good amount of energy and excitement despite the volume reduction. They are as expected much better than disposable foam earplugs.

When thinking in terms of volume reduction instead of the modes I really like them.

'Engage' mode and conversation

There is one exception, and that is with voices/conversation (the purpose of the "Engage" mode). As I've mentioned a couple times that's something Loop advertise a lot and I just don't get it.

I can only assume given how much they talk about it that it must work for some people, but it really doesn't for me. It turns a clear voice on top of background noise into a muffled and quieter voice on top of quieter background noise. For me, they are worse than useless when it comes to conversation.

So yeah, your mileage may vary but I'd be wary about buying Loops solely for the purpose of conversation, and extremely wary if you also have auditory processing or hearing issues. For "Experience" and "Quiet" sure, but I would be sceptical of their pitch for "Engage".

How I use my Loop Switch

I carry them with me everywhere now and use them for:

• Music gigs — generally the lowest mode, sometimes pop it up to the middle if needed
• Walking around in the city — the highest mode much of the time, lower when I need to be more aware
• Transport — crack that one on highest, blocks pretty much all transport noise
• Sleep — they are not comfortable when resting your head sideways on a pillow, so I don't do this often. But in a pinch they do work, and work well if you're sleeping on transport with a neck pillow. I'm considering getting a pair of the "Dream" earplugs for home.
• Focus while I work — also on the highest most of the time when I want quiet whilst working

After 9 months of daily use they're still in good condition and have no major differences from when I got them.

Combined with bone conduction earphones

This feels like a weird one — bone conduction earphones are designed to keep your ears free and you aware of your surroundings, whilst earplugs do the opposite!

That said, my primary earphones are bone conduction earphones, previously the Aftershockz Aeropex and now the Shockz OpenRun Pro. And I don't want to have to own and carry a second pair of earphones when I want to focus on what I'm listening to.

It's not a perfect combo but it does work surprisingly well!

The main thing to note is the character of sound is changed quite significantly by inserting earplugs with bone conduction earphones. Essentially the earphones are tuned for open ears and by changing that you are blocking particularly the high frequencies from getting to your ears. Everything becomes a lot more bassy.

For speech like audiobooks and podcasts I don't notice it enough to find it a major issue.

With music it's really obvious. My music app has an equaliser that allows me to knock back the low frequencies and increase the high frequencies so by using that I have managed to match it up roughly to still be decent listening, but far from a great experience.

If you're really fussed about audio quality all the time, or you don't have access to an equaliser then this isn't for you. But if your phone/music app does have an equaliser and you're happy with okay sound quality then it works!

It definitely works better with purely bone conduction earphones like the Aeropex however, whilst earphones combining bone conduction and open speakers like the OpenRun Pro are much more muffled and perform worse so keep that in mind.

Should I buy them?

As mentioned, you should have hearing protection if you go to live music. Even if you don't use it, you will regret not having when you need it.

If I need earplugs anyway then I may as well make sure I have decent ones, and I think the Switch 2 is a really good pair of earplugs. Yes they're expensive, but for me the ease and versatility makes them easily worth it.

I would re-iterate that for me at least they're not at all useful for voices and conversation so if that's your primary use then don't get your hopes too high.

But on the other hand you have different ears from me — and thank goodness because I'm currently busy with mine.

If you have any comments or feedback on this article, let me know! I'd love to hear your thoughts, go ahead and send me an email at alistair@accudio.com or contact me on Mastodon.

The post 16 months with Loop Switch 2 earplugs appeared first on alistairshepherd.uk.