Published

Two articles on SPA or SPA-like sites vs alternatives

I missed these two articles by Tom MacWright from last year.

Second-guessing the modern web, 10 May 2020
If not SPAs, What?, 28 October 2020

In both, he outlines few upsides and downsides about the single page app (SPA) approach to websites and has a few points that I have really struggled to articulate in the past.

From “Second-guessing”:

There is a swath of use cases which would be hard without React and which aren’t complicated enough to push beyond React’s limits. But there are also a lot of problems for which I can’t see any concrete benefit to using React. Those are things like blogs, shopping-cart-websites, mostly-CRUD-and-forms-websites. For these things, all of the fancy optimizations are trying to get you closer to the performance you would’ve gotten if you just hadn’t used so much technology.

I’ve dabbled with React and Vue in small side projects and experiments. But the point above is the big reason I’ve never taken the time to sit down and learn either of them properly. For almost every client site I’ve ever done, it just didn’t make sense to make it an SPA.

And I’m not 100% sure, but I think this might contribute to longevity. Some of my clients are still working with the same sites I built for them nearly 10 years ago, a few with just minor security-related updates in the meantime and no other maintenance strictly required. That’s not to say that those sites couldn’t use a “lick of paint” to bring them in to the 2020s; the point is that they work. And for organizations working on really tight budgets, or budgets that fluctuate wildly due to public funding, stability is really important. They can’t afford a developer on retainer to keep things running smoothly.

But of course the SPA vibe is pretty attractive, particularly for cultural orgs. MacWright has some decent alternatives suggested in “If not SPAs” including Turbolinks, Barba.js, and instant.page. Will also mention MoOx/pjax since I’ve used it before for page transitions with very good results, but probably won’t use it in the future as it hasn’t been updated in a while.

And again, there’s the rub. The more non-native scripts, plugins, etc I use in a project, the more likely that it’s going to be a major headache (and thus major time/money for the client) for me to change things down the line if or when that bit of tech is no longer supported or has changed significantly.

So it’s not even so much about being wary of React or Vue, it’s about not making assumptions, being cautious and cognizant of future needs or restrictions when proposing a tech stack. Any tech stack you choose will ultimately become a ball-and-chain, not just those based on JavaScript frameworks. It’s just that the ball can sometimes be heavier than it needed to be, and you can anticipate that with a little foresight.

Published

Edit your hosts file on a Mac to spoof DNS changes

Sometimes I need to spoof DNS changes before they go live, like when double-checking the behavior of a site in a production environment before the site launches.

You can do this by editing your Hosts file. By editing your Hosts file, you’re basically telling your computer, “Hey, ignore what all of the DNS caches are telling you about where to find this site. This is where you should actually look for it.”

All great and useful, but I forget how to do this every time. For future reference:

Open up Terminal (the command line) and run

sudo nano /etc/hosts

You’ll likely be prompted to enter the password for the user you have set up on your computer since sudo tells the computer to execute a command as a superuser, and it needs to make sure you’re authorized to do that. Once the command runs, the file you specified (/etc/hosts) will be opened up in the GNU nano command line text editor. Nano can be a little confusing if it’s super new to you, refer to the docs or search around, guides abound online.

There will probably be a bit of content in this file already. Some of it might be comments, text preceded by a # symbol. Don’t change the existing contents unless you know what the effect will be and you’re really sure about it!

Instead, on a new line at the base, just add a new line with the IP address you want to point to followed by the URL without the protocol (so piperhaywood.com, not https://piperhaywood.com).

Once you’ve changed it, save the file and exit nano. When you load up the URL in a browser, you should be seeing whatever resources are available at the IP address you’ve specified. If you’re still seeing the “old” site, try loading it in a private browsing window.

Don’t forget to change it back when you’re done.

Published

Dev environment issue related to MySQL and missing OpenSSL v1.0.0 symlink

I woke up early this morning to get some work done before a call and suddenly my local dev environment stopped working without warning and with seemingly no reason. The root issue was that MySQL wouldn’t work, /usr/local/opt/openssl/lib/libssl.1.0.0.dylib was not loading.

TL;DR: This may have been related to some automatic cleanup on Homebrew’s part. But regardless, a simple restart sorted it. If this happens again and restarting doesn’t sort it, try uninstalling and reinstalling MySQL.

The rest of the detail is below for posterity if I run in to this in the future.

Read more

Published

Fix for overflow at top / bottom of screen when using CSS Scroll Snap

I’m currently working on a site that uses CSS Scroll Snap to frame some of the content nicely as you scroll through. In Chrome though, I was getting weird overflow issues at the top and bottom of the screen. If I scrolled to the bottom and then kept attempting to scroll down, it would gradually add more and more length to the page. Same with scrolling back up.

Adding overscroll-behavior-y: none; to the body element sorted it out. Read more about overscroll-behavior on MDN.

I originally tried to add this property to the html element since that’s the element with scroll-snap-type: y mandatory;. This didn’t work though, it seems that overscroll-behavior has to be on body.

Published

Disabling “save to Pinterest”

Just had a collaborator ask if we could disable the “save to Pinterest” button even if a visitor has a Pinterest addon / extension in their browser. My immediate reaction was “Maybe? I’d think not but will see!”

Turns out something like this should be possible. Pinterest supports disabling saves from a site, see their documentation. You can either enable it site-wide or per image.

I’m surprised but really happy to see that they offer this, hope that they continue to do so.

Published

Single `mv` command to change all filenames in directory to lower case and replace spaces

This is the mv command I use to change all of the filenames in my current directory from mixed case to lowercase and replace spaces with underscores.

for file in *; do mv "$file" `echo $file | tr ' ' '_' | tr '[:upper:]' '[:lower:]'`  ; done

The ; semicolons indicate the end of each line of this command. To break it down:

  1. for file in * loops over all the files in the directory. You could change the * wildcard to something like *.jpg if you wanted to only target JPG files.
  2. do mv "$file" instructs the system to move each file in the loop to the location that immediately follows.
  3. `echo $file | tr ' ' '_' | tr '[:upper:]' '[:lower:]'` is the location we’re moving the file to. We use the tr “translate” command to replace spaces with underscores, and then again (separated by the | pipe character) to replace uppercase letters with lowercase letters. Then we echo that translated filename.
  4. done lets the system know that the loop is done.

I use this occasionally to prep files for use on the web when working on a static site, one that isn’t hooked it up to a CMS.

Published

Now online: Open-weather

Screenshot of the Open-weather website showing a storm over Japan

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

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.