Geohashing expedition 2020-09-09 51 -1

This checkin to geohash 2020-09-09 51 -1 reflects a geohashing expedition. See more of Dan's hash logs.

Location

Edge of a field bounded by Letcombe Brook, over the A338 from Landmead Solar Farm.

Participants

Plans

We’re discussing the possibility of a Subdivision geohash achievement for people who’ve reached every “X in a Y”, and Fippe pointed out that I’m only a hash in the Vale of White Horse from being able to claim such an achievement for Oxfordshire’s regions. And then this hashpoint appears right in the Vale of White Horse: it’s like it’s an omen!

Technically it’s a workday so this might have to be a lunchtime expedition, but I think that might be workable. I’ve got an electric vehicle with a hundred-and-something miles worth of batteries in the tank and it looks like there might be a lay-by nearby the hashpoint (with a geocache in it!): I can drive down there at lunchtime, walk carefully back up the main road, and try to get to the hashpoint!

Expedition

I worked hard to clear an hour of my day to take a trip, then jumped in my (new) electric car and set off towards the hashpoint. As I passed Newbridge I briefly considered stopping and checking up on my geocache there but feeling pressed for time I decided to push on. I parked in the lay-by where GC5XHJG is apparently hidden but couldn’t find it: I didn’t search for long because the farmer in the adjacent field was watching me with suspicion and I figured that anyway I could hunt for it on the way back.

Walking along the A338 was treacherous! There are no paths, only a verge covered in thick grass and spiky plants, and a significant number of the larger vehicles (and virtually all of the motorbikes) didn’t seem to be obeying the 60mph speed limit!

Reaching the gate, I crawled under (reckoning that it’s probably there to stop vehicles and not humans) and wandered along the lane. I saw a red kite and a heron doing their thing before I reached the bridge, crossed Letcombe Brook, and followed the edge of the field. Stuffing my face with blackberries as I went, it wasn’t long before I reached the hashpoint on one edge of the field.

I took a short-cut back before realising that this would put me in the wrong place to leave a The Internet Was Here sign, so I doubled-back to place it on the gate I’d crawled under. Then I returned to the lay-by, where another car had just pulled up (right over the GZ of the geocache I’d hoped to find!) and didn’t seem to be going anywhere. Sadly I couldn’t wait around all day – I had work to do! – so I went home, following the satnav in the car in a route that resulted in a figure-of-eight tracklog.

Tracklog

My GPS keeps a tracklog. Here you go:

Geohashing expedition 2020-09-09 51 -1 tracklog map

Video

You can also watch it at:

Photos

360° panoramic VR photo of the 2020-09-09 51 -1 geohashpoint

× ×

Dan Q couldn’t find GC5XHJG Layby Dash A

This checkin to GC5XHJG Layby Dash A reflects a geocaching.com log entry. See more of Dan's cache logs.

Parked my car in this lay-by while on my way to the 2020-09-09 51 -1 geohashpoint. Took a quick look for the cache but the farmer in the adjacent field parked his tractor right alongside me and was watching with suspicion, so I thought better of it and decided to come back after visiting the hashpoint and try again.

The geohashing expedition was a success, and I returned to the lay-by for another attempt… but somebody else had parked here (pretty much exactly where I’d measured the coordinates to be… boo!). I waited for a while but they didn’t seem like they were leaving so I abandoned my search: I’ll try again next time I’m in the vicinity.

Firefox Daylight Makes Me Sad

I love Firefox, as I’ve doubtless said before. In 2005 it reached the point at which (with the right combination of add-ons) it could replace Opera as my default browser. Going mobile, I used it on my N900 (still an underrated device) back in 2010, and later I’d use it on my Android devices. I love the power, productivity, performance, and privacy Firefox helps to give me.

Enter the latest iteration of the Android version, Firefox Daylight, which came out last week.

Start page shown after first upgrading to Firefox Daylight including options for URL bar location.
When you first run Firefox Daylight, you’re asked where you want the address bar, among other things.

First, the good: this latest version of Firefox for Android is fast. Blazingly fast. The privacy controls are clearer and easier to access. Having picture-in-picture mode on mobile is a nice touch, as is the new generation of tracking prevention features.

But Firefox Daylight still makes me frown. And it’s a trio of smaller things that really niggle:

1. Top or bottom toolbar… but top is a second-class citizen.

In theory, I like the idea of having the address bar and its friends at the bottom of the screen where it’s more-accessible to your thumb. I’ve even tried it, independently. in years past. But it’s too much of a mental leap for me nowadays, plus it doesn’t cleanly fit into the “scroll down and the address bar disappears” user experience that’s become commonplace.

Making bottom toolbar the default was perhaps a little radical, then, but at least Mozilla provided an option to put it back at the top. But… it’s not quite right:

Firefox Daylight's navigation controls can involve you moving from the bottom to the top of the screen in succession. Ick.
Sure, I’ll move my thumb the entire height of the screen every time I want to open a new tab.

Even with the toolbar moved back to the top, some controls associated with it stay at the bottom. Want to open a new tab? You have to press the “tabs” button at the top of the screen, then the “plus” button at the bottom of the screen, then – probably – the address bar back at the top of the screen again! You’ve just covered two complete lengths of the screen to do something that used to require none. Not a satisfactory experience.

Fennec F-Droid (showing Firefox for Android's old interface) has the "add tab" button right at the top, on the toolbar. It also uses a "tiled" layout for the tabs with the oldest first, rather than a list view with the oldest last.
The old interface put the oft-used “add tab” button in the toolbar in the same place as the “tabs” button you just pressed. Much better.

2. Tab previews were more space-efficient before

You’ve probably already spotted the other change to the “current tabs” view. Previously, open tabs were shown as mini previews with their titles above. Now they’re shown as tiny (sometimes absent) icon-sized previews with their titles alongside. This allows the domain name to be shown, which is nice, but not nice enough to justify reducing the instant visual recognition the previous interface provided.

It’s not even like you can fit more tabs onto a screen. The capacity is basically the same. You’re just making smaller hit targets with less recognisable graphics. Plus: previously the most-recent tabs were at the bottom (close to where your thumb is, which was the justification for making the address bar default to the bottom); now they’re at the top, further adding to the distance travelled.

3. Plugin support is terrible

I know first hand that implementing backwards-compatibility is hard, but breaking most plugins and then providing a list of nine or so popular/recommended ones that still works isn’t a great experience.

Firefox Daylight's recommended add-ons list
No uMatrix. No Violentmonkey (or any equivalent). No Ghostery, even! Feels like surfing the Web with one hand tied behind my back.

Feels a bit like this was released before it was ready.

For the time being, I’m using Fennec F-Droid as my primary mobile browser. It picks up exactly where Firefox for Android left off, and it doesn’t break my workflow. I hope to switch back to regular Firefox for Android someday, but Daylight needs “finishing” first.

× × × ×

Dan Q found GC140G9 Thames Path: Newbridge (not)

This checkin to GC140G9 Thames Path: Newbridge (not) reflects a geocaching.com log entry. See more of Dan's cache logs.

Came down to the river to launch my partner’s brother on a swimming expedition (pictured putting on his wetsuit) downstream and to triple-check access to my nearby new cache GC8YZKJ. Recent logs about the cache being submerged made me worry and I spent some time looking too-close to the water’s edge, but as soon as I expanded my search I caught sight of it immediately. TFTC!

×

Holograms on Chocolate

This is a repost promoting content originally published elsewhere. See more things Dan's reposted.

This is incredibly cool. Using (mostly) common household tools and chemicals and a significant amount of effort, Ben (who already built himself a home electron microscope, as you do) demonstrates how you can etch a hologram directly into chocolate, resulting in a completely edible hologram. I’d never even thought before about the fact that a hologram could be embossed into almost any opaque surface before, so this blew my mind. In hindsight it makes perfect sense, but it still looks like magic to see it done.

Run Club Goes for a Swim

Out on a Run Club expedition up the Thames Path this evening, took a quick dip in the river with Robin.

Also available on: QTube.

Oxford’s Long-Lost Zoo

Oxford has many things, but it doesn’t have a zoo. But for a few years in the 1930s, it did, and it’s a fascinating story that starts with marmalade and ends with a geocache.

With thanks to John Amor, whose book Gosford Hill & Oxford Zoo (ISBN 978-0-9544474-5-8) answered my initial research questions, and to the Bodleian Libraries for giving me the resources to go deeper. Also thanks to my Alphamattic teammates for listening to me talk about a different bit of Oxford history and encouraging me to make this video.

Music: Don’t Turn Around, by Ivan Chew (ramblinglibrarian), used under a CC-Attribution-NonCommercial license.
Some footage of Oxford provided by Steve B (@bigantvideo), used under the Pexels license.
Uses photos taken prior to 1925 of unknown provenance or subsequently released into the public domain.

Parts of this video were filmed during COVID-19 lockdown restrictions. Appropriate social distancing practices were applied.

Also available via YouTube and QTube.

To the future occupants of my office at the MIT Media Lab

This is a repost promoting content originally published elsewhere. See more things Dan's reposted.

Hi. My name is Ethan Zuckerman. From 2011-2020, I enjoyed working in this office. I led a research group at the Media Lab called the Center for Civic Media, and I taught here and in Comparative Media Studies and Writing. I resigned in the summer of 2019, but stayed at the lab to help my students graduate and find jobs and to wind down our grants. When COVID-19 hit in March 2020, I left campus and came back on August 14 to clean out my office and to leave you this note.

I’m leaving the note because the previous occupant left me a note of sorts. I was working here late one night. I looked up above my desk and saw a visegrip pliers attached to part of the HVAC system. I climbed up to investigate and found a brief note telling the MIT facilities department that the air conditioning had been disabled (using the vice grips, I presume) as part of a research project and that one should contact him with any questions.

That helped explain one of the peculiarities of the office. When I moved in, attached to the window was a contraption that swallowed the window handle and could be operated with red or green buttons attached to a small circuitboard. Press the green button and the window would open very, very slowly. Red would close it equally slowly. I wondered whether the mysterious researcher might be able to remove it and reattach the window handle. So I emailed him.

I’m reminded of that time eleven years ago that I looked up the person who’d gotten my (recycled) university username and emailed them. Except Ethan’s note, passed on to the next person to occupy his former office at MIT, is much cooler. And not just because it speaks so eloquently to the quirky and bizarre culture of the place (Aber’s got its own weird culture too, y’know!) but because it passes on a slice of engineering history that its previous owner lived with, but perhaps never truly understood. A fun read.

Note #17583

Needed new UPS batteries.
Almost bought from @insight_uk but they require registration to checkout.
Purchased from @SourceUPSLtd instead.
Moral: having no “guest checkout” costs you business.

Loading CSS Asynchronously Without JS Dependency

tl;dr? skip to the proof-of-concept/demo of lazy-loading CSS where possible while still loading it “conventionally” to users without Javascript

In a “daily tip” a couple of days ago, the excellent Chris Ferdinandi recommended an approach to loading CSS asynchronously based on a refined technique by Scott Jehl. The short of it is that you load your stylesheets like this:

<link rel="stylesheet" href="/path/to/my.css" media="print" onload="this.media='all'">

You see what that’s doing? It’s loading the stylesheet for the print medium, but then when the document finishes loading it’s switching the media type from “print” to “all”. Because it didn’t apply to begin with the stylesheet isn’t render-blocking. You can use this to delay secondary styles so the page essentials can load at full speed.

This website's Lighthouse score showing a Total Blocking Time of 0ms.
Reducing blocking times, like I have on this page, is one of many steps in optimising perceived page performance.

I don’t like this approach. I mean: I love the elegance… I just don’t like the implications.

Why I don’t like lazy-loading CSS using Javascript

Using Javascript to load CSS, in order to prevent that CSS blocking rendering, feels to me like it conceptually breaks the Web. It certainly violates the expectations of progressive enhancement, because it introduces a level of fault-intolerance that I consider (mostly) unacceptable.

CSS and Javascript are independent of one another. A well-designed progressively-enhanced page should function with HTML only, HTML-and-CSS only, HTML-and-JS only, or all three.CSS adds style, and JS adds behvaiour to a page; and when you insist that the user agent uses Javascript in order to load stylistic elements, you violate the separation of these technologies (I’m looking at you, the majority of heavyweight front-end frameworks!).

If you’re thinking that the only people affected are nerds like me who browse with Javascript wholly or partially disabled, you’re wrong: gov.uk research shows that around 1% of your visitors have Javascript fail for some reason or another: because it’s disabled (whether for preference, privacy, compatibility with accessibility technologies, or whaterver), blocked, firewalled, or they’re using a browser that you didn’t expect.

The Web Pyramid. In the style of a "food pyramid", shows Text Worth Reading at the bottom, supporting Markup, supporting Images, supporting CSS, supporting (a small amount of) Scripts.
Maciej Cegłowski‘s 2015 talk “Website Obesity” draws the boundaries firmly, using this great diagram.

Can we lazy-load CSS in a way that doesn’t depend on Javascript? (spoiler: yes)

Chris’s daily tip got me thinking: could there exist a way to load CSS in a non-render-blocking way but which degraded gracefully in the event that Javascript was unavailable? I.e. if Javascript is working, lazy-load CSS, otherwise: load conventionally as a fallback. It turns out, there is!

In principle, it’s this:

  1. Link your stylesheet from within a <noscript> block, thereby only exposing it where Javascript is disabled. Give it a custom attribute to make it easy to find later, e.g. <noscript lazyload> (if you’re a standards purist, you might prefer to use a data- attribute).
  2. Have your Javascript extract the contents of these <noscript> blocks and reinject them. In modern browsers, this is as simple as e.g. [...document.querySelectorAll('noscript[lazyload]')].forEach(ns=>ns.outerHTML=ns.innerHTML).

If you need support for Internet Explorer, you need a little more work, because Internet Explorer doesn’t expose<noscript> blocks to the DOM in a helpful way. There are a variety of possible workarounds; I’ve implemented one but not put too much thought into it because I rarely have to think about Internet Explorer these days.

In any case, I’ve implemented a proof of concept/demonstration if you’d like to see it in action: just take a look and view source (or read the page) for details. Or view the source alone via this gist.

Lazy-loading CSS using my approach provides most of the benefits of other approaches… but works properly in environments without Javascript too.

Update: Chris Ferdinandi’s refined this into an even cleaner approach that takes the best of both worlds.

× ×

Building a Playframe (Timelapse Video)

This week, with help from Robin and JTA, I built a TropicTemple Tall XXL climbing frame in the garden of our new house. Manufacturer Fatmoose provided us with a pallet-load of lumber and a sack of accessories, delivered to our driveway, based on a design Ruth and I customised using their website, and we assembled it on-site over the course of around three days. The video above is a timelapse taken from our kitchen window using a tablet I set up for that purpose, interspersed with close-up snippets of us assembling it and of the children testing it out.

Playframe in VR
You can explore the play equipment in VR, if you like.

I’ve also built a Virtual Tour so you can explore the playframe using your computer, phone, or VR headset. Take a look!

The video is also available via:

Note #17552

Dan with his Masters Degree certificate (Master of Science in Computing: Information Security and Forensics)

I’m unlikely to get a graduation ceremony like last time (on account of social distancing and whatnot), but I get a certificate to acknowledge my most-recent qualification.

×