Sunday, January 14th, 2018
Monday, January 8th, 2018
Slides from a conference talk with a really clear explanation of how
await works with promises.
Monday, January 1st, 2018
Friday, November 17th, 2017
I’ve been to four conferences in two weeks. I wasn’t speaking at any of them so I was able to relax and enjoy the talks.
One week later, I was in the Duke of York’s cinema for FFConf along with all the other Clearleft frontend devs—it’s always a thought-provoking day out.
Thursday, November 2nd, 2017
The dConstruct Audio Archive works offline
I’m really proud of the three years I ran the show—2012, 2013, and 2014—and I have great memories from each event. I’m inordinately pleased that the individual websites are still online after all these years. I’m equally pleased with the dConstruct audio archive that we put online in 2012. Now that the event itself is no longer running, it truly is an archive—a treasury of voices from the past.
I think that these kinds of online archives are eminently suitable for some offline design. So I’ve added a service worker script to the dConstruct archive.
But what about the individual pages? For something like Resilient Web Design—another site that won’t be updated—I pre-cache everything. I could do that with the dConstruct archive. All of the pages with all of the images add up to less than two megabytes; the entire site weighs less than a single page on Wired.com or The Verge.
In the end, I decided to go with a cache-as-you-go strategy. Every time a page or an image is fetched from the network, it is immediately put in a cache. The next time that page or image is requested, the file is served from that cache instead of the network.
Here’s the logic for fetch requests:
- First, look to see if the file is in a cache. If it is, great! Serve that.
- If the file isn’t in a cache, make a network request and serve the response …but put a copy of a file in the cache.
- The next time that file is requested, go to step one.
Save for offline
That caching strategy works great for pages, images, and other assets. But there’s one kind of file on the dConstruct archive that’s a bit different: the audio files. They can be fairly big, so I don’t want to cache those unless the user specifically requests it.
If you end up on the page for a particular talk, and your browser supports service workers, you’ll get an additional UI element in the list of options: a toggle to “save offline” (under the hood, it’s a checkbox). If you activate that option, then the audio file gets put into a cache.
Now if you lose your network connection while browsing the site, you’ll get a custom offline page with the option to listen to any audio files you saved for offline listening. You’ll also see this collection of talks on the homepage, regardless of whether you’ve got an internet connection or not.
So if you’ve got a long plane journey ahead of you, have a browse around the dConstruct archive and select some talks for your offline listening pleasure.
Or just enjoy the speediness of browsing the site.
Tuesday, October 31st, 2017
Speak and repeat
The latest blog post, by Rachel, is called Do I need to write a brand new talk every time?
New presenters often feel that they need to write a brand-new talk for each conference they are invited to. Unless your job is giving presentations, or you are being paid very well for each talk you give, it is unlikely that you will be able to keep this up if you do more than a couple of talks per year.
It’s true. When I first started giving talks, I felt really guilty at the thought of “recycling” a talk I had already given. “Those people have paid money to be here—they deserve a brand new talk”, I thought. But then someone pointed out to me, “Y’know, it’s actually really arrogant to think that anyone would’ve seen any previous talk of yours.” Good point.
I explain it to people like a band touring an album. Lots of work goes into the album, and the tour puts those ideas on display. To expect a band to write a brand new album’s worth of music in between Pittsburgh and Chicago is absurd.— Brad Frost (@brad_frost) October 30, 2017
Giving the same talk more than once also allows me to put in the extra effort into the talk prep. If I’m going through the hair-tearing-out hell of trying to wrestle a talk into shape, I’m inevitably going to ask, “Why am I putting myself through this‽” If the answer to that question is “So you can give this talk just once”, I’d probably give up in frustration. But if I know that I’ll have an opportunity to present it more than once, improving it each time, then that gives me the encouragement to keep going.
I do occasionally give a one-off specially-commissioned talk, but those are the exceptions. My talk on the
A element at CSS Day’s HTML Special was one of those. Same with my dConstruct talk back in 2008. I just gave a new talk on indie web building blocks at Mozilla’s View Source event, but I’d quite like to give that one again (if you’re running an event, get in touch if that sounds like something you’d like).
My most recent talk isEvaluating Technology. I first gave it at An Event Apart in San Francisco exactly a year ago. I’ll present it for the final time at An Event Apart in Denver in a few weeks. Then it will be retired; taken out to the woodshed; pivoted to video.
I’m already starting to think about my next talk. The process of writing a talk is something else that Rachel has written about. She’s far more together than me. My process involves lots more procrastination, worry, panic, and pacing. Some of the half-baked ideas will probably leak out as blog posts here. It’s a tortuous process, but in the end, I find the satisfaction of delivering the final talk to be very rewarding.
Here’s the thing, though: until I deliver the talk for the first time in front of an audience—no matter how much I might have practiced it—I have literally no idea if it’s any good. I honestly can’t tell whether what I’ve got is gold dust or dog shit (and during the talk prep, my opinion of it can vacillate within the space of five minutes). And so, even though I’ve been giving talks for many years now, if it’s brand new material, I get very nervous.
That’s one more reason to give the same talk more than once instead of creating a fresh hell each time.
Thursday, September 21st, 2017
I had the great pleasure of finally meeting Hui Jing when Mozilla invited me along to Singapore to speak at their developer roadshow. Hui Jing is speaking at each one of the events on the roadshow, and documenting the journey here.
She’s being very modest about her talk: it was superb! Entertaining and informative in equal measure, delivered with gusto. Seriously, frontend conference organisers, try to get Hui Jing to speak about CSS at your event—you won’t regret it.
Tuesday, August 29th, 2017
Brendan’s list of dos and don’ts (mostly don’ts) from his years of conference speaking.
Monday, July 24th, 2017
Putting on a conference
It’s been a few weeks now since Patterns Day and I’m still buzzing from it. I might be biased, but I think it was a great success all ‘round—for attendees, for speakers, and for us at Clearleft organising the event.
I first had the idea for Patterns Day quite a while back. To turn the idea into reality meant running some numbers. Patterns Day wouldn’t have been possible without Alis. She did all the logistical work—the hard stuff—which freed me up to concentrate on the line-up. I started to think about who I could invite to speak, and at the same time, started looking for a venue.
I knew from the start that I wanted it to be one-day single-track conference in Brighton, much like Responsive Day Out. I knew I wouldn’t be able to use the Corn Exchange again—there’s extensive rebuilding going on there this year. I put together a shortlist of Brighton venues and Alis investigated their capacities and costs, but to be honest, I knew that I wanted to have it in the Duke Of York’s. I love that place, and I knew from attending FFconf that it makes for an excellent conference venue.
The seating capacity of the Duke Of York’s is quite a bit less than the Corn Exchange, so I knew the ticket price would have to be higher than that of Responsive Day Out. The Duke Of York’s isn’t cheap to rent for the day either (but worth every penny).
To calculate the ticket price, I had to figure out the overall costs:
- Venue hire,
- A/V hire,
- Printing costs (for name badges, or in this case, stickers),
- Payment provider commission—we use Stripe through the excellent Ti.to,
- Speaker’s travel,
- Speaker’s accommodation,
- Speaker’s dinner the evening before the event,
- Speaker’s payment.
Some conference organisers think they can skimp on that last part. Those conference organisers are wrong. A conference is nothing without its speakers. They are literally the reason why people buy tickets.
Because the speakers make or break a conference, there’s a real temptation to play it safe and only book people who are veterans. But then you’re missing out on a chance to boost someone when they’re just starting out with public speaking. I remember taking a chance on Alla a few years back for Responsive Day Out 3—she had never given a conference talk before. She, of course, gave a superb talk. Now she’s speaking at events all over the world, and I have to admit, it gives me a warm glow inside. When it came time for Patterns Day, Alla had migrated into the “safe bet” category—I knew she’d deliver the perfect closing keynote.
I understand why conference organisers feel like they need to play it safe. From their perspective, they’re already taking on a lot of risk in putting on a conference in the first place. It’s easy to think of yourself as being in a position of vulnerability—”If I don’t sell enough tickets, I’m screwed!” But I think it’s important to realise that you’re also in a position of power, whether you like it or not. If you’re in charge of putting together the line-up of a conference, that’s a big responsibility, not just to the attendees on the day, but to the community as a whole. It’s like that quote by Eliel Saarinen:
Always design a thing by considering it in its next larger context. A chair in a room, a room in a house, a house in an environment, an environment in a city plan.
Part of that responsibility to the wider community is representation. That’s why I fundamentally disagree with ppk when he says:
The other view would be that there should be 50% woman speakers. Although that sounds great I personally never believed in this argument. It’s based on the general population instead of the population of web developers, and if we’d extend that argument to its logical conclusion then 99.9% of the web development conference speakers should know nothing about web development, since that’s the rough ratio in the general population.
That makes it sound like a conference’s job is to represent the status quo. By that logic, the line-up should include plenty of bad speakers—after all, the majority of web developers aren’t necessarily good speakers. But of course that’s not how conferences work. They don’t represent typical ideas—quite the opposite. What’s the point of having an event that simply reinforces the general consensus? This isn’t Harrison Bergeron. You want a line-up that’s exceptional.
I don’t think conference organisers can shirk this issue and say “It’s out of my hands; I’m just reflecting the way things are.” The whole point of having a conference in the first place is to trigger some kind of change. If you’re not happy with the current make-up of the web community (and I most definitely am not), then a conference is the perfect opportunity to try to demonstrate an alternative. We do it with the subject matter of the talks—”Our code/process/tooling doesn’t have to be this way!”—and I think we should also apply that to the wider context: “Our culture doesn’t have to be this way!”
Passing up that chance isn’t just a missed opportunity, I think it’s also an abdication of responsibility. Believe me, I know that organising a conference is a lot of work, but that’s not a reason to cop out. On the contrary, it’s all the more reason to step up to the plate and try your damnedest to make a difference. Otherwise, why even have a conference?
Whenever the issue of diversity at conferences comes up, there is inevitably someone who says “All I care about is having the best speakers.” But if that were true, shouldn’t your conference (and every other conference) have exactly the same line-up every year?
The truth is that there are all sorts of factors that play into the choice of speakers. I think representation should be a factor, but that’s all it is—one factor of many. Is the subject matter relevant? That’s a factor. Do we already have someone on the line-up covering similar subject matter? That’s a factor. How much will it cost to get this speaker? That’s a factor. Is the speaker travelling from very far away? That’s a factor.
In the case of Patterns Day, I had to factor in the range of topics. I wanted a mixture of big-picture talks as well as hands-on nitty-gritty case studies. I also didn’t want it to be too developer-focused or too design-focused. I was aiming for a good mix of both.
In the end, I must admit that I am guilty of doing exactly what I’ve been railing against. I played it safe. I put together a line-up of speakers that I wanted to see, and that I knew with absolute certainty would deliver great presentations. There were plenty of potential issues for me to get stressed about in the run-up to the event, but the quality of the talks wasn’t one of them. On the one hand, I wish I had taken more chances with the line-up, but honestly, if I could do it over again, I wouldn’t change a thing.
Because I was trying to keep the ticket price as low as possible—and the venue hire was already a significant cost—I set myself the constraint of only having speakers from within the UK (Jina was the exception—she was going to come anyway as an attendee, so of course I asked her to speak). Knowing that the speaker’s travel costs would be low, I could plug the numbers into an algebraic formula for figuring out the ticket price:
costs ÷ seats = price
Add up all the costs and divide that total by the number of available seats to get the minimum ticket price.
In practice, you probably don’t want to have to sell absolutely every single ticket just to break even, so you set the price for a sales figure lower than 100%—maybe 80%, or 50% if you’re out to make a tidy profit (although if you’re out to make a tidy profit, I don’t think conferences are the right business to be in—ask any conference organiser).
Some conferences factor in money for sponsorship to make the event happen. I prefer to have sponsors literally sponsoring additions to the conference. In the case of Patterns Day, the coffee and pastries were sponsored by Deliveroo, and the videos were sponsored by Amazon. But sponsorship didn’t affect the pricing formula.
The Duke Of York’s has around 280 seats. I factored in about 30 seats for speakers, Clearlefties, and other staff. That left 250 seats available for attendees. But that’s not the number I plugged into the pricing formula. Instead, I chose to put 210 tickets on sale and figured out the ticket price accordingly.
What happened to the remaining 40 seats? The majority of them went to Codebar students and organisers. So if you bought a ticket for Patterns Day, you directly subsidised the opportunity for people under-represented in technology to attend. Thank you.
Speaking personally, I found that having the Codebar crew in attendance really made my day. They’re my heroes, and it meant the world to me that they were able to be there.
Sunday, April 30th, 2017
Oodles and oodles of videos of talks from London developer meetups.
Thursday, October 6th, 2016
Benjamin’s retrospective on three years of volunteering at web conferences, some of them run by Clearleft.
Friday, July 22nd, 2016
The life cycle of a Service Worker—with all its events and states—is the one bit that I’ve never paid that much attention to. My eyes just glaze over when it comes to installation, registration, and activation. But this post explains the whole process really clearly. Now it’s starting to make sense to me.
Wednesday, June 1st, 2016
Tuesday, May 10th, 2016
Sunday, February 21st, 2016
This looks like it could be quite a handy (and relatively lightweight) script for attaching events—like animations—to an item’s visibility, so the events only trigger when the item is scrolled into view.
Continuing the topic of public speaking, Jenn has a really good technique for figuring out how to arrange the pieces of your talk without getting bogged down in designing slides.
Lena’s in-depth run-down of how she puts together a conference talk. If you’re new to public speaking, this is well worth reading.
Wednesday, January 20th, 2016
Codebar had a very good 2015.
Of the 137 workshops run, “100 of those workshops were organised by our two busiest chapters, London and Brighton”—50 each.
Monday, November 16th, 2015
Full Meaning Ampersand
In the space of one week, Brighton played host to three excellent conferences:
- FF Conf on Friday, November 6th,
- Meaning on Thursday, November 12th, and
- Ampersand on Friday, November 13th.
I made it to two of the three—alas, I couldn’t make it to Meaning this year because it clashed with Richard’s superb workshop on Responsive Web Typography.
FF Conf and Ampersand were both superb. Despite having very different subject matter, the two events have a lot in common. They’re both affordable, one-day, single-track, focused gatherings.
Both events really benefit from having a mastermind overseeing the line-up: Remy in the case of FF Conf, and Richard in the case of Ampersand. That really paid off. Both events were superbly curated, with a diverse mix of speakers and topics.
Videos will be available from FF Conf, and audio will be available from Ampersand. Be sure to check them out once they’re released.
Tuesday, November 10th, 2015
This looks like being a very handy book on public speaking. I’m going to order a copy for the Clearleft office. I’ll let you know what it’s like.