Jeremy Keith

Jeremy Keith

Making websites. Writing books. Speaking at conferences. Living in Brighton. Working at Clearleft. Playing music. Taking photos. Answering email.

Journal 2325 Articles 64 Links 6060 Notes 2522

Monday, August 29th, 2016

How we made the RioRun progressive web app | Info | The Guardian

The devs at The Guardian walk through the process of building a progressive web app for the Olympics. There were some gotchas with the life cycle of service workers, but the pay-off was worth it:

Once you get there though, it’s quite magical when you load the page on a phone, switch it to airplane mode, reload, and continue using the app as though nothing was wrong.

Thursday, August 25th, 2016

The rise and fall of the Gopher protocol | MinnPost

A deep dive into the history of Gopher. For a while there, it looked like it was going to be bigger than the World Wide Web.

This article is filled with timely details:

The programmers were young guys, mostly in their 20s and, like McCahill, mostly huge Nirvana fans. Paul Lindner, a coding wunderkind from northern Minnesota who was dubbed the Gopher Dude for his evangelism, had long metal-head hair and signed Gopher emails with lyrics like “You have to spit to see the shine” from Babes in Toyland. Early Gopher servers were named Mudhoney, Danzig, and Anthrax.

Ah, Babes In Toyland! It’s like the soundtrack to my time in art college in the early 90s. I remember one of the best gigs ever being a triple bill of The Sultans Of Ping, Babes In Toyland, and Theraphy? at Sir Henrys in Cork.

Wednesday, August 24th, 2016

Shadow DOM v1: self-contained web components | Web Fundamentals - Google Developers

An in-depth look at the current Shadow DOM spec. It’s well-written but I don’t think this will really click with me until I start playing around with it for myself.

It’s good to see that the examples have some thought given to fallback content.

There’s also a corresponding tutorial on custom elements

SPACEPLAN

I thoroughly enjoyed playing this game. On the face of it, it seems like little more than a cow-clicker, but the way that the plot and the gameplay unfolds is really delightful.

This feels like the kind of game that would only work on the web—keep it in a browser tab in the background, revisiting occasionally throughout the day.

Marking up help text in forms

Zoe asked a question on Twitter recently:

‘Sfunny—I had been pondering this exact question. In fact, I threw a CodePen together a couple of weeks ago.

Visually, both examples look the same; there’s a label, then a form field, then some extra text (in this case, a validation message).

The first example puts the validation message in an em element inside the label text itself, so I know it won’t be missed by a screen reader—I think I first learned this technique from Derek many years ago.

<div class="first error example">
 <label for="firstemail">Email
<em class="message">must include the @ symbol</em>
 </label>
 <input type="email" id="firstemail" placeholder="e.g. you@example.com">
</div>

The second example puts the validation message after the form field, but uses aria-describedby to explicitly associate that message with the form field—this means the message should be read after the form field.

<div class="second error example">
 <label for="secondemail">Email</label>
 <input type="email" id="secondemail" placeholder="e.g. you@example.com" aria-describedby="seconderror">
 <em class="message" id="seconderror">must include the @ symbol</em>
</div>

In both cases, the validation message won’t be missed by screen readers, although there’s a slight difference in the order in which things get read out. In the first example we get:

  1. Label text,
  2. Validation message,
  3. Form field.

And in the second example we get:

  1. Label text,
  2. Form field,
  3. Validation message.

In this particular example, the ordering in the second example more closely matches the visual representation, although I’m not sure how much of a factor that should be in choosing between the options.

Anyway, I was wondering whether one of these two options is “better” or “worse” than the other. I suspect that there isn’t a hard and fast answer.

Tuesday, August 23rd, 2016

Writing Less Damn Code | HeydonWorks

I’m in complete agreement with Heydon here:

But it turns out the only surefire way to make performant Web Stuff is also to just write less. Minify? Okay. Compress? Well, yeah. Cache? Sounds technical. Flat out refuse to code something or include someone else’s code in the first place? Now you’re talking.

Just like the “mobile first” mindset, if you demand that everything must justify its existence, you end up with a better experience for everyone:

My favorite thing about aiming to have less stuff is this: you finish up with only the stuff you really need — only the stuff your user actually wants. Massive hero image of some dude drinking a latte? Lose it. Social media buttons which pull in a bunch of third-party code while simultaneously wrecking your page design? Give them the boot. That JavaScript thingy that hijacks the user’s right mouse button to reveal a custom modal? Ice moon prison.

Hypothesis: if you really insist on using a pull quote online, you should apply aria-hidden=”true”.

Why do pull quotes exist on the web?

There you are reading an article when suddenly it’s interrupted by a big piece of text that’s repeating something you just read in the previous paragraph. Or it’s interrupted by a big piece of text that’s spoiling a sentence that you are about to read in subsequent paragraphs.

There you are reading an article when suddenly it’s interrupted by a big piece of text that’s repeating something you just read in the previous paragraph.

To be honest, I find pull quotes pretty annoying in printed magazines too, but I can at least see the justification for them there: if you’re flipping through a magazine, they act as eye-catching inducements to stop and read (in much the same way that good photography does or illustration does). But once you’re actually reading an article, they’re incredibly frustrating.

You either end up learning to blot them out completely, or you end up reading the same sentence twice.

You either end up learning to blot them out completely, or you end up reading the same sentence twice. Blotting them out is easier said than done on a small-screen device. At least on a large screen, pull quotes can be shunted off to the side, but on handheld devices, pull quotes really make no sense at all.

Are pull quotes online an example of a skeuomorph? “An object or feature which imitates the design of a similar artefact made from another material.”

I think they might simply be an example of unexamined assumptions. The default assumption is that pull quotes on the web are fine, because everyone else is doing pull quotes on the web. But has anybody ever stopped to ask why? It was this same spiral of unexamined assumptions that led to the web drowning in a sea of splash pages in the early 2000s.

I think they might simply be an example of unexamined assumptions.

I’m genuinely curious to hear the design justification for pull quotes on the web (particularly on mobile), because as a reader, I can give plenty of reasons for their removal.

Alas, tomorrow evening’s Brighton Homebrew Website Club is cancelled—apologies, my fellow website tinkerers.