Journal tags: event

233

sparkline

Hosting online events

Back in 2014 Vitaly asked me if I’d be the host for Smashing Conference in Freiburg. I jumped at the chance. I thought it would be an easy gig. All of the advantages of speaking at a conference without the troublesome need to actually give a talk.

As it turned out, it was quite a bit of work:

It wasn’t just a matter of introducing each speaker—there was also a little chat with each speaker after their talk, so I had to make sure I was paying close attention to each and every talk, thinking of potential questions and conversation points. After two days of that, I was a bit knackered.

Last month, I hosted an other event, but this time it was online: UX Fest. Doing the post-talk interviews was definitely a little weirder online. It’s not quite the same as literally sitting down with someone. But the online nature of the event did provide one big advantage…

To minimise technical hitches on the day, and to ensure that the talks were properly captioned, all the speakers recorded their talks ahead of time. That meant I had an opportunity to get a sneak peek at the talks and prepare questions accordingly.

UX Fest had a day of talks every Thursday in June. There were four talks per Thursday. I started prepping on the Monday.

First of all, I just watched all the talks and let them wash me over. At this point, I’d often think “I’m not sure if I can come up with any questions for this one!” but I’d let the talks sit there in my subsconscious for a while. This was also a time to let connections between talks bubble up.

Then on the Tuesday and Wednesday, I went through the talks more methodically, pausing the video every time I thought of a possible question. After a few rounds of this, I inevitably ended up with plenty of questions, some better than others. So I then re-ordered them in descending levels of quality. That way if I didn’t get to the questions at the bottom of the list, it was no great loss.

In theory, I might not get to any of my questions. That’s because attendees could also ask questions on the day via a chat window. I prioritised those questions over my own. Because it’s not about me.

On some days there was a good mix of audience questions and my own pre-prepared questions. On other days it was mostly my own questions.

Either way, it was important that I didn’t treat the interview like a laundry list of questions to get through. It was meant to be a conversation. So the answer to one question might touch on something that I had made a note of further down the list, in which case I’d run with that. Or the conversation might go in a really interesting direction completely unrelated to the questions or indeed the talk.

Above all, these segments needed to be engaging and entertaining in a personable way, more like a chat show than a post-game press conference. So even though I had done lots of prep for interviewing each speaker, I didn’t want to show my homework. I wanted each interview to feel like a natural flow.

To quote the old saw, this kind of spontaneity takes years of practice.

There was an added complication when two speakers shared an interview slot for a joint Q&A. Not only did I have to think of questions for each speaker, I also had to think of questions that would work for both speakers. And I had to keep track of how much time each person was speaking so that the chat wasn’t dominated by one person more than the other. This was very much like moderating a panel, something that I enjoy very much.

In the end, all of the prep paid off. The conversations flowed smoothly and I was happy with some of the more thought-provoking questions that I had researched ahead of time. The speakers seemed happy too.

Y’know, there are not many things I’m really good at. I’m a mediocre developer, and an even worse designer. I’m okay at writing. But I’m really good at public speaking. And I think I’m pretty darn good at this hosting lark too.

Speaking about sci-fi

I’m going to be speaking at the Beyond Tellerrand “Stay Curious” event on June 16th. But I’m not going to be talking about anything (directly) web-related…

The topic for the evening is science fiction. There’ll be a talk from me, a talk from Steph, and then a discussion, which I’m really looking forward to.

I got together with Steph last week, which was really fun—we could’ve talked for hours! We compared notes and figured out a way to divvy up the speaking slots. Steph is going to do a deep dive into one specific subgenre of sci-fi. So to set the scene, I’m going to give a broad but shallow overview of the history of sci-fi. To keep things managable, I’m only going to be talking about sci-fi literature (although we can get into films, TV, and anything else in the discussion afterwards).

But I don’t want to just regurgitate facts like a Wikipedia article. I’ve decided that the only honest thing to do is give my own personal history with sci-fi. Instead of trying to give an objective history, I’m going to tell a personal story …even if that means being more open and vulnerable.

I think I’ve got the arc of the story I want to tell. I’ve been putting slides together and I’m quite excited now. I’ve realised I’ve got quite a lot to say. But I don’t want the presentation to get too long. I want to keep it short and snappy so that there’s plenty of time for the discussion afterwards. That’s going to be the best part!

That’s where you come in. The discussion will be driven by the questions and chat from the attendees. Tickets are available on a pay-what-you-want basis, with a minimum price of just €10. It’ll be an evening event, starting at 6:30pm UK time, 7:30pm in central Europe. So if you’re in the States, that’ll be your morning or afternoon.

Come along if you have any interest in sci-fi. If you have no interest in sci-fi, then please come along—we can have a good discusison about it.

See you on June 16th!

Hosting UX Fest

I quite enjoy interviewing people. I don’t mean job interviews. I mean, like, talk show interviews. I’ve had a lot of fun over the years moderating panel discussions: @media Ajax in 2007, SxSW in 2008, Mobilism in 2011, the Progressive Web App Dev Summit and EnhanceConf in 2016.

I’ve even got transcripts of some panels I’ve moderated:

I enjoyed each and every one. I also had the pleasure of interviewing the speakers at every Responsive Day Out. Hosting events like that is a blast, but what with The Situation and all, there hasn’t been much opportunity for hosting conferences.

Well, I’m going to be hosting an event next month: UX Fest. It’s this year’s online version of UX London.

An online celebration of digital design, taking place throughout June 2021.

I am simultaneously excited and nervous. I’m excited because I’ll have the chance to interview a whole bunch of really smart people. I’m nervous because it’s all happening online and that might feel quite different to an in-person discussion.

But I have an advantage. While the interviews will be live, the preceding talks will be pre-recorded. That means I have to time watch and rewatch each talk, spot connections between them, and think about thought-provoking questions for each speaker.

So that’s what I’m doing between now and the beginning of June. If you’d like to bear witness to the final results, I encourage you to get a ticket for UX Fest. You can come to the three-day conference in the first week of June, or you can get a ticket for the festival spread out over the following three Thursdays in June, or you can get a combo ticket for both and save some money.

There’s an inclusion programme for the conference and festival days:

Anyone from an underrepresented group is invited to apply. We especially invite and welcome Black, indigenous & people of colour, LGBTQIA+ people and people with disabilities.

Here’s the application form.

There’ll also be a whole bunch of hands-on masterclasses throughout June that you can book individually. I won’t be hosting those though. I’ll have plenty to keep me occupied hosting the conference and the festival.

I hope you’ll join me along with Krystal Higgins, David Dylan Thomas, Catt Small, Scott Kubie, Temi Adeniyi, Teresa Torres, Tobias Ahlin and many more wonderful speakers—it’s going to fun!

The State of the Web — the links

An Event Apart Spring Summit is happening right now. I opened the show yesterday with a talk called The State Of The Web:

The World Wide Web has come a long way in its three decades of existence. There’s so much we can do now with HTML, CSS, and JavaScript: animation, layout, powerful APIs… we can even make websites that work offline! And yet the web isn’t exactly looking rosy right now. The problems we face aren’t technical in nature. We’re facing a crisis of expectations: we’ve convinced people that the web is slow, buggy, and inaccessible. But it doesn’t have to be this way. There is no fate but what we make. In this perspective-setting talk, we’ll go on a journey to the past, present, and future of web design and development. You’ll laugh, you’ll cry, and by the end, you’ll be ready to make the web better.

I wrote about preparing this talk and you can see the outline on Kinopio. I thought it turned out well, but I never actually know until people see it. So I’m very gratified and relieved that it went down very well indeed. Phew!

Eric and the gang at An Event Apart asked for a round-up of links related to this talk and I was more than happy to oblige. I’ve separated them into some of the same categories that the talk covers.

I know that these look like a completely disconnected grab-bag of concepts—you’d have to see the talk to get the connections. But even without context, these are some rabbit holes you can dive down…

Apollo 8

Hypertext

The World Wide Web

NASA

This (somewhat epic) slidedeck is done.

Done

Remember how I said I was preparing an online conference talk? Well, I’m happy to say that not only is the talk prepared, but I’ve managed to successfully record it too.

If you want to see the finished results, come along to An Event Apart Spring Summit on April 19th. To sweeten the deal, I’ve got a discount code you can use when you buy any multi-day pass: AEAJEREMY.

Recording the talk took longer than I thought it would. I think it was because I said this:

It feels a bit different to prepare a talk for pre-recording rather than live delivery on stage. In fact, it feels less like preparing a conference talk and more like making a documentary.

Once I got that idea in my head, I think I became a lot fussier about the quality of the recording. “Would David Attenborough allow his documentaries to have the sound of a keyboard audibly being pressed? No! Start again!”

I’m pleased with the final results. And I’m really looking forward to the post-presentation discussion with questions from the audience. The talk gets provocative—and maye a bit ranty—towards the end so it’ll be interesting to see how people react to that.

It feels good to have the presentation finished, but it also feels …weird. It’s like the feeling that conference organisers get once the conference is over. You spend all this time working towards something and then, one day, it’s in the past instead of looming in the future. It can make you feel kind of empty and listless. Maybe it’s the same for big product launches.

The two big projects I’ve been working on for the past few months were this talk and season two of the Clearleft podcast. The talk is in the can and so is the final episode of the podcast season, which drops tomorrow.

On the one hand, it’s nice to have my decks cleared. Nothing work-related to keep me up at night. But I also recognise the growing feeling of doubt and moodiness, just like the post-conference blues.

The obvious solution is to start another big project, something on the scale of making a brand new talk, or organising a conference, or recording another podcast season, or even writing a book.

The other option is to take a break for a while. Seeing as the UK government has extended its furlough scheme, maybe I should take full advantage of it. I went on furlough for a while last year and found it to be a nice change of pace.

Preparing an online conference talk

I’m terrible at taking my own advice.

Hana wrote a terrific article called You’re on mute: the art of presenting in a Zoom era. In it, she has very kind things to say about my process for preparing conference talks.

As it happens, I’m preparing a conference talk right now for delivery online. Am I taking my advice about how to put a talk together? I am on me arse.

Perhaps the most important part of the process I shared with Hana is that you don’t get too polished too soon. Instead you get everything out of your head as quickly as possible (probably onto disposable bits of paper) and only start refining once you’re happy with the rough structure you’ve figured out by shuffling those bits around.

But the way I’ve been preparing this talk has been more like watching a progress bar. I started at the start and even went straight into slides as the medium for putting the talk together.

It was all going relatively well until I hit a wall somewhere between the 50% and 75% mark. I was blocked and I didn’t have any rough sketches to fall back on. Everything was a jumbled mess in my brain.

It all came to a head at the start of last week when that jumbled mess in my brain resulted in a very restless night spent tossing and turning while I imagined how I might complete the talk.

This is a terrible way of working and I don’t recommend it to anyone.

The problem was I couldn’t even return to the proverbial drawing board because I hadn’t given myself a drawing board to return to (other than this crazy wall of connections on Kinopio).

My sleepless night was a wake-up call (huh?). The next day I forced myself to knuckle down and pump out anything even if it was shit—I could refine it later. Well, it turns out that just pumping out any old shit was exactly what I needed to do. The act of moving those fingers up and down on the keyboard resulted in something that wasn’t completely terrible. In fact, it turned out pretty darn good.

Past me said:

The idea here is to get everything out of my head.

I should’ve listened to that guy.

At this point, I think I’ve got the talk done. The progress bar has reached 100%. I even think that it’s pretty good. A giveaway for whether a talk is any good is when I find myself thinking “Yes, this has good points well made!” and then five minutes later I’m thinking “Wait, is this complete rubbish that’s totally obvious and doesn’t make much sense?” (see, for example, every talk I’ve ever prepared ever).

Now I just to have to record it. The way that An Event Apart are running their online editions is that the talks are pre-recorded but followed with live Q&A. That’s how the Clearleft events team have been running the conference part of the Leading Design Festival too. Last week there were three days of this format and it worked out really, really well. This week there’ll be masterclasses which are delivered in a more synchronous way.

It feels a bit different to prepare a talk for pre-recording rather than live delivery on stage. In fact, it feels less like preparing a conference talk and more like making a documentary. I guess this is what life is like for YouTubers.

I think the last time I was in a cinema before The Situation was at the wonderful Duke of York’s cinema here in Brighton for an afternoon showing of The Proposition followed by a nice informal chat with the screenwriter, one Nick Cave, local to this parish. It was really enjoyable, and that’s kind of what Leading Design Festival felt like last week.

I wonder if maybe we’ve been thinking about online events with the wrong metaphor. Perhaps they’re not like conferences that have moved online. Maybe they’re more like film festivals where everyone has the shared experience of watching a new film for the first time together, followed by questions to the makers about what they’ve just seen.

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.

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.

Saving forms

I added a long-overdue enhancement to The Session recently. Here’s the scenario…

You’re on a web page with a comment form. You type your well-considered thoughts into a textarea field. But then something happens. Maybe you accidentally navigate away from the page or maybe your network connection goes down right when you try to submit the form.

This is a textbook case for storing data locally on the user’s device …at least until it has safely been transmitted to the server. So that’s what I set about doing.

My first decision was choosing how to store the data locally. There are multiple APIs available: sessionStorage, IndexedDB, localStorage. It was clear that sessionStorage wasn’t right for this particular use case: I needed the data to be saved across browser sessions. So it was down to IndexedDB or localStorage. IndexedDB is the more versatile and powerful—because it’s asynchronous—but localStorage is nice and straightforward so I decided on that. I’m not sure if that was the right decision though.

Alright, so I’m going to store the contents of a form in localStorage. It accepts key/value pairs. I’ll make the key the current URL. The value will be the contents of that textarea. I can store other form fields too. Even though localStorage technically only stores one value, that value can be a JSON object so in reality you can store multiple values with one key (just remember to parse the JSON when you retrieve it).

Now I know what I’m going to store (the textarea contents) and how I’m going to store it (localStorage). The next question is when should I do it?

I could play it safe and store the comment whenever the user presses a key within the textarea. But that seems like overkill. It would be more efficient to only save when the user leaves the current page for any reason.

Alright then, I’ll use the unload event. No! Bad Jeremy! If I use that then the browser can’t reliably add the current page to the cache it uses for faster back-forwards navigations. The page life cycle is complicated.

So beforeunload then? Well, maybe. But modern browsers also support a pagehide event that looks like a better option.

In either case, just adding a listener for the event could screw up the caching of the page for back-forwards navigations. I should only listen for the event if I know that I need to store the contents of the textarea. And in order to know if the user has interacted with the textarea, I’m back to listening for key presses again.

But wait a minute! I don’t have to listen for every key press. If the user has typed anything, that’s enough for me. I only need to listen for the first key press in the textarea.

Handily, addEventListener accepts an object of options. One of those options is called “once”. If I set that to true, then the event listener is only fired once.

So I set up a cascade of event listeners. If the user types anything into the textarea, that fires an event listener (just once) that then adds the event listener for when the page is unloaded—and that’s when the textarea contents are put into localStorage.

I’ve abstracted my code into a gist. Here’s what it does:

  1. Cut the mustard. If this browser doesn’t support localStorage, bail out.
  2. Set the localStorage key to be the current URL.
  3. If there’s already an entry for the current URL, update the textarea with the value in localStorage.
  4. Write a function to store the contents of the textarea in localStorage but don’t call the function yet.
  5. The first time that a key is pressed inside the textarea, start listening for the page being unloaded.
  6. When the page is being unloaded, invoke that function that stores the contents of the textarea in localStorage.
  7. When the form is submitted, remove the entry in localStorage for the current URL.

That last step isn’t something I’m doing on The Session. Instead I’m relying on getting something back from the server to indicate that the form was successfully submitted. If you can do something like that, I’d recommend that instead of listening to the form submission event. After all, something could still go wrong between the form being submitted and the data being received by the server.

Still, this bit of code is better than nothing. Remember, it’s intended as an enhancement. You should be able to drop it into any project and improve the user experience a little bit. Ideally, no one will ever notice it’s there—it’s the kind of enhancement that only kicks in when something goes wrong. A little smidgen of resilient web design. A defensive enhancement.

Design Principles For The Web—the links

I’m speaking today at an online edition of An Event Apart called Front-End Focus. I’ll be opening up the show with a talk called Design Principles For The Web, which ironically doesn’t have much of a front-end focus:

Designing and developing on the web can feel like a never-ending crusade against the unknown. Design principles are one way of unifying your team to better fight this battle. But as well as the design principles specific to your product or service, there are core principles underpinning the very fabric of the World Wide Web itself. Together, we’ll dive into applying these design principles to build websites that are resilient, performant, accessible, and beautiful.

That explains why I’ve been writing so much about design principles …well, that and the fact that I’m mildly obsessed with them.

To avoid technical difficulties, I’ve pre-recorded the talk. So while that’s playing, I’ll be spamming the accompanying chat window with related links. Then I’ll do a live Q&A.

Should you be interested in the links that I’ll be bombarding the attendees with, I’ve gathered them here in one place (and they’re also on the website of An Event Apart). The narrative structure of the talk might not be clear from scanning down a list of links, but there’s some good stuff here that you can dive into if you want to know what the inside of my head is like.

References

adactio.com

Wikipedia

Putting design principles into action

I was really looking forward to speaking at An Event Apart this year. I was going to be on the line-up for Seattle, Boston, and Minneapolis; three cities I really like.

At the start of the year, I decided to get a head-start on my new talk so I wouldn’t be too stressed out when the first event approached. I spent most of January and February going through the chaotic process of assembling a semi-coherent presentation out of a katamari of vague thoughts.

I was making good progress. Then The Situation happened. One by one, the in-person editions of An Event Apart were cancelled (quite rightly). But my talk preparation hasn’t been in vain. I’ll be presenting my talk at an online edition of An Event Apart on Monday, August 17th.

You should attend. Not for my talk, but for Ire’s talk on Future-Proof CSS which sounds like it was made for me:

In this talk, we’ll cover how to write CSS that stands the test of time. From progressive enhancement techniques to accessibility considerations, we’ll learn how to write CSS for 100 years in the future (and, of course, today).

My talk will be about design principles …kinda. As usual, it will be quite a rambling affair. At this point I almost take pride in evoking a reaction of “where’s he going with this?” during the first ten minutes of a talk.

When I do actually get around to the point of the talk—design principles—I ask whether it’s possible to have such a thing as universal principles. After all, the whole point of design principles is that they’re specific to an endeavour, whether that’s a company, an organisation, or a product.

I think that some principles are, if not universal, then at least very widely applicable. I’ve written before about two of my favourites: the robustness principle and the principle of least power:

There’s no shortage of principles, laws, and rules out there, and I find many of them very useful, but if I had to pick just two that are particularly applicable to my work, they would be the robustness principle and the rule of least of power.

What’s interesting about both of those principles is that they are imperative. They tell you how to act:

Be conservative in what you send, be liberal in what you accept.

Choose the least powerful language suitable for a given purpose.

Other princples are imperative, but they tell you what not to do. Take the razors of Occam and Hanlon, for example:

Entities are not to be multiplied without necessity.

Never attribute to malice that which is adequately explained by stupidity.

But these imperative principles are exceptions. The vast majority of “universal” principles take the form of laws that are observations. They describe the state of the world without providing any actions to take.

There’s Hofstadter’s Law, for example:

It always takes longer than you expect, even when you take into account Hofstadter’s Law.

Or Clarke’s third law:

Any sufficiently advanced technology is indistinguishable from magic.

By themselves, these observational laws are interesting but they leave it up to you to decide on a course of action. On the other hand, imperative principles tell you what to do but don’t tell you why.

It strikes me that it could be fun (and useful) to pair up observational and imperative principles:

Because of observation A, apply action B.

For example:

Because of Murphy’s Law, apply the principle of least power.

Or in its full form:

Because anything that can go wrong will go wrong, choose the least powerful language suitable for a given purpose.

I feel like the Jevons paradox is another observational principle that should inform our work on the web:

The Jevons paradox occurs when technological progress increases the efficiency with which a resource is used, but the rate of consumption of that resource rises because of increasing demand.

For example, even though devices, browsers, and networks are much, much better now than they were, say, ten years ago, that doesn’t mean that websites have become better or faster. Instead, it’s precisely because there’s more power available that people think nothing of throwing megabytes of JavaScript at users. See Scott’s theory that 5G Will Definitely Make the Web Slower, Maybe:

JavaScript size has ballooned as networks have improved.

This problem would be addressed if web developers were more conservative in what they sent. The robustness principle in action.

Because of the Jevons paradox, apply the robustness principle.

Admittedly, the expanded version of that is far too verbose:

Because technological progress increases the efficiency with which a resource is used, but the rate of consumption of that resource rises because of increasing demand, be conservative in what you send, be liberal in what you accept.

I’m sure there are more and better pairings to be made: an observational principle to tell you why you should take action, and an imperative principle to tell you what action you should take.

Reading

At the beginning of the year, Remy wrote about extracting Goodreads metadata so he could create his end-of-year reading list. More recently, Mark Llobrera wrote about how he created a visualisation of his reading history. In his case, he’s using JSON to store the information.

This kind of JSON storage is exactly what Tom Critchlow proposes in his post, Library JSON - A Proposal for a Decentralized Goodreads:

Thinking through building some kind of “web of books” I realized that we could use something similar to RSS to build a kind of decentralized GoodReads powered by indie sites and an underlying easy to parse format.

His proposal looks kind of similar to what Mark came up with. There’s a title, an author, an image, and some kind of date for when you started and/or finished reading the book.

Matt then points out that RSS gets close to the data format being suggested and asks how about using RSS?:

Rather than inventing a new format, my suggestion is that this is RSS plus an extension to deal with books. This is analogous to how the podcast feeds are specified: they are RSS plus custom tags.

Like Matt, I’m in favour of re-using existing wheels rather than inventing new ones, mostly to avoid a 927 situation.

But all of these proposals—whether JSON or RSS—involve the creation of a separate file, and yet the information is originally published in HTML. Along the lines of Matt’s idea, I could imagine extending the h-entry collection of class names to allow for books (or films, or other media). It already handles images (with u-photo). I think the missing fields are the date-related ones: when you start and finish reading. Those fields are present in a different microformat, h-event in the form of dt-start and dt-end. Maybe they could be combined:


<article class="h-entry h-event h-review">
<h1 class="p-name p-item">Book title</h1>
<img class="u-photo" src="image.jpg" alt="Book cover.">
<p class="p-summary h-card">Book author</p>
<time class="dt-start" datetime="YYYY-MM-DD">Start date</time>
<time class="dt-end" datetime="YYYY-MM-DD">End date</time>
<div class="e-content">Remarks</div>
<data class="p-rating" value="5">★★★★★</data>
<time class="dt-published" datetime="YYYY-MM-DDThh:mm">Date of this post</time>
</article>

That markup is simultaneously a post (h-entry) and an event (h-event) and you can even throw in h-card for the book author (as well as h-review if you like to rate the books you read). It can be converted to RSS and also converted to .ics for calendars—those parsers are already out there. It’s ready for aggregation and it’s ready for visualisation.

I publish very minimal reading posts here on adactio.com. What little data is there isn’t very structured—I don’t even separate the book title from the author. But maybe I’ll have a little play around with turning these h-entries into combined h-entry/event posts.

Indie Web Camp London 2020

Do you have plans for the weekend of March 14th and 15th?

If you live anywhere near London, might I suggest that you sign up for Indie Web Camp.

Cheuk and Ana are putting it together with assistance from Calum. As always, there will be one day of Barcamp-style discussions, followed by a fun hands-on day of making.

If you’re wondering whether this is for you, ask yourself if any of this situations apply:

  • You don’t have your own website yet, but you want one.
  • You have your own website, but you need some help with it.
  • You have some ideas about the independent web.
  • You have your own website but you never seem to find the time to update it.
  • You’d like to help other people with their websites.

If you recognise yourself in any one of those scenarios, then you should definitely come along to Indie Web Camp London 2020!

Liveblogging An Event Apart 2019

I was at An Event Apart in San Francisco last week. It was the last one of the year, and also my last conference of the year.

I managed to do a bit of liveblogging during the event. Combined with the liveblogging I did during the other two Events Apart that I attended this year—Seattle and Chicago—that makes a grand total of seventeen liveblogged presentations!

  1. Slow Design for an Anxious World by Jeffrey Zeldman
  2. Designing for Trust in an Uncertain World by Margot Bloomstein
  3. Designing for Personalities by Sarah Parmenter
  4. Generation Style by Eric Meyer
  5. Making Things Better: Redefining the Technical Possibilities of CSS by Rachel Andrew
  6. Designing Intrinsic Layouts by Jen Simmons
  7. How to Think Like a Front-End Developer by Chris Coyier
  8. From Ideation to Iteration: Design Thinking for Work and for Life by Una Kravets
  9. Move Fast and Don’t Break Things by Scott Jehl
  10. Mobile Planet by Luke Wroblewski
  11. Unsolved Problems by Beth Dean
  12. Making Research Count by Cyd Harrell
  13. Voice User Interface Design by Cheryl Platz
  14. Web Forms: Now You See Them, Now You Don’t! by Jason Grigsby
  15. The Weight of the WWWorld is Up to Us by Patty Toland
  16. The Mythology of Design Systems by Mina Markham
  17. The Technical Side of Design Systems by Brad Frost

For my part, I gave my talk on Going Offline. Time to retire that talk now.

Here’s what I wrote when I first gave the talk back in March at An Event Apart Seattle:

I was quite nervous about this talk. It’s very different from my usual fare. Usually I have some big sweeping arc of history, and lots of pretentious ideas joined together into some kind of narrative arc. But this talk needed to be more straightforward and practical. I wasn’t sure how well I would manage that brief.

I’m happy with how it turned out. I had quite a few people come up to me to say how much they appreciated how I was explaining the code. That was very nice to hear—I really wanted this talk to be approachable for everyone, even though it included plenty of JavaScript.

The dates for next year’s Events Apart have been announced, and I’ll be speaking at three of them:

The question is, do I attempt to deliver another practical code-based talk or do I go back to giving a high-level talk about ideas and principles? Or, if I really want to challenge myself, can I combine the two into one talk without making a Frankenstein’s monster?

Come and see me at An Event Apart in 2020 to find out.

The Technical Side of Design Systems by Brad Frost

Day two of An Event Apart San Francisco is finishing with a talk from Brad on design systems (so hot right now!):

You can have a killer style guide website, a great-looking Sketch library, and robust documentation, but if your design system isn’t actually powering real software products, all that effort is for naught. At the heart of a successful design system is a collection of sturdy, robust front-end components that powers other applications’ user interfaces. In this talk, Brad will cover all that’s involved in establishing a technical architecture for your design system. He’ll discuss front-end workshop environments, CSS architecture, implementing design tokens, popular libraries like React and Vue.js, deploying design systems, managing updates, and more. You’ll come away knowing how to establish a rock-solid technical foundation for your design system.

I will attempt to liveblog the Frostmeister…

“Design system” is an unfortunate name …like “athlete’s foot.” You say it to someone and they think they know what you mean, but nothing could be further from the truth.

As Mina said:

A design system is a set of rules enforced by culture, process and tooling that govern how your organization creates products.

A design system the story of how an organisation gets things done.

When Brad talks to companies, he asks “Have you got a design system?” They invariably say they do …and then point to a Sketch library. When the focus goes on the design side of the process, the production side can suffer. There’s a gap between the comp and the live site. The heart and soul of a design system is a code library of reusable UI components.

Brad’s going to talk through the life cycle of a project.

Sell

He begins with selling in a design system. That can start with an interface inventory. This surfaces visual differences. But even if you have, say, buttons that look the same, the underlying code might not be consistent. Each one of those buttons represents time and effort. A design system gives you a number of technical benefits:

  • Reduce technical debt—less frontend spaghetti code.
  • Faster production—less time coding common UI components and more time building real features.
  • Higher-quality production—bake in and enforce best practices.
  • Reduce QA efforts—centralise some QA tasks.
  • Potentially adopt new technologies faster—a design system can help make additional frameworks more managable.
  • Useful reference—an essential resource hub for development best practices.
  • Future-friendly foundation—modify, extend, and improve over time.

Once you’ve explained the benefits, it’s time to kick off.

Kick off

Brad asks “What’s yer tech stack?” There are often a lot of tech stacks. And you know what? Users don’t care. What they see is one brand. That’s the promise of a design system: a unified interface.

How do you make a design system deal with all the different tech stacks? You don’t (at least, not yet). Start with a high priority project. Use that as a pilot project for the design system. Dan talks about these projects as being like television pilots that could blossom into a full season.

Plan

Where to build the design system? The tech stack under the surface is often an order of magnitude greater than the UI code—think of node modules, for example. That’s why Brad advocates locking off that area and focusing on what he calls a frontend workshop environment. Think of the components as interactive comps. There are many tools for this frontend workshop environment: Pattern Lab, Storybook, Fractal, Basalt.

How are you going to code this? Brad gets frontend teams in a room together and they fight. Have you noticed that developers have opinions about things? Brad asks questions. What are your design principles? Do you use a CSS methodology? What tools do you use? Spaces or tabs? Then Brad gets them to create one component using the answers to those questions.

Guidelines are great but you need to enforce them. There are lots of tools to automate coding style.

Then there’s CSS architecture. Apparently we write our styles in React now. Do you really want to tie your CSS to one environment like that?

You know what’s really nice? A good ol’ sturdy cacheable CSS file. It can come in like a fairy applying all the right styles regardless of tech stack.

Design and build

Brad likes to break things down using his atomic design vocabulary. He echoes what Mina said earlier:

Embrace the snowflakes.

The idea of a design system is not to build 100% of your UI entirely from components in the code library. The majority, sure. But it’s unrealistic to expect everything to come from the design system.

When Brad puts pages together, he pulls in components from the code library but he also pulls in one-off snowflake components where needed.

The design system informs our product design. Our product design informs the design system.

—Jina

Brad has seen graveyards of design systems. But if you make a virtuous circle between the live code and the design system, the design system has a much better chance of not just surviving, but thriving.

So you go through those pilot projects, each one feeding more and more into the design system. Lather, rinse, repeat. The first one will be time consuming, but each subsequent project gets quicker and quicker as you start to get the return on investment. Velocity increases over time.

It’s like tools for a home improvement project. The first thing you do is look at your current toolkit. If you don’t have the tool you need, you invest in buying that new tool. Now that tool is part of your toolkit. Next time you need that tool, you don’t have to go out and buy one. Your toolkit grows over time.

The design system code must be intuitive for developers using it. This gets into the whole world of API design. It’s really important to get this right—naming things consistently and having predictable behaviour.

Mina talked about loose vs. strict design systems. Open vs. locked down. Make your components composable so they can adapt to future requirements.

You can bake best practices into your design system. You can make accessibility a requirement in the code.

Launch

What does it mean to “launch” a design system?

A design system isn’t a project with an end, it’s the origin story of a living and evolving product that’ll serve other products.

—Nathan Curtis

There’s a spectrum of integration—how integrated the design system is with the final output. The levels go from:

  1. Least integrated: static.
  2. Front-end reference code.
  3. Most integrated: consumable compents.

Chris Coyier in The Great Divide talked about how wide the spectrum of front-end development is. Brad, for example, is very much at the front of the front end. Consumable UI components can create a bridge between the back of the front end and the front of the front end.

Consumable UI components need to be bundled, packaged, and published.

Maintain

Now we’ve entered a new mental space. We’ve gone from “Let’s build a website” to “Let’s maintain a product which other products use as a dependency.” You need to start thinking about things like semantic versioning. A version number is a promise.

A 1.0.0 designation comes with commitment. Freewheeling days of unstable early foundations are behind you.

—Nathan Curtis

What do you do when a new tech stack comes along? How does your design system serve the new hotness. It gets worse: you get products that aren’t even web based—iOS, Android, etc.

That’s where design tokens come in. You can define your design language in a platform-agnostic way.

Summary

This is hard.

  • Your design system must live in the technologies your products use.
  • Look at your product roadmaps for design system pilot project opportunities.
  • Establish code conventions and use tooling and process to enforce them.
  • Build your design system and pilot project UI screens in a frontend workshop environment.
  • Bake best practices into reusable components & make them as rigid or flexible as you need them to be.
  • Use semantic versioning to manage ongoing design system product work.
  • Use design tokens to feed common design properties into different platforms.

You won’t do it all at once. That’s okay. Baby steps.

The Mythology of Design Systems by Mina Markham

It’s day two of An Event Apart San Francisco. The brilliant Mina Markham is here to talk to us about design systems (so hot right now!). I’m going to attempt to liveblog it:

Design systems have dominated web design conversations for a few years. Just as there’s no one way to make a website, there is no one way to make a design system. Unfortunately this has led to a lot of misconceptions around the creation and impact of this increasingly important tool.

Drawing on her experiences building design systems at two highly visible and vastly different organizations, Mina will debunk some common myths surrounding design systems.

Mina is a designer who codes. Or an engineer who designs. She makes websites. She works at Slack, but she doesn’t work on the product; she works on slack.com and the Slack blog. Mina also makes design systems. She loves design systems!

There are some myths she’s heard about design systems that she wants to dispel. She will introduce us to some mythological creatures along the way.

Myth 1: Designers “own” the design system

Mina was once talking to a product designer about design systems and was getting excited. The product designer said, nonplussed, “Aren’t you an engineer? Why do you care?” Mina explained that she loved design systems. The product designer said “Y’know, design systems should really be run by designers” and walked away.

Mina wondered if she had caused offense. Was she stepping on someone’s toes? The encounter left her feeling sad.

Thinking about it later, she realised that the conversation about design systems is dominated by product designers. There was a recent Twitter thread where some engineers were talking about this: they felt sidelined.

The reality is that design systems should be multi-disciplinary. That means engineers but it also means other kinds of designers other than product designers too: brand designers, content designers, and so on.

What you need is a hybrid, or unicorn: someone with complimentary skills. As Jina has said, design systems themselves are hybrids. Design systems give hybrids (people) a home. Hybrids help bring unity to an organization.

Myth 2: design systems kill creativity

Mina hears this one a lot. It’s intertwined with some other myths: that design systems don’t work for editorial content, and that design systems are just a collection of components.

Components are like mermaids. Everyone knows what one is supposed to look like, and they can take many shapes.

But if you focus purely on components, then yes, you’re going to get frustrated by a feeling of lacking creativity. Mina quotes @brijanp saying “Great job scrapbookers”.

Design systems encompass more than components:

  • High level principles.
  • Brand guidelines.
  • Coding standards.
  • Accessibility compliance.
  • Governance.

A design system is a set of rules enforced by culture, process and tooling that govern how your organization creates products.

—Mina

Rules and creativity are not mutually exclusive. Rules can be broken.

For a long time, Mina battled against one-off components. But then she realised that if they kept coming up, there must be a reason for them. There is a time and place for diverging from the system.

It’s like Alice Lee says about illustrations at Slack:

There’s a time and place for both—illustrations as stock components, and illustrations as intentional complex extensions of your specific brand.

Yesenia says:

Your design system is your pantry, not your cookbook.

If you keep combining your ingredients in the same way, then yes, you’ll keep getting the same cake. But if you combine them in different ways, there’s a lot of room for creativity. Find the key moments of brand expression.

There are strict and loose systems.

Strict design systems are what we usually think of. AirBnB’s design system is a good example. It’s detailed and tightly controlled.

A loose design system will leave more space for experimentation. TED’s design system consists of brand colours and wireframes. Everything else is left to you:

Consistency is good only insofar as it doesn’t prevent you from trying new things or breaking out of your box when the context justifies it.

Yesenia again:

A good design sytem helps you improvise.

Thinking about strict vs. loose reminds Mina of product vs. marketing. A design system for a product might need to be pixel perfect, whereas editorial design might need more breathing room.

Mina has learned to stop fighting the one-off snowflake components in a system. You want to enable the snowflakes without abandoning the system entirely.

A loose system is key for maintaining consistency while allowing for exploration and creativity.

Myth 3: a design system is a side project

Brad guffaws at this one.

Okay, maybe no one has said this out loud, but you definitely see a company’s priorities focused on customer-facing features. A design system is seen as something for internal use only. “We’ll get to this later” is a common refrain.

“Later” is a mythical creature—a phoenix that will supposedly rise from the ashes of completed projects. Mina has never seen a phoenix. You never see “later” on a roadmap.

Don’t treat your design system as a second-class system. If you do, it will not mature. It won’t get enough time and resources. Design systems require real investment.

Mina has heard from people trying to start design systems getting the advice, “Just do it!” It seems like good advice, but it could be dangerous. It sets you up for failure (and burnout). “Just doing it” without support is setting people up for a bad experience.

The alternative is to put it on the roadmap. But…

Myth 4: a design system should be on the product roadmap

At a previous company, Mina once put a design system on the product roadmap because she saw it wasn’t getting the attention it needed. The answer came back: nah. Mina was annoyed. She had tried to “just do it” and now when she tried to do it through the right channels, she’s told she can’t.

But Mina realised that it’s not that simple. There are important metrics she might not have been aware of.

A roadmap is multi-faceted thing, like Cerebus, the three-headed dog of the underworld.

Okay, so you can’t put the design sytem on the roadmap, but you can tie it to something with a high priority. You could refactor your way to a design system. Or you could allocate room in your timeline to slip in design systems work (pad your estimates a little). This is like a compromise between “Just do it!” and “Put it on the roadmap.”

A system’s value is realized when products ship features that use a system’s parts.

—Nathan Curtis

The other problem with putting a design system on the roadmap is that it implies there’s an end date. But a design system is never finished (unless you abandon it).

Myth 5: our system should do what XYZ’s system did

It’s great that there are so many public design systems out there to look to and get inspired by. We can learn from them. “Let’s do that!”

But those inspiring public systems can be like a succubus. They’re powerful and seductive and might seem fun at first but ultimately leave you feeling intimidated and exhausted.

Your design system should be build for your company’s specific needs, not Google’s or Github’s or anyone’s.

Slack has multiple systems. There’s one for the product called Slack Kit. It’s got great documentation. But if you go on Slack’s marketing website, it doesn’t look like the product. It doesn’t use the same typography or even colour scheme. So it can’t use the existing the design system. Mina created the Spacesuit design system specifically for the marketing site. The two systems are quite different but they have some common goals:

  • Establish common language.
  • Reduce technical debt.
  • Allow for modularity.

But there are many different needs between the Slack client and the marketing site. Also the marketing site doesn’t have the same resources as the Slack client.

Be inspired by other design systems, but don’t expect the same resutls.

Myth 6: everything is awesome!

When you think about design systems, everything is nice and neat and orderly. So you make one. Then you look at someone else’s design system. Your expectations don’t match the reality. Looking at these fully-fledged design systems is like comparing Instagram to real life.

The perfect design system is an angel. It’s a benevolent creature acting as an intermediary between worlds. Perhaps you think you’ve seen one once, but you can’t be sure.

The truth is that design system work is like laying down the railway tracks while the train is moving.

For a developer, it is a rare gift to be able to implement a project with a clean slate and no obligations to refactor an existing codebase.

Mina got to do a complete redesign in 2017, accompanied by a design system. The design system would power the redesign. Everything was looking good. Then slowly as the rest of the team started building more components for the website, unconnected things seemed to be breaking. This is what design systems are supposed to solve. But people were creating multiple components that did the same thing. Work was happening on a deadline.

Even on the Hillary For America design system (Pantsuit), which seemed lovely and awesome on the outside, there were multiple components that did the same thing. The CSS got out of hand with some very convoluted selectors trying to make things flexible.

Mina wants to share those stories because it sometimes seems that we only share the success stories.

Share work in progress. Learn out in the open. Be more vulnerable, authentic, and real.

Oh, Vienna!

Earlier this year I was in Düsseldorf for a triple bill of events:

  1. Indie Web Camp
  2. Beyond Tellerrand
  3. Accessibility Club

At Accessibility Club, I had the pleasure of seeing a great presentation from Manuel Matuzovic. Afterwards, a gaggle of us geeks went out for currywurst and beer. I got chatting with Manuel, who mentioned that he’s based in Vienna, where he organises a web meetup. I told him I’d love to come and speak at it sometime. He seemed very keen on the idea!

A few weeks later, I dropped him a line so he knew I was serious with my offer:

Hi Manuel,

Just wanted to drop a quick line to say how nice it was to hang out in Düsseldorf—albeit briefly.

I’d definitely be up for coming over to Vienna sometime for a meet up. Hope we can make that work sometime!

Cheers,

Jeremy

Manuel responded:

thank you for reaching out to me. Your timing couldn’t be better. :)

I was so excited that you showed interest in visiting Vienna that I thought about organising something that’s a little bit bigger than a meetup but smaller than a conference. 

I’m meeting today with my friend Max Böck to tell him about the idea and to ask him if he would want to help me organise a event.

Well, they did it. I just got back from the inaugural Web Clerks Community Conf in Vienna. It was a day full of excellent talks given to a very warm and appreciate audience.

The whole thing was livestreamed so you can catch up on the talks. I highly recommend watching Max’s talk on the indie web.

I had a really nice time hanging out with friends like Charlie, Rachel, Heydon, and my travelling companion, Remy. But it was equally great to meet new people, like the students who were volunteering and attending. I love having the chance to meet the next generation of people working on the web.

Something for the weekend

Your weekends are valuable. Spend them wisely. I have some suggestion on how you might spend next weekend, October 19th and 20th, depending on where you are in the world.

If you’re in the bay area, or anywhere near San Francisco, I highly recommend that you go to Science Hack Day—two days of science, hacking, and fun. This will be the last one in San Francisco so don’t miss your chance.

If you’re in the south of England, or anywhere near Brighton, come along to Indie Web Camp. Saturday will feature discussions on owning your data. Sunday will be a day of doing. I’ve written about previous Indie Web Camps before, and I really can’t recommend it highly enough!

Do me a favour and register for a spot—it’s free—so I’ve got some idea of numbers. Looking forward to seeing you there!

Travel talk

It’s been a busy two weeks of travelling and speaking. Last week I spoke at Finch Conf in Edinburgh, Code Motion in Madrid, and Generate CSS in London. This week I was at Indie Web Camp, View Source, and Fronteers, all in Amsterdam.

The Edinburgh-Madrid-London whirlwind wasn’t ideal. I gave the opening talk at Finch Conf, then immediately jumped in a taxi to get to the airport to fly to Madrid, so I missed all the excellent talks. I had FOMO for a conference I actually spoke at.

I did get to spend some time at Code Motion in Madrid, but that was a waste of time. It was one of those multi-track events where the trade show floor is prioritised over the talks (and the speakers don’t get paid). I gave my talk to a mostly empty room—the classic multi-track experience. On the plus side, I had a wonderful time with Jessica exploring Madrid’s many tapas delights. The food and drink made up for the sub-par conference.

I flew back from Madrid to the UK, and immediately went straight to London to deliver the closing talk of Generate CSS. So once again, I didn’t get to see any of the other talks. That’s a real shame—it sounds like they were all excellent.

The day after Generate though, I took the Eurostar to Amsterdam. That’s where I’ve been ever since. There were just as many events as in the previous week, but because they were all in Amsterdam, I could savour them properly, instead of spending half my time travelling.

Indie Web Camp Amsterdam was excellent, although I missed out on the afternoon discussions on the first day because I popped over to the Mozilla Tech Speakers event happening at the same time. I was there to offer feedback on lightning talks. I really, really enjoyed it.

I’d really like to do more of this kind of thing. There aren’t many activities I feel qualified to give advice on, but public speaking is an exception. I’ve got plenty of experience that I’m eager to share with up-and-coming speakers. Also, I got to see some really great lightning talks!

Then it was time for View Source. There was a mix of talks, panels, and breakout conversation corners. I saw some fantastic talks by people I hadn’t seen speak before: Melanie Richards, Ali Spittal, Sharell Bryant, and Tejas Kumar. I gave the closing keynote, which was warmly received—that’s always very gratifying.

After one day of rest, it was time for Fronteers. This was where myself and Remy gave the joint talk we’ve been working on:

Neither of us is under any illusions about the nature of a joint talk. It’s not half as much work; it’s more like twice the work. We’ve both seen enough uneven joint presentations to know what we want to avoid.

I’m happy to say that it went off without a hitch. Remy definitely had the tougher task—he did a live demo. Needless to say, he did it flawlessly. It’s been a real treat working with Remy on this. Don’t tell him I said this, but he’s kind of a web hero of mine, so this was a real honour and a privilege for me.

I’ve got some more speaking engagements ahead of me. Most of them are in Europe so I’m going to do my utmost to travel to them by train. Flying is usually more convenient but it’s terrible for my carbon footprint. I’m feeling pretty guilty about that Madrid trip; I need to make ammends.

I’ll be travelling to France next week for Paris Web. Taking the Eurostar is a no-brainer for that one. Straight after that Jessica and I will be going to Frankfurt for the book fair. Taking the train from Paris to Frankfurt will be nice and straightforward.

I’ll be back in Brighton for Indie Web Camp on the weekend of October 19th and 20th—you should come!—and then I’ll be heading off to Antwerp for Full Stack Fest. Anywhere in Belgium is easily reachable by train so that’ll be another Eurostar journey.

After that, it gets a little trickier. I’ll be going to Berlin for Beyond Tellerrand but I’m not sure I can make it work by train. Same goes for Web Clerks in Vienna. Cities that far east are tough to get to by train in a reasonable amount of time (although I realise that, compared to many others, I have the luxury of spending time travelling by train).

Then there are the places that I can only get to by plane. There’s the United States. I’ll be speaking at An Event Apart in San Francisco in December. A flight is unavoidable. Last time we went to the States, Jessica and I travelled by ocean liner. But that isn’t any better for the environment, given the low-grade fuel burned by ships.

And then there’s Ireland. I make trips back there to see my mother, but there’s no alternative to flying or taking a ferry—neither are ideal for the environment. At least I can offset the carbon from my flights; the travel equivalent to putting coins in the swear jar.

Don’t get me wrong—I’m not moaning about the amount of travel involved in going to conferences and workshops. It’s fantastic that I get to go to new and interesting places. That’s something I hope I never take for granted. But I can’t ignore the environmental damage I’m doing. I’ll be making more of an effort to travel by train to Europe’s many excellent web events. While I’m at it, I can ask Paul for his trainspotter expertise.

The Weight of the WWWorld is Up to Us by Patty Toland

It’s Patty Toland’s first time at An Event Apart! She’s from the fantabulous Filament Group. They’re dedicated to making the web work for everyone.

A few years ago, a good friend of Patty’s had a medical diagnosis that required everyone to pull together. Another friend shared an article about how not to say the wrong thing. This is ring theory. In a moment of crisis, the person involved is in the centre. You need to understand where you are in this ring structure, and only ever help and comfort inwards and dump concerns and problems outwards.

At the same time, Patty spent time with her family at the beach. Everyone reads the same books together. There was a book about a platoon leader in Vietnam. 80% of the story was literally a litany of stuff—what everyone was carrying. This was peppered with the psychic and emotional loads that they were carrying.

A month later there was a lot of coverage of Syrian refugees arriving in Europe. People were outraged to see refugees carrying smartphones as though that somehow showed they weren’t in a desperate situation. But smartphones are absolutely a necessity in that situation, and most of the phones were less expensive, lower-end devices. Refugeeinfo.eu was a useful site for people in crisis, but the navigation was designed to require JavaScript.

When people thing about mobile, they think about freedom and mobility. But with that JavaScript decision, the developers piled baggage on to the users.

There was a common assertion that slow networks were a third-world challenge. Remember Facebook’s network challenges? They always talked about new markets in India and Africa. The implication is that this isn’t our problem in, say, Omaha or New York.

Pew Research provided a lot of data back then that showed that this thinking was wrong. Use of cell phones, especially smartphones and tablets, escalated dramatically in the United States. There was a trend towards mobile-only usage. This was in low-income households—about one third of the population. Among 5,400 panelists, 15% did not have a JavaScript-enabled device.

Pew Research provided updated data this year. The research shows an increase in those trends. Half of the population access the web primarily on mobile. The cost of a broadband subscription is too expensive for many people. Sometimes broadband access simply isn’t available.

There’s a term called “the homework gap.” Two thirds of teachers assign broadband-dependent homework, while one third of students have no access to broadband.

At most 37% of people have unlimited data. Most people run out of data on a frequent basis.

Speed also varies wildly. 4G doesn’t really mean anything. The data is all over the place.

This shows that network issues are definitely not just a third world challenge.

On the 25th anniversary of the web, Tim Berners-Lee said the web’s potential was only just beginning to be glimpsed. Everyone has a role to play to ensure that the web serves all of humanity. In his contract for the web, Tim outlined what governments, companies, and users need to do. This reminded Patty of ring theory. The user is at the centre. Designers and developers are in the next circle out. Then there’s the circle of companies. Then there are platforms, browsers, and frameworks. Finally there’s the outer circle of governments.

Are we helping in or dumping in? If you look at the data for the average web page size (2 megabytes), we are definitely dumping in. The size of third-party JavaScript has octupled.

There’s no way for a user to know before clicking a link how big and bloated the page is going to be. Even if they abandon the page load, they’ve still used (and wasted) a lot of data.

Third party scripts—like ads—are really bad at dumping in (to use the ring theory model). The best practices for ads suggest that up to 100 additional HTTP requests is totally acceptable. Unbelievable! It doesn’t matter how performant you’ve made a site when this crap gets piled on top of it.

In 2018, the internet’s data centres alone may already have had the same carbon footprint as all global air travel. This will probably triple in the next seven years. The amount of carbon it takes to train a single AI algorithm is more than the entire life cycle of a car. Then there’s fucking Bitcoin. A single Bitcoin transaction could power 21 US households. It is designed to use—specifically, waste—more and more energy over time.

What should we be doing?

Accessibility should be at the heart of what we build. Plan, test, educate, and advocate. If advocacy doesn’t work, fear can be a motivator. There’s an increase in accessibility lawsuits.

Our websites should be as light as possible. Ask, measure, monitor, and optimise. RequestMap is a great tool for visualising requests. You can see the size and scale of third-party requests. You can also see when images are far, far bigger than they need to be.

Take a critical guide to everything and pare everything down. Set perforance budgets—file size budgets, for example. Optimise images, subset custom fonts, lazyload images and videos, get third-party tools out of the critical path (or out completely), and seek out lighter frameworks.

Test on real devices that real people are using. See Alex Russell’s data on the differences between the kind of devices we use and typical low-end devices. We literally need to stop people in JavaScript.

Push the boundaries. See the amazing work that Adrian Holovaty did with Soundslice. He had to make on-the-fly sheet music generation work on old iPads that musicians like to use. He recommends keeping old devices around to see how poorly your product is working on it.

If you have some power, then your job is to empower somebody else.

—Toni Morrison