Tags: medium

342

sparkline

Tuesday, February 19th, 2019

Interaction 19

Right before heading to Geneva to spend the week hacking at CERN, I was in Seattle with a sizable Clearleft contingent to attend Interaction 19, the annual conference put on by the Interaction Design Association.

Ben has rounded up the highlights from my fellow Clearlefties. There are some good talks listed there: John Maeda, Nelly Ben Hayoun, and Jon Bell were thoroughly enjoyable. Some other talks were just okay, and there was one talk, by IXDA president Alok Nandi, that was almost impressive in how rambling and incoherent it was. It was like being in a scene from Silicon Valley. I remember clapping at the end; not out of appreciation, but out of relief.

If truth be told, Interaction 19 had about a day’s worth of really great content …spread out over three days. To be fair, that’s par for the course. When we went to Interaction 17 in New York, the hit/miss ratio was about the same:

There were some really good talks at the event, but alas, the muti-track format made it difficult to see all of them. Continuous partial FOMO was the order of the day.

And as I said at the time:

To be honest, the conference was only part of the motivation for the trip. Spending a week in New York with a gaggle of Clearlefties was its own reward.

So I’m willing to cut Interaction 19 a lot of slack. Even if quite a few of the talks were just so-so, getting to hang with Clearlefties in Seattle during snowmageddon was a lot of fun (and you’ll be pleased to hear that we didn’t even resort to cannibalism to survive).

But while the content of the conference was fair to middling, the organisation of it was a shambles:

Imagine the Fyre Festival but in downtown Seattle in winter. Welcome to @ixdconf. #ixd19

They sold more tickets than there were seats. I ended up watching the first morning’s keynotes being streamed to a screen in a conference room in a different building.

Now, I’ve been at events with keynotes that have overflow rooms—South by Southwest does this. But that’s at a different scale. This is a conference with a known number of attendees, each one of them spending over a thousand dollars to attend. I’m pretty sure that a first-come, first-served policy isn’t the best way of treating those attendees.

Anyway, here’s what I submitted for that round-up of the best talks, but which, for reasons of prudence, was omitted from the final post:

I really enjoyed the keynote by Liz Jackson on inclusive design. I would’ve enjoyed it even more if I could’ve seen it in person. Instead I watched it live-streamed to a meeting room two buildings over because the conference sold more tickets than they had seats for. This was after queueing in the cold for registration. So I feel like I learned a lot from Interaction 19 …about how not to organise a conference.

Still, as Ben notes:

We all enjoyed ourselves thoroughly, despite best efforts by the West Coast snow to disrupt the entire city.

I’m going to be back in Seattle in just under two weeks for An Event Apart. Now that’s a conference! It runs like a well-oiled machine, and every talk in its single track has been curated for excellence …with one exception.

Sunday, February 17th, 2019

Timelines of the web

Recreating the original WorldWideWeb browser was an exercise in digital archeology. With a working NeXT machine in the room, Kimberly was able to examine the source code for the first every browser and discover a treasure trove within. Like this gem in HTUtils.h:

#define TCP_PORT 80 /* Allocated to http by Jon Postel/ISI 24-Jan-92 */

Sure enough, by June of 1992 port 80 was documented as being officially assigned to the World Wide Web (Gopher got port 70). Jean-François Groff—who worked on the World Wide Web project with Tim Berners-Lee—told us that this was a moment they were very pleased about. It felt like this project of theirs was going places.

Jean-François also told us that the WorldWideWeb browser/editor was kind of like an advanced prototype. The idea was to get something up and running as quickly as possible. Well, the NeXT operating system had a very robust Text Object, so the path of least resistance for Tim Berners-Lee was to take the existing word-processing software and build a hypertext component on top of it. Likewise, instead of creating a brand new format, he used the existing SGML format and added one new piece: linking with A tags.

So the WorldWideWeb application was kind of like a word processor and document viewer mashed up with hypertext. Ted Nelson complains to this day that the original sin of the web was that it borrowed this page-based metaphor. But Nelson’s Project Xanadu, originally proposed in 1974 wouldn’t become a working reality until 2014—a gap of forty years. Whereas Tim Berners-Lee proposed his system in March 1989 and had working code within a year. There’s something to be said for being pragmatic and working with what you’ve got.

The web was also a mashup of ideas. Hypertext existed long before the web—Ted Nelson coined the term in 1963. There were conferences and academic discussions devoted to hypertext and hypermedia. But almost all the existing hypertext systems—including Tim Berners-Lee’s own ENQUIRE system from the early 80s—were confined to a local machine. Meanwhile networked computers were changing everything. First there was the ARPANET, then the internet. Tim Berners-Lee’s ambitious plan was to mash up hypertext with networks.

Going into our recreation of WorldWideWeb at CERN, I knew I wanted to convey this historical context somehow.

The World Wide Web officially celebrates its 30th birthday in March of this year. It’s kind of an arbitrary date: it’s the anniversary of the publication of Information Management: A Proposal. Perhaps a more accurate date would be the day the first website—and first web server—went online. But still. Let’s roll with this date of March 12, 1989. I thought it would be interesting not only to look at what’s happened between 1989 and 2019, but also to look at what happened between 1959 and 1989.

So now I’ve got two time cones that converge in the middle: 1959 – 1989 and 1989 – 2019. For the first time period, I made categories of influences: formats, hypertext, networks, and computing. For the second time period, I catalogued notable results: browsers, servers, and the evolution of HTML.

I did a little bit of sketching and quickly realised that these converging timelines could be represented somewhat like particle collisions. Once I had that idea in my head, I knew how I would be spending my time during the hack week.

Rather than jumping straight into the collider visualisation, I took some time to make a solid foundation to build on. I wanted to be sure that the timeline itself would be understable even if it were, say, viewed in the first ever web browser.

Progressive enhancement. Marking up (and styling) an interactive timeline that looks good in a modern browser and still works in the first ever web browser.

I marked up each timeline as an ordered list of h-events:

<li class="h-event y1968">
  <a href="https://en.wikipedia.org/wiki/NLS_%28computer_system%29" class="u-url">
    <time class="dt-start" datetime="1968-12-09">1968</time>
    <abbr class="p-name" title="oN-Line System">NLS</abbr>
  </a>
</li>

With the markup in place, I could concentrate on making it look halfway decent. For small screens, the layout is very basic—just a series of lists. When the screen gets wide enough, I lay those lists out horzontally one on top of the other. In this view, you can more easily see when events coincide. For example, ENQUIRE, Usenet, and Smalltalk all happen in 1980. But the real beauty comes when the screen is wide enough to display everthing at once. You can see how an explosion of activity in the early 90s. In 1994 alone, we get the release of Netscape Navigator, the creation of HTTPS, and the launch of Amazon.com.

The whole thing is powered by CSS transforms and positioning. Each year on a timeline has its own class that gets moved to the correct chronological point using calc(). I wanted to use translateX() but I couldn’t get the maths to work for that, so I had use plain ol’ left and right:

.y1968 {
  left: calc((1968 - 1959) * (100%/30) - 5em);
}

For events before 1989, it’s the distance of the event from 1959. For events after 1989, it’s the distance of the event from 2019:

.y2014 {
  right: calc((2019 - 2014) * (100%/30) - 5em);
}

(Each h-event has a width of 5em so that’s where the extra bit at the end comes from.)

I had to do some tweaking for legibility: bunches of events happening around the same time period needed to be separated out so that they didn’t overlap too much.

As a finishing touch, I added a few little transitions when the page loaded so that the timeline fans out from its centre point.

Et voilà!

Progressive enhancement. Marking up (and styling) an interactive timeline that looks good in a modern browser and still works in the first ever web browser.

I fiddled with the content a bit after peppering Robert Cailliau with questions over lunch. And I got some very valuable feedback from Jean-François. Some examples he provided:

1971: Unix man pages, one of the first instances of writing documents with a markup language that is interpreted live by a parser before being presented to the user.

1980: Usenet News, because it was THE everyday discussion medium by the time we created the web technology, and the Web first embraced news as a built-in information resource, then various platforms built on the web rendered it obsolete.

1982: Literary Machines, Ted Nelson’s book which was on our desk at all times

I really, really enjoyed building this “collider” timeline. It was a chance for me to smash together my excitement for web history with my enjoyment of using the raw materials of the web; HTML and CSS in this case.

The timeline pales in comparison to the achievement of the rest of the team in recreating the WorldWideWeb application but I was just glad to be able to contribute a little something to the project.

Hello WorldWideWeb.

Saturday, February 16th, 2019

WorldWideWeb

Nine people came together at CERN for five days and made something amazing. I still can’t quite believe it.

Coming into this, I thought it was hugely ambitious to try to not only recreate the experience of using the first ever web browser (called WorldWideWeb, later Nexus), but to also try to document the historical context of the time. Now that it’s all done, I’m somewhat astounded that we managed to achieve both.

Want to see the final result? Here you go:

worldwideweb.cern.ch

That’s the website we built. The call to action is hard to miss:

Launch WorldWideWeb

Behold! A simulation of using the first ever web browser, recreated inside your web browser.

Now you could try clicking around on the links on the opening doucment—remembering that you need to double-click on links to activate them—but you’ll quickly find that most of them don’t work. They’re long gone. So it’s probably going to be more fun to open a new page to use as your starting point. Here’s how you do that:

  1. Select Document from the menu options on the left.
  2. A new menu will pop open. Select Open from full document reference.
  3. Type a URL, like, say https://adactio.com
  4. Press that lovely chunky Open button.

You are now surfing the web through a decades-old interface. Double click on a link to open it. You’ll notice that it opens in a new window. You’ll also notice that there’s no way of seeing the current URL. Back then, the idea was that you would navigate primarily by clicking on links, creating your own “associative trails”, as first envisioned by Vannevar Bush.

But the WorldWideWeb application wasn’t just a browser. It was a Hypermedia Browser/Editor.

  1. From that Document menu you opened, select New file…
  2. Type the name of your file; something like test.html
  3. Start editing the heading and the text.
  4. In the main WorldWideWeb menu, select Links.
  5. Now focus the window with the document you opened earlier (adactio.com).
  6. With that window’s title bar in focus, choose Mark all from the Links menu.
  7. Go back to your test.html document, and highlight a piece of text.
  8. With that text highlighted, click on Link to marked from the Links menu.

If you want, you can even save the hypertext document you created. Under the Document menu there’s an option to Save a copy offline (this is the one place where the wording of the menu item isn’t exactly what was in the original WorldWideWeb application). Save the file so you can open it up in a text editor and see what the markup would’ve looked it.

I don’t know about you, but I find this utterly immersive and fascinating. Imagine what it must’ve been like to browse, create, and edit like this. Hypertext existed before the web, but it was confined to your local hard drive. Here, for the first time, you could create links across networks!

After five days time-travelling back thirty years, I have a new-found appreciation for what Tim Berners-Lee created. But equally, I’m in awe of what my friends created thirty years later.

Remy did all the JavaScript for the recreated browser …in just five days!

Kimberly was absolutely amazing, diving deep into the original source code of the application on the NeXT machine we borrowed. She uncovered some real gems.

Of course Mark wanted to make sure the font was as accurate as possible. He and Brian went down quite a rabbit hole, and with remote help from David Jonathan Ross, they ended up recreating entire families of fonts.

John exhaustively documented UI patterns that Angela turned into marvelous HTML and CSS.

Through it all, Craig and Martin put together the accomanying website. Personally, I think the website is freaking awesome—it’s packed with fascinating information! Check out the family tree of browsers that Craig made.

What a team!

Tuesday, February 12th, 2019

Back at CERN

We got the band back together.

In September of 2013, I had the great pleasure and privilege of going to CERN with a bunch of very smart people. I’m not sure how I managed to slip by. We were there to recreate the experience of using the line-mode browser. As I wrote at the time:

Just to be clear, the line-mode browser wasn’t the world’s first web browser. That honour goes to Tim Berners-Lee’s WorldWideWeb programme. But whereas WorldWideWeb only ran on NeXT machines, the line-mode browser worked cross-platform and was, therefore, instrumental in demonstrating the power of the web as a universally-accessible medium.

In the run-up to the 30th anniversary of the original (vague but exciting) proposal for what would become the World Wide Web, we’ve been invited back to try to recreate the experience of using that first web browser, the one that one ever ran on NeXT machines.

I missed the first day due to travel madness—flying back from Interaction 19 in Seattle during snowmageddon to Heathrow and then to Geneva—but by the time I arrived, my hackmates had already made a great start in identifying the objectives:

  1. Give people an understanding of the user experience of the WorldWideWeb browser.
  2. Demonstrate that a read/write philosophy was there from the beginning.
  3. Give context—what was going on at the time?

That second point is crucial. WorldWideWeb wasn’t just a web browser; it was a browser/editor. That’s by far the biggest change in terms of the original vision of the web and what we ended up getting from Mosaic onwards.

Remy is working hard on the first point. He documented the first day and now on the second day, he’s made enormous progress already.

I’m focusing on point number three. I want to show the historical context for the World Wide Web. Here’s my plan…

Seeing as we’re coming up on the thirtieth anniversary, I thought it would be interesting to take the year of the proposal (1989) and look back in a time cone of thirty years previous to that at the influences on Tim Berners-Lee. I also want to look at what has happened with the web in the thirty years since the proposal. So the date of the proposal will be a centre point, with the timespan of 1959-1989 converging on it from the past, and the timespan of 1989-2019 diverging from it into the future. I hope it could make for a nice visualisation. Maybe I could try to get it look like data from a particle collision.

We’re here till the weekend and everyone else has already made tremendous progress. Kimberly has been hacking the Gibson …well, that’s what it looked like when she was deep in the code of the NeXT machine we’ve borrowed from Musée Bolo (merci beaucoup!).

We took a little time out for a tour of the data centre. Oh, and at lunch time, we sat with Robert Cailliau and grilled him with questions about the birth of the web. Quite a day!

Now it’s time for me to hit the hay and prepare for another day of hacking in this extraordinary place.

Friday, February 1st, 2019

Ch-ch-ch-changes

It’s browser updatin’ time! Firefox 65 just dropped. So did Chrome 72. Safari 12.1 is shipping with iOS 12.2.

It’s interesting to compare the release notes for each browser and see the different priorities reflected in them (this is another reason why browser diversity is A Good Thing).

A lot of the Firefox changes are updates to dev tools; they just keep getting better and better. In fact, I’m not sure “dev tools” is the right word for them. With their focus on layout, typography, and accessibility, “design tools” might be a better term.

Oh, and Firefox is shipping support for some CSS properties that really help with print style sheets, so I’m disproportionately pleased about that.

In Safari’s changes, I’m pleased to see that the datalist element is finally getting implemented. I’ve been a fan of that element for many years now. (Am I a dork for having favourite HTML elements? Or am I a dork for even having to ask that question?)

And, of course, it wouldn’t be a Safari release without a new made up meta tag. From the people who brought you such hits as viewport and apple-mobile-web-app-capable, comes …supported-color-schemes (Apple likes to make up meta tags almost as much as Google likes to make up rel values).

There’ll be a whole bunch of improvements in how progressive web apps will behave once they’ve been added to the home screen. We’ll finally get some state persistence if you navigate away from the window!

Updated the behavior of websites saved to the home screen on iOS to pause in the background instead of relaunching each time.

Maximiliano Firtman has a detailed list of the good, the bad, and the “not sure yet if good” for progressive web apps on iOS 12.2 beta. Thomas Steiner has also written up the progress of progressive web apps in iOS 12.2 beta. Both are published on Ev’s blog.

At first glance, the release notes for Chrome 72 are somewhat paltry. The big news doesn’t even seem to be listed there. Maximiliano Firtman again:

Chrome 72 for Android shipped the long-awaited Trusted Web Activity feature, which means we can now distribute PWAs in the Google Play Store!

Very interesting indeed! I’m not sure if I’m ready to face the Kafkaesque process of trying to add something to the Google Play Store just yet, but it’s great to know that I can. Combined with the improvements coming in iOS 12.2, these are exciting times for progressive web apps!

Thursday, January 31st, 2019

New Adventures 2019

My trip to Nottingham for the New Adventures conference went very well indeed.

First of all, I had an all-day workshop to run. I was nervous. Because I no longer prepare slides for workshops—and instead rely on exercises and discussions—I always feel like I’m winging it. I’m not winging it, but without the security blanket of a slide deck, I don’t have anything to fall back on.

As it turned out, I needn’t have worried. The workshop went great. Well, I thought it went great but you’d really have to ask the attendees to know for sure. One of the workshop participants, Westley Knight, wrote about his experience:

The workshop itself was fluid enough to cater to the topics that the attendees were interested in; from over-arching philosophy to technical detail around service workers and new APIs. It has helped me to understand that learning in this kind of environment doesn’t have to be rigorously structured, and can be shaped as the day progresses.

(By the way, if you’d like me to run this workshop at your company, get in touch.)

With the workshop done, it was time for me to freak out fully about my conference talk. I was set to open the show. No pressure.

Actually, I felt pretty damn good about what I had been preparing for the past few months (it takes me aaages to put a talk together), but I always get nervous about presenting new material—until I’ve actually given the talk in front of a real audience, I don’t actually know if it’s any good or not.

Clare was speaking right after me, but she was having some technical issues. It’s funny; as soon as she had a problem, I immediately switched modes from conference speaker to conference organiser. Instead of being nervous, I flipped into being calm and reassuring, getting Clare’s presentation—and fonts—onto my laptop, and making sure her talk would go as smoothly as possible (it did!).

My talk went down well. The audience was great. Everyone paid attention, laughed along with the jokes, and really listened to what I was trying to say. For a speaker, you can’t ask for better than that. And people said very nice things about the talk afterwards. Sam Goddard wrote about how it resonated with him.

Wearing my eye-watering loud paisley shirt on stage at New Adventures.

You can peruse the slides from my presentation but they make very little sense out of context. But video of the talk is forthcoming.

The advantage to being on first was that I got my talk over with at the start of the day. Then I could relax and enjoy all the other talks. And enjoy them I did! I think all of the speakers were feeling the same pressure I was, and everybody brought their A-game. There were some recurring themes throughout the day: responsibility; hope; diversity; inclusion.

So New Adventures was already an excellent event by the time we got to Ethan, who was giving the closing talk. His talk elevated the day into something truly sublime.

Look, I could gush over how good Ethan’s talk was, or try to summarise it, but there’s really no point. I’ll just say that I felt the same sense of being present at something genuinely important that I felt when I was in the room for his original responsive web design talk at An Event Apart back in 2010. When the video is released, you really must watch it. In the meantime, you can read through the articles and books that Ethan cited in his presentation.

New Adventures 2019 was worth attending just for that one talk. I was very grateful I had the opportunity to attend, and I still can’t quite believe that I also had the opportunity to speak.

Wednesday, January 16th, 2019

Signal v Noise exits Medium – Signal v. Noise

Traditional blogs might have swung out of favor, as we all discovered the benefits of social media and aggregating platforms, but we think they’re about to swing back in style, as we all discover the real costs and problems brought by such centralization.

Monday, January 14th, 2019

Writing for hiring

Cassie joined Clearleft as a junior front-end developer last year. It’s really wonderful having her around. It’s a win-win situation: she’s enthusiastic and eager to learn; I’m keen to help her skill up in any way I can. And it’s working out great for the company—she has already demonstrated that she can produce quality HTML and CSS.

I’m very happy about Cassie’s success, not just on a personal level, but also from a business perspective. Hiring people into junior roles—when you’ve got the time and ability to train them—is an excellent policy. Hiring Charlotte back in 2014 was Clearleft’s first foray into hiring for a junior front-end dev position and it was a huge success. Cassie is demonstrating that it wasn’t just a fluke.

Alas, we can’t only hire junior developers. We’ve got a lot of work in the pipeline right now and we’re going to need a full-time seasoned developer who can hit the ground running. That’s why Clearleft is recruiting for a senior front-end developer.

As lead developer, Danielle will make the hiring decision, but because she’s so busy on project work right now—hence the need to hire more people—I’m trying to help her out any way I can. I offered to write the job description.

Seeing as I couldn’t just write “A clone of Danielle, please”, I had to think about what makes for a great front-end developer who uses their experience wisely. But I didn’t want to create a list of requirements, and I certainly didn’t want to create a list of specific technologies.

My first instinct was to look at other job ads and take my cue from them. But, let’s face it, most job ads are badly written, and prone to turning into laundry lists. So I decided to just write like I normally would. You know, like a human.

Here’s what I wrote. I hope it’s okay. I don’t really have much to compare it to, other than what I don’t want it to be.

Have a read of it and see what you think. And if you’re an experienced front-end developer who’d like to work by the seaside, you should apply for the role.

Sunday, January 13th, 2019

Code print

You know what I like? Print stylesheets!

I mean, I’m not a huge fan of trying to get the damn things to work consistently—thanks, browsers—but I love the fact that they exist (athough I’ve come across a worrying number of web developers who weren’t aware of their existence). Print stylesheets are one more example of the assumption-puncturing nature of the web: don’t assume that everyone will be reading your content on a screen. News articles, blog posts, recipes, lyrics …there are many situations where a well-considered print stylesheet can make all the difference to the overall experience.

You know what I don’t like? QR codes!

It’s not because they’re ugly, or because they’ve been over-used by the advertising industry in completely inapropriate ways. No, I don’t like QR codes because they aren’t an open standard. Still, I must grudgingly admit that they’re a convenient way of providing a shortcut to a URL (albeit a completely opaque one—you never know if it’s actually going to take you to the URL it promises or to a Rick Astley video). And now that the parsing of QR codes is built into iOS without the need for any additional application, the barrier to usage is lower than ever.

So much as I might grit my teeth, QR codes and print stylesheets make for good bedfellows.

I picked up a handy tip from a Smashing Magazine article about print stylesheets a few years back. You can the combination of a @media print and generated content to provide a QR code for the URL of the page being printed out. Google’s Chart API provides a really handy shortcut for generating QR codes:

https://chart.googleapis.com/chart?cht=qr&chs=150x150&chl=http://example.com

Except that there’s no telling how long that will continue to work. Google being Google, they’ve deprecated the simple image chart API in favour of the over-engineered JavaScript alternative. So just as I recently had to migrate all my maps over to Leaflet when Google changed their Maps API from under the feet of developers, the clock is ticking on when I’ll have to find an alternative to the Image Charts API.

For now, I’ve got the QR code generation happening on The Session for individual discussions, events, recordings, sessions, and tunes. For the tunes, there’s also a separate URL for each setting of a tune, specifically for printing out. I’ve added a QR code there too.

Experimenting with print stylesheets and QR codes.

I’ve been thinking about another potential use for QR codes. I’m preparing a new talk for An Event Apart Seattle. The talk is going to be quite practical—for a change—and I’m going to be encouraging people to visit some URLs. It might be fun to include the biggest possible QR code on a slide.

I’d better generate the images before Google shuts down that API.

Monday, January 7th, 2019

Resolution

The start of a new year is the traditional time for making resolutions. I’ve done it in the past. Now I’m not sure it’s such a good idea.

Think about it. It’s January. The middle of winter. It’s cold outside. The days are short. The only seasonal foods available are root vegetables and brassicas. Considering this lack of sunlight and fruit, it seems inadvisable to try to also deny yourself the intake of sugar, alcohol, meat, carbohydrates or gluten. You’re playing with a stacked deck. And then when inevitably, in the depths of winter, you cave in and pour yourself a glass of wine or indulge in a piece of cake, you now have the added weight of guilt on your shoulders to carry through the neverending winter nights.

Of course not all resolutions involve the abnegation of material pleasures. Many a new year’s promise involves a renewed commitment to work, exercise, or culture-vulching. But again, is this really the best time of year to do that? Given the weather, are you really in the best frame of mind to tackle such a tall order?

No, I don’t think I’ll be making any new year’s resolutions. If anything, this is the time of year when I won’t feel bad about having a pint of ale or a comforting stew. It’s also the time of year when I’m going to cut myself more slack if I’m not exercising diligently or working hard. Let’s face it, just making it through these months intact should be achievement enough.

If I were to make a resolution, it would only be that, come summertime, I’ll take stock and maybe make a commitment to cut down on some guilty pleasure or increase some noble activity then. A midsummer’s resolution, if you will.

Until then, I’ll be cosying up and indulging in any bodily comforts I crave. My resolve to do that is strong.

Monday, December 31st, 2018

2018 in numbers

I posted to adactio.com 1,387 times in 2018: sparkline

In amongst those notes were:

In my blog posts, the top tags were:

  1. frontend and development (42 posts), sparkline
  2. serviceworkers (27 posts), sparkline
  3. design (20 posts), sparkline
  4. writing and publishing (19 posts), sparkline
  5. javascript (18 posts). sparkline

In my links, the top tags were:

  1. development (305 links), sparkline
  2. frontend (289 links), sparkline
  3. design (178 links), sparkline
  4. css (110 links), sparkline
  5. javascript (106 links). sparkline

When I wasn’t updating this site:

But these are just numbers. To get some real end-of-year thoughts, read posts by Remy, Andy, Ana, or Bill Gates.

Saturday, December 29th, 2018

Words I wrote in 2018

I wrote just shy of a hundred blog posts in 2018. That’s an increase from 2017. I’m happy about that.

Here are some posts that turned out okay…

A lot of my writing in 2018 was on technical topics—front-end development, service workers, and so on—but I should really make more of an effort to write about a wider range of topics. I always like when Zeldman writes about his glamourous life. Maybe in 2019 I’ll spend more time letting you know what I had for lunch.

I really enjoy writing words on this website. If I go too long between blog posts, I start to feel antsy. The only relief is to move my fingers up and down on the keyboard and publish something. Sounds like a bit of an addiction, doesn’t it? Well, as habits go, this is probably one of my healthier ones.

Thanks for reading my words in 2018. I didn’t write them for you—I wrote them for me—but it’s always nice when they resonate with others. I’ll keep on writing my brains out in 2019.

Friday, December 28th, 2018

Books I read in 2018

I read twenty books in 2018, which is exactly the same amount as I read in 2017. Reflecting on that last year, I said “It’s not as many as I hoped.” It does seem like a meagre amount, but in my defence, some of the books I read this year were fairly hefty tomes.

I decided to continue my experiment from last year of alternating fiction and non-fiction books. That didn’t quite work out, but it makes for a good guiding principle.

In ascending reading order, these are the books I read in 2018

A Fire Upon The Deep by Vernor Vinge

★★★☆☆

I started this towards the end of 2017 and finished it at the start of 2018. A good sci-fi romp, but stretched out a little bit long.

Time Travel: A History by James Gleick

★★★★☆

I really enjoyed this, but then, that’s hardly a surprise. The subject matter is tailor made for me. I don’t think this quite matches the brilliance of Gleick’s The Information, but I got a real kick out of it. A book dedicated to unearthing the archeology of a science-fiction concept is a truly fascinating idea. And it’s not just about time travel, per se—this is a meditation on the nature of time itself.

Traction by Gino Wickman

Andy was quite taken with this management book and purchased multiple copies for the Clearleft leadership team. I’ll refrain from rating it because it was more like a homework assignment than a book I would choose to read. It crystalises some good organisational advice into practical steps, but it probably could’ve been quite a bit shorter.

Provenance by Ann Leckie

★★★☆☆

It feels very unfair but inevitable to compare this to Ann Leckie’s amazing debut Imperial Radch series. It’s not in quite the same league, but it’s also not trying to be. This standalone book has a lighter tone. It’s a rollicking good sci-fi procedural. It may not be as mind-blowingly inventive as Ancillary Justice, but it’s still a thoroughly enjoyable read.

Visions, Ventures, Escape Velocities: A Collection of Space Futures edited by Ed Finn and Joey Eschrich, with guest editor Juliet Ulman

★★★☆☆

This book is free to download so it’s rather excellent value for money. It alternates sci-fi short stories with essays. Personally, I would skip the essays—they’re all a bit too academic for my taste. But some of these stories are truly excellent. There’s a really nice flow to the collection: it begins in low Earth orbit, then expands out to the Mars, the asteroid belt, and beyond. Death on Mars by Madeline Ashby was a real standout for me.

The Best of Richard Matheson by Richard Matheson, edited by Victor LaValle

★★★★☆

For some reason, I was sent a copy of this book by an editor at Penguin Classics. I have no idea why, but thank you, Sam! This turned out to be a lot of fun. I had forgotten just how many classics of horror and sci-fi are the work of Richard Matheson. He probably wrote your favourite Twilight Zone episode. There’s a real schlocky enoyment to be had from snacking on these short stories, occassionally interspersed with genuinely disturbing moments and glimpses of beauty.

Close To The Machine: Technophilia And Its Discontents by Ellen Ullman

★★★☆☆

Lots of ’90s feels in this memoir. A lot of this still resonates today. It’s kind of fascinating to read it now with the knowledge of how this whole internet thing would end up going.

Gnomon by Nick Harkaway

★★★★☆

This gripped me from the start, and despite its many twisty strands, it managed to keep me with it all the way through. Maybe it’s a bit longer than it needs to be, and maybe some of the diversions don’t entirely work, but it makes up for that with its audaciousness. I still prefer Goneaway World, but any Nick Harkaway book is a must-read.

Hidden Figures by Margot Lee Shetterly

★★★★☆

Terrific stuff. If you’ve seen the movie, you’ve got about one tenth of the story. The book charts a longer arc and provides much deeper social and political context.

Dawn by Octavia Butler

★★★☆☆

This is filled with interesting ideas, but the story never quite gelled for me. I’m not sure if I should continue with the rest of the Lilith’s Brood series. But there’s something compelling and unsettling in here.

Sapiens: A Brief History Of Humankind by Yuval Noah Harari

★★☆☆☆

Frustratingly inconsistent. Here’s my full review.

The Fifth Season by N.K. Jemisin

★★★★☆

The Obelisk Gate by N.K. Jemisin

★★★☆☆

The Stone Sky by N.K. Jemisin

★★★☆☆

I devoured these books back-to-back. The Fifth Season was terrific—packed to the brim with inventiveness. But neither The Obelisk Gate nor The Stone Sky quite did it for me. Maybe my expectations were set too high by that first installment. But The Broken Earth is still a fascinating and enjoyable series.

Programmed Inequality by Marie Hicks

I was really looking forward to this one, but I found its stiff academic style hard to get through. I still haven’t finished it. But I figure if I could read Sapiens through to the end, I can certainly manage this. The subject matter is certainly fascinating, and the research is really thorough, but I’m afraid the book is showing its thesis roots.

The Power by Naomi Alderman

★★★☆☆

This plays out its conceit well, and it’s a fun read, but it’s not quite a classic. It feels more like a Neil Gamain or Lauren Beukes page-turner than, say, a Margaret Atwood exploration. Definitely worth a read, though.

New York 2140 by Kim Stanley Robinson

★★★★☆

The world-building (or maybe it’s world rebuilding) is terrific. But once again, as is often the case with Kim Stanley Robinson, I find the plot to be lacking. This is not in the same league as Aurora. It’s more like 2312-on-sea. It’s frustrating. I’m torn between giving it three stars or four. I’m going to be generous because even though it’s not the best Kim Stanley Robinson book, it contains some of his best writing. There are passages that are breathtakingly good.

A Thread Across The Ocean by John Steele Gordon

★★★★☆

After (temporarily) losing my library copy of New York 2140, I picked this up in a bookstore in Charlottesville so I’d have something to read during my stay there. I was very glad I did. I really, really enjoyed this. It’s all about the transatlantic telegraphic cable, so if that’s your thing—as it is mine—you’re going to enjoy this. It makes a great companion piece to Tom Standage’s The Victorian Internet. Come for the engineering, stay for the nautical tales of derring-do.

Borne by Jeff VanderMeer

★★★★☆

Not as disturbing as the Southern Reach Trilogy, but equally unsettling in its own way. Shades of Oryx and Crake, but in a more fantastically surreal setting.

The Airs Of Earth by Brian Aldiss

★★★☆☆

A good collection of short stories from the master of sci-fi. I’ve got a backlog of old pulpy paperback Aldiss collections like this that make for good snackfood for the mind.

Algorithms to Live By: The Computer Science of Human Decisions by Brian Christian and Tom Griffiths

A Christmas present from my brother-in-law. I just cracked this open, so you’ll have to come back next year to find out how it fared.

Alright. Now it’s time to pick the winners.

I think the best fiction book I read this year was Nick Harkaway’s Gnomon.

For non-fiction, it’s a tough call. I really enjoyed Hidden Figures and A Thread Across The Ocean, but I think I’m going to have to give the top spot to James Gleick’s Time Travel: A History.

But there were no five star books this year. Maybe that will change in 2019. And maybe I’ll read more books next year, too. We’ll see.

In 2017, seven of the twenty books I read were by women. In 2018, it was nine out of twenty (not counting anthologies). That’s better, but I want keep that trajectory going in 2019.

Songs I liked from 2018

Thursday, December 27th, 2018

Audio I listened to in 2018

I wrapped up last year with a list of some of the best audio I listened to in 2017. This year I huffduffed about 260 pieces of audio, so I could do a similar end-of-year list for 2018. But I thought I’d do something a little different this time.

It seems like podcasting is going from strength to strength with each passing year. Some friends of mine started new podcasts in 2018. Matt started Hobby Horse, where he talks to people about their tangential obsessions. Meanwhile Khoi started Wireframe, a jolly good podcast about design.

Apart from the trend of everyone having their own podcast these days, there’s also been a trend for quite short and manageable “seasons” of podcasts. See, for example, Horizon Line by Atlas Obscura, which is just four episodes long. Given the cherry-picking nature of my usual audio consumption (the very reason I made Huffduffer in the first place), this trend suits me quite well. There have been a few podcast runs in 2018 that I can recommend in their entirety.

The Secret History Of The Future is a collaboration between Seth Stevenson and Tom Standage, one of my favourite non-fiction authors. They look at modern technology stories through the lens of the past, much like Standage has done in books like The Victorian Internet. There are annoying sponsor blurbs to skip past, but apart from that, it’s a top-notch podcast.

I discovered Settling The Score this year. It’s a podcast all about film scores. The two hosts have spent the year counting down the top 25 scores in the American Film Institute’s list of (supposedly) greatest scores in American cinema history. It’s a pleasure to listen to them take a deep dive into each film and its score, analysing what works and what doesn’t. It will also make you want to rewatch the movie in question.

By far my favourite podcast listening experience this year was with Stephen Fry’s Great Leap Years. It’s just six episodes long, but it manages to tell the sweep of human history and technology in an entertaining and fascinating way. I’ll admit I’m biased because it dwells on many of my hobby horses: the printing press, the telegraph, Claude Shannon and information theory. There are no annoying sponsorship interruptions, and best of all, you’ve got the wonderful voice of Stephen Fry in your earholes the whole time. Highly recommended!

So there you have it: three podcasts from 2018 that are worth subscribing to in their entirety:

Wednesday, December 19th, 2018

Vienna

Back in December 1997, when Jessica and I were living in Freiburg, Dan came to visit. Together, we boarded a train east to Vienna. There we would ring in the new year to the sounds of the Salonorchester Alhambra, the band that Dan’s brother Andrew was playing in (and the band that would later be my first paying client when I made their website—I’ve still got the files lying around somewhere).

That was a fun New Year’s ball …although I remember my mortification when we went for gulash beforehand and I got a drop on the pristine tux that I had borrowed from Andrew.

My other memory of that trip was going to the Kunsthistorisches Museum to see the amazing Bruegel collection. It’s hard to imagine that ever being topped, but then this year, they put together a “once in a lifetime” collection, gathering even more Bruegel masterpieces together in Vienna.

Jessica got the crazy idea in her head that we could go there. In a day.

Looking at the flights, it turned out to be not such a crazy idea after all. Sure, it meant an early start, but it was doable. We booked our museum tickets, and then we booked plane tickets.

That’s how we ended up going to Vienna for the day this past Monday. It was maybe more time than I’d normally like to spend in airports in a 24 hour period, but it was fun. We landed, went into town for a wiener schnitzel, and then it was off to the museum for an afternoon of medieval masterpieces. Hunters in the Snow, the Tower of Babel, and a newly restored Triumph of Death sent from the Prado were just some of the highlights.

There’s a website to accompany the exhibition called Inside Bruegel. You can zoom on each painting to see the incredible detail. You can even compare the infrared and x-ray views. Dive in and explore the world of Pieter Bruegel the Elder.

The Battle between Carnival and Lent

Thursday, December 6th, 2018

Mistletoe Offline

This article first appeared in 24 Ways, the online advent calendar for geeks.

It’s that time of year, when we gather together as families to celebrate the life of the greatest person in history. This man walked the Earth long before us, but he left behind words of wisdom. Those words can guide us every single day, but they are at the forefront of our minds during this special season.

I am, of course, talking about Murphy, and the golden rule he gave unto us:

Anything that can go wrong will go wrong.

So true! I mean, that’s why we make sure we’ve got nice 404 pages. It’s not that we want people to ever get served a File Not Found message, but we acknowledge that, despite our best efforts, it’s bound to happen sometime. Murphy’s Law, innit?

But there are some Murphyesque situations where even your lovingly crafted 404 page won’t help. What if your web server is down? What if someone is trying to reach your site but they lose their internet connection? These are all things than can—and will—go wrong.

I guess there’s nothing we can do about those particular situations, right?

Wrong!

A service worker is a Murphy-battling technology that you can inject into a visitor’s device from your website. Once it’s installed, it can intercept any requests made to your domain. If anything goes wrong with a request—as is inevitable—you can provide instructions for the browser. That’s your opportunity to turn those server outage frowns upside down. Take those network connection lemons and make network connection lemonade.

If you’ve got a custom 404 page, why not make a custom offline page too?

Get your server in order

Step one is to make …actually, wait. There’s a step before that. Step zero. Get your site running on HTTPS, if it isn’t already. You won’t be able to use a service worker unless everything’s being served over HTTPS, which makes sense when you consider the awesome power that a service worker wields.

If you’re developing locally, service workers will work fine for localhost, even without HTTPS. But for a live site, HTTPS is a must.

Make an offline page

Alright, assuming your site is being served over HTTPS, then step one is to create an offline page. Make it as serious or as quirky as is appropriate for your particular brand. If the website is for a restaurant, maybe you could put the telephone number and address of the restaurant on the custom offline page (unsolicited advice: you could also put this on the home page, you know). Here’s an example of the custom offline page for this year’s Ampersand conference.

When you’re done, publish the offline page at suitably imaginative URL, like, say /offline.html.

Pre-cache your offline page

Now create a JavaScript file called serviceworker.js. This is the script that the browser will look to when certain events are triggered. The first event to handle is what to do when the service worker is installed on the user’s device. When that happens, an event called install is fired. You can listen out for this event using addEventListener:

addEventListener('install', installEvent => {
// put your instructions here.
}); // end addEventListener

In this case, you want to make sure that your lovingly crafted custom offline page is put into a nice safe cache. You can use the Cache API to do this. You get to create as many caches as you like, and you can call them whatever you want. Here, I’m going to call the cache Johnny just so I can refer to it as JohnnyCache in the code:

addEventListener('install', installEvent => {
  installEvent.waitUntil(
    caches.open('Johnny')
    .then( JohnnyCache => {
      JohnnyCache.addAll([
       '/offline.html'
      ]); // end addAll
     }) // end open.then
  ); // end waitUntil
}); // end addEventListener

I’m betting that your lovely offline page is linking to a CSS file, maybe an image or two, and perhaps some JavaScript. You can cache all of those at this point:

addEventListener('install', installEvent => {
  installEvent.waitUntil(
    caches.open('Johnny')
    .then( JohnnyCache => {
      JohnnyCache.addAll([
       '/offline.html',
       '/path/to/stylesheet.css',
       '/path/to/javascript.js',
         '/path/to/image.jpg'
      ]); // end addAll
     }) // end open.then
  ); // end waitUntil
}); // end addEventListener

Make sure that the URLs are correct. If just one of the URLs in the list fails to resolve, none of the items in the list will be cached.

Intercept requests

The next event you want to listen for is the fetch event. This is probably the most powerful—and, let’s be honest, the creepiest—feature of a service worker. Once it has been installed, the service worker lurks on the user’s device, waiting for any requests made to your site. Every time the user requests a web page from your site, a fetch event will fire. Every time that page requests a style sheet or an image, a fetch event will fire. You can provide instructions for what should happen each time:

addEventListener('fetch', fetchEvent => {
// What happens next is up to you!
}); // end addEventListener

Let’s write a fairly conservative script with the following logic:

  • Whenever a file is requested,
  • First, try to fetch it from the network,
  • But if that doesn’t work, try to find it in the cache,
  • But if that doesn’t work, and it’s a request for a web page, show the custom offline page instead.

Here’s how that translates into JavaScript:

// Whenever a file is requested
addEventListener('fetch', fetchEvent => {
  const request = fetchEvent.request;
  fetchEvent.respondWith(
    // First, try to fetch it from the network
    fetch(request)
    .then( responseFromFetch => {
      return responseFromFetch;
    }) // end fetch.then
    // But if that doesn't work
    .catch( fetchError => {
      // try to find it in the cache
      caches.match(request)
      .then( responseFromCache => {
        if (responseFromCache) {
         return responseFromCache;
       // But if that doesn't work
       } else {
         // and it's a request for a web page
         if (request.headers.get('Accept').includes('text/html')) {
           // show the custom offline page instead
           return caches.match('/offline.html');
         } // end if
       } // end if/else
     }) // end match.then
   }) // end fetch.catch
  ); // end respondWith
}); // end addEventListener

I am fully aware that I may have done some owl-drawing there. If you need a more detailed breakdown of what’s happening at each point in the code, I’ve written a whole book for you. It’s the perfect present for Murphymas.

Hook up your service worker script

You can publish your service worker script at /serviceworker.js but you still need to tell the browser where to look for it. You can do that using JavaScript. Put this in an existing JavaScript file that you’re calling in to every page on your site, or add this in a script element at the end of every page’s HTML:

if (navigator.serviceWorker) {
  navigator.serviceWorker.register('/serviceworker.js');
}

That tells the browser to start installing the service worker, but not without first checking that the browser understands what a service worker is. When it comes to JavaScript, feature detection is your friend.

You might already have some JavaScript files in a folder like /assets/js/ and you might be tempted to put your service worker script in there too. Don’t do that. If you do, the service worker will only be able to handle requests made to for files within /assets/js/. By putting the service worker script in the root directory, you’re making sure that every request can be intercepted.

Go further!

Nicely done! You’ve made sure that if—no, when—a visitor can’t reach your website, they’ll get your hand-tailored offline page. You have temporarily defeated the forces of chaos! You have briefly fought the tide of entropy! You have made a small but ultimately futile gesture against the inevitable heat-death of the universe!

This is just the beginning. You can do more with service workers.

What if, every time you fetched a page from the network, you stored a copy of that page in a cache? Then if that person tries to reach that page later, but they’re offline, you could show them the cached version.

Or, what if instead of reaching out the network first, you checked to see if a file is in the cache first? You could serve up that cached version—which would be blazingly fast—and still fetch a fresh version from the network in the background to pop in the cache for next time. That might be a good strategy for images.

So many options! The hard part isn’t writing the code, it’s figuring out the steps you want to take. Once you’ve got those steps written out, then it’s a matter of translating them into JavaScript.

Inevitably there will be some obstacles along the way—usually it’s a misplaced curly brace or a missing parenthesis. Don’t be too hard on yourself if your code doesn’t work at first. That’s just Murphy’s Law in action.

Monday, December 3rd, 2018

Programming CSS

There’s a worrying tendency for “real” programmers look down their noses at CSS. It’s just a declarative language, they point out, not a fully-featured programming language. Heck, it isn’t even a scripting language.

That may be true, but that doesn’t mean that CSS isn’t powerful. It’s just powerful in different ways to traditional languages.

Take CSS selectors, for example. At the most basic level, they work like conditional statments. Here’s a standard if statement:

if (condition) {
// code here
}

The condition needs to evaluate to true in order for the code in the curly braces to be executed. Sound familiar?

condition {
// styles here
}

That’s a very simple mapping, but what if the conditional statement is more complicated?

if (condition1 && condition2) {
// code here
}

Well, that’s what the decendant selector does:

condition1 condition2 {
// styles here
}

In fact, we can get even more specific than that by using the child combinator, the sibling combinator, and the adjacent sibling combinator:

  • condition1 > condition2
  • condition1 ~ condition2
  • condition2 + condition2

AND is just one part of Boolean logic. There’s also OR:

if (condition1 || condition2) {
// code here
}

In CSS, we use commas:

condition1, condition2 {
// styles here
}

We’ve even got the :not() pseudo-class to complete the set of Boolean possibilities. Once you add quantity queries into the mix, made possible by :nth-child and its ilk, CSS starts to look Turing complete. I’ve seen people build state machines using the adjacent sibling combinator and the :checked pseudo-class.

Anyway, my point here is that CSS selectors are really powerful. And yet, quite often we deliberately choose not to use that power. The entire raison d’être for OOCSS, BEM, and Smacss is to deliberately limit the power of selectors, restricting them to class selectors only.

On the face of it, this might seem like an odd choice. After all, we wouldn’t deliberately limit ourselves to a subset of a programming language, would we?

We would and we do. That’s what templating languages are for. Whether it’s PHP’s Smarty or Twig, or JavaScript’s Mustache, Nunjucks, or Handlebars, they all work by providing a deliberately small subset of features. Some pride themselves on being logic-less. If you find yourself trying to do something that the templating language doesn’t provide, that’s a good sign that you shouldn’t be trying to do it in the template at all; it should be in the controller.

So templating languages exist to enforce simplicity and ensure that the complexity happens somewhere else. It’s a similar story with BEM et al. If you find you can’t select something in the CSS, that’s a sign that you probably need to add another class name to the HTML. The complexity is confined to the markup in order to keep the CSS more straightforward, modular, and maintainable.

But let’s not forget that that’s a choice. It’s not that CSS in inherently incapable of executing complex conditions. Quite the opposite. It’s precisely because CSS selectors (and the cascade) are so powerful that we choose to put guard rails in place.

Monday, November 26th, 2018

Prototypes and production

When we do front-end development at Clearleft, we’re usually delivering production code, often in the form of a component library. That means our priorities are performance, accessibility, robustness, and other markers of quality when it comes to web development.

But every so often, we use the materials of front-end development—HTML, CSS, and JavaScript—to produce something that isn’t intended for production. I’m talking about prototyping.

There are plenty of non-code prototyping tools out there, and our designers often reach for them to communicate subtleties like motion design. But when it comes to testing a prototype with real users, it’s hard to beat the flexibility of HTML, CSS, and JavaScript. Load it up in a browser and away you go.

We do a lot of design sprints, where time is of the essence. The prototype we produce on the penultimate day of the sprint definitely won’t be production quality, but it will be good enough to test.

What’s interesting is that—when it comes to prototyping—our usual front-end priorities can and should go out the window. The priority now is speed. If that means sacrificing semantics or performance, then so be it. If I’m building a prototype and I find myself thinking “now, what’s the right class name for this component?”, then I know I’m in the wrong mindset. That question might be valid for production code, but it’s a waste of time for prototypes.

So these two kinds of work require very different attitudes. For production work, quality is key. For prototyping, making something quickly is what matters.

Whereas I would think long and hard about the performance impacts of third-party libraries and frameworks on a public project, I won’t give it a second thought when it comes to a prototype. Throw all the JavaScript frameworks and CSS libraries you want at it (although I would argue that in-browser technologies like CSS Grid have made CSS libraries like Bootstrap less necessary, even for prototyping).

Alternating between production projects and prototyping projects can be quite fun, if a little disorienting. It’s almost like I have to flip a switch in my brain to change tracks.

When a prototype is successful, works great, and tests well, there’s a real temptation to use the prototype code as the basis for the final product. Don’t do this! I’ve made that mistake in the past and it always ends badly. I ended up spending far more time trying to wrangle prototype code to a production level than if I had just started from a clean slate.

Build prototypes to test ideas, designs, interactions, and interfaces …and then throw the code away. The value of a prototype is in answering questions and testing hypotheses. Don’t fall for the sunk cost fallacy when it’s time to switch over into production mode.

Of course it should go without saying that you should never, ever release prototype code into production.

And yet…

More and more live sites seem to be built with a prototyping mindset. Weighty JavaScript frameworks are used regardless of appropriateness. Accessibility, if it’s even considered at all, is relegated to an afterthought. Fragile architectures are employed that rely on first loading and then executing JavaScript in order to render basic content. Developer experience is prioritised over user experience.

Heydon recently highlighted an article that offered this tip for aspiring web developers:

As for HTML, there’s not much to learn right away and you can kind of learn as you go, but before making your first templates, know the difference between in-line elements like span and how they differ from block ones like div.

That’s perfectly reasonable advice …if you’re building a prototype. But if you’re building something for public consumption, you have a duty of care to the end users.

Sunday, November 25th, 2018

How Warren Buffett Won His Multi-Million Dollar Long Bet

The story of Long Bets, specifically that one.

Given the nature of the long bet I’ve got running, I’m surprised that the Long Now Foundation are publishing on Medium. Wanna bet how long this particular URL will last?