Jeremy Keith's Blog, page 44

Prediction

Arthur C. Clarke once said:

Trying to predict the future is a discouraging and hazardous occupation becaue the profit invariably falls into two stools. If his predictions sounded at all reasonable, you can be quite sure that in 20 or most 50 years, the progress of science and technology has made him seem ridiculously conservative. On the other hand, if by some miracle a prophet could describe the future exactly as it was going to take place, his predictions would sound so absurd, so far-fetched, that everybody would laugh him to scorn.

But I couldn���t resist responding to a recent request for augery. Eric asked An Event Apart speakers for their predictions for the coming year. The responses have been gathered together and published, although it���s in the form of a PDF for some reason.

Here���s what I wrote:

This is probably more of a hope than a prediction, but 2021 could be the year that the ponzi scheme of online tracking and surveillance begins to crumble. People are beginning to realize that it���s far too intrusive, that it just doesn���t work most of the time, and that good ol���-fashioned contextual advertising would be better. Right now, it feels similar to the moment before the sub-prime mortgage bubble collapsed (a comparison made in Tim Hwang���s recent book, Subprime Attention Crisis). Back then people thought ���Well, these big banks must know what they���re doing,��� just as people have thought, ���Well, Facebook and Google must know what they���re doing���…but that confidence is crumbling, exposing the shaky stack of cards that props up behavioral advertising. This doesn���t mean that online advertising is coming to an end���far from it. I think we might see a golden age of relevant, content-driven advertising. Laws like Europe���s GDPR will play a part. Apple���s recent changes to highlight privacy-violating apps will play a part. Most of all, I think that people will play a part. They will be increasingly aware that there���s nothing inevitable about tracking and surveillance and that the web works better when it respects people���s right to privacy. The sea change might not happen in 2021 but it feels like the water is beginning to swell.

Still, predicting the future is a mug���s game with as much scientific rigour as astrology, reading tea leaves, or haruspicy.

Much like behavioural advertising.

Design leadership on the Clearleft podcast

What rough beast, its hour come round at last, slouches towards your podcast player of choice to be reborn?

Why it���s season two of the Clearleft podcast!

Yes, it���s that time again when you can treat your earholes to six episodes of condensed discussion on design-related topics at a rate of one episode per week.

The first episode of season two is all about design leadership. This was a lot of fun to put together. I was able to mine the rich seam of talks from the past few years of Leading Design conferences. I found some great soundbites from Jane Austin and Hannah Donovan. I was also able to include the audio from a roundtable discussion at Clearleft. These debates are a regular occurrence at the UX laundromat, where we share what we���re working on. I should record them more often. There was some quality ranting from Jon, Andy, and Chris.

Best of all, I interviewed Temi Adeniyi, a brilliant design leader based in Berlin. Hearing her journey was fascinating. She���s going to be speaking at this year���s online Leading Design Festival too.

I think you���ll enjoy this episode if you are:

a designer thinking about becoming a design leader,a designer who wants to remain an individual contributor, ora design leader who was once a hands-on designer.

Actually, the lessons here probably apply regardless of your field. Engineers and lead developers will probably relate to the quandaries raised.

The whole thing clocks in at just over 21 minutes.

Have a listen and see what you think. And if you like what you hear, be sure to share the Clearleft podcast with your friends and co-workers. Go on���drop it in a Slack channel.

If you���re not already subscribed to the podcast, you might want to pop the RSS feed into your podcast player.

Sanguine nation

I have mostly been inside one building for the best part of a year. I have avoided going inside of any other buildings during that time. I have made the occasional foray into shop buildings but rarely and briefly.

Last week I went into another building. But it was probably the safest building to enter. I was there to give blood. Masking and distancing were the order of the day.

I try to give blood whenever I can. Before The Situation, my travelling lifestyle made this difficult. It was tricky to book in advance when I didn���t know if I���d be in the country. And sometimes the destinations I went to prevented me from giving blood on my return.

Well, that���s all changed! For the past year I���ve been able to confidently make blood donation appointments knowing full well that I wasn���t going to be doing any travelling.

On video calls recently, a few people have remarked on how long my hair is now. I realised that in the past year I���ve gone to give blood more often than I���ve been to the hairdresser. Three nill, if you���re keeping score.

But why not do both? A combined haircut and blood donation.

Think about it. In both situations you have to sit in a chair doing nothing for a while.

I realise that the skillsets don���t overlap. Either barbers would need to be trained in the art of finding a vein or health workers would need to be trained in the art of cutting hair while discussing last night���s match and whether you���re going anywhere nice this year.

Anything that encourages more blood donations is good in my books. Perhaps there are other establishments that offer passive sitting activities that could be combined with the donation process.

Nail salons? You could get one hand manicured while donating blood from the other arm.

Libraries and book shops? Why not have a combined book-reading and blood donation? Give a pint and get a signed copy.

Airplanes? You���re stuck in a seat for a few hours anyway. Might as well make it count.

Dentists? Maybe that���s too much multitasking with different parts of the body.

But what about dentistry on airplanes? Specifically the kind of dentistry that requires sedation. The infrastructure is already in place: there are masks above every seat. Shortly after take off, pull the mask towards you and let the nitrous oxide flow. Even without any dentistry, that sounds like a reasonable way to make the hours stuck in an airplane just fly by.

None of us are going to be taking any flights any time soon, but when we do …build back better, I say.

In the meantime, give blood.

Authentication

Two-factor authentication is generally considered A Good Thing������ when you���re logging in to some online service.

The word ���factor��� here basically means ���kind��� so you���re doing two kinds of authentication. Typical factors are:

Something you know (like a password),Something you have (like a phone or a USB key),Something you are (biometric Black Mirror shit).

Asking for a password and an email address isn���t two-factor authentication. They���re two pieces of identification, but they���re the same kind (something you know). Same goes for supplying your fingerprint and your face: two pieces of information, but of the same kind (something you are).

None of these kinds of authentication are foolproof. All of them can change. All of them can be spoofed. But when you combine factors, it gets a lot harder for an attacker to breach both kinds of authentication.

The most common kind of authentication on the web is password-based (something you know). When a second factor is added, it���s often connected to your phone (something you have).

Every security bod I���ve talked to recommends using an authenticator app for this if that option is available. Otherwise there���s SMS���short message service, or text message to most folks���but SMS has a weakness. Because it���s tied to a phone number, technically you���re only proving that you have access to a SIM (subscriber identity module), not a specific phone. In the US in particular, it���s all too easy for an attacker to use social engineering to get a number transferred to a different SIM card.

Still, authenticating with SMS is an option as a second factor of authentication. When you first sign up to a service, as well as providing the first-factor details (a password and a username or email address), you also verify your phone number. Then when you subsequently attempt to log in, you input your password and on the next screen you���re told to input a string that���s been sent by text message to your phone number (I say ���string��� but it���s usually a string of numbers).

There���s an inevitable friction for the user here. But then, there���s a fundamental tension between security and user experience.

In the world of security, vigilance is the watchword. Users need to be aware of their surroundings. Is this web page being served from the right domain? Is this email coming from the right address? Friction is an ally.

But in the world of user experience, the opposite is true. ���Don���t make me think��� is the rallying cry. Friction is an enemy.

With SMS authentication, the user has to manually copy the numbers from the text message (received in a messaging app) into a form on a website (in a different app���a web browser). But if the messaging app and the browser are on the same device, it���s possible to improve the user experience without sacrificing security.

If you���re building a form that accepts a passcode sent via SMS, you can use the autocomplete attribute with a value of ���one-time-code���. For a six-digit passcode, your input element might look something like this:

With one small addition to one HTML element, you���ve saved users some tedious drudgery.

There���s one more thing you can do to improve security, but it���s not something you add to the HTML. It���s something you add to the text message itself.

Let���s say your website is example.com and the text message you send reads:

Your one-time passcode is 123456.

Add this to the end of the text message:

@example.com #123456

So the full message reads:

Your one-time passcode is 123456.@example.com #123456

The first line is for humans. The second line is for machines. Using the @ symbol, you���re telling the device to only pre-fill the passcode for URLs on the domain example.com. Using the # symbol, you���re telling the device the value of the passcode. Combine this with autocomplete="one-time-code" in your form and the user shouldn���t have to lift a finger.

I���m fascinated by these kind of emergent conventions in text messages. Remember that the @ symbol and # symbol in Twitter messages weren���t ideas from Twitter���they were conventions that users started and the service then adopted.

It���s a bit different with the one-time code convention as there is a specification brewing from representatives of both Google and Apple.

Tess is leading from the Apple side and she���s got another iron in the fire to make security and user experience play nicely together using the convention of the /.well-known directory on web servers.

You can add a URL for /.well-known/change-password which redirects to the form a user would use to update their password. Browsers and password managers can then use this information if they need to prompt a user to update their password after a breach. I���ve added this to The Session.

Oh, and on that page where users can update their password, the autocomplete attribute is your friend again:

If you want them to enter their current password first, use this:

All of the things I���ve mentioned���the autocomplete attribute, origin-bound one-time codes in text messages, and a well-known URL for changing passwords���have good browser support. But even if they were only supported in one browser, they���d still be worth adding. These additions do absolutely no harm to browsers that don���t yet support them. That���s progressive enhancement.

In the zone

I went to art college in my younger days. It didn���t take. I wasn���t very good and I didn���t work hard. So I dropped out before they could kick me out.

But I remember one instance where I actually ended up putting in more work than my fellow students���an exceptional situation.

In the first year of art college, we did a foundation course. That���s when you try a bit of everything to help you figure out what you want to concentrate on: painting, sculpture, ceramics, printing, photography, and so on. It was a bit of a whirlwind, which was generally a good thing. If you realised you really didn���t like a subject, you didn���t have to stick it out for long.

One of those subjects was animation���a relatively recent addition to the roster. On the first day, the tutor gave everyone a pack of typing paper: 500 sheets of A4. We were told to use them to make a piece of animation. Put something on the first piece of paper. Take a picture. Now put something slightly different on the second piece of paper. Take a picture of that. Repeat another 498 times. At 24 frames a second, the result would be just over 20 seconds of animation. No computers, no mobile phones. Everything by hand. It was so tedious.

And I loved it. I ended up asking for more paper.

(Actually, this was another reason why I ended up dropping out. I really, really enjoyed animation but I wasn���t able to major in it���I could only take it as a minor.)

I remember getting totally absorbed in the production. It was the perfect mix of tedium and creativity. My mind was simultaneously occupied and wandering free.

Recently I���ve been re-experiencing that same feeling. This time, it���s not in the world of visuals, but of audio. I���m working on season two of the Clearleft podcast.

For both seasons and episodes, this is what the process looks like:

Decide on topics. This will come from a mix of talking to Alex, discussing work with my colleagues, and gut feelings about what might be interesting.Gather material. This involves arranging interviews with people; sometimes co-workers, sometimes peers in the wider industry. I also trawl through the archives of talks from Clearleft conferences for relevent presentations.Assemble the material. This is where I���m chipping away at the marble of audio interviews to get at the nuggets within. I play around with the flow of themes, trying different juxtapositions and narrative structures.Tie everything together. I add my own voice to introduce the topic and segue from point to point.Release. I upload the audio, update the RSS feed, and publish the transcript.

Lots of podcasts (that I really enjoy) stop at step two: record a conversation and then release it verbatim. Job done.

Being a glutton for punishment, I wanted to do more of an amalgamation for each episode, weaving multiple conversations together.

Right now I���m in step three. That���s where I���ve found the same sweet spot that I had back in my art college days. It���s somewhat mindless work, snipping audio waveforms and adjusting volume levels. At the same time, there���s the creativity of putting those audio snippets into a logical order. I find myself getting into the zone, losing track of time. It���s the same kind of flow state you get from just the right level of coding or design work. Normally this kind of work lends itself to having some background music, but that���s not an option with podcast editing. I���ve got my headphones on, but my ears are busy.

I imagine that is what life is like for an audio engineer or producer.

When I first started the Clearleft podcast, I thought I would need to use GarageBand for this work, arranging multiple tracks on a timeline. Then I discovered Descript. It���s been an enormous time-saver. It���s like having GarageBand and a text editor merged into one. I can see the narrative flow as a text document, as well as looking at the accompanying waveforms.

Descript isn���t perfect. The transcription accuracy is good enough to allow me to search through my corpus of material, but it���s not accurate enough to publish as is. Still, it gives me some nice shortcuts. I can elimate ums and ahs in one stroke, or shorten any gaps that are too long.

But even with all those conveniences, this is still time-consuming work. If I spend three or four hours with my head down sculpting some audio and I get anything close to five minutes worth of usable content, I consider it time well spent.

Sometimes when I���m knee-deep in a piece of audio, trimming and arranging it just so to make a sentence flow just right, there���s a voice in the back of my head that says, ���You know that no one is ever going to notice any of this, don���t you?��� I try to ignore that voice. I mean, I know the voice is right, but I still think it���s worth doing all this fine tuning. Even if nobody else knows, I���ll have the satisfaction of transforming the raw audio into something a bit more polished.

If you aren���t already subscribed to the RSS feed of the Clearleft podcast, I recommend adding it now. New episodes will start showing up …sometime soon.

Yes, I���m being a little vague on the exact dates. That���s because I���m still in the process of putting the episodes together.

So if you���ll excuse me, I need to put my headphones on and enter the zone.

Letters of exclusion

I think my co-workers are getting annoyed with me. Any time they use an acronym or initialism���either in a video call or Slack���I ask them what it stands for. I���m sure they think I���m being contrarian.

The truth is that most of the time I genuinely don���t know what the letters stand for. And I���ve got to that age where I don���t feel any inhibition about asking ���stupid��� questions.

But it���s also true that I really, really dislike acronyms, initialisms, and other kinds of jargon. They���re manifestations of gatekeeping. They demarcate in-groups from outsiders.

Of course if you���re in a conversation with an in-group that has the same background and context as you, then sure, you can use acronyms and initialisms with the confidence that there���s a shared understanding. But how often can you be that sure? The more likely situation���and this scales exponentially with group size���is that people have differing levels of inside knowledge and experience.

I feel sorry for anyone trying to get into the field of web performance. Not only are there complex browser behaviours to understand, there���s also a veritable alphabet soup of initialisms to memorise. Here���s a really good post on web performance by Harry, but notice how the initialisms multiply like tribbles as the post progresses until we���re talking about using CWV metrics like LCP, FID, and CLS���alongside TTFB and SI���to look at PLPs, PDPs, and SRPs. And fair play to Harry; he expands each initialism the first time he introduces it.

But are we really saving any time by saying FID instead of first input delay? I suspect that the only reason why the word ���cumulative��� precedes ���layout shift��� is just to make it into the three-letter initialism CLS.

Still, I get why initialisms run rampant in technical discussions. You can be sure that most discussions of particle physics would be incomprehensible to outsiders, not necessarily because of the concepts, but because of the terminology.

Again, if you���re certain that you���re speaking to peers, that���s fine. But if you���re trying to communicate even a little more widely, then initialisms and abbreviations are obstacles to overcome. And once you���re in the habit of using the short forms, it gets harder and harder to apply context-shifting in your language. So the safest habit to form is to generally avoid using acronyms and initialisms.

Unnecessary initialisms are exclusionary.

Think about on-boarding someone new to your organisation. They���ve already got a lot to wrap their heads around without making them figure out what a TAM is. That���s a real example from Clearleft. We have a regular Thursday afternoon meeting. I call it the Thursday afternoon meeting. Other people ���don���t.

I���m trying���as gently as possible���to ensure we���re not being exclusionary in our language. My co-workers indulge me, even it���s just to shut me up.

But here���s the thing. I remember many years back when a job ad went out on the Clearleft website that included the phrase ���culture fit���. I winced and explained why I thought that was a really bad phrase to use���one that is used as code for ���more people like us���. At the time my concerns were met with eye-rolls and chuckles. Now, as knowledge about diversity and inclusion has become more widespread, everyone understands that using a phrase like ���culture fit��� can be exclusionary.

But when I ask people to expand their acronyms and initialisms today, I get the same kind of chuckles. My aversion to abbreviations is an eccentric foible to be tolerated.

But this isn���t about me.

Get safe

The verbs of the web are GET and POST. In theory there���s also PUT, DELETE, and PATCH but in practice POST often does those jobs.

I���m always surprised when front-end developers don���t think about these verbs (or request methods, to use the technical term). Knowing when to use GET and when to use POST is crucial to having a solid foundation for whatever you���re building on the web.

Luckily it���s not hard to know when to use each one. If the user is requesting something, use GET. If the user is changing something, use POST.

That���s why links are GET requests by default. A link ���gets��� a resource and delivers it to the user.

Most forms use the POST method becuase they���re changing something���creating, editing, deleting, updating.

But not all forms should use POST. A search form should use GET.

When a user performs a search, they���re still requesting a resource (a page of search results). It���s just that they need to provide some specific details for the GET request. Those details get translated into a query string appended to the URL specified in the action attribute.

/search?term=value

I sometimes see the GET method used incorrectly:

���Log out��� links that should be forms with a ���log out��� button���you can always style it to look like a link if you want.���Unsubscribe��� links in emails that immediately trigger the action of unsubscribing instead of going to a form where the POST method does the unsubscribing. I realise that this turns unsubscribing into a two-step process, which is a bit annoying from a usability point of view, but a destructive action should never be baked into a GET request.

When the it was first created, the World Wide Web was stateless by design. If you requested one web page, and then subsequently requested another web page, the server had no way of knowing that the same user was making both requests. After serving up a page in response to a GET request, the server promptly forgot all about it.

That���s how web browsing should still work. In fact, it���s one of the Web Platform Design Principles: It should be safe to visit a web page:

The Web is named for its hyperlinked structure. In order for the web to remain vibrant, users need to be able to expect that merely visiting any given link won���t have implications for the security of their computer, or for any essential aspects of their privacy.

The expectation of safe stateless browsing has been eroded over time. Every time you click on a search result in Google, or you tap on a recommended video in YouTube, or���heaven help us���you actually click on an advertisement, you just know that you���re adding to a dossier of your online profile. That���s not how the web is supposed to work.

Don���t get me wrong: building a profile of someone based on their actions isn���t inherently wrong. If a user taps on ���like��� or ���favourite��� or ���bookmark���, they are actively telling the server to perform an update (and so those actions should be POST requests). But do you see the difference in where the power lies? With POST actions���fave, rate, save���the user is in charge. With GET requests, no one is supposed to be in charge���it���s meant to be a neutral transaction. Alas, the reality of today���s web is that many GET requests give more power to the dossier-building servers at the expense of the user���s agency.

The very first of the Web Platform Design Principles is Put user needs first:

If a trade-off needs to be made, always put user needs above all.

The current abuse of GET requests is damage that the web needs to route around.

Browsers are helping to a certain extent. Most browsers have the concept of private browsing, allowing you some level of statelessness, or at least time-limited statefulness. But it���s kind of messed up that private browsing is the exception, while surveillance is the default. It should be the other way around.

Firefox and Safari are taking steps to reduce tracking and fingerprinting. Rejecting third-party coookies by default is a good move. I���d love it if third-party JavaScript were also rejected by default:

In retrospect, it seems unbelievable that third-party JavaScript is even possible. I mean, putting arbitrary code���that can then inject even more arbitrary code���onto your website? That seems like a security nightmare!

I imagine if JavaScript were being specced today, it would almost certainly be restricted to the same origin by default.

Chrome has different priorities, which is understandable given that it comes from a company with a business model that is currently tied to tracking and surveillance (though it needn���t remain that way). With anti-trust proceedings rumbling in the background, there���s talk of breaking up Google to avoid monopolistic abuses of power. I honestly think it would be the best thing that could happen to Chrome if it were an independent browser that could fully focus on user needs without having to consider the surveillance needs of an advertising broker.

But we needn���t wait for the browsers to make the web a safer place for users.

Developers write the code that updates those dossiers. Developers add those oh-so-harmless-looking third-party scripts to page templates.

What if we refused?

Front-end developers in particular should be the last line of defence for users. The entire field of front-end devlopment is supposed to be predicated on the prioritisation of user needs.

And if the moral argument isn���t enough, perhaps the technical argument can get through. Tracking users based on their GET requests violates the very bedrock of the web���s architecture. Stop doing that.

My typical day

Colin wrote about his typical day and suggested I do the same.

Y���know, in the Before Times I think this would���ve been trickier. What with travelling and speaking, I didn���t really have a ���typical��� day ���and I liked it that way. Now, thanks to The Situation, my days are all pretty similar.

8:30am ��� This is the time I���ve set my alarm for, but sometimes I wake up a bit earlier. I get up, fire up the coffee machine, go to the head and empty my bladder. Maybe I���ll have a shower.9am ��� I fire up email and Slack, wishing my co-workers a good morning. Over the course of each day, I���ve usually got short 1:1s booked in with two or three of my colleagues. Just fifteen minutes or so to catch up and find out what they���re working on, what���s interesting, what���s frustrating. The rest of the time, I���ll probably be working on the Clearleft podcast.1pm ��� Lunch time. Jessica takes her lunch break at the same time. We���ll usually have a toasted sandwich or a bowl of noodles. While we eat, Jessica will quiz me with the Learned League questions she���s already answered that morning. I get all the fun of testing my knowledge without the pressure of competing.2pm ��� If the weather���s okay, we might head out for a brisk walk, probably to the nearby park where we can watch good doggos. Otherwise, it���s back to the podcast mines. I���ve already amassed a fair amount of raw material from interviews, so I���m spending most of my time in Descript, crafting and editing each episode. In about three hours of work, I reckon I get four or five minutes of good audio together. I should really be working on my upcoming talk for An Event Apart too, but I���m procrastinating. But I���m procrastinating by doing the podcast, so I���ve kind of tricked myself into doing something I���m supposed to be doing by avoiding something else I���m supposed to be doing.Sometime between 5pm and 6pm ��� I knock off work. I pick up my mandolin and play some tunes. If Jessica���s done with work too, we play some tunes together.7pm ��� If it���s a Tuesday or Thursday, then it���s a ballet night for Jessica. While she���s in the kitchen doing her class online, I chill out in the living room, enjoying a cold beer, listening to some music with headphones on, and doing some reading or writing. I might fire up NetNewsWire and read the latest RSS updates from my friends, or I might write a blog post.8pm ��� If it is a ballet night, then dinner will be something quick and easy to prepare; probably pasta. Otherwise there���s more time to prepare something with care and love. Jessica is the culinary genius so my contributions are mostly just making sure she���s got her mise en place ahead of time, and cleaning up afterwards. I choose a bottle of wine and set the table, and then we sit down to eat together. It is definitely the highlight of the day.9pm ��� After cleaning up, I make us both cups of tea and we settle in on the sofa to watch some television. Not broadcast television; something on the Apple TV from Netflix, Amazon Prime, Disney+, or BBC iPlayer most likely. If we���re in the right mood, we���ll watch a film.Sometime between 11pm and midnight ��� I change into my PJs, brush and floss my teeth, and climb into bed with a good book. When I feel my eyelids getting heavy, I switch off the light and go to sleep. That���s where I���m a Viking!

That���s a typical work day. My work week is Monday to Thursday. I switched over to a four-day week when The Situation hit, and now I don���t ever want to go back. It means making less money, but it���s worth it for a three day weekend.

My typical weekend involves more mandolin playing, more reading, more movies, and even better meals. I���ll also do some chores: clean the floors; back up my data.

Speaking online

I really, really missed speaking at conferences in 2020. I managed to squeeze in just one meatspace presentation before everything shut down. That was in Nottingham, where myself and Remy reprised our double-bill talk, How We Built The World Wide Web In Five Days.

That was pretty much all the travelling I did in 2020, apart from a joyous jaunt to Galway to celebrate my birthday shortly before the Nottingham trip. It���s kind of hilarious to look at a map of the entirety of my travel in 2020 compared to previous years.

Mind you, one of my goals for 2020 was to reduce my carbon footprint. Mission well and truly accomplished there.

But even when travel was out of the question, conference speaking wasn���t entirely off the table. I gave a brand new talk at An Event Apart Online Together: Front-End Focus in August. It was called Design Principles For The Web and I���ve just published a transcript of the presentation. I���m really pleased with how it turned out and I think it works okay as an article as well as a talk. Have a read and see what you think (or you can listen to the audio if you prefer).

Giving a talk online is …weird. It���s very different from public speaking. The public is theoretically there but you feel like you���re just talking at your computer screen. If anything, it���s more like recording a podcast than giving a talk.

Luckily for me, I like recording podcasts. So I���m going to be doing a new online talk this year. It will be at An Event Apart���s Spring Summit which runs from April 19th to 21st. Tickets are available now.

I have a pretty good idea what I���m going to talk about. Web stuff, obviously, but maybe a big picture overview this time: the past, present, and future of the web.

Time to prepare a conference talk.

2020

In 2020, I didn���t have the honour and privilege of speaking at An Event Apart in places like Seattle, Boston, and Minneapolis. I didn���t experience that rush that comes from sharing ideas with a roomful of people, getting them excited, making them laugh, sparking thoughts. I didn���t enjoy the wonderful and stimulating conversations with my peers that happen in the corridors, or over lunch, or at an after-party. I didn���t have a blast catching up with old friends or making new ones.

But the States wasn���t the only country I didn���t travel to. Closer to home, I didn���t have the opportunity to take the Eurostar and connecting trains to cities like Cologne, Lisbon, and Stockholm. I didn���t sample the food and drink of different countries.

In the summer, I didn���t travel to the west coast of Ireland for the second in year in a row for the annual Willie Clancy festival of traditional Irish music. I didn���t spend each day completely surrounded by music. I didn���t play in some great sessions. I didn���t hear some fantastic and inspiring musicians.

Back here in Brighton, I didn���t go to the session in The Jolly Brewer every Wednesday evening and get lost in the tunes. I didn���t experience that wonderful feeling of making music together and having a pint or two. And every second Sunday afternoon, I didn���t pop along to The Bugle for more jigs and reels.

I didn���t walk into work most days, arrive at the Clearleft studio, and make a nice cup of coffee while chit-chatting with my co-workers. I didn���t get pulled into fascinating conversations about design and development that spontaneously bubble up when you���re in the same space as talented folks.

Every few months, I didn���t get a haircut.

Throughout the year, I didn���t make any weekend trips back to Ireland to visit my mother.

2020 gave me a lot of free time. I used that time to not write a book. And with all that extra time on my hands, I read fewer books than I had read in 2019. Oh, and on the side, I didn���t learn a new programming language. I didn���t discover an enthusiasm for exercise. I didn���t get out of the house and go for a brisk walk on most days. I didn���t start each day prepping my sourdough.

But I did stay at home, thereby slowing the spread of a deadly infectious disease. I���m proud of that.

I did play mandolin. I did talk to my co-workers through a screen. I did eat very well���and very local and seasonal. I did watch lots of television programmes and films. I got by. Sometimes I even took pleasure in this newly-enforced lifestyle.

I made it through 2020. And so did you. That���s an achievement worth celebrating���congratulations!

Let���s see what 2021 doesn���t bring.