Journal tags: structure

It’s often said that it’s easier to make a fast website than it is to keep a website fast. Things slip through. If you’re not vigilant, performance can erode without you noticing.

It’s a similar story for other invisible but important facets of your website: privacy, security, accessibility. Because they’re hidden from view, you won’t be able to see if there’s a regression.

That’s why it’s a good idea to have regular audits for performance, privacy, security, and accessibility.

I wrote about accessibility testing a while back, and how there’s quite a bit that you can do for yourself before calling in an expert to look at the really gnarly stuff:

When you commission an accessibility audit, you want to make sure you’re getting the most out of it. Don’t squander it on issues that you can catch and fix yourself. Make sure that the bulk of the audit is being spent on the specific issues that are unique to your site.

I recently did an internal audit of the Clearleft website. After writing up the report, I also did a lunch’n’learn to share my methodology. I wanted to show that there’s some low-hanging fruit that pretty much anyone can catch.

To start with, there’s keyboard navigation. Put your mouse and trackpad to one side and use the tab key to navigate around.

Caveat: depending on what browser you’re using, you might need to update some preferences for keyboard navigation to work on links. If you’re using Safari, go to “Preferences”, then “Advanced”, and tick “Press Tab to highlight each item on a web page.”

Tab around and find out. You should see some nice chunky :focus-visible styles on links and form fields.

Here’s something else that anyone can do: zoom in. Increase the magnification to 200%. Everything should scale proportionally. How about 500%? You’ll probably see a mobile-friendly layout. That’s fine. As long as nothing is broken or overlapping, you’re good.

At this point, I reach for some tools. I’ve got some bookmarklets that do similar things: tota11y and ANDI. They both examine the source HTML and CSS to generate reports on structure, headings, images, forms, and so on.

These tools are really useful, but you need to be able to interpret the results. For example, a tool can tell you if an image has no alt text. But it can’t tell you if an image has good or bad alt text.

Likewise, these tools are great for catching colour-contrast issues. But there’s a big difference between a colour-contrast issue on the body copy compared to a colour-contrast issue on one unimportant page element.

I think that demonstrates the most important aspect of any audit: prioritisation.

Finding out that you have accessibility issues isn’t that useful if they’re all presented as an undifferentiated list. What you really need to know are which issues are the most important to fix.

By the way, I really like the way that the Gov.uk team prioritises accessibility concerns:

The team puts accessibility concerns in 2 categories:

1. Theoretical: A question or statement regarding the accessibility of an implementation within the Design System without evidence of real-world impact.
2. Evidenced: Sharing new research, data or evidence showing that an implementation within the Design System could cause barriers for disabled people.

The team will usually prioritise evidenced issues and queries over theoretical ones.

When I wrote up my audit for the Clearleft website, I structured it in order of priority. The most important things to fix are at the start of the audit. I also used a simple scale for classifying the severity of issues: low, medium, and high priority.

Thankfully there were no high-priority issues. There were a couple of medium-priority issues. There were plenty of low-priority issues. That’s okay. That’s a pretty good distribution.

If you’re interested, here’s the report I delivered…

Accessibility audit on clearleft.com

Colour contrast

There are a few issues with the pink colour. When it’s used on a grey background, or when it’s used as a background colour for white text, the colour contrast isn’t high enough.

The SVG arrow icon could be improved too.

Recommendations

Medium priority

• Change the pink colour universally to be darker. The custom property --red is currently rgb(234, 33, 90). Change it to rgb(210, 20, 73) (thanks, James!)

Low priority

• The SVG arrow icon currently uses currentColor. Consider hardcoding solid black (or a very, very dark grey) instead.

Images

Alt text is improving on the site. There’s reasonable alt text at the top level pages and the first screen’s worth of case studies and blog posts. I made a sweep through these pages a while back to improve the alt text but I haven’t done older blog posts and case studies.

Recommendations

Medium priority

• Make a sweep of older blog posts and case studies and fix alt text.

Low priority

• Images on the contact page have alt text that starts with “A photo of…” — this is redundant and can be removed.

Headings

The site is using headings sensibly. Sometimes the nesting of headings isn’t perfect, but this is a low priority issue. For example, on the contact page there’s an h1 followed by two h3s. In theory this isn’t correct. In practice (for screen reader users) it’s not an issue.

Recommendations

Low priority

• On the home page, “UX London 2023” should probably be h3 instead of h1.
• On the case studies index page we’re currently using h3 headings for the industry sector (“Charities”, “Education” etc.) but these should probably not be headings at all. On the blog index page we use a class “Tags” for a similar purpose. Consider reusing that pattern on the case studies index page.
• On the about index page, “We’re driven to be” is an h3 and the subsequent three headings are h2s. Ideally this would be reversed: a single h2 followed by three h3s.

Link text

Sometimes the same text is used for different links.

Recommendations

Low priority

• On the home page the text “Read the case study” is re-used for multiple links. It would be better if each link were different e.g. “Read about The Natural History Museum.”

Forms

The only form on the site is the newsletter sign-up form. It’s marked up pretty well: the input has an associated label, although a visible (clickable) label would be better.

Tabbing order

The site doesn’t use JavaScript to mess with tabbing order for keyboard users. The source order of elements in the markup generally makes sense so all is good.

The focus styles are nice and clear too!

Structure

The site is using HTML landmark elements sensibly (header, nav, main, footer, etc.).

I’ve always liked the idea that your website can be your API. Like, you’ve already got URLs to identify resources, so why not make that URL structure predictable and those resources parsable?

That’s why the (read-only) API for The Session doesn’t live at a separate subdomain. It uses the same URL structure as the regular site, but you can request the resources in an alternative format: JSON, XML, RSS.

This works out pretty well, mostly because I put a lot of thought into the URL structure of the site. I’m something of a URL fetishist, but I think that taking a URL-first approach to information architecture can be a good exercise.

Most of the resources on The Session involve nouns like tunes, events, discussions, and so on. There’s a consistent and predictable structure to the URLs for those sections:

• /things
• /things/new
• /things/search

And then an idividual item can be found at:

• things/ID

That’s all nice and predictable and the naming of the URLs matches what you’d expect to find:

• tunes
• tunes/new
• tunes/search?q=Ireland
• tunes/320

Tunes, events, discussions, sessions. Those are all fine. But there’s one section of the site that has this root URL:

/recordings

When I was coming up with the URL structure twenty years ago, it was clear what you’d find there: track listings for albums of music. No one would’ve expected to find actual recordings of music available to listen to on-demand. The bandwidth constraints and technical limitations of the time made that clear.

Two decades on, the situation has changed. Now someone new to the site might well expect to hit a link called “recordings” and expect to hear actual recordings of music.

So I should probably change the label on the link. I don’t think “albums” is quite right—what even is an album any more? The word “discography” is probably the most appropriate label.

Here’s my dilemma: if I update the label, should I also update the URL structure?

Right now, the section of the site with /tunes URLs is labelled “tunes”. The section of the site with /events URLs is labelled “events”. Currently the section of the site with /recordings URLs is labelled “recordings”, but may soon be labelled “discography”.

If you click on “tunes”, you end up at /tunes. But if you click on “discography”, you end up at /recordings.

Is that okay? Am I the only one that would be bothered by that?

I could update the URLs to match the labelling (with redirects for the old URLs, of course), but I’m not so keen on this URL structure:

• /discography
• /discography/new
• /discography/search
• /discography/ID

It doesn’t seem as tidy as:

• /recordings
• /recordings/new
• /recordings/search
• /recordings/ID

But if I don’t update the URLs to match the label, then I’m just going to have to live with the mismatch.

I’m just thinking out loud here. I think I should definitely update the label. I just won’t make any decision on changing URLs for a while yet.

I was talking to someone recently about a forgotten battle in the history of the early web. It was a battle between search engines and directories.

These days, when the history of the web is told, a whole bunch of services get lumped into the category of “competitors who lost to Google search”: Altavista, Lycos, Ask Jeeves, Yahoo.

But Yahoo wasn’t a search engine, at least not in the same way that Google was. Yahoo was a directory with a search interface on top. You could find what you were looking for by typing or you could zero in on what you were looking for by drilling down through a directory structure.

Yahoo wasn’t the only directory. DMOZ was an open-source competitor. You can still experience it at DMOZlive.com:

The official DMOZ.com site was closed by AOL on February 17th 2017. DMOZ Live is committed to continuing to make the DMOZ Internet Directory available on the Internet.

Search engines put their money on computation, or to use today’s parlance, algorithms (or if you’re really shameless, AI). Directories put their money on humans. Good ol’ information architecture.

It turned out that computation scaled faster than humans. Search won out over directories.

Now an entire generation has been raised in the aftermath of this battle. Monica Chin wrote about how this generation views the world of information:

Catherine Garland, an astrophysicist, started seeing the problem in 2017. She was teaching an engineering course, and her students were using simulation software to model turbines for jet engines. She’d laid out the assignment clearly, but student after student was calling her over for help. They were all getting the same error message: The program couldn’t find their files.

Garland thought it would be an easy fix. She asked each student where they’d saved their project. Could they be on the desktop? Perhaps in the shared drive? But over and over, she was met with confusion. “What are you talking about?” multiple students inquired. Not only did they not know where their files were saved — they didn’t understand the question.

Gradually, Garland came to the same realization that many of her fellow educators have reached in the past four years: the concept of file folders and directories, essential to previous generations’ understanding of computers, is gibberish to many modern students.

Dr. Saavik Ford confirms:

We are finding a persistent issue with getting (undergrad, new to research) students to understand that a file/directory structure exists, and how it works. After a debrief meeting today we realized it’s at least partly generational.

We live in a world ordered only by search:

While some are quite adept at using labels, tags, and folders to manage their emails, others will claim that there’s no need to do because you can easily search for whatever you happen to need. Save it all and search for what you want to find. This is, roughly speaking, the hot mess approach to information management. And it appears to arise both because search makes it a good-enough approach to take and because the scale of information we’re trying to manage makes it feel impossible to do otherwise. Who’s got the time or patience?

There are still hold-outs. You can prise files from Scott Jenson’s cold dead hands.

More recently, Linus Lee points out what we’ve lost by giving up on directory structures:

Humans are much better at choosing between a few options than conjuring an answer from scratch. We’re also much better at incrementally approaching the right answer by pointing towards the right direction than nailing the right search term from the beginning. When it’s possible to take a “type in a query” kind of interface and make it more incrementally explorable, I think it’s almost always going to produce a more intuitive and powerful interface.

Directory structures still make sense to me (because I’m old) but I don’t have a problem with search. I do have a problem with systems that try to force me to search when I want to drill down into folders.

I have no idea what Google Drive and Dropbox are doing but I don’t like it. They make me feel like the opposite of a power user. Trying to find a file using their interfaces makes me feel like I’m trying to get a printer to work. Randomly press things until something happens.

Anyway. Enough fist-shaking from me. I’m going to ponder Linus’s closing words. Maybe defaulting to a search interface is a cop-out:

Text search boxes are easy to design and easy to add to apps. But I think their ease on developers may be leading us to ignore potential interface ideas that could let us discover better ideas, faster.

The Clearleft newsletter goes out every two weeks on a Thursday. You can peruse the archive to see past editions.

I think it’s a really good newsletter, but then again, I’m the one who writes it. It just kind of worked out that way. In theory, anyone at Clearleft could write an edition of the newsletter.

To make that prospect less intimidating, I put together a document for my colleagues describing how I go about creating a new edition of the newsletter. Then I thought it might be interesting for other people outside of Clearleft to get a peek at how the sausage is made.

So here’s what I wrote…

Topics

The description of the newsletter is:

A round-up of handpicked hyperlinks from Clearleft, covering design, technology, and culture.

It usually has three links (maybe four, tops) on a single topic.

The topic can be anything that’s interesting, especially if it’s related to design or technology. Every now and then the topic can be something that incorporates an item that’s specifically Clearleft-related (a case study, an event, a job opening). In general it’s not very salesy at all so people will tolerate the occasional plug.

You can use the “iiiinteresting” Slack channel to find potential topics of interest. I’ve gotten in the habit of popping potential newsletter fodder in there, and then adding related links in a thread.

Tone

Imagine you’re telling a friend about something cool you’ve just discovered. You can sound excited. Don’t worry about this looking unprofessional—it’s better to come across as enthusiastic than too robotic. You can put real feelings on display: anger, disappointment, happiness.

That said, you can also just stick to the facts and describe each link in turn, letting the content speak for itself.

If you’re expressing a feeling or an opinion, use the personal pronoun “I”. Don’t use “we” unless you’re specifically referring to Clearleft.

But most of the time, you won’t be using any pronouns at all:

So-and-so has written an article in such-and-such magazine on this-particular-topic.

You might find it useful to have connecting phrases as you move from link to link:

Speaking of some-specific-thing, this-other-person has a different viewpoint.

or

On the subject of this-particular-topic, so-and-so wrote something about this a while back.

Structure

The format of the newsletter is:

1. An introductory sentence or short paragraph.
2. A sentence describing the first link, ending with the title of the item in bold.
3. A link to the item on its own separate line.
4. An excerpt from the link, usually a sentence or two, styled as a quote.
5. Repeat steps 2 to 4 another two times.


Take a look through the archive of previous newsletters to get a feel for it.

Subject line

Currently the newsletter is called dConstruct from Clearleft. The subject line of every edition is in the format:

dConstruct from Clearleft — Title of the edition

(Note that’s an em dash with a space on either side of it separating the name of the newsletter and the title of the edition)

I often try to come up with a pun-based title (often a punny portmanteau) but that’s not necessary. It should be nice and short though: just one or two words.

Cennydd asked for recommendations on Twitter a little while back:

Can anyone recommend an outlining app for macOS? I’m falling out with OmniOutliner. Not Notion, please.

This was my response:

The only outlining tool that makes sense for my brain is https://kinopio.club/

It’s more like a virtual crazy wall than a virtual Dewey decimal system.

I’ve written before about how I prepare a conference talk. The first step involves a sheet of A3 paper:

I used to do this mind-mapping step by opening a text file and dumping my thoughts into it. I told myself that they were in no particular order, but because a text file reads left to right and top to bottom, they are in an order, whether I intended it or not. By using a big sheet of paper, I can genuinely get things down in a disconnected way (and later, I can literally start drawing connections).

Kinopio is like a digital version of that A3 sheet of paper. It doesn’t force any kind of hierarchy on your raw ingredients. You can clump things together, join them up, break them apart, or just dump everything down in one go. That very much suits my approach to preparing something like a talk (or a book). The act of organising all the parts into a single narrative timeline is an important challenge, but it’s one that I like to defer to later. The first task is braindumping.

When I was preparing my talk for An Event Apart Online, I used Kinopio.club to get stuff out of my head. Here’s the initial brain dump. Here are the final slides. You can kind of see the general gist of the slidedeck in the initial brain dump, but I really like that I didn’t have to put anything into a sequential outline.

In some ways, Kinopio is like an anti-outlining tool. It’s scrappy and messy—which is exactly why it works so well for the early part of the process. If I use a tool that feels too high-fidelity too early on, I get a kind of impedence mismatch between the state of the project and the polish of the artifact.

I like that Kinopio feels quite personal. Unlike Google Docs or other more polished tools, the documents you make with this aren’t really for sharing. Still, I thought I’d share my scribblings anyway.

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.

I mentioned how much I enjoyed Mike Hill’s talk at Beyond Tellerrand in Düsseldorf:

Mike gave a talk called The Power of Metaphor and it’s absolutely brilliant. It covers the monomyth (the hero’s journey) and Jungian archetypes, illustrated with the examples Star Wars, The Dark Knight, and Jurassic Park.

At Clearleft, I’m planning to reprise the workshop I did a few years ago about narrative structure—very handy for anyone preparing a conference talk, blog post, case study, or anything really:

Ellen and I have been enjoying some great philosophical discussions about exactly what a story is, and how does it differ from a narrative structure, or a plot. I really love Ellen’s working definition: Narrative. In Space. Over Time.

This led me to think that there’s a lot that we can borrow from the world of storytelling—films, novels, fairy tales—not necessarily about the stories themselves, but the kind of narrative structures we could use to tell those stories. After all, the story itself is often the same one that’s been told time and time again—The Hero’s Journey, or some variation thereof.

I realised that Mike’s monomyth talk aligns nicely with my workshop. So I decided to prep my fellow Clearlefties for the workshop with a movie night.

Popcorn was popped, pizza was ordered, and comfy chairs were suitably arranged. Then we watched Mike’s talk. Everyone loved it. Then it was decision time. Which of three films covered in the talk would we watch? We put it to a vote.

It came out as an equal tie between Jurassic Park and The Dark Knight. How would we resolve this? A coin toss!

The toss went to The Dark Knight. In retrospect, a coin toss was a supremely fitting way to decide to watch that film.

It was fun to watch it again, particularly through the lens of Mike’s analyis of its Jungian archetypes.

But I still think the film is about game theory.

After a fun and productive Indie Web Camp, I stuck around Düsseldorf for Beyond Tellerand. I love this event. I’ve spoken at it quite a few times, but this year it was nice to be there as an attendee. It’s simultaneously a chance to reconnect with old friends I haven’t seen in a while, and an opportunity to meet lovely new people. There was plenty of both this year.

I think this might have been the best Beyond Tellerrand yet, and that’s saying something. It’s not just that the talks were really good—there was also a wonderful atmosphere.

Marc somehow manages to curate a line-up that’s equal parts creativity and code; design and development. It shouldn’t work, but it does. I love the fact that he had a legend of the industry like David Carson on the same stage as first-time speaker like Dorobot …and the crowd loved ‘em equally!

During the event, I found out that I had a small part to play in the creation of the line-up…

Three years ago, I linked to a video of a talk by Mike Hill:

A terrific analysis of industrial design in film and games …featuring a scene-setting opening that delineates the difference between pleasure and happiness.

It’s a talk about chairs in Jodie Foster films. Seriously. It’s fantastic!

Marc saw my link, watched the video, and decided he wanted to get Mike Hill to speak at Beyond Tellerrand. After failing to get a response by email, Marc managed to corner Mike at an event in Amsterdam and get him on this year’s line-up.

Mike gave a talk called The Power of Metaphor and it’s absolutely brilliant. It covers the monomyth (the hero’s journey) and Jungian archetypes, illustrated with the examples Star Wars, The Dark Knight, and Jurassic Park:

Under the surface of their most celebrated films lies a hidden architecture that operates on an unconscious level; This talk is designed to illuminate the techniques that great storytellers use to engage a global audience on a deep and meaningful level through psychological metaphor.

The videos from Beyond Tellerrand are already online so you can watch the talk now.

Mike’s talk was back-to-back with a talk from Carolyn Stransky called Humanising Your Documentation:

In this talk, we’ll discuss how the language we use affects our users and the first steps towards writing accessible, approachable and use case-driven documentation.

While the talk was ostensibly about documentation, I found that it was packed full of good advice for writing well in general.

I had a thought. What if you mashed up these two talks? What if you wrote documentation through the lens of the hero’s journey?

Think about it. When somone arrives at your documentation, they’ve crossed the threshold to the underworld. They are in the cave, facing a dragon. You are their guide, their mentor, their Obi-Wan Kenobi. You can help them conquer their demons and return to the familiar world, changed by their journey.

Too much?

I gave a talk at the State Of The Browser conference in London earlier this month. It was a 25 minute spiel called The Web Is Agreement.

While I was putting the talk together, I posted some pictures of my talk preparation process. People seemed to be quite interested in that peek behind the curtain, so I thought I’d jot down the process I used.

There are two aspects to preparing a talk: the content and the presentation. I like to keep the preparation of those two parts separate. It’s kind of like writing: instead of writing and editing at the same time, it’s more productive to write any old crap first (to get it out of your head) and then go back and edit—“write drunk and edit sober”. Separating out those two mindsets allows you to concentrate on the task at hand.

So, to begin with, I’m not thinking about how I’m going to present the material at all. I’m only concerned with what I want to say.

When it comes to preparing the subject matter for a talk, step number zero is to banish your inner critic. You know who I mean. That little asshole with the sneering voice that says things like “you’re not qualified to talk about this” or “everything has already been said.” Find a way to realise that this demon is a) speaking from inside your head and b) not real. Maybe try drawing your inner critic. Ridiculous? Yes. Yes, it is.

Alright, time to start. There’s nothing more intimidating than a blank slidedeck, except maybe a blank Photoshop file, or a blank word processing document. In each of those cases, I find that starting with software is rarely a good idea. Paper is your friend.

I get a piece of A3 paper and start scribbling out a mind map. “Mind map” is a somewhat grandiose term for what is effectively a lo-fi crazy wall.

The idea here is to get everything out of my head. Don’t self-censor. At this stage, there are no bad ideas. This is a “yes, and…” exercise, not a “no, but…” exercise. Divergent, not convergent.

Not everything will make it into the final talk. That’s okay. In fact, I often find that there’s one thing that I’m really attached to, that I’m certain will be in the talk, that doesn’t make the cut. Kill your darlings.

I used to do this mind-mapping step by opening a text file and dumping my thoughts into it. I told myself that they were in no particular order, but because a text file reads left to right and top to bottom, they are in an order, whether I intended it or not. By using a big sheet of paper, I can genuinely get things down in a disconnected way (and later, I can literally start drawing connections).

For this particular talk, I knew that the subject matter would be something to do with web standards. I brain-dumped every vague thought I had about standards in general.

The next step is what I call chunking. I start to group related ideas together. Then I give a label to each of these chunks. Personally, I like to use a post-it note per chunk. I put one word or phrase on the post-it note, but it could just as easily be a doodle. The important thing is that you know what the word or doodle represents. Each chunk should represent a self-contained little topic that you might talk about for 3 to 5 minutes.

At this point, I can start thinking about the structure of the talk: “Should I start with this topic? Or should I put that in the middle?” The cost of changing my mind is minimal—I’m just moving post-it notes around.

With topics broken down into chunks like this, I can flesh out each one. The nice thing about this is that I’ve taken one big overwhelming task—prepare a presentation!—and I’ve broken it down into smaller, more manageable tasks. I can take a random post-it note and set myself, say, ten or fifteen minutes to jot down an explanation of it.

The explanation could just be bullet points. For this particular talk, I decided to write full sentences.

Even though, in this case, I was writing out my thoughts word for word, I still kept the topics in separate files. That way, I can still move things around easily.

Crafting the narrative structure of a talk is the part I find most challenging …but it’s also the most rewarding. By having the content chunked up like this, I can experiment with different structures. I like to try out different narrative techniques from books and films, like say, flashback: find the most exciting part of the talk; start with that, and then give the backstory that led up to it. That’s just one example. There are many possible narrative stuctures.

What I definitely don’t do is enact the advice that everyone is given for their college presentations:

1. say what you’re going to say,
2. say it, and
3. recap what you’ve said.

To me, that’s the equivalent of showing an audience the trailer for a film right before watching the film …and then reading a review of the film right after watching it. Just play the film! Give the audience some credit—assume the audience has no knowledge but infinite intelligence.

Oh, and there’s one easy solution to cracking the narrative problem: make a list. If you’ve got 7 chunks, you can always give a talk on “Seven things about whatever” …but it’s a bit of a cop-out. I mean, most films have a three-act structure, but they don’t start the film by telling the audience that, and they don’t point out when one act finishes and another begins. I think it’s much more satisfying—albeit more challenging—to find a way to segue from chunk to chunk.

Finding the narrative thread is tricky work, but at least, by this point, it’s its own separate task: if I had tried to figure out the narrative thread at the start of the process, or even when I was chunking things out, it would’ve been overwhelming. Now it’s just the next task in my to-do list.

I suppose, at this point, I might as well make some slides.

I’m not trying to be dismissive of slides—I think having nice slides is a very good thing. But I do think that they can become the “busy work” of preparing a presentation. If I start on the slides too soon, I find they’ll take up all my time. I think it’s far more important to devote time to the content and structure of the talk. The slides should illustrate the talk …but the slides are not the talk.

If you don’t think of the slides as being subservient to the talk, there’s a danger that you’ll end up with a slidedeck that’s more for the speaker’s benefit than the audience’s.

It’s all too easy to use the slides as a defence mechanism. You’re in a room full of people looking towards you. It’s perfectly reasonable for your brain to scream, “Don’t look at me! Look at the slides!” But taken too far, that can be interpreted as “Don’t listen to me!”

For this particular talk, there were moments when I wanted to make sure the audience was focused on some key point I was making. I decided that having no slide at all was the best way of driving home my point.

But slidedeck style is quite a personal thing, so use whatever works for you.

It’s a similar story with presentation style. Apart from some general good advice—like, speak clearly—the way you present should be as unique as you are. I have just one piece of advice, and it’s this: read Demystifying Public Speaking by Lara Hogan—it’s really, really good!

(I had to apologise to Lara last time I saw her, because I really wanted her to sign my copy of her book …but I didn’t have it, because it’s easily the book I’ve loaned out to other people the most.)

I did a good few run-throughs of my talk. There were a few sentences that sounded fine written down, but were really clumsy to say out loud. It reminded me of what Harrison Ford told George Lucas during the filming of Star Wars: “You can type this shit, George, but you can’t say it.”

I gave a final run-through at work to some of my Clearleft colleagues. To be honest, I find that more nerve-wracking than speaking on a stage in front of a big room full of strangers. I think it’s something to do with the presentation of self.

Finally, the day of the conference rolled around, and I was feeling pretty comfortable with my material. I’m pretty happy with how it turned out. You can read The Web Is Agreement, and you can look at the slides, but as with any conference talk, you kinda had to be there.

We tend to like false dichotomies in the world of web design and web development. I’ve noticed one recently that keeps coming up in the realm of design systems and components.

It’s about separation of concerns. The web has a long history of separating structure, presentation, and behaviour through HTML, CSS, and JavaScript. It has served us very well. If you build in that order, ensuring that something works (to some extent) before adding the next layer, the result will be robust and resilient.

But in this age of components, many people are pointing out that it makes sense to separate things according to their function. Here’s the Diana Mounter in her excellent article about design systems at Github:

Rather than separating concerns by languages (such as HTML, CSS, and JavaScript), we’re are working towards a model of separating concerns at the component level.

This echoes a point made previously in a slidedeck by Cristiano Rastelli.

Separating interfaces according to the purpose of each component makes total sense …but that doesn’t mean we have to stop separating structure, presentation, and behaviour! Why not do both?

There’s nothing in the “traditonal” separation of concerns on the web (HTML/CSS/JavaScript) that restricts it only to pages. In fact, I would say it works best when it’s applied on smaller scales.

In her article, Pattern Library First: An Approach For Managing CSS, Rachel advises starting every component with good markup:

Your starting point should always be well-structured markup.

This ensures that your content is accessible at a very basic level, but it also means you can take advantage of normal flow.

That’s basically an application of starting with the rule of least power.

In chapter 6 of Resilient Web Design, I outline the three-step process I use to build on the web:

1. Identify core functionality.
2. Make that functionality available using the simplest possible technology.
3. Enhance!

That chapter is filled with examples of applying those steps at the level of an entire site or product, but it doesn’t need to end there:

We can apply the three‐step process at the scale of individual components within a page. “What is the core functionality of this component? How can I make that functionality available using the simplest possible technology? Now how can I enhance it?”

There’s another shared benefit to separating concerns when building pages and building components. In the case of pages, asking “what is the core functionality?” will help you come up with a good URL. With components, asking “what is the core functionality?” will help you come up with a good name …something that’s at the heart of a good design system. In her brilliant Design Systems book, Alla advocates asking “what is its purpose?” in order to get a good shared language for components.

My point is this:

• Separating structure, presentation, and behaviour is a good idea.
• Separating an interface into components is a good idea.

Those two good ideas are not in conflict. Presenting them as though they were binary choices is like saying “I used to eat Italian food, but now I drink Italian wine.” They work best when they’re done in combination.

A few people on Twitter have asked about the table of contents for my new book about service workers, Going Offline. Fair enough—why not see the menu before placing your order?

1. Introducing Service Workers Does what is says on the tin. It also talks about switching to HTTPS. This chapter is online at A List Apart so you can try before you buy.
2. Preparing for Offline This chapter talks about how you register a service worker, and introduces the concept of promises in JavaScript.
3. Making Fetch Happen Yes, this chapter title is a Mean Girls reference; fight me. The chapter explains fetch events and shows how a service worker can intercept them.
4. Cache Me if you Can This puntastic chapter is all about caching, and shows you can use caches in your service worker script.
5. Service Worker Strategies This is the heart of the book, where you get decide what kind of strategy you want to implement—when to go to the network, when to go a cache, and so on. And as a last resort, you can have a custom offline page.
6. Refining Your Service Worker Building on the previous chapter, this one looks at how you can use different strategies for different kinds of files—images, pages, etc.
7. Tidying Up This chapter is about good service worker hygiene like deleting old caches. It also introduces some more coding style options.
8. The Offline Experience By this chapter, the service worker script is done. But there’s still plenty of room for enhancements on that custom offline page, including the use of offline storage.
9. Progressive Web Apps The book finishes with an explanation of progressive web apps, and a step-by-step guide to creating your own web app manifest.

Sound good? Pre-order your copy of the book now and you’ll have it in your hands ten days from now.

I’m in New York. Again. This time it’s for Google’s AMP Conf, where I’ll be giving ‘em a piece of my mind on a panel.

The conference starts tomorrow so I’ve had a day or two to acclimatise and explore. Seeing as Google are footing the bill for travel and accommodation, I’m staying at a rather nice hotel close to the conference venue in Tribeca. There’s live jazz in the lounge most evenings, a cinema downstairs, and should I request it, I can even have a goldfish in my room.

Today I realised that my hotel sits in the apex of a triangle of interesting buildings: carrier hotels.

Looming above my hotel is 32 Avenue of the Americas. On the outside the building looks like your classic Gozer the Gozerian style of New York building. Inside, the lobby features a mosaic on the ceiling, and another on the wall extolling the connective power of radio and telephone.

The same architects also designed 60 Hudson Street, which has a similar Art Deco feel to it. Inside, there’s a cavernous hallway running through the ground floor but I can’t show you a picture of it. A security guard told me I couldn’t take any photos inside …which is a little strange seeing as it’s splashed across the website of the building.

I walked around the outside of 60 Hudson, taking more pictures. Another security guard asked me what I was doing. I told her I was interested in the history of the building, which is true; it was the headquarters of Western Union. For much of the twentieth century, it was a world hub of telegraphic communication, in much the same way that a beach hut in Porthcurno was the nexus of the nineteenth century.

For a 21st century hub, there’s the third and final corner of the triangle at 33 Thomas Street. It’s a breathtaking building. It looks like a spaceship from a Chris Foss painting. It was probably designed more like a spacecraft than a traditional building—it’s primary purpose was to withstand an atomic blast. Gone are niceties like windows. Instead there’s an impenetrable monolith that looks like something straight out of a dystopian sci-fi film.

Brutalist on the outside, its interior is host to even more brutal acts of invasive surveillance. The Snowden papers revealed this AT&T building to be a centrepiece of the Titanpointe programme:

They called it Project X. It was an unusually audacious, highly sensitive assignment: to build a massive skyscraper, capable of withstanding an atomic blast, in the middle of New York City. It would have no windows, 29 floors with three basement levels, and enough food to last 1,500 people two weeks in the event of a catastrophe.

But the building’s primary purpose would not be to protect humans from toxic radiation amid nuclear war. Rather, the fortified skyscraper would safeguard powerful computers, cables, and switchboards. It would house one of the most important telecommunications hubs in the United States…

Looking at the building, it requires very little imagination to picture it as the lair of villainous activity. Laura Poitras’s short film Project X basically consists of a voiceover of someone reading an NSA manual, some ominous background music, and shots of 33 Thomas Street looming in its oh-so-loomy way.

A top-secret handbook takes viewers on an undercover journey to Titanpointe, the site of a hidden partnership. Narrated by Rami Malek and Michelle Williams, and based on classified NSA documents, Project X reveals the inner workings of a windowless skyscraper in downtown Manhattan.

It was only last week that myself and Ellen were brainstorming ideas for a combined workshop. Our enthusiasm got the better of us, and we said “Let’s just do it!” Before we could think better of it, the room was booked, and the calendar invitations were sent.

The topic was “story.”

No wait, maybe it was …”narrative.”

That’s not quite right either.

“Content,” perhaps?

Basically, here’s the issue: at some point everyone at Clearleft needs to communicate something by telling a story. It might be a blog post. It might be a conference talk. It might be a proposal for a potential client. It might be a case study of our work. Whatever form it might take, it involves getting a message across …using words. Words are hard. We wanted to make them a little bit easier.

We did two workshops. Ellen’s was yesterday. Mine was today. They were both just about two hours in length.

Get out of my head!

Ellen’s workshop was all about getting thoughts out of your head and onto paper. But before we could even start to do that, we had to confront our first adversary: the inner critic.

You know the inner critic. It’s that voice inside you that says “You’ve got nothing new to say”, or “You’re rubbish at writing.” Ellen encouraged each of us to drag this inner critic out into the light—much like Paul Ford did with his AnxietyBox.

Each of us drew a cartoon of our inner critic, complete with speech bubbles of things our inner critic says to us.

In a bizarre coincidence, Chloe and I had exactly the same inner critic, complete with top hat and monocle.

With that foe vanquished, we proceeded with a mind map. The idea was to just dump everything out of our heads and onto paper, without worrying about what order to arrange things in.

I found it to be an immensely valuable exercise. Whenever I’ve tried to do this before, I’d open up a blank text file and start jotting stuff down. But because of the linear nature of a text file, there’s still going to be an order to what gets jotted down; without meaning to, I’ve imposed some kind of priority onto the still-unformed thoughts. Using a mind map allowed me get everything down first, and then form the connections later.

There were plenty of other exercises, but the other one that really struck me was a simple framework of five questions. Whatever it is that you’re trying to say, write down the answers to these questions about your audience:

1. What are they sceptical about?
2. What problems do they have?
3. What’s different now that you’ve communicated your message?
4. Paint a pretty picture of life for them now that you’ve done that.
5. Finally, what do they need to do next?

They’re straightforward questions, but the answers can really help to make sure you’re covering everything you need to.

There were many more exercises, and by the end of the two hours, everyone had masses of raw material, albeit in an unstructured form. My workshop was supposed to help them take that content and give it some kind of shape.

The structure of stories

Ellen and I have been enjoying some great philosophical discussions about exactly what a story is, and how does it differ from a narrative structure, or a plot. I really love Ellen’s working definition: Narrative. In Space. Over Time.

This led me to think that there’s a lot that we can borrow from the world of storytelling—films, novels, fairy tales—not necessarily about the stories themselves, but the kind of narrative structures we could use to tell those stories. After all, the story itself is often the same one that’s been told time and time again—The Hero’s Journey, or some variation thereof.

So I was interested in separating the plot of a story from the narrative device used to tell the story.

To start with, I gave some examples of well-known stories with relatively straightforward plots:

• Star Wars,
• Little Red Riding Hood,
• Your CV,
• Jurassic Park, and
• Ghostbusters.

I asked everyone to take a story (either from that list, or think of another one) and write the plot down on post-it notes, one plot point per post-it. Before long, the walls were covered with post-its detailing the plot lines of:

• Robocop,
• Toy Story,
• Back To The Future,
• Elf,
• E.T.,
• The Three Little Pigs, and
• Pretty Woman.

Okay. That’s plot. Next we looked at narrative frameworks.

Flashback

Begin at a crucial moment, then back up to explain how you ended up there.

e.g. Citizen Kane “Rosebud!”

Dialogue

Instead of describing the action directly, have characters tell it to one another.

e.g. The Dialogues of Plato …or The Breakfast Club (or one of my favourite sci-fi short stories).

In Media Res

Begin in the middle of the action. No exposition allowed, but you can drop hints.

e.g. Mad Max: Fury Road (or Star Wars, if it didn’t have the opening crawl).

Backstory

Begin with a looooong zooooom into the past before taking up the story today.

e.g. 2001: A Space Odyssey.

Distancing Effect

Just the facts with no embellishment.

e.g. A police report.

You get the idea.

In a random draw, everyone received a card with a narrative device on it. Now they had to retell the story they chose using that framing. That led to some great results:

• Toy Story, retold as a conversation between Andy and his psychiatrist (dialogue),
• E.T., retold as a missing person’s report on an alien planet (distancing effect),
• Elf, retold with an introduction about the very first Christmas (backstory),
• Robocop, retold with Murphy already a cyborg, remembering his past (flashback),
• The Three Little Pigs, retold with the wolf already at the door and no explanation as to why there’s straw everywhere (in media res).

Once everyone had the hang of it, I asked them to revisit their mind maps and other materials from the previous day’s workshop. Next, they arranged the “chunks” of that story into a linear narrative …but without worrying about getting it right—it’s not going to stay linear for long. Then, everyone is once again given a narrative structure. Now try rearranging and restructuring your story to use that framework. If something valuable comes out of that, great! If not, well, it’s still a fun creative exercise.

And that was pretty much it. I had no idea what I was doing, but it didn’t matter. It wasn’t really about me. It was about helping others take their existing material and play with it.

That said, I’m glad I finally got this process out into the world in some kind of semi-formalised way. I’ve been preparing talks and articles using these narrative exercises for a while, but this workshop was just the motivation I needed to put some structure on the process.

I think I might try to create a proper deck of cards—along the lines of Brian Eno’s Oblique Strategies or Stephen Andersons’s Mental Notes—so that everyone has the option of injecting a random narrative structural idea into the mix whenever they’re stuck.

At the very least, it would be a distraction from listening to that pesky inner critic.

When I got back from Bletchley Park yesterday, I immediately started huffduffing more stories about cryptography and code-breaking.

One of the stories I found was an episode of Ockham’s Razor featuring Professor Mark Dodgson. He talks about the organisational structure at Bletchley Park:

The important point was the organization emphasised team-working and open knowledge sharing where it was needed, and demarcation and specialisation where it was most appropriate.

This reminds of another extraordinary place, also displaying remarkable levels of collaboration, that has an unusual lack of traditional hierarchies and structure: CERN.

Bletchley Park produced the computer. CERN produced the web.

After speaking at Go Beyond Pixels in St. John’s, I had some time to explore Newfoundland a little bit. Geri was kind enough to drive me to a place I really wanted to visit: the cable station at Heart’s Content.

I’ve wanted to visit Heart’s Content (and Porthcurno in Cornwall) ever since reading The Victorian Internet, a magnificent book by Tom Standage that conveys the truly world-changing nature of the telegraph. Heart’s Content plays a pivotal role in the story: the landing site of the transatlantic cable, spooled out by the Brunel-designed Great Eastern, the largest ship in the world at the time.

Recently I was sent an advance reading copy of Tubes by Andrew Blum. It makes a great companion piece to Standage’s book as Blum explores the geography of the internet:

For all the talk of the placelessness of our digital age, the Internet is as fixed in real, physical places as any railroad or telephone system ever was.

There’s an interview with Andrew Blum on PopTech, a review of Tubes on Brain Pickings, and I’ve huffduffed a recent talk by Andrew Blum in Philadelphia.

Now there are more places I want to visit: the nexus points on TeleGeography’s Submarine Cable Map; the hubs of Hibernia Atlantic, whose about page reads like a viral marketing campaign for some soon-to-be-released near-future Hollywood cyberpunk thriller.

I’ve got the kind of travel bug described by Neal Stephenson in his classic 1996 Wired piece Mother Earth Mother Board:

In which the hacker tourist ventures forth across the wide and wondrous meatspace of three continents, acquainting himself with the customs and dialects of the exotic Manhole Villagers of Thailand, the U-Turn Tunnelers of the Nile Delta, the Cable Nomads of Lan tao Island, the Slack Control Wizards of Chelmsford, the Subterranean Ex-Telegraphers of Cornwall, and other previously unknown and unchronicled folk; also, biographical sketches of the two long-dead Supreme Ninja Hacker Mage Lords of global telecommunications, and other material pertaining to the business and technology of Undersea Fiber-Optic Cables, as well as an account of the laying of the longest wire on Earth, which should not be without interest to the readers of Wired.

Maybe one day I’ll get to visit the places being designed by Sheehan Partners, currently only inhabited by render ghosts on their website (which feels like it’s part of the same subversive viral marketing campaign as the Hibernia Atlantic site).

Perhaps I can find a reason to stop off in Ashburn, Virginia or The Dalles, Oregon, once infamous as the site of a cult-induced piece of lo-tech bioterrorism, now the site of Google’s Project 02. Not that there’s much chance of being allowed in, given Google’s condescending attitude when it comes to what they do with our data: “we know what’s best, don’t you trouble your little head about it.”

It’s that same attitude that lurks behind that most poisonous of bullshit marketing terms…

The cloud.

What a crock of shit.

Whereas other bullshit marketing terms once had a defined meaning that has eroded over time due to repeated use and abuse—Ajax, Web 2.0, HTML5, UX—“the cloud” is a term that sets out to deceive from the outset, imbued with the same Lakoffian toxicity as “downsizing” or “friendly fire.” It is the internet equivalent of miasma theory.

My friend @substitute suggested replacing every technobabble instance of “cloud” with “the Moon” and it’s changed my life

— Pinboard (@Pinboard) January 6, 2012

Death to the cloud! Long live the New Flesh of servers, routers, wires and cables.