Journal

2919 sparkline

Friday, November 25th, 2022

Tweaking navigation sizing

Gerry talks about “top tasks” a lot. He literally wrote the book on it:

Top tasks are what matter most to your customers.

Seems pretty obvious, right? But it’s actually pretty rare to see top tasks presented any differently than other options.

Look at the global navigation on most websites. Typically all the options are given equal prominence. Even the semantics under the hood often reflect this egalitarian ideal, with each list in an unordered list. All the navigation options are equal, but I bet that the reality for most websites is that some navigation options are more equal than others.

I’ve been guilty of this on The Session. The site-wide navigation shows a number of options: tunes, events, discussions, etc. Each one is given equal prominence, but I can tell you without even looking at my server logs that 90% of the traffic goes to the tunes section—that’s the beating heart of The Session. That’s why the home page has a search form that defaults to searching for tunes.

I wanted the navigation to reflect the reality of what people are coming to the site for. I decided to make the link to the tunes section more prominent by bumping up the font size a bit.

I was worried about how weird this might look; we’re so used to seeing all navigation items presented equally. But I think it worked out okay (though it might take a bit of getting used to if you’re accustomed to the previous styling). It helps that “tunes” is a nice short word, so bumping up the font size on that word doesn’t jostle everything else around.

I think this adjustment is working well for this situation where there’s one very clear tippy-top task. I wouldn’t want to apply it across the board, making every item in the navigation proportionally bigger or smaller depending on how often it’s used. That would end up looking like a ransom note.

But giving one single item prominence like this tweaks the visual hierarchy just enough to favour the option that’s most likely to be what a visitor wants.

That last bit is crucial. The visual adjustment reflects what visitors want, not what I want. You could adjust the size of a navigation option that you want to drive traffic to, but in the long run, all you’re going to do is train people to trust your design less.

You don’t get to decide what your top task is. The visitors to your website do. Trying to foist an arbitrary option on them would be the tail wagging the dog.

Anway, I’m feeling a lot better about the site-wide navigation on The Session now that it reflects reality a little bit more. Heck, I may even bump that font size up a little more.

Monday, November 21st, 2022

Portability

Exactly sixteen years ago on this day, I wrote about Twitter, a service I had been using for a few weeks. I documented how confusing yet compelling it was.

Twitter grew and grew after that. But at some point, it began to feel more like it was shrinking, shrivelling into a husk of its former self.

Just over ten years ago, there was a battle for the soul of Twitter from within. One camp wanted it to become an interoperable protocol, like email. The other camp wanted it to be a content farm, monetised by advertisers. That’s the vision that won. They declared war on the third-party developers who had helped grow Twitter in the first place, and cracked down on anything that didn’t foster e N g A g E m E n T.

The muskofication of Twitter is the nail in the coffin. In the tradition of all scandals since Watergate, I propose we refer to the shocking recent events at Twitter as Elongate.

Post-Elongate Twitter will limp on, I’m sure, but it can never be the fun place it once was. The incentives just aren’t there. As Bastian wrote:

Twitter was once an amplifier for brilliant ideas, for positivity, for change, for a better future. Many didn’t understand the power it had as a communication platform. But that power turned against the exact same people who needed this platform so urgently. It’s now a waste of time and energy at best and a threat to progress and society at worst.

I don’t foresee myself syndicating my notes to Twitter any more. I’ve removed the site from my browser’s bookmarks. I’ve removed it from my phone’s home screen too.

As someone who’s been verified on Twitter for years, with over 140,000 followers, it should probably feel like a bigger deal than it does. I echo Robin’s observation:

The speed with which Twitter recedes in your mind will shock you. Like a demon from a folktale, the kind that only gains power when you invite it into your home, the platform melts like mist when that invitation is rescinded.

Meanwhile, Mastodon is proving to be thoroughly enjoyable. Some parts are still rough around the edges, but compared to Twitter in 2006, it’s positively polished.

Interestingly, the biggest complaint that I and my friends had about Twitter all those years ago wasn’t about Twitter per se, but about lock-in:

Twitter is yet another social network where we have to go and manually add all the same friends from every other social network.

That’s the very thing that sets the fediverse apart: the ability to move from one service to another and bring your social network with you. Now Matt is promising to add ActivityPub to Tumblr. That future we wanted sixteen years ago might finally be arriving.

Friday, November 18th, 2022

That fediverse feeling

Right now, Twitter feels like Dunkirk beach in May 1940. And look, here comes a plucky armada of web servers running Mastodon instances!

Others have written some guides to getting started on Mastodon:

There are also tools like Twitodon to help you migrate from Twitter to Mastodon.

Getting on board isn’t completely frictionless. Understanding how Mastodon works can be confusing. But then again, so was Twitter fifteen years ago.

Right now, many Mastodon instances are struggling with the influx of new sign-ups. But this is temporary. And actually, it’s also very reminiscent of the early unreliable days of Twitter.

I don’t want to go into the technical details of Mastodon and the fediverse—even though those details are fascinating and impressive. What I’m really struck by is the vibe.

In a nutshell, I’m loving it! It feels …nice.

I was fully expecting Mastodon to be full of meta-discussions about Mastodon, but in the past few weeks I’ve enjoyed people posting about stone circles, astronomy, and—obviously—cats and dogs.

The process of finding people to follow has been slow, but in a good way. I’ve enjoyed seeking people out. It’s been easier to find the techy folks, but I’ve also been finding scientists, journalists, and artists.

On the one hand, the niceness of the experience isn’t down to technical architecture; it’s all about the social norms. On the other hand, those social norms are very much directed by technical decisions. The folks working on the fediverse for the past few years have made very thoughtful design decisions to amplify niceness and discourage nastiness. It’s all very gratifying to experience!

Personally, I’m posting to Mastodon via my own website. As much as I’m really enjoying Mastodon, I still firmly believe that nothing beats having control of your own content on your domain.

But I also totally get that not everyone has the same set of priorities as me. And frankly, it’s unrealistic to expect everyone to have their own domain name.

It’s like there’s a spectrum of ownership. On one end, there’s publishing on your own website. On the other end, there’s publishing on silos like Twitter, Facebook, Medium, Instagram, and MySpace.

Publishing on Mastodon feels much closer to the website end of the spectrum than it does to the silo end of the spectrum. If something bad happens to the Mastodon instance you’re on, you can up and move to a different instance, taking your social graph with you.

In a way, it’s like delegating domain ownership to someone you trust. If you don’t have the time, energy, resources, or interest in having your own domain, but you trust someone who’s running a Mastodon instance, it’s the next best thing to publishing on your own website.

Simon described it well when he said Mastodon is just blogs:

A Mastodon server (often called an instance) is just a shared blog host. Kind of like putting your personal blog in a folder on a domain on shared hosting with some of your friends.

Want to go it alone? You can do that: run your own dedicated Mastodon instance on your own domain.

And rather than compare Mastodon to Twitter, Simon makes a comparison with RSS:

Do you still miss Google Reader, almost a decade after it was shut down? It’s back!

A Mastodon server is a feed reader, shared by everyone who uses that server.

Lots of other folks are feeling the same excitement in the air that I’m getting:

Bastian wrote:

Real conversations. Real people. Interesting content. A feeling of a warm welcoming group. No algorithm to mess around with our timelines. No troll army to destory every tiny bit of peace. Yes, Mastodon is rough around the edges. Many parts are not intuitive. But this roughness somehow added to the positive experience for me.

This could really work!

Brent Simmons wrote:

The web is wide open again, for the first time in what feels like forever.

I concur! Though, like Paul, I love not being beholden to either Twitter or Mastodon:

I love not feeling bound to any particular social network. This website, my website, is the one true home for all the stuff I’ve felt compelled to write down or point a camera at over the years. When a social network disappears, goes out of fashion or becomes inhospitable, I can happily move on with little anguish.

But like I said, I don’t expect everyone to have the time, means, or inclination to do that. Mastodon definitely feels like it shares the same indie web spirit though.

Personally, I recommend experiencing Mastodon through the website rather than a native app. Mastodon instances are progressive web apps so you can add them to your phone’s home screen.

You can find me on Mastodon as @adactio@mastodon.social

I’m not too bothered about what instance I’m on. It really only makes a difference to my local timeline. And if I do end up finding an instance I prefer, then I know that migrating will be quite straightforward, by design. Perhaps I should be on an instance with a focus on front-end development or the indie web. I still haven’t found much of an Irish traditional music community on the fediverse. I’m wondering if maybe I should start a Mastodon instance for that.

While I’m a citizen of mastodon.social, I’m doing my bit by chipping in some money to support it: sponsorship levels on Patreon start at just $1 a month. And while I can’t offer much technical assistance, I opened my first Mastodon pull request with a suggested improvement for the documentation.

I’m really impressed with the quality of the software. It isn’t perfect but considering that it’s an open source project, it’s better than most VC-backed services with more and better-paid staff. As Giles said, comparing it to Twitter:

I’m using Mastodon now and it’s not the same, but it’s not shit either. It’s different. It takes a bit of adjustment. And I’m enjoying it.

Most of all, I love, love, love that Mastodon demonstrates that things can be different. For too long we’ve been told that behavioural advertising was an intrinsic part of being online, that social networks must inevitably be monolithic centralised beasts, that we have to relinquish control to corporations in order to be online. The fediverse is showing us a better way. And this isn’t just a proof of concept either. It’s here now. It’s here to stay, if you want it.

Thursday, November 17th, 2022

Syndicating to Mastodon

I’ve been contemplating a checkbox. The label for this checkbox reads:

This is a bot account

Let me back up…

In what seems like decades ago, but was in fact just a few weeks, Elon Musk bought Twitter and began burning it to the ground. His admirers insist he’s playing some form of four-dimensional chess, but to the rest of us, his actions are indistinguishable from a spoilt rich kid not understanding what a social network is.

It wasn’t giving me much cause for anguish personally. For the past eight years, I’ve only used Twitter as a syndication endpoint for my own notes. But I understand that’s a very privileged position to be in. Most people on Twitter don’t have the same luxury of independence. It’s genuinely maddening and saddening to see their years of sharing destroyed by one cruel idiot.

Lots of people started moving to Mastodon. I figured I should do the same for my syndicated notes.

At first, I signed up for an account on mastodon.cloud. No particular reason. But that’s where I saw this very insightful post from Anil Dash:

When it came time to reckon with social media’s failings, nobody ran to the “web3” platforms. Nobody asked “can I get paid per message”? Nobody asked about the blockchain. The community of people who’ve been quietly doing this work for years (decades!) ended up being the ones who welcomed everyone over, as always.

I was getting my account all set up and beginning to follow some other folks, when I realised that I actually already had an exisiting account over on mastodon.social. Doh! Turns out that I signed up back in 2017 to kick the tyres, but never did much else because there weren’t many other people around back then. Oh, how times have changed!

Anyway, I thought I had really screwed up by having two accounts but this turned out to be an opportunity to experience some of the thoughtfulness in Mastodon’s design. The process of migrating from one Mastodon account to another—on a completely different instance—was very smooth! It was clear that this wasn’t an afterthought. This is an essential part of the fediverse and the design of the migration flow reflects that.

This gives me enormous peace of mind. If I ever want to switch to a different instance and still keep my network intact, I know it won’t be a problem. Mastodon is like the opposite of the roach-motel mentality that permeates most VC-backed so-called social networks.

As I played around some more—reading, following, exploring—my feelings of fondness only grew stronger. I like this place a lot!

I definitely wanted to syndicate my notes to Mastodon. At first, I implemented a straightforward RSS-to-Mastodon syndication using IFTTT (IF This, Then That), thanks to Matthias’s excellent tutorial.

But that didn’t feel quite right. When I syndicate to Twitter, I make a conscious choice each time. There’s a “Twitter” toggle that I can enable or disable in my posting interface. Mastodon deserved the same level of thoughtfulness.

So I switched off the IFTTT recipe and started exploring the Mastodon API. It’s going to sound like a humblebrag when I tell you that I got cross-posting working in almost no time at all, but that’s not a testament to my coding prowess (I’m really not very good), but rather a testament to the Mastodon API, which was a joy to work with.

  1. On your Mastodon instance, go to /settings/applications.
  2. Click on New Application.
  3. Fill in the details about your website and select write:statuses (and probably write:media) from the Scopes list.
  4. Copy Your access token to use in API calls.
  5. Write some sloppy code (in my case, PHP that uses CURL).

I did hit a wall when it came to posting images. That took me a while to get working, and I couldn’t figure out why. Was it something at Mastodon’s end while it was struggling under the influx of new users? As it turns out, no. It was entirely down to me being an idiot. (You know that situation where you’re working on a problem for ages and you’ve become convinced it’s an extremely gnarly rocket-science problem, but then turns out to be something stupid like a typo? Yeah. That.)

Then there’s the whole question of how to receive replies, likes, and reboosts from Mastodon here on my own site. Luckily, that was super easy, thanks to Brid.gy. One click and I was done. I love Brid.gy!

Take this note, for example. There’s a version on Twitter and a version on Mastodon. The original version on my own site gets responses from both places.

If I’m replying to a response on Twitter, I do not syndicate that to Mastodon.

Likewise, if I’m replying to a response on Mastodon, I do not syndicate that to Twitter.

Oh, one thing worth mentioning: if you’re sending a reply to something on Mastodon using the API, there’s an in_reply_to_id field for you to provide. But you should also include the full @username@instance of the person you’re replying to at the beginning of the message to ensure that it’s displayed as a reply rather than showing up as a regular post. Note the difference between this note on my site and its syndicated version on Mastodon.

Anyway, now I’m posting to Mastodon, but I’m doing it through the the interface of my own website. Which brings me to that checkbox in Mastodon’s profile settings:

This is a bot account

The help text reads:

Signal to others that the account mainly performs automated actions and might not be monitored

If I were doing the automatic cross-posting from RSS, I’d definitely tick that box. But as I’m making a conscious decision whenever I syndicate to Mastodon, I think I’m going to leave that checkbox unticked.

My cross-posting is not automated and I’m very much monitoring my Mastodon account …because I’m enjoying my Mastodon experience more than I’ve enjoyed anything online for quite some time. Highly recommended!

Wednesday, November 16th, 2022

Artemis rising

Two weeks ago I was on stage for two days hosting Leading Design in London.

Last week I was on stage for two days hosting Clarity in New Orleans.

It was an honour and a pleasure to MC at both events. Hard work, but very, very rewarding. And people seemed to like the cut of my jib, so that’s good.

With my obligations fulfilled, I’m now taking some time off before diving back into some exciting events-related work (he said, teasingly).

Jessica and I left New Orleans for Florida on the weekend. We’re spending a week at the beach house in Saint Augustine, doing all the usual Floridian activities: getting in the ocean, eating shrimp, sitting around doing nothing, that kind of thing.

But last night we got to experience something very unusual indeed.

We stayed up late, fighting off tiredness until strolling down to the beach sometime after 1am.

It was a mild night. I was in shorts and short sleeves, standing on the sand with the waves crashing, letting my eyes adjust to the darkness.

We were looking to the south. That’s where Cape Canaveral is, about a hundred miles away.

A hundred miles is quite a distance, and it was a cloudy night, so I wasn’t sure whether we’d be able to see anything. But when the time came, shortly before 2am, there was no mistaking it.

An orange glow appeared on the ocean, just over the horizon. Then an intense bright orange-red flame burst upwards. Even at this considerable distance, it was remarkably piercing.

It quickly travelled upwards, in an almost shaky trajectory, until entering the clouds.

And that was it. Brief, but unforgettable. We had seen the launch of Artemis 1 on the Space Launch System, the most powerful rocket ever launched.

Saturday, November 5th, 2022

Negativity bias

When I wrote about my hopes and fears for the View Transitions API, a few people latched on to this sentiment:

If the View Transitions API only works for single page apps, it could be the single worst thing to happen to the web in years.

But I also wrote:

If the View Transitions API works across page navigations, it could be the single best thing to happen to the web in years.

I think it’s worth focusing on that.

Part of the problem is that I gave my hopes and fears an equal airing. But they’re not equally likely.

Take the possibility that the View Transitions API only ships for single page apps, but never ships for regular page transitions. The consequences of that would be big—the API would act as an incentive to build single page apps. But the likelihood of that happening is small. In fact, according to Jake, there’s already an implemention for page transitions in the works at Chrome.

Now what if the View Transitions API ships for pages? The consequences would be equally big—the API would act as an incentive to ditch single page apps and build in a more performant, resilient way. Best of all, the chances of that happening are very large indeed (pretty much a certainty now, given Jake’s update).

So I made a comparison between both of the consequences, which are equally large, but I didn’t make a corresponding comparison of the likelihoods, which are not equally large. Mea culpa!

I should’ve made it clearer that, although the consequences would be really bad if the View Transitions API only supports single page apps, the actual likelihood of that is pretty slim.

That’s probably my negativity bias showing through. (The reason I have a negativity bias is because I am a human. Like, have you ever noticed that if you get feedback on something and 98% of it is positive, you inevitably fixate on the 2%?)

Anyway, the real takeaway here is that if the View Transitions API ships for pages, then the consequences will be really, really good! It would be another nail in the coffin for monolithic JavaScript frameworks slowing down the web. And best of all, the likelihood of this happening is very high!

So let me amend my closing sentences from my previous post:

If the View Transitions API only works for single page apps—which is very unlikely—it could be the single worst thing to happen to the web in years.

If the View Transitions API works across page navigations—which is very, very likely—it could be the single best thing to happen to the web in years.

The glass is half full and it’s only going to get fuller. Time to start planning for a turbo-charged web now.

If you’ve got a website with full page navigations, start thinking about how you’ll be able to apply the View Transitions API as a progressive enhancement to improve the user experience.

If you’ve got a single page app, start thinking about how to ditch a whole bunch of uneccessary dependencies to make a more lightweight foundation of HTML instead of JavaScript, and still get all those slick transitions you get in a single page app!

Time for transitions

I am simultaneously very excited and very nervous about the View Transitions API.

You may know it by its former name—Shared Element Transitions. The name change is very recent.

I’ve been saying for years that some kind of API like this would be brilliant:

I honestly think if browsers implemented this, 80% of client-rendered Single Page Apps could be done as regular good ol’-fashioned websites.

Miriam Suzanne describes the theory of View Transitions succinctly:

Shared-element transitions are designed to work with standard web navigation across multiple page loads, as well as page transitions in ‘single-page’ apps (often called SPAs).

This all sounds brilliant. But the devil is in the implementation details. Right now, the API only works for single page apps. This is totally understandable. For purely pragmatic reasons, single page apps are a simple use case to solve for. It’s going to take a lot more work to get this API to work for multi-page apps (or as we used to call them, websites).

If we get a View Transitions API that works across page navigations, it could potentially turbo-charge the web. It will act as a disencentive to building single page apps—you’d be able to provide swish transitions without sacrificing performance or resilience at the alter of a heavy-handed JavaScript-only architecture.

But if the API only ever works for single page apps (which is the current situation), then it will act as an incentive to make any kind of website into a single page app, regardless of whether it’s actually the appropriate architecture.

That prospect has me very worried indeed.

I’m making my feelings on this known just in case any of the implementators out there are thinking, “Hey, maybe it’s fine that this API only works for single page apps—I’m sure most people would be happy with that.”

If the View Transitions API works across page navigations, it could be the single best thing to happen to the web in years.

If the View Transitions API only works for single page apps, it could be the single worst thing to happen to the web in years.

Update: Jake says:

We’re currently landing code in Chrome for the MPA version.

Very happy to hear that! It’s already in the spec, but it’s good to hear that the implementation isn’t going to lag too much.

Also, read this follow-up.

Monday, October 31st, 2022

Do You Like Rock Music?

I spent Friday morning in band practice with Salter Cane. It was productive. We’ve got some new songs that are coming together nicely. We’re still short a drummer though, so if you know anyone in Brighton who might be interested, let me know.

As we were packing up, we could here the band next door. They were really good. Just the kind of alt-country rock that would go nicely with Salter Cane.

On the way out, Jessica asked at the front desk who that band was. They’re called The Roebucks.

When I got home I Ducked, Ducked and Went to find out more information. There’s a Bandcamp page with one song. Good stuff. I also found their Facebook page. That’s where I saw this little tidbit:

Hello, we are supporting @seapowerband at @chalk_venue on the 30th of October. Hope you can make it!

Wait, that’s this very weekend! And I love Sea Power (formerly British Sea Power—they changed their name, which was a move that only annoyed the very people who’s worldviews prompted the name change in the first place). How did I not know about this gig? And how are there tickets still available?

And that’s how I came to spend my Sunday evening rocking out to two great bands.

Sunday, October 30th, 2022

Overloading buttons

It’s been almost two years since I added audio playback on The Session. The interface is quite straightforward. For any tune setting, there’s a button that says “play audio”. When you press that button, audio plays and the button’s text changes to “pause audio.”

By updating the button’s text like this, I’m updating the button’s accessible name. In other situations, where the button text doesn’t change, you can indicate whether a button is active or not by toggling the aria-pressed attribute. I’ve been doing that on the “share” buttons that act as the interface for a progressive disclosure. The label on the button—“share”—doesn’t change when the button is pressed. For that kind of progressive disclosure pattern, the button also has an aria-controls and aria-expanded attribute.

From all the advice I’ve read about button states, you should either update the accessible name or change the aria-pressed attribute, but not both. That would lead to the confusing situation of having a button labelled “pause audio” as having a state of “pressed” when in fact the audio is playing.

That was all fine until I recently added some more functionality to The Session. As well as being able to play back audio, you can now adjust the tempo of the playback speed. The interface element for this is a slider, input type="range".

But this means that the “play audio” button now does two things. It plays the audio, but it also acts as a progressive disclosure control, revealing the tempo slider. The button is simultaneously a push button for playing and pausing music, and a toggle button for showing and hiding another interface element.

So should I be toggling the aria-pressed attribute now, even though the accessible name is changing? Or is it enough to have the relationship defined by aria-controls and the state defined by aria-expanded?

Based on past experience, my gut feeling is that I’m probably using too much ARIA. Maybe it’s an anti-pattern to use both aria-expanded and aria-pressed on a progressive disclosure control.

I’m kind of rubber-ducking here, and now that I’ve written down what I’m thinking, I’m pretty sure I’m going to remove the toggling of aria-pressed in any situation where I’m already toggling aria-expanded.

What I really need to do is enlist the help of actual screen reader users. There are a number of members of The Session who use screen readers. I should get in touch and see if the new functionality makes sense to them.

Tuesday, October 25th, 2022

Prepping

Speaking of in-person gatherings, I’ve got some exciting—if not downright nervewracking—events coming up soon.

Next week I’ll be in London for Leading Design. Looking at the line-up that Rebecca is assembled, I’m kind of blown away—it looks fantastic!

You’ll notice that I’m in that line-up, but don’t worry—I’m not giving a talk. I’ll be there as host. That means I get to introduce the speakers before they speak, and ask them a question or two afterwards.

Then, one week later, I do it all again at Clarity in New Orleans. I’m really honoured that Jina has invited me to MC. Again, it’s a ridiculously fantastic line-up (once you ignore my presence).

I really, really enjoy hosting events. And yet I always get quite anxious in the run-up. I think it’s because there isn’t much I can do to prepare.

During The Situation, I had something of an advantage when I was hosting UX Fest. The talks were pre-recorded, which meant that I could study them ahead of time. At a live event, I won’t have that luxury. Instead, I need to make sure that I pay close attention to each talk and try to come up with good questions.

Based on past experience, my anxiety is unwarranted. Once I’m actually talking to these super-smart people, the problem isn’t a lack of things to discuss, but the opposite—so much to talk about in so little time!

I keep trying to remind myself of that.

See, it’s different if I’m speaking at an event. Sure, I’ll get nervous, but I can do something about it. I can prepare and practice to alleviate any anxiety. I feel like I have more control over the outcome when I’m giving a talk compared with hosting.

In fact, I do have a speaking gig on the horizon. I’ll be giving a brand new talk at An Event Apart in San Francisco in December.

It was just a month ago when Jeffrey invited me to speak. Of course I jumped at the chance—it’s always an honour to be asked—but I had some trepidation about preparing a whole new talk in time.

I’ve mentioned this before but it takes me aaaaaaaages to put a talk together. Don’t get me wrong; I think it’s worth it. I may not be good at much, but I know I can deliver a really good conference talk …once I’ve spent ridiculously long preparing it.

But more recently I’ve noticed that I’ve managed to shorten this time period. Partly that’s because I recklessly agree to prepare the talk in a shorter amount of time—nothing like a deadline to light a fire under my ass. But it’s also because a lot of the work is already done.

When I have a thought or an opinion about something, I write it down here on my own website. They’re brain farts, but their my brain farts. I consider them half-baked, semi-formed ideas.

For a conference talk, I need something fully-baked and well-formed. But I can take a whole bunch of those scrappy blog posts and use them as raw material.

There’s still a lot of work involved. As well as refining the message I want to get across, I have to structure these thoughts into a narrative thread that makes sense. That’s probably the hardest part of preparing a conference talk …and the most rewarding.

So while I’ve been feeling somewhat under the gun as I’ve been preparing this new talk for An Event Apart, I’ve also been feeling that the talk is just the culmination; a way of tying together some stuff I’ve been writing about it here for the past year or two.

It’s still entirely possible that the talk could turn out to be crap, but I think the odds are in my favour. I’ve been able to see how the ideas I’ve been writing about have resonated with people, so I can feel pretty confident that they’ll go down well in a talk.

As for the topic of the talk? All will be revealed.