HTML — Piper Haywood

Published Thursday, 10 December 2020 by Piper Haywood

How to embed an Are.na channel using an `iframe` in HTML

A friend got in touch recently about using this WordPress theme, asking if it would be possible to integrate support for Are.na channels in the theme. I suggested that it’s probably out of scope for the theme but could be great as a plugin that integrates the Are.na API, definitely something I’d be interested in making. Started thinking about how it might work best, wanted to keep it relatively simple and such since ideally I’d want it to work with classic WP and Gutenberg.

Turns out, I was way overcomplicating it. I mentioned the plugin idea to Sam and he suggested just doing an iframe embed like they do on the lovely Are.na blog. Of course! 🤦🏻‍♀️

I’d still like to explore the plugin idea at some point since it would offer a few more opportunities (see things to consider about embeds below, particularly the fact that Are.na embed support is undocumented), but this seems like a nice way of doing it in the meantime.

Example below of Gemma’s Internet Explorers channel as an embed:

How it works

This is the embed code for that particular iframe:

<iframe style="border:none;" width="100%" height="590" src="https://www.are.na/gemma-copeland/internet-explorers/embed" title="Gemma Copeland’s Are.na channel “Internet Explorers”"></iframe>

If you’re less familiar with HTML, here’s what’s going on.

The opening and closing HTML tags <iframe></iframe> stand for an Inline Frame element. This type of element nests a separate resource like a webpage on to the page you’re currently looking at. It contains the attributes style, width, height, src, and title to modify the way it behaves.

Since many browsers render an iframe with a border by default, we’re using the style attribute to get rid of the border on this iframe. You can also style HTML elements with classes and CSS, but we’re using this technique, known as inline styles, for simplicity’s sake.

The width and height attributes specify—you guessed it—the width and height of the iframe. If you were missing either of these attributes, the iframe would collapse. According to the standards, these values should both be set as integers which the browser interprets as pixels. That said, browsers seem to be able to interpret a 100% width correctly, meaning that it fills 100% of the width of its container. If you want to stick to standards, you could add a high width value and then add max-width:100%; to your inline styles.

The src or “source” attribute tells the browser what content you want to embed. Without it, you’d just have an empty iframe. The URL we’re using here is exactly the same as the URL for Gemma’s actual Internet Explorers channel (https://www.are.na/gemma-copeland/internet-explorers), with the addition of /embed on the end. If you try visiting this URL, https://www.are.na/gemma-copeland/internet-explorers/embed, you’ll see that it is essentially a stripped-down version of the original Channel page that is more suitable for embedding.

The title attribute indicates the contents of the iframe. It can be important for accessibility since some screen readers will use it.

Things to consider before embedding content on your site

There are a few things worth keeping in mind if you decide to try this. These notes apply to any embedded content, regardless of where it’s coming from.

1. An `iframe` embeds the tracking and cookie behavior of its source, not just its contents

When you embed another webpage on your site with an iframe, it will behave the exact same way as if you had visited the source website. In other words, that website may collect data about your visitors, use cookies, embed additional third-party tracking, or monitor your visitors’ interaction with the embedded content.

You should be sure that you’re ok with this before including an embed on your site. Personally, this is one reason why I don’t use embeds very often.

I feel comfortable embedding an Are.na channel in this case because it’s for demonstration purposes, they adhere to the GDPR, and I’m satisfied by the way they handle data according to their privacy policy.

2. The accessibility of an `iframe` embed depends mostly on the source page

It’s recommended to add a title attribute to your embeds for better accessibility, but that’s pretty much where your accessibility control stops. If the source page hasn’t been built with accessibility in mind, it may be difficult to browse for people that use alternative ways to navigate the web.

Unfortunately, Are.na channel embed pages are missing accessibility features such as unique title elements, descriptive alt texts for the block images, and semantic elements such as <figure> or <figcaption>. This is kind of understandable though since these embed pages are an undocumented feature, something that they probably made more for their own use, and they’re no doubt focusing their main efforts on the public-facing product. Would love to see it tweaked though, particularly since they use these embeds on their own blog.

3. It’s nearly impossible to change the way an embed looks

There’s very little you can do to change the look of an embed. You can change the way the frame itself appears, like removing the default border as we’ve done in the example above, but you usually can’t change the contents of the embed.

Sometimes a platform will accept additional attributes or URL parameters that change an embed’s functionality. YouTube is an example, see their Player Parameters documentation. But this just changes the general functionality, it doesn’t allow you to actually change the placement of the play button or change the controls from red to blue. You can use some fiddly JavaScript to get things looking like you want, but it’s pretty hacky.

Instead, if you want to heavily customize the way that the embed contents look, you should probably integrate the content using the platform’s API if they offer it. This is what we did on Gemma’s site, using the Are.na API and Eleventy to add channels directly to her homepage. This content inherits her site’s styles, so it’s more in keeping with the look and feel of her site.

4. Embeds can break

Broken links are an ever-present problem on the web, people are always changing URLs and taking down content. A broken link is only noticeable if you click it, whereas a broken iframe can look pretty crap. If this would bother you, then you might want to be careful about how much embedded content you include on your site.

Besides this, the source website can restrict which domains are allowed to embed their content at any time. This is unlikely to happen with a platform like Vimeo or YouTube which offer embeds as a part of their advertised functionality. But with this Are.na channel embed for example, Are.na might decide that they only want to allow their embed pages to be embedded on their own site and change their Content-Security-Policy or X-Frame-Options HTTP response headers accordingly. And it’s their right to do so if they wish!

If you want to increase the likelihood that third-party content will be available on your site in the future, it’s best to use documented methods, ideally an API. If you integrate content via an API, you can craft a graceful error message in the event that the content doesn’t load. This can look a lot more forgiving than a broken embed.

5. Embeds probably won’t be crawled by search engine bots

This is… not a huge concern IMO. But I mention it since it may be a concern for others. Search engine bots don’t tend to crawl iframe contents, meaning that they won’t take that content in to account when determining what your page is all about. If this is super important to you, then use the platform’s API (if available) to integrate third-party content directly in to your site.

Edit at 2pm: Changed width description since 100% isn’t technically in line with standards, though it works.

Published Tuesday, 8 September 2020 by Piper Haywood

Now online: Open-weather

open-weather.community

The Open-weather website is online. A bit about Open-weather:

Open-weather is a project by Sophie Dyer and Sasha Engelmann probing the noisy relationships between bodies, atmospheres and weather systems through experiments in amateur radio, open data and feminist tactics of sensing and séance.

The site is pretty straightforward, a static hub for a bunch of resources hosted in various places including their PublicLab wiki and archive of amateur radio-generated weather data. The homepage is currently a large scrollable nowcast produced in collaboration by people across the globe. We decided to embed the Google Sheet archive directly in the site for now, though that may change in the future. We may do the same for pages such as methodology, to come later on. We’ll see!

The site is hosted on Netlify and the code is in a GitLab repo. Pls excuse sub-par commit messages and the very minimal README.

Sasha and Sophie are giving a talk at 14:30 UTC-4 Toronto as part of Our Networks distributed festival. Definitely worth grabbing a ticket, it’s super well priced considering how much Our Networks is putting on and absolutely worth supporting that org.

Published Friday, 24 July 2020 by Piper Haywood

Open source tools for multi-source and cross-format academic publishing

I’m working with Sasha Engelmann and Sophie Dyer on the Open Weather platform, an archive and learning resource related to NOAA satellite 🛰 imagery. Sasha just shared a few open source publication tools that were brought to her attention by a friend and fellow artist at her Akademie Schloss Solitude residency, wanted to add them here for further research and future reference.

Manifold: A platform for publishing academic texts online

Manifold is a free “intuitive, collaborative, open-source platform for scholarly publishing”. See their repo on GitHub.

Manifold powers the Fembot Collective including Ada, Fembot’s journal on gender, new media, and technology. Looks like Fembot has been working with Manifold since about a year ago when the platform launched their pilot. Read Ada 16: Emerging Gender, Media and Technology Scholarship in Africa.

It looks pretty cool (and so does Fembot + Ada!). Manifold can bring together a whole lot of different methods of writing such as Epub, Markdown, HTML, and Google Docs. Hence the name Manifold, I guess. This is incredibly useful when bringing the work of different researchers together. Also makes it clear to me that good markup in writing is so worth it.

Manifold wants to make a digital book much more than just a screen version of a physical book, something that can easily fold in explorations, supplements, and other resources that augment the main text. It also incorporates annotation and discussion settings to keep the conversation going.

I’d love to see a book that really heavily uses the platform’s unusual features. Metagaming: Playing, Competing, Spectating, Cheating, Trading, Making, and Breaking Videogames is a featured project that’s worth a look. The chapters are punctuated with metagames they’ve created that you can download and install.

As a reader, I feel that the typography lets it down a bit. I found it hard to read, particularly on larger screens. A slightly narrower maximum width to the main text column would help a lot. Losing the justification and greater paragraph indentations would help too. Manifold does have some theme options, but it doesn’t involve control over the typography.

If your priorities are bringing together content from a wide arrange of sources, incorporating the work of disparate researchers with varying levels of technical abilities, and relative ease of setup (the documentation seems comprehensive), then Manifold seems like an incredible tool. If you need to retain any control over the design though or if you also want print publishing tools, it might not be the right fit for the job.

And probably worth mentioning: I think you’d need at least a bit of technical know-how to get this set up safely and securely. Probably worth getting in touch with Manifold directly if you’re an org since they’re still in beta.

B-ber: A tool for single-source, cross-format, design-conscious publishing

Triple Canopy is a magazine that “resists the atomization of culture”. They’re responsible for b-ber, a tool for single-source, cross-format, design-conscious publishing. Here’s how they describe it in the b-ber GitHub repo:

b-ber is both a method and an application for producing publications in a variety of formats—EPUB 3, Mobi/KF8, static website, PDF, and XML file, which can be imported into InDesign for print layouts—from a single source that consists of plain-text files and other assets. b-ber also functions as a browser-based EPUB reader, which explains the name.

Their text introducing b-ber “Working on our thoughts”—title from the Nietzche quote “Our writing tools are also working on our thoughts” according to the footnotes—is a good read, explains the impetus and a bit about the ups and downs of how it evolved.

B-ber can only consume one input, an extended form of Markdown. This makes it more limited than Manifold in that regard, but the output options are substantial. It’s particularly strong for the design-conscious, the fact that you can import to InDesign and easily theme the browser-based EPUB reader is pretty fantastic. This is exactly the sort of thing I was looking for back when I was working at Occasional Papers!

The reading experience of the default b-ber theme (or whichever they use on their post) is nicer than Manifold in my opinion, it’s just a lot easier to read. There are some snags, but I imagine you could resolve these in a custom theme. Related to that, see their repository of b-ber demos and b-ber theme starter.

It’s definitely worth following the development of this project if you’re in to digital publishing. Their announcement post was published back in December, not very long ago! Excited to see how it develops.

As with Manifold, I think you’d need a reasonable amount of technical knowledge to get this set up. Since it seems to be more of an internal Triple Canopy tool that they’ve kindly made open source for wider use, they probably wouldn’t be able to provide as much support as Manifold might be able to. (This is just a guess though!)

My experience

Though I’ve been tempted, I’ve never built something that was meant to have a digital bookish-ness, everything I’ve developed has had online-first layouts and components in mind. Some sites have had fairly extensive print styles, but that’s usually as far as it goes.

The most common related problem I’ve run in to on sites with long-format academic writing is footnotes. I’ve never come across a CMS that handles footnotes well. Heck, even HTML doesn’t handle them all that well, there aren’t any appropriate semantic elements as far as I’m aware (though there were in HTML3?).

The only easily accessible markup system that works with footnotes AFAIK is extended Markdown syntax. To use extended Markdown on a client site though, A) I have to be sure that the client is on board with learning quite a bit of Markdown (they often are once they understand the benefit, but some are stubborn!), and B) it needs to be compatible with whatever layout system the designer has devised.

I used this approach a while ago on the Jock Kinneir Library site, as of right now they’re using footnotes on the Biography page.

This implementation wasn’t super straightforward since the site couldn’t use a single Markdown field for content, we needed more of a page builder to accomplish the layout. Because of that, I had to do some trickery to recompile the footnotes at the base of the page content as opposed to after each text section. Honestly I can’t 100% remember how I accomplished it… It’s on Craft so uses Twig templates, and I don’t think we had the time to make a custom module that would take advantage of server-side logic. I do remember that it was a bit hackier than I wanted, but it safely accomplished what needed to be done.

If I need to include footnotes or something similar in the future, I’ll probably refer to this comprehensive article on footnotes, endnotes, and sidenotes (via @s3ththompson).

Would be curious if others have come across similar free, open source tools, or if anyone knows of work being done on the HTML spec to get some progress with footnotes.

At any rate, all of the above just reinforces my opinion that anyone who writes, regardless of how tech-savvy, should learn how to write in Markdown at minimum, ideally the extended syntax. If your archive of writing is in a machine-readable format, you’re miles ahead should you ever wish to publish it somewhere remotely digital or want to convert it to an IDML file or something similar.

Edit 24 September 2020: Added link to article about sidenotes.

Published Monday, 20 July 2020 by Piper Haywood

Commonplace WordPress theme

I’ve been gradually updating the WordPress theme that powers this site with the help of a very talented designer and thinker, my friend Bec Worth.

It began with conversations about overhauling her own site. She had a few disparate Tumblrs with a ton (and I really do mean a ton) of great references, photos, and more that had accumulated over the years. All of them had fallen in to disuse for one reason or another, but she still felt like some sort of outlet for collecting these sorts of snippets and longer-format writing would be really useful. She brought up the Commonplace book as a particular inspiration. I’d never come across it before but it really resonated.

We continued talking about her site, and I started to restructure my old color-heavy Notebook theme (view in Wayback Machine) to strip out the less necessary functionality, improve the accessibility, etc. I wanted to make it something that could be more widely useful to not just me and Bec, but others as well. The early version of this new theme used variable Work Sans (view in Wayback Machine)

She liked where it was going, so we got her set up on a WordPress instance and used the Tumblr importer to pull in all of that old content. Since then, we’ve been using her log and my site to test out ideas and continue pushing the idea of what a Commonplace Book could be on the web. For more along these lines, I recommend reading her post “What would a Commonplace Book feel like on the web?”

What’s next

It’s far from finished. The type is nowhere near as tight as Bec’s designs, I need to spend a bit more time on that! Amongst other things, I need to clean up the table of posts, add a thumbnail view, and improve the gallery block styles. We’re also going to figure out a way of highlighting work and other projects, something that draws a bit more attention than normal posts.

And color! We’d like to make it possible for people to select preferred text colors, maybe on a post-by-post basis or per category. Color is tricky though, I’d like to preserve some baseline of legibility and I’m not sure how much I could do as the developer to enforce that. Also, how do we handle this if we introduce dark mode support? The HSL or LCH color spaces might be helpful.

I’m not planning to submit this to the WordPress theme directory. Right now, this means that installation and updates are pretty manual, the theme has to be uploaded via FTP before it can be installed. Because of that, I’ll eventually set up an update server so that anyone using the theme can perform one-click updates from the WordPress admin area. Note to self: see this article for more on how to do this.

Realistically, people using the theme might want to change up certain aspects of the theme to be more “them”. Instead of adding a ton of theme options like font pickers and that sort of thing, I’d like to encourage people to tinker with it themselves. This is going to require a bit of documentation to point people in the right direction. I’ll probably start with how someone with little-to-no CSS experience could go about changing the font (i.e. upload font files in the Media library then add the necessary CSS lines in the Customizer, or setting up a child theme).

Clearly, it’s a work in progress!

But anyone is welcome to give it a try for themselves. I recommend it if you’ve been looking for a place to keep important references or get thoughts out of your head. Head to the commonplace-wp-theme GitHub repository to download it and read a bit more.

If you do end up using it, we’d love to know.

Published Friday, 1 May 2020 by Piper Haywood

“A person is only a coder as much as you are an InDesign-er or Microsoft Word-er”

Jake Dow-Smith just announced Publish Something Online ↗, a resource geared towards students. It’s super worthwhile and a very fun browse. From the intro:

Building websites is often seen as an uncreative, mathematics-based task undertaken by coders. This library encourages you to learn how to design and build interactive experiences and to consider this a tool in your design toolkit. A person is only a ~~coder~~ as much as you are an InDesign-er or Microsoft Word-er.

This library will introduce you not just to code resources, but also to examples of alternative forms of screen-based interaction and the technologies they are based on.

Published Sunday, 16 February 2020 by Piper Haywood

Where are the non-English programming languages? Thoughts prompted by a small but mighty bug

A short two-parter

Part 1: A small-but-mighty bug

I’m doing a few coding-for-designers workshops with the students in the MA Graphic Media Design programme at the LCC, the first one was this past Thursday.

We’re focusing on web stuff since that’s what they expressed the most interest in and it’s in my wheelhouse. We started with a broad and brief overview of code, about how we use human-readable programming languages to communicate with computers. But 99% of the time, when we say “human-readable” we really mean “English-based”. More on this later.

After my short intro, we put together a simple webpage with HTML and CSS. A few of the students ran in to a small-but-mighty bug that I’ve never encountered before.

We were working on a basic CSS rule set, something like:

body {
  background-color: linear-gradient(blue, pink)；
}

And for one of the students, it just wasn’t working. I checked it a bunch of times, it was all typed perfectly. No missing spaces or characters, spelling was fine. VSCode indicated that the background-color declaration wasn’t finished, which seemed weird. I looked really closely at it and noticed that the semicolon seemed a little thinner than the others in the file.

Turns out that the student had typed a full-width semicolon (U+FF1B) instead of a semicolon (U+003B). The full-width semicolon is used in Chinese to “demarcate parallel structures in a paragraph”. Another student ran in to the same problem a few minutes later, using a full-width left curly bracket (U+FF5B) instead of a left curly bracket (U+007B).

I had asked them to type in a semicolon, to type in a curly bracket, and so they typed the characters the way they normally do in their native languages. Super understandable.

If you were just starting to learn what code is and how it works, I can’t imagine how hard it would be to debug this sort of language-based problem on your own.

Part 2: Where are the non-English programming languages?

Gretchen McCulloch wrote a very worthwhile Wired article titled “Coding Is for Everyone—as Long as You Speak English”. I feel like every programmer / dev should read it.

Programming doesn’t have to be English-centric. As McCulloch puts it:

The computer doesn’t care. The computer is already running an invisible program (a compiler) to translate your IF or <body> into the 1s and 0s that it functions in, and it would function just as effectively if we used a potato emoji 🥔 to stand for IF and the obscure 15th century Cyrillic symbol multiocular O ꙮ to stand for <body>.

How would we go about implementing non-English HTML tags? W3C has an FAQ on the topic where they state that “HTML or XHTML tags are all pre-defined (in English) and must remain that way if they are to be correctly recognized by user agents (eg. browsers).”

Since browsers just implement the standards set by W3C (I’m pretty sure that’s right?), I’m guessing that W3C would have to approve it if we wanted native non-English HTML support. It seems like it would be a bit of a mountain to climb but if we take something like Wikipedia’s translation efforts as an example, surely there are tons of people out there that would help with translation?

Gonna keep an eye on this. Need to find a book or good article on the history of ALGOL.

Published Wednesday, 5 February 2020 by Piper Haywood

Using CSS, HTML, and maybe a little logic to display images with a consistent surface area

Every once in a while, I have to figure out how to display images on the web with a consistent surface area. It’s usually in relation to making a lot of logos with very different aspect ratios look evenly sized so that none of them stick out like a sore thumb.

I haven’t had to do this in a while but came across a tweet by Nick Sherman that prompted me to think about it again.

To achieve an evenly-sized group of images, you have to calculate a maximum width that is proportionate to the surface area you want. To do this, you need to be able to calculate a square root, you need the width and height of each original image, and all of your images need to be tightly cropped since extra negative space will throw things off visually.

In the past, I’ve achieved this with logic since vanilla CSS doesn’t currently support a sqrt() function (more on this later). I’ve usually used PHP since I tend to work with Kirby CMS pretty often.

The function in PHP:

function max_img_width($img_width, $img_height, $ideal_area) {
  $max_width = round($img_width * sqrt($ideal_area / ($img_width * $img_height)));
  echo $max_width;
}

And the function in use + corresponding HTML:

<img style="max-width: <?php max_img_width(1500, 3000, 40000); ?>px;" src="https://piperhaywood.com/my-image.jpg">

A CSS-only solution that works now

There seems to be a CSS-only way to go about this though. Apparently you can approximate square roots in CSS by using a series of CSS variables and calc(), see more info in this thread.

I will warn you: this is ugly. Also, it heavily relies on CSS variables which may or may not work for you depending on your browser support requirements. Here’s the CSS and the image markup:

img {
  --width: 0;
  --height: 0;
  --ideal-area: 40000;
  --area: calc(var(--width) * var(--height));
  --ratio: calc(var(--ideal-area) / var(--area));
  --guess01: calc(calc(var(--ratio) + calc( var(--ratio) / var(--ratio))) / 2);
  --guess02: calc(calc(var(--guess01) + calc( var(--ratio) / var(--guess01))) / 2);
  --guess03: calc(calc(var(--guess02) + calc( var(--ratio) / var(--guess02))) / 2);
  --guess04: calc(calc(var(--guess03) + calc( var(--ratio) / var(--guess03))) / 2);
  --guess05: calc(calc(var(--guess04) + calc( var(--ratio) / var(--guess04))) / 2);
  --guess06: calc(calc(var(--guess05) + calc( var(--ratio) / var(--guess05))) / 2);
  --guess07: calc(calc(var(--guess06) + calc( var(--ratio) / var(--guess06))) / 2);
  --guess08: calc(calc(var(--guess07) + calc( var(--ratio) / var(--guess07))) / 2);
  max-width: calc(var(--width) * var(--guess08) / 2 * 1px);
}

<img style="--width: 1500; --height: 3000;" src="https://piperhaywood.com/my-image.jpg">

I’d want to do some more browser testing since this results in a pretty gnarly calc() situation by --guess08, but at first glance this seems like it might be a worthwhile solution. It doesn’t give us exactly proportionate surface areas but it gets very close. It only starts to fall apart with super skyscraper-y and letterbox-y images.

A few quick notes regarding why this is written as it is and ways that it could be tweaked:

I capped the number of guesses at eight because any more seemed to just fail, Chrome and Safari wouldn’t interpret such a big calc() equation.

I set the default width and height to zero so that there is no max width restriction if the image tag is missing the width and height CSS variables. This could be changed, as could the ideal area variable (increase to get larger images, decrease to get smaller).

The 1px value in the max-width calculation is required so that the value is interpreted as a unit. That said, it doesn’t have to be pixels! Could change this to another unit like 1em or 1%.

If I wanted to display these evenly centred, I’d probably give the images some margin and then wrap them in a container with styles as below:

.container {
  align-items: center;
  display: flex;
  flex-wrap: wrap;
  justify-content: center;
}

Could also use CSS grid for a more consistent spacing result.

And a final reminder: this only visually scales the images. Try to avoid loading a 3000px wide image if you’re going to be displaying it around 200px wide, your users and the planet will thank you.

A CSS-only solution that might work in the future

So apparently more complex math functions including sqrt() might be coming to CSS in the future! See this issue raised by Lea Verou in the CSS specifications editor’s drafts repo and the exponential functions section from CSS Values and Units Module Level 4 in the W3C editor’s draft from 3 February 2020 (a couple days ago!).

I’m not sure when this would become part of the spec and no idea if / when the browsers might implement them, but here is a snippet that should work with that new function in theory:

img {
  --width: 0;
  --height: 0;
  --ideal-area: 40000;
  max-width: calc(var(--width) * sqrt(calc(var(--ideal-area) / calc(var(--width) * var(--height)))) / 2 * 1px);
}

I’m happy that Nick asked the question on Twitter, I actually need this on an upcoming project where I’ve only got Twig to work with which doesn’t support square roots, and I’d prefer to avoid JavaScript in this instance. Hopefully this is the solution, will update here if so.

A picture says a thousand words, so see Nick’s very nice demo of area-based image sizing with CSS to check out one possible outcome.

Edit 05.02.20

Edited a few words for clarity, added Nick’s demo, added future example incorporating a CSS-based sqrt() function.

Thanks Sam Baldwin for bringing future math function support in CSS to my attention!

Edit 06.02.20

Simplified the PHP + HTML example.

The original PHP + HTML example used a --max-width CSS variable instead of just applying a max-width directly. I used a CSS variable because I thought that they were compliant with a strict Content Security Policy that includes the style-src directive set to unsafe-inline. That assumption was incorrect, though there does seem to be some discussion about the topic.

Thanks Lizzie Malcolm for questioning the CSS var usage in the PHP example!

Edit 18.02.20

Changed parenthesis-enclosed arithmetic so that each is enclosed in calc(). Plain CSS seems to interpret arithmetic enclosed in parenthesis just fine, but SASS doesn’t seem to like it.

Published Thursday, 9 January 2020 by Piper Haywood

Switching from Google Analytics to Matomo (f.k.a. Piwik) on WordPress

It’s a new decade, time to leave Google Analytics.

A big part of me wants to say screw it, just get rid of analytics altogether. But I find it interesting. I’ve never used it to decide what to write, and I don’t think I ever will, but it’s just fascinating to find out what makes the rounds. I’ll never know why a short post about repairing my mom’s straw bag was my most popular post for years, but I’m glad to know a lot of people checked it out.

So I decided to keep my Google Analytics property in place and just locked it down as much as I could. I adjusted the script to respect users’ Do Not Track browser settings (Paul Fawkesley has a short article about how to do this). I also configured Google Analytics to anonymise IP addresses, and I deliberately disabled Data Collection for Advertising Features, Demographics and Interest Reports, User-ID, and all data-sharing settings. I also set a low data retention policy to make sure old data would get deleted.

None of this changed the fact that I was still sharing data with Google.

Site update: a new taxonomy index and a11y improvements

Just pushed an update to this site.

The Browse page is now mainly an index of taxonomies and archives (years, post formats, categories, tags). This new index replaces the opacity-based tag cloud. I kind of miss it, but it was problematic. Very hard to digest, and the lighter greys were way too low-contrast.

Besides the index, most of the changes are related to accessibility. I focused on making the tabbing experience a bit better, introducing a couple skip links. Note that I haven’t totally ironed out the tabbing… Most of my manual testing for this update was done in Chrome. I checked it briefly in Safari and it’s pretty weird, but I think it may have to do with the default Safari settings. I haven’t adjusted these yet, read more about Safari tab settings on a11yproject.com. Besides the tabbing, I also had a handful of links that weren’t suitably descriptive, particularly on the new term index. I added more aria-label attributes where I could. See the “Using aria-label for link purpose” page on the WCAG wiki for more info.

I’m trying to work on accessibility a bit more on an ongoing basis. Need to take a little dive in to this Hacker News thread, via this tweet.

Exploring the use cases for serverless website architecture

Last Saturday, Sam introduced me to Chris Coyier’s talk on serverless-ness, The All-Powerful Front-End Developer. Pretty interesting and useful. I’m glad he leads it by breaking down the problematic nature of the word “serverless”! The following day was spent in agorama’s p2p workshop at furtherfield. Coincidentally, there is a lot of overlap in these topics.

I’ve spent the past few days wrapping my head around all of this, contextualising it against the sorts of concerns and projects we work with. Though I desperately want to get going with Dat, I’m starting with serverless because it may solve an urgent need in my day-to-day work. Right now, I’m spending much more time than I realistically can maintaining CMSs and hosting environments for older websites.

All of the below is a thought dump on the topic, an attempt to pick apart the meaning of and the use cases for a serverless website architecture.