Archive: September, 2021

On this day twenty years ago I wrote the first entry in my online journal. In the intervening two decades I’ve written a further 2,817 entries.

I am now fifty years old, which means I’ve been blogging for two fifths of my lifetime.

My website has actually been around for longer than twenty years, but its early incarnations had no blog. That all changed when I relaunched the site on September 30th, 2001.

I wrote at the time:

I’m not quite sure what I will be saying here over the coming days, weeks, months and years.

Honestly I still feel like that.

I think it’s safe to assume an “anything goes” attitude for what I post here. Being a web developer, there’s bound to be lots of geeky, techy stuff but I also want a place where I can rant and rave about life in general.

That’s been pretty true, although I feel that maybe there’s been too much geeky stuff and not enough about everything else in my life.

I’ll try and post fairly regularly but I don’t want to make any promises I can’t keep. Hopefully, I’ll be updating the journal on a daily basis.

I made no promises but I think I’ve done a pretty good job. Many’s the blogger who has let the weeds grow over their websites as they were lured by the siren song of centralised social networks. I’m glad that I’ve managed to avoid that fate. It feels good to look back on twenty years of updates posted on my own domain.

Anyway, let’s see what happens. I hope you’ll like it.

I hope you still like it.

Here are some of my handpicked highlights from the past twenty years of blogging:

• Hyperdrive, April 20th, 2007

  Last night in San Francisco.

• Design doing, November 11, 2007

  The opposite of design thinking.

• Iron Man and me, December 1st, 2008

  The story of how one of my Flickr pictures came to be used in a Hollywood movie.

• Seams, May 12th, 2014

  There is a crack, a crack in everything. That’s how the light gets in.

• Web! What is it good for?, May 28th, 2015

  Not absolutely nothing, but not absolutely everything either.

• Split, April 10th, 2019

  Materials and tools; client and server; declarative and imperative; inclusion and privilege.

We’re past the halfway mark for this season of the Clearleft podcast. Episode four came out today. It’s all about innovation.

At the beginning of the episode, I think you can hear the scorn in my voice. Y’see, innovation is one of the words—like “disruptive”—that gets thrown around a lot and everyone assumes it only has positive connotations. But words like “innovative” and “disruptive” can be applied to endeavours that are not good for the world.

Bitcoin, for example, could rightly be described as innovative (and disruptive) but it’s also a planet-destroying ponzi scheme—like a lovechild of the trolley problem and the paperclip maximizer designed to generate the most amount of waste for the least amount of value.

So, yeah, I’m not a fan of innovation for innovation’s sake. But don’t worry. For this episode of the podcast I set my personal feelings to one side and let the episode act as a conduit for much smarter people.

The whole thing clocks in at 25 minutes but I think this episode might have the widest range of contributors yet. There are snippets from an internal Clearleft discussion, soundbites from a panel discussion, extracts from conference talks, as well as interviews with individuals. From Clearleft there’s Chris How, Andy Thornton, Jon Aizlewood and Lorenzo Ferronato. From the panel discussion there’s Janna Bastow, Matt Cooper-Wright, Dorota Biniecka and Akshan Ish. And from UX Fest there’s Radhika Dutt, Teresa Torres and Gregg Bernstein.

I happily defer to their expertise on this topic. Have a listen and hear what they have to say.

Each season of the Clearleft podcast has six episodes. Three of the six episodes of the current season are available with another three still to come.

In case you missed them, the episodes of season three released so far are:

1. Coaching

   What’s the difference between training, coaching, and mentorship?

2. Design Engineering

   A role that sits at the intersection—or rather, the gap—between design and engineering.

3. Design Research

   The journey from evaluative research to generative research.

That’s quite a mixed bag. You might think that there’s no particular unifying to a season of the podcast.

Well, that’s kind of true. There’s no specific theme. But each season does have a meta-grouping.

At Clearleft, we think about our services in three interconnected categories: explore, create, and grow.

• “Explore” is all about the big strategic picture.
• “Create” is the nitty-gritty work of delivery.
• “Grow” is what connects those together.

Each season of the podcast focuses on one of those categories. This season it’s all about “explore” with a bit of “grow” thrown in.

The next three episodes of this season will double down on the big-picture thinking. I don’t want to give any spoilers, but I’ll just remind you that if you’re not already subscribed to the Clearleft podcast, I highly recommend rectifying that situation.

Subscribe via RSS, or on Apple, Google, Spotify, or wherever you get your podcasts from.

And if you’re already subscribed …thank you. If you’re enjoying listening to it half as much as I’m enjoying making it, then I’m enjoying it twice as much as you.

Seriously though, if you like what you hear, please share it around. Drop a link to the Clearleft podcast into your work Slack channel or share it in a tweet.

Thank you for listening.

We’re halfway through the third season of the Clearleft podcast already!

Episode three is all about design research. I like the narrative structure of this. It’s a bit like a whodunnit, but it’s more like a whydunnit. The “why” question is “why aren’t companies hiring more researchers?”

The scene of the crime is this year’s UX Fest, where talks by both Teresa Torres and Gregg Bernstein uncovered the shocking lack of researchers. From there, I take up the investigation with Maite Otondo and Stephanie Troeth.

I won’t spoil it but by the end there’s an answer to the mystery.

I learned a lot along the way too. I realised how many axes of research there are. There’s qualitative research (stories, emotion, and context) and then there’s quantitative research (volume and data). But there’s also evualative research (testing a hyphothesis) and generative research (exploring a problem space before creating a solution). By my count that gives four possible combos: qualitative evaluative research, quantitative evaluative research, qualitative generative research, and quantitative generative research. Phew!

Steph was a terrific guest. Only a fraction of our conversation made it into the episode, but we chatted for ages.

And Maite kind of blew my mind too, especially when she was talking about the relationship between research and design and she said:

Research is about the present and design is about the future.

🤯

I’m going to use that quote again in a future episode. In fact, this episode on design research leads directly into the next two episodes. You won’t want to miss them. So if you’re not already subscribed to the Clearleft podcast, you should get on that, whether it’s via the RSS feed, Apple, Google, Spotify, Overcast, or wherever you get your podcasts from.

Have a listen to this episode on design research and if you’re a researcher yourself, remember that unlike most companies we value research at Clearleft and that’s why we’re hiring another researcher right now. Come and work with us!

The Clearleft newsletter goes out every two weeks on a Thursday. You can peruse the archive to see past editions.

I think it’s a really good newsletter, but then again, I’m the one who writes it. It just kind of worked out that way. In theory, anyone at Clearleft could write an edition of the newsletter.

To make that prospect less intimidating, I put together a document for my colleagues describing how I go about creating a new edition of the newsletter. Then I thought it might be interesting for other people outside of Clearleft to get a peek at how the sausage is made.

So here’s what I wrote…

Topics

The description of the newsletter is:

A round-up of handpicked hyperlinks from Clearleft, covering design, technology, and culture.

It usually has three links (maybe four, tops) on a single topic.

The topic can be anything that’s interesting, especially if it’s related to design or technology. Every now and then the topic can be something that incorporates an item that’s specifically Clearleft-related (a case study, an event, a job opening). In general it’s not very salesy at all so people will tolerate the occasional plug.

You can use the “iiiinteresting” Slack channel to find potential topics of interest. I’ve gotten in the habit of popping potential newsletter fodder in there, and then adding related links in a thread.

Tone

Imagine you’re telling a friend about something cool you’ve just discovered. You can sound excited. Don’t worry about this looking unprofessional—it’s better to come across as enthusiastic than too robotic. You can put real feelings on display: anger, disappointment, happiness.

That said, you can also just stick to the facts and describe each link in turn, letting the content speak for itself.

If you’re expressing a feeling or an opinion, use the personal pronoun “I”. Don’t use “we” unless you’re specifically referring to Clearleft.

But most of the time, you won’t be using any pronouns at all:

So-and-so has written an article in such-and-such magazine on this-particular-topic.

You might find it useful to have connecting phrases as you move from link to link:

Speaking of some-specific-thing, this-other-person has a different viewpoint.

or

On the subject of this-particular-topic, so-and-so wrote something about this a while back.

Structure

The format of the newsletter is:

1. An introductory sentence or short paragraph.
2. A sentence describing the first link, ending with the title of the item in bold.
3. A link to the item on its own separate line.
4. An excerpt from the link, usually a sentence or two, styled as a quote.
5. Repeat steps 2 to 4 another two times.


Take a look through the archive of previous newsletters to get a feel for it.

Subject line

Currently the newsletter is called dConstruct from Clearleft. The subject line of every edition is in the format:

dConstruct from Clearleft — Title of the edition

(Note that’s an em dash with a space on either side of it separating the name of the newsletter and the title of the edition)

I often try to come up with a pun-based title (often a punny portmanteau) but that’s not necessary. It should be nice and short though: just one or two words.

If you’re subscribed to the Clearleft podcast, then the latest episode is winging its way through the ether to your podcast software. The topic is one close to my heart: design engineering.

I wrote about this role back in February. I think my fervour comes across in that post and you can probably hear it in the podcast episode too.

As ever, I end up asking the question, “So what exactly is insert topic of the podcast episode here?”

I’ve got some smart folks answering that question. There’s an excerpt from Tobias Ahlin’s talk at this year’s UX Fest. And when I interviewed Adekunle Oduye for a previous episode on prototyping, we also discussed design engineering so I pulled out the relevant bits. But the bulk of the episode features the voice of Trys Mudford.

As you can gather from the many posts on Trys’s blog, he has a lot to say on the topic of design engineering. Luckily for me, he says it all with a clear, articulate delivery—the perfect podcast guest!

This episode finishes with a call to action (oh, the synergy!). If, after listening to 23 minutes of discussion on design engineering, you find yourself thinking “Hey, I think I might be a design engineer!”, then you should definitely head along to this job opening at Clearleft:

We’re currently looking for a design-friendly front-end developer with demonstrable skills in pattern-based prototyping and production.

Have a listen to episode two of season three of the Clearleft podcast and if you like what you hear, come and join us!

I was doing some accessibility work with a client a little while back. It was mostly giving their site the once-over, highlighting any issues that we could then discuss. It was an audit of sorts.

While I was doing this I started to realise that not all accessibility issues are created equal. I don’t just mean in their severity. I mean that some issues can—and should—be caught early on, while other issues can only be found later.

Take colour contrast. This is something that should be checked before a line of code is written. When designs are being sketched out and then refined in a graphical editor like Figma, that’s the time to check the ratio between background and foreground colours to make sure there’s enough contrast between them. You can catch this kind of thing later on, but by then it’s likely to come with a higher cost—you might have to literally go back to the drawing board. It’s better to find the issue when you’re at the drawing board the first time.

Then there’s the HTML. Most accessibility issues here can be caught before the site goes live. Usually they’re issues of ommission: form fields that don’t have an explicitly associated label element (using the for and id attributes); images that don’t have alt text; pages that don’t have sensible heading levels or landmark regions like main and nav. None of these are particularly onerous to fix and they come with the biggest bang for your buck. If you’ve got sensible forms, sensible headings, alt text on images, and a solid document structure, you’ve already covered the vast majority of accessibility issues with very little overhead. Some of these checks can also be automated: alt text for images; labels for inputs.

Then there’s interactive stuff. If you only use native HTML elements you’re probably in the clear, but chances are you’ve got some bespoke interactivity on your site: a carousel; a mega dropdown for navigation; a tabbed interface. HTML doesn’t give you any of those out of the box so you’d need to make your own using a combination of HTML, CSS, JavaScript and ARIA. There’s plenty of testing you can do before launching—I always ask myself “What would Heydon do?”—but these components really benefit from being tested by real screen reader users.

So if you commission an accessibility audit, you should hope to get feedback that’s mostly in that third category—interactive widgets.

If you get feedback on document structure and other semantic issues with the HTML, you should fix those issues, sure, but you should also see what you can do to stop those issues going live again in the future. Perhaps you can add some steps in the build process. Or maybe it’s more about making sure the devs are aware of these low-hanging fruit. Or perhaps there’s a framework or content management system that’s stopping you from improving your HTML. Then you need to execute a plan for ditching that software.

If you get feedback about colour contrast issues, just fixing the immediate problem isn’t going to address the underlying issue. There’s a process problem, or perhaps a communication issue. In that case, don’t look for a technical solution. A design system, for example, will not magically fix a workflow issue or route around the problem of designers and developers not talking to each other.

When you commission an accessibility audit, you want to make sure you’re getting the most out of it. Don’t squander it on issues that you can catch and fix yourself. Make sure that the bulk of the audit is being spent on the specific issues that are unique to your site.

When I wrote about the new accent-color property in CSS, I pondered how much control a web developer should have over styling form controls:

Who are we to make that decision? Shouldn’t the user’s choice take primacy over our choices?

But then again, where do we draw the line? We’re allowed over-ride link colours. We’re allowed over-ride font choices.

Ultimately, I came down on the side of granting authors more control:

If developers don’t get a standardised way to customise native form controls, they’ll just recreate their own over-engineered versions.

This question of “who gets to decide?” used to be much more prevelant in the early days of the web. One way to think about this is that there are three stakeholders involved in the presentation of a web page:

1. The author of the page. “Author” is spec-speak for designer or developer.
2. The user.
3. The browser, or user agent. A piece of software tries to balance the needs of both author and user. But, as the name implies, the user takes precedence.

These days we tend to think of web design a single-stakeholder undertaking. The author decides how something should be presented and then executes that decision using CSS.

But as Eric once said, every line of you CSS you write is a suggestion to the browser. That’s not how we think about CSS though. We think of CSS like a series of instructions rather than suggestions. Never mind respecting the user’s preferences; one of the first things we do is reset all the user agent’s styles.

In the early days of the web, more consideration was given to the idea of style suggestions rather than instructions. Heck, users could always over-ride any of your suggestions with their own user stylesheet. These days, users would need to install a browser extension to do the same thing.

The first proposal for CSS had a concept called “influence”:

h2.font.size = 20pt 40%

Here, the requested influence is reduced to 40%. If a style sheet later in the cascade also requests influence over h2.font.size, up to 60% can be granted. When the document is rendered, a weighted average of the two requests is calculated, and the final font size is determined.

I think the only remnant of “influence” left in CSS is accidental. It’s in the specificity of selectors …and the !important declaration.

I think it’s a shame that user stylesheets are no longer a thing. But I get why they were dropped from browsers. They date from a time when it was mostly nerds using the web, before “regular folks” came on board. I understand why it became a little-used feature, suitable for being dropped. But the principle of it still rankles slightly.

But in recent years there has been a slight return to the multi-stakeholder concept of styling websites. Thanks to prefers-reduced-motion and prefers-color-scheme, a responsible author can choose to bow to the wishes of the user.

I was reminded of this when I added a dark mode to my website:

Y’know, when I first heard about Apple adding dark mode to their OS—and also to CSS—I thought, “Oh, great, Apple are making shit up again!” But then I realised that, like user style sheets, this is one more reminder to designers and developers that they don’t get the last word—users do.

Whenever a new version of Chrome comes out, there’s an accompanying blog post listing what’s new. Chrome 93 just came out and, sure enough, Pete has written a blog post about it.

But what I think is the most exciting addition to the browser isn’t listed.

What is this feature that’s got me so excited?

Okay, I’ve probably oversold it now because actually, it looks like a rather small trivial addition. It’s the accent-color property in CSS.

Up until now, accent colour was controlled by the operating system. If you’re on a Mac, go to “System Preferences” and then “General”. There you’ll see an option to change your accent colour. Try picking a different colour. You’ll see that change cascade down into the other form fields in that preference pane: checkboxes, radio buttons, and dropdowns.

Your choice will also cascade down into web pages. Any web page that uses native checkboxes, radio buttons and other interface elements will inherit that colour.

This is how interface elements are supposed to work. The browser inherits the look’n’feel of the inputs from the operating system.

That’s the theory anyway. In practice, form elements—such as dropdowns—can look different from browser to browser, something that shouldn’t be happening if the browsers are all inheriting from the operating system.

Anyway, it’s probably this supposed separation of responsibility between browser and operating system which has led to the current situation with form fields and CSS. Authors can style form fields up to a point, but there’s always a line that you don’t get to cross.

The accent colour of a selected radio button or a checkbox has historically been on the other side of that line. You either had to accept that you couldn’t change the colour, or you had to make your own checkbox or radio button interface. You could use CSS to hide the native element and replace it with an image instead.

That feels a bit over-engineered and frankly kind of hacky. It reminds me of the bad old days of image replacement for text before we had web fonts.

Now, with the accent-color property in CSS, authors can over-ride the choice that the user has set at the operating system level.

On the one hand, this doesn’t feel great to me. Who are we to make that decision? Shouldn’t the user’s choice take primacy over our choices?

But then again, where do we draw the line? We’re allowed over-ride link colours. We’re allowed over-ride font choices.

Ultimately I think it’s a good thing that authors can now specify an accent colour. What makes me think that is the behaviour that authors have shown if they don’t have this ability—they do it anyway, and in a hackier manner. This is why I think the work of the Open UI group is so important. If developers don’t get a standardised way to customise native form controls, they’ll just recreate their own over-engineered versions.

The purpose of Open UI to the web platform is to allow web developers to style and extend built-in web UI controls, such as select dropdowns, checkboxes, radio buttons, and date/color pickers.

Trying to stop developers from styling checkboxes and radio buttons is like trying to stop teenagers from having sex. You might as well accept that it’s going to happen and give them contraception so they can at least do it safely.

So I welcome this new CSS condom.

You can see accent-color in action in this demo. Change the value of the accent-color property to see the form fields update:

:root {
  accent-color: rebeccapurple;
}

Applying it at the document level like that will make it universal, but you can also use the property on an element-by-element basis using whatever selector you want.

That demo works in Chrome and Edge 93, the current release. It also works in Firefox 92, which literally just landed (like as I was writing this blog post, support for accent-color magically arrived!).

As for Safari, well, who knows? If Apple published a roadmap, then developers would have a clue when to expect a property like this to land. But we mere mortals cannot be trusted with such important hush-hush information.

In the meantime, keep an eye on Can I Use. And lack of support on one browser is no reason not to use accent-color anyway. It’s a progressive enhancement. Add it to your CSS today and it will work in more browsers in the future.

Season three of the Clearleft podcast is here!

The first episode is a nice gentle one to ease into things. It’s about coaching …and training …and mentorship. Basically I wanted to find out what the differences are between those three things.

But I must confess, there’s a commercial reason why this episode is coming out now. There’s a somewhat salesy promotion of an upcoming coaching programme with Julia Whitney. This is definitely the most overt marketing I’ve done on the Clearleft podcast, but if you listen to the episode, I think you’ll agree that it fits well with the theme.

Fear not, future episodes will not feature this level of cross-promotion. Far from it. You can expect some very revealing podcast episodes that pull no punches in getting under the skin of design at Clearleft.

The stars of this episode are my colleagues Rebecca and Chris, who were an absolute joy to interview.

Have a listen and hear for yourself.

If you’re not already subscribed to the Clearleft podcast, you should probably remedy that. The third season is about to drop any day now.

Once again, the season will comprise six episodes released on a weekly schedule.

That’s a cadence I more or less picked at random, but I think it’s working out well. Six episodes are enough for the podcast to sustain your interest without overstaying its welcome. And by taking nice long breaks between seasons, you’re never going to end up with that podcast problem of having a backlog of episodes that you never seem to get around to listening to.

That said, if you did fancy going through the backlog, there’s a mere twelve episodes for you to catch up on. Six from season one and six from season two. None of the episodes are overly long. Again, I don’t want this podcast to overstay its welcome. I respect your time. A typical episode is somewhere between 20 and 25 minutes of multiple viewpoints and voices.

You can subscribe to the RSS feed or use whichever service you prefer to get your podcasts from: Apple, Google, Spotify, Stitcher, Deezer, TuneIn, Castro, Pocket Casts, Player FM, or my own personal choice, Overcast.

Or you could just huffduff whichever episodes sound most appealing to you. But honestly, and I may be biased here, they’re all pretty darn great so I recommend subscribing.

If you subscribe now, then the episodes from season three will magically appear in your podcast software of choice. Again, I know I’m biased, but this is going to be an excellent season featuring some very smart folks sharing their stories.

Just to be clear, in case you haven’t listened to the Clearleft podcast before, this isn’t your usual podcast format. Yes, I interview people but I don’t release one interview per episode. Instead, each episode zeroes in one topic, and features different opinions from different people. It’s tight and snappy with no filler. That involves a lot of production and editing work, but I think it’s worth it for the end result.

Can you tell that I’m excited?

I went and spoke at an actual real live conference. As expected, it felt good …and weird. All at the same time.

It felt strange to be inside a building with other humans sharing an experience. At times it felt uncomfortable. The speaker’s dinner the night before the conference was lovely …and anxiety-inducing. Not just because it was my first time socialising in ages, but also just because it was indoors. I’ve been avoid indoor dining.

But the travel to Zürich all went smoothly. The airport wasn’t too busy. And on the airplane, everyone was dutifully masked up.

There’s definitely more paperwork and logistics involved in travelling overseas now. Jessica and I had to fill in our passenger locator forms for Switzerland and the UK. We also needed to pre-book a Covid test for two days after we got back. And we had to get a Covid test while we were in Switzerland so that we could show a negative result on returning to England. It doesn’t matter if you’re double-vaccinated; these tests are mandatory, which is totally fair.

Fortunately the conference organisers took care of booking those tests, which was great. On the first day of the conference I ducked out during the first break to go to the clinic next door and have a swab shoved up my nose. Ten minutes later I was handed a test result—negative!—complete with an official-looking stamp on it.

Two days later, after the conference was over, we had time to explore Zürich before heading to the airport to catch our evening flight. We had a very relaxing day which included a lovely boat trip out on the lake.

It was when we got to the airport that the relaxation ended.

We showed up at the airport in loads of time. I subscribe to the Craig Mod school of travel anyway, but given The Situation, I wanted to make sure we accounted for any extra time needed.

We went through security just fine and waited around for our gate to come up on the screen of gates and flights. Once we had a gate, we made our way there. We had to go through passport control but that didn’t take too long.

At the gate, there was a queue so—being residents of England—we immediately got in line. The airline was checking everyone’s paperwork.

When we got to the front of the line, we showed all our documents. Passport? Check. Boarding pass? Check. Passenger locator form? Check. Negative Covid result? Che …wait a minute, said the member of staff, this is in German. According to gov.uk, the test result needs to be in English, French, or Spanish.

I looked at the result. Apart from the heading at the top, all of the actual information was international: names, dates, and the test result itself said “neg.”

Not good enough.

My heart sank. “Call or email the clinic where you got the result. Get them to send you an English or French version” said the airline representative. Okay. We went off to the side and started doing that.

At this point there was still a good 40 or 50 minutes ’till the flight took off. We could sort this out.

I phoned the clinic. It was late Saturday afternoon and the clinic was closed. Shit!

Jessica and I went back to the gate agent we were dealing with and began pleading our case (in German …maybe that would help). She was very sympathetic but her hands were tied. Then she proposed a long shot. There was a Covid-testing centre in the airport. She would call them and tell them we were coming. But at this point it was 35 minutes until the flight left. We’d really have to leg it.

She scribbled down vague directions for where we had to go, and we immediately pelted off.

At this point I feel I should confess. I did not exhibit grace under pressure. I was, to put it mildy, freaking out.

Perhaps because I was the one selfishly indulging in panic, Jessica kept her head. She reminded me that we weren’t travelling to a conference—there wasn’t anywhere we had to be. Worst case scenario, we’d have to spend an extra night in Zürich and get a different flight tomorrow. She was right. I needed to hear that.

I was still freaking out though. We were running around like headless chickens trying to find where we needed to go. The instructions had left out the crucial bit of information that we actually needed to exit through passport control (temporarily re-entering Swiss territory) in order to get to the testing centre. Until we figured that out, we were just running hither and tither in a panic while the clock continued to count down.

It was a nightmare. I don’t mean that figuratively. I mean, I’m pretty sure I’ve had this exact nightmare. I’m in a building with a layout I don’t know and I need to get somewhere urgently but I don’t know how to get there.

Even the reason for this panicked situation felt like it had a dream logic to it. You know when you wake up from a bad dream and you examine the dream in retrospect and you realise it doesn’t actually make any sense? Well, that’s how this felt. You’ve got a negative test result but it needs it to be in one of these three languages …I mean, that sounds like the kind of nonsensical reasoning that should dissolve upon awakening.

Time was slipping away. Our flight leaves in twenty minutes.

Finally we realise that we need to go back through passport control. On the other side we run around some more until we spot the location that matches the vague description we’ve been given. There’s a sign! Covid testing centre!

We burst in through the doors. The gate agent had called ahead so we were expected. The young doctor on duty was cool as a cucumber. He must have to deal with this situation all day long. He calmly got us both to start filling in the appropriate online forms to pay for the tests, but instead of waiting for us to finish doing that, he started the testing straight away. Smart!

This felt like another nightmare I’ve had. I don’t mean having a swab shoved up my nose until it tickles my brain—that was probably the least uncomfortable part of this whole ordeal. I mean I need to fill out this web form accurately. On a touch screen device. And do it as quickly as possible!

Well, we did it. Filled in the forms, got the swabs. But now it was less than fifteen minutes until our flight time and we knew we still had to get back through passport control where there were lines of people.

“You’ll have the test results by email in ten minutes,” said the doctor. “Go!”

We sprinted out of there and went straight for the passport lines. Swallowing my pride, I went to the people at the end of a line. “Our flight leaves in ten minutes! Can we please cut in front!?”

“No.”

Right, next line. “Our flight leaves in…”

“Yes, yes! Go!”

“Thank you! Thank you so much!”

We repeated this craven begging until we got to the front of the line and gave our passports to the same guy who had orginally stamped them first time we came through. He was unfazed.

Then we ran back to the gate. Almost everyone had boarded by this point, but the gate was still open. Maybe we could actually make it!

But we still needed our test results. We both stood at the gate with our phones in hand, the email app open, frantically pulling to refresh.

The minutes were ticking by. At this point the flight departure time had arrived, but the gate agent said there was a slight delay. They could wait one or two minutes more.

Pull, refresh. Pull, refresh.

“I’ve got mine!” shouted Jessica. Half a minute later, mine showed up.

We showed the gate agent the results. She stamped whatever needed to be stamped and we were through.

I couldn’t believe it! Just 15 minutes ago I had been thinking we might as well give up—there was absolutely no way we were going to make it.

But here we were boarding the plane.

We got to our seats and strapped in. We were both quite sweaty and probably looked infectious …but we also had fresh proof that neither of had the ’rona.

We just sat there smiling, looking at each other, and shaking our heads. I just couldn’t believe we had actually made it.

The captain made an announcement. They were having a little technical difficulty with the plane’s system—no doubt the cause of the slight delay, luckily for us. They were going to reboot the system in the time-honoured fashion of turning it off and again.

The lights briefly went out and then came back on as the captain executed this manouvre.

Meanwhile Jessica and I were coming down from our adrenaline rush. Our breathing was beginning to finally slow down.

The captain’s voice came on again. That attempt at fixing the glitch hadn’t worked. So to play it safe, we were going to switch planes. The new plane would take off in an hour and a half from a different gate.

As the other passengers tutted and muttered noises of disapproval, Jessica and I just laughed. A delay? No problem!

But oh, the Alanis Morissette levels of irony! After all that stress at the mercy of the ticking clock, it turned out that time was in plentiful supply after all.

Everything after that proceeded without incident. We got on the replacement plane. We flew back to England. We breezed across the border and made our way home.

It felt good to be home.