Subscribe: Adactio
http://www.adactio.com/journal/journal.rss
Added By: Feedage Forager Feedage Grade B rated
Language: English
Tags:
apps  cache  home screen  it’s  progressive web  progressive  prompt  talk  testing  time  web apps  web  world  🍅 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Adactio

Adactio: Journal



The online journal of Jeremy Keith, an author and web developer living and working in Brighton, England.



 



Origin story

Sat, 09 Dec 2017 10:32:49 GMT

In an excellent piece called The First Web Apps: 5 Apps That Shaped the Internet as We Know It, Matthew Guay wrote:

The world wide web wasn’t supposed to be this fun. Berners-Lee imagined the internet as a place to collaborate around text, somewhere to share research data and thesis papers.

In his somewhat confused talk at FFConf this year, James Kyle said:

The web was designed to share documents.

Douglas Crockford said

The web was not designed to do any of things it is doing. It was intended to be a simple—even primitive—document retrieval system.

Some rando on Hacker News declared:

Essentially every single aspect of the web is terrible. It was designed as a static document presentation system with hyperlinks.

It appears to be a universally accepted truth. The web was designed for sharing documents, and was never meant for the kind of applications we can build these days.

I don’t think that’s quite right. I think it’s fairer to say that the first use case for the web was document retrieval. And yes, that initial use case certainly influenced the first iteration of HTML. But right from the start, the vision for the web wasn’t constrained by what it was being asked to do at the time. (I mean, if you need an example of vision, Tim Berners-Lee called it the World Wide Web when it was just on one computer!)

The original people working on the web—Tim Berners-Lee, Robert Cailliau, Jean-Francois Groff, etc.—didn’t to try define the edges of what the web would be capable of. Quite the opposite. All of them really wanted a more interactive read-write web where documents could not only be read, but also edited and updated.

As for the idea of having a programming language in browsers (as well as a markup language), Tim Berners-Lee was all for it …as long as it could be truly ubiquitous.

To say that the web was made for sharing documents is like saying that the internet was made for email. It’s true in the sense that it was the most popular use case, but that never defined the limits of the system.

The secret sauce of the internet lies in its flexibility—it’s a deliberately dumb network that doesn’t care about the specifics of what runs on it. This lesson was then passed on to the web—another deliberately simple system designed to be agnostic to use cases.

It’s true that the web of today is very, very different to its initial incarnation. We got CSS; we got JavaScript; HTML has evolved; HTTP has evolved; URLs have …well, cool URIs don’t change, but you get the idea. The web is like the ship of Theseus—so much of it has been changed and added to over time. That doesn’t mean its initial design was flawed—just the opposite. It means that its initial design wasn’t unnecessarily rigid. The simplicity of the early web wasn’t a bug, it was a feature.

The web (like the internet upon which it runs) was designed to be flexible, and to adjust to future use-cases that couldn’t be predicted in advance. The best proof of this flexibility is the fact that we can and do now build rich interactive applications on the World Wide Web. If the web had truly been designed only for documents, that wouldn’t be possible.




Nosediving

Tue, 28 Nov 2017 12:01:04 GMT

Nosedive is the first episode of season three of Black Mirror.

It’s fairly light-hearted by the standards of Black Mirror, but all the more chilling for that. It depicts a dysutopia where people rate one another for points that unlock preferential treatment. It’s like a twisted version of the whuffie from Cory Doctorow’s Down And Out In The Magic Kingdom. Cory himself points out that reputation economies are a terrible idea.

Nosedive has become a handy shortcut for pointing to the dangers of social media (in the same way that Minority Report was a handy shortcut for gestural interfaces and Her is a handy shortcut for voice interfaces).

“Social media is bad, m’kay?” is an understandable but, I think, fairly shallow reading of Nosedive. The problem isn’t with the apps, it’s with the system. A world in which we desperately need to keep our score up if we want to have any hope of advancing? That’s a nightmare scenario.

The thing is …that system exists today. Credit scores are literally a means of applying a numeric value to human beings.

Nosedive depicts a world where your score determines which seats you get in a restaurant, or which model of car you can rent. Meanwhile, in our world, your score determines whether or not you can get a mortgage.

Nosedive depicts a world in which you know your own score. Meanwhile, in our world, good luck with that:

It is very difficult for a consumer to know in advance whether they have a high enough credit score to be accepted for credit with a given lender. This situation is due to the complexity and structure of credit scoring, which differs from one lender to another.

Lenders need not reveal their credit score head, nor need they reveal the minimum credit score required for the applicant to be accepted. Owing only to this lack of information to the consumer, it is impossible for him or her to know in advance if they will pass a lender’s credit scoring requirements.

Black Mirror has a good track record of exposing what’s unsavoury about our current time and place. On the surface, Nosedive seems to be an exposé on the dangers of going to far with the presentation of self in everyday life. Scratch a little deeper though, and it reveals an even more uncomfortable truth: that we’re living in a world driven by systems even worse than what’s depicted in this dystopia.

How about this for a nightmare scenario:

Two years ago Douglas Rushkoff had an unpleasant encounter outside his Brooklyn home. Taking out the rubbish on Christmas Eve, he was mugged — held at knife-point by an assailant who took his money, his phone and his bank cards. Shaken, he went back indoors and sent an email to his local residents’ group to warn them about what had happened.

“I got two emails back within the hour,” he says. “Not from people asking if I was OK, but complaining that I’d posted the exact spot where the mugging had taken place — because it might adversely affect their property values.”




Getaway

Wed, 22 Nov 2017 14:53:52 GMT

It had been a while since we had a movie night at Clearleft so I organised one for last night. We usually manage to get through two movies, and there’s always a unifying theme decided ahead of time. For last night, I decided that the broad theme would be …transport. But then, through voting on Slack, people could decide what the specific mode of transport would be. The choices were: taxi, getaway car, truck, or submarine. Nobody voted for submarines. That’s a shame, but in retrospect it’s easy to understand—submarine films aren’t about transport at all. Quite the opposite. Submarine films are about being trapped in a metal womb/tomb (and many’s the spaceship film that qualifies as a submarine movie). There were some votes for taxis and trucks, but the getaway car was the winner. I then revealed which films had been pre-selected for each mode of transport. Taxi Collateral, Michael Mann, 2004 (86% 🍅) Night On Earth, Jim Jarmusch, 1991 (73% 🍅) Taxi Driver, Martin Scorsese, 1976 (99% 🍅) Getaway car Shorts: Getaway Driver, The Getaway Baby Driver, Edgar Wright, 2017 (93% 🍅) Wheelman, Jeremy Rush, 2017 (88% 🍅) Drive, Nicolas Winding Refn, 2011 (93% 🍅) The Driver, Walter Hill, 1978 (80% 🍅) Truck Fury Road, George Miller, 2015 (97% 🍅) Duel, Steven Spielberg, 1971 (88% 🍅) Submarine Below, David Twohy, 2002 (64% 🍅) Crimson Tide, Tony Scott, 1995 (87% 🍅) The Hunt For Red October, John McTiernan, 1990 (86% 🍅) I thought Baby Driver would be a shoe-in for the first film, but enough people had already seen it quite recently to put it out of the running. We watched Wheelman instead, which was like Locke meets Drive. So what would the second film be? Well, some of those films in the full list could potentially fall into more than one category. The taxi in Collateral is (kinda) being used as a getaway car. And if you expand the criterion to getaway vehicle, then Furiosa’s war rig surely counts, right? Okay, we were just looking for an excuse to watch Fury Road again. I mean, c’mon, it was the black and chrome edition! I had the great fortune of seeing that on the big screen a while back and I’ve been raving about it ever since. Besides, you really don’t need an excuse to rewatch Fury Road. I loved it the first time I saw it, and it just keeps getting better and better each time. The editing! The sound! The world-building! With every viewing, it feels more and more like the film for our time. It may have been a bit of stretch to watch it under the thematic umbrella of getaway vehicles, but it’s a getaway for our current political climate: instead of the typical plot involving a gang driving at full tilt from a bank heist, imagine one where the gang turns around, ousts the bankers, and replaces the whole banking system with a matriarchal community. “Hope is a mistake”, Max mansplains (maxplains?) to Furiosa at one point. He’s wrong. Judicious hope is what drives us forward (or, this case, back …to the citadel). Watching Fury Road again, I drew hope from the character of Nux. An alt-warboy in thrall to a demagogue and raised on a diet of fake news (Valhalla! V8!) can not only be turned by tenderness, he can become an ally to those working for a better world. Witness! [...]



An associative trail

Mon, 20 Nov 2017 17:43:43 GMT

Every now and then, I like to revisit Vannevar Bush’s classic article from the July 1945 edition of the Atlantic Monthly called As We May Think in which he describes a theoretical machine called the memex. A memex is a device in which an individual stores all his books, records, and communications, and which is mechanized so that it may be consulted with exceeding speed and flexibility. It is an enlarged intimate supplement to his memory. It consists of a desk, and while it can presumably be operated from a distance, it is primarily the piece of furniture at which he works. On the top are slanting translucent screens, on which material can be projected for convenient reading. There is a keyboard, and sets of buttons and levers. Otherwise it looks like an ordinary desk. 1945! Apart from its analogue rather than digital nature, it’s a remarkably prescient vision. In particular, there’s the idea of “associative trails”: Wholly new forms of encyclopedias will appear, ready made with a mesh of associative trails running through them, ready to be dropped into the memex and there amplified. The lawyer has at his touch the associated opinions and decisions of his whole experience, and of the experience of friends and authorities. Many decades later, Anne Washington ponders what a legal memex might look like: My legal Memex builds a network of the people and laws available in the public records of politicians and organizations. The infrastructure for this vision relies on open data, free access to law, and instantaneously availability. As John Sheridan from the UK’s National Archives points out, hypertext is the perfect medium for laws: Despite the drafter’s best efforts to create a narrative structure that tells a story through the flow of provisions, legislation is intrinsically non-linear content. It positively lends itself to a hypertext based approach. The need for legislation to escape the confines of the printed form predates the all major innovators and innovations in hypertext, from Vannevar Bush’s vision in ” As We May Think“, to Ted Nelson’s coining of the term “hypertext”, through to and Berners-Lee’s breakthrough world wide web. I like to think that Nelson’s concept of transclusion was foreshadowed several decades earlier by the textual amendment (where one Act explicitly alters – inserts, omits or amends – the text of another Act, an approach introduced to UK legislation at the beginning of the 20th century). That’s from a piece called Deeply Intertwingled Laws. The verb “to intertwingle” was another one of Ted Nelson’s neologisms. There’s an associative trail from Vannevar Bush to Ted Nelson that takes some other interesting turns… Picture a new American naval recruit in 1945, getting ready to ship out to the pacific to fight against the Japanese. Just as the ship as leaving the harbour, word comes through that the war is over. And so instead of fighting across the islands of the pacific, this young man finds himself in a hut on the Philippines, reading whatever is to hand. There’s a copy of The Atlantic Monthly, the one with an article called As We May Think. The sailor was Douglas Engelbart, and a few years later when he was deciding how he wanted to spend the rest of his life, that article led him to pursue the goal of augmenting human intellect. He gave the mother of all demos, featuring NLS, a working hypermedia system. Later, thanks to Bill Atkinson, we’d get another system called Hypercard. It was advertised with the motto Freedom to Associate, in an advertising campaign that directly referenced Vannevar Bush. And now I’m using the World Wide Web, a hypermedia system that takes in the whole planet, to create an associative trail. In this post, I’m linking (without asking anyone for permission) to six different sources, and in doing so, I’m creating a unique associative trail. And because this post has a URL (that won’t change), you are fr[...]



Hooked and booked

Sat, 18 Nov 2017 18:55:25 GMT

At Booking.com, they do a lot of A/B testing. At Booking.com, they’ve got a lot of dark patterns. I think there might be a connection. A/B testing is a great way of finding out what happens when you introduce a change. But it can’t tell you why. I used the site earlier in the year, and actually felt my heart rate increase. Never again.— Paul Robert Lloyd (@paulrobertlloyd) October 24, 2017 The problem is that, in a data-driven environment, decisions ultimately come down to whether something works or not. But just because something works, doesn’t mean it’s a good thing. If I were trying to convince you to buy a product, or use a service, one way I could accomplish that would be to literally put a gun to your head. It would work. Except it’s not exactly a good solution, is it? But if we were to judge by the numbers (100% of people threatened with a gun did what we wanted), it would appear to be the right solution. When speaking about A/B testing at Booking.com, Stuart Frisby emphasised why it’s so central to their way of working: One of the core principles of our organisation is that we want to be very customer-focused. And A/B testing is really a way for us to institutionalise that customer focus. I’m not so sure. I think A/B testing is a way to institutionalise a focus on business goals—increasing sales, growth, conversion, and all of that. Now, ideally, those goals would align completely with the customer’s goals; happy customers should mean more sales …but more sales doesn’t necessarily mean happy customers. Using business metrics (sales, growth, conversion) as a proxy for customer satisfaction might not always work …and is clearly not the case with many of these kinds of sites. Whatever the company values might say, a company’s true focus is on whatever they’re measuring as success criteria. If that’s customer satisfaction, then the company is indeed customer-focused. But if the measurements are entirely about what works for sales and conversions, then that’s the real focus of the company. I’m not saying A/B testing is bad—far from it! (although it can sometimes be taken to the extreme). I feel it’s best wielded in combination with usability testing with real users—seeing their faces, feeling their frustration, sharing their joy. In short, I think that A/B testing needs to be counterbalanced. There should be some kind of mechanism for getting the answer to “why?” whenever A/B testing provides to the answer to “what?” In-person testing could be one way of providing that balance. Or it could be somebody’s job to always ask “why?” and determine if a solution is qualitatively—and not just quantitatively—good. (And if you look around at your company and don’t see anyone doing that, maybe that’s a role for you.) Curious: How many large companies have an ethics board? Or some kind of moral advisory role employed?— Erin Weigel (@endesignonline) November 2, 2017 If there really is a connection between having a data-driven culture of A/B testing, and a product that’s filled with dark patterns, then the disturbing conclusion is that dark patterns work …at least in the short term. [...]



Brighton conferences

Fri, 17 Nov 2017 16:51:30 GMT

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.

There was UX Brighton on November 3rd, featuring a terrific opening keynote from Boxman.

(image)

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.

(image)

Yesterday, I went to Meaning in the daytime, and Bytes in the evening.

(image)

Every one of those events was in Brighton. That’s pretty good going for a town this size …and that’s not even counting the regular events like Async, Codebar, and Ladies That UX.




What is a Progressive Web App?

Wed, 15 Nov 2017 18:52:40 GMT

It seems like any new field goes through an inevitable growth spurt that involves “defining the damn thing.” For the first few years of the IA Summit, every second presentation seemed to be about defining what Information Architecture actually is. See also: UX. See also: Content Strategy.

Now it seems to be happening with Progressive Web Apps …which is odd, considering the damn thing is defined damn well.

I’ve written before about the naming of Progressive Web Apps. On the whole, I think it’s a pretty good term, especially if you’re trying to convince the marketing team.

Regardless of the specifics of the name, what I like about Progressive Web Apps is that they have a clear definition. It reminds me of Responsive Web Design. Whatever you think of that name, it comes with a clear list of requirements:

  1. A fluid layout,
  2. Fluid images, and
  3. Media queries.

Likewise, Progressive Web Apps consist of:

  1. HTTPS,
  2. A service worker, and
  3. A Web App Manifest.

There’s more you can do in addition to that (just as there’s plenty more you can do on a responsive site), but the core definition is nice and clear.

Except, for some reason, that clarity is being lost.

Here’s a post by Ben Halpern called What the heck is a “Progressive Web App”? Seriously.

I have a really hard time describing what a progressive web app actually is.

He points to Google’s intro to Progressive Web Apps:

Progressive Web Apps are user experiences that have the reach of the web, and are:

  • Reliable - Load instantly and never show the downasaur, even in uncertain network conditions.
  • Fast - Respond quickly to user interactions with silky smooth animations and no janky scrolling.
  • Engaging - Feel like a natural app on the device, with an immersive user experience.

Those are great descriptions of the benefits of Progressive Web Apps. Perfect material for convincing your clients or your boss. But that appears on developers.google.com …surely it would be more beneficial for that audience to know the technologies that comprise Progressive Web Apps?

Ben Halpern again:

Google’s continued use of the term “quality” in describing things leaves me with a ton of confusion. It really seems like they want PWA to be a general term that doesn’t imply any particular implementation, and have it be focused around the user experience, but all I see over the web is confusion as to what they mean by these things. My website is already “engaging” and “immersive”, does that mean it’s a PWA?

I think it’s important to use the right language for the right audience.

If you’re talking to the business people, tell them about the return on investment you get from Progressive Web Apps.

If you’re talking to the marketing people, tell them about the experiential benefits of Progressive Web Apps.

But if you’re talking to developers, tell them that a Progressive Web App is a website served over HTTPS with a service worker and manifest file.




Installing Progressive Web Apps

Mon, 06 Nov 2017 09:53:58 GMT

When I was testing the dConstruct Audio Archive—which is now a Progressive Web App—I noticed some interesting changes in how Chrome on Android offers the “add to home screen” prompt. It used to literally say “add to home screen.” Now it simply says “add.” I vaguely remember there being some talk of changing the labelling, but I could’ve sworn it was going to change to “install”. I’ve got to be honest, just having the word “add” doesn’t seem to provide much context. Based on the quick’n’dirty usability testing I did with some co-workers, it just made things confusing. “Add what?” “What am I adding?” Additionally, the prompt appeared immediately on the first visit to the site. I thought there was supposed to be an added “engagement” metric in order for the prompt to appear; that the user needs to visit the site more than once. You’d think I’d be happy that users will be presented with the home-screen prompt immediately, but based on the behaviour I saw, I’m not sure it’s a good thing. Here’s what I observed: The user types the URL archive.dconstruct.org into the address bar. The site loads. The home-screen prompt slides up from the bottom of the screen. The user immediately moves to dismiss the prompt (cue me interjecting “Don’t close that!”). This behaviour is entirely unsurprising for three reasons: We web designers and web developers have trained users to dismiss overlays and pop-ups if they actually want to get to the content. Nobody’s going to bother to actually read the prompt if there’s a 99% chance it’s going to say “Sign up to our newsletter!” or “Take our survey!”. The prompt appears below the “line of death” so there’s no way to tell it’s a browser or OS-level dialogue rather than a JavaScript-driven pop-up from the site. Because the prompt now appears on the first visit, no trust has been established between the user and the site. If the prompt only appeared on later visits (or later navigations during the first visit) perhaps it would stand a greater chance of survival. It’s still possible to add a Progressive Web App to the home screen, but the option to do that is hidden behind the mysterious three-dots-vertically-stacked icon (I propose we call this the shish kebab icon to distinguish it from the equally impenetrable hamburger icon). I was chatting with Andreas from Mozilla at the View Source conference last week, and he was filling me in on how Firefox on Android does the add-to-homescreen flow. Instead of a one-time prompt, they’ve added a persistent icon above the “line of death” (the icon is a combination of a house and a plus symbol). title="Add to Home Screen feature in Firefox for Android" width="480" height="270" src="https://www.youtube.com/embed/cy0xW8gFmLA" gesture="media"> When a Firefox 58 user arrives on a website that is served over HTTPS and has a valid manifest, a subtle badge will appear in the address bar: when tapped, an “Add to Home screen” confirmation dialog will slide in, through which the web app can be added to the Android home screen. This kind of badging also has issues (without the explicit text “add to home screen”, the user doesn’t know what the icon does), but I think a more persistently visible option like this works better than the a one-time prompt. Firefox is following the lead of the badging approach pioneered by the Samsung Internet browser. It provides a plus symbol that, when pressed, reveals the options to add to home screen or simply bookmark. I don’t think Chrome for Android has any plans for this kind of badging, but they are working on letting the si[...]



The dConstruct Audio Archive works offline

Thu, 02 Nov 2017 15:41:37 GMT

The dConstruct conference is as old as Clearleft itself. We put on the first event back in 2005, the year of our founding. The last dConstruct was in 2015. It had a good run. 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. Caching To start with, there’s the no-brainer: as soon as someone hits the website, pre-cache static assets like CSS, JavaScript, the logo, and icon images. Now subsequent page loads will be quicker—those assets are taken straight from the cache. 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. [...]



Speak and repeat

Tue, 31 Oct 2017 19:59:53 GMT

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. 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. [...]