Archive: October 31st, 2017

Speak and repeat

Rachel and Drew are starting a new service called Notist. It’s going to be a place where conference speakers can collate their materials. They’ve also got a blog.

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.

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.

Inter UI font family

A nice free and open source font designed for digital interfaces:

Inter UI is a font for highly legible text on computer screens.

Never Use Futura

The book draws together the many and varied uses of Futura that make it a universal language while simultaneously confirming its unique typographic voice. The book is a playful yet passionate rebuttal to the perceived dominance of Helvetica as the typeface of modern design.

‘Neopets’: Inside Look at Early 2000s Internet Girl Culture - Rolling Stone

Girls on Neopets took what they needed from the site and used the skills acquired there to further develop a burgeoning digital girls’ culture, whether it be in expanding their guild pages into personal sites, teaching others to code, or exchanging those skills for economic gain in Neopets.

I have anecdotal evidence from a few people that Neopets was their introduction to web design and development.

Turning another website into a Progressive Web App.

Turning another website into a Progressive Web App.

Airplanes and Ashtrays – CSS Wizardry

Whenever you plan or design a system, you need to build in your own ashtrays—a codified way of dealing with the inevitability of somebody doing the wrong thing. Think of what your ideal scenario is—how do you want people to use whatever you’re building—and then try to identify any aspects of it which may be overly opinionated, prescriptive, or restrictive. Then try to preempt how people might try to avoid or circumvent these rules, and work back from there until you can design a safe middle-ground into your framework that can accept these deviations in the safest, least destructive way possible.

ES2015+ cheatsheet

A one-stop-shop with a quick overview of the new JavaScript features in ES-whatever-we’re-calling-it-now.

Netflix functions without client-side React, and it’s a good thing - JakeArchibald.com

A great bucketload of common sense from Jake:

Rather than copying bad examples from the history of native apps, where everything is delivered in one big lump, we should be doing a little with a little, then getting a little more and doing a little more, repeating until complete. Think about the things users are going to do when they first arrive, and deliver that. Especially consider those most-likely to arrive with empty caches.

And here’s a good way of thinking about that:

I’m a fan of progressive enhancement as it puts you in this mindset. Continually do as much as you can with what you’ve got.

All too often, saying “use the right tool for the job” is interpreted as “don’t use that tool!” but as Jake reminds us, the sign of a really good tool is its ability to adapt instead of demanding rigid usage:

Netflix uses React on the client and server, but they identified that the client-side portion wasn’t needed for the first interaction, so they leaned on what the browser can already do, and deferred client-side React. The story isn’t that they’re abandoning React, it’s that they’re able to defer it on the client until it’s was needed. React folks should be championing this as a feature.

On platforms and sustainability – confused of calcutta

JP Rangaswami also examines the rise of the platforms but he’s got some ideas for a more sustainable future:

A part of me wants to evoke Jane Jacobs and Christopher Alexander when it comes to building sustainable platforms. The platform “community” needs to be cared for and looked after, the living spaces they inhabit need to be designed to last. Multipurpose rather than monoculture, diverse rather than homogeneous . Prior industrial models where entire communities would rely on a single industry need to be learnt from and avoided. We shouldn’t be building the rust belts of the future. We should be looking for the death and life of great platforms, for a pattern language for sustainable platforms.

André Staltz - The Web began dying in 2014, here’s how

This is the clickbaitiest of titles, but the post has some good sobering analysis of how much traffic driven by a small handful players. It probably won’t make you feel very cheery about the future.

(For some reason, this article uses all-caps abbreviations for company names, as though a stock ticker started generating hot takes: GOOG, FB, AMZN, etc. It’s a very odd writing style for a human.)