Tags: book

385

sparkline

Friday, May 19th, 2017

Notes From An Emergency

But real problems are messy. Tech culture prefers to solve harder, more abstract problems that haven’t been sullied by contact with reality. So they worry about how to give Mars an earth-like climate, rather than how to give Earth an earth-like climate. They debate how to make a morally benevolent God-like AI, rather than figuring out how to put ethical guard rails around the more pedestrian AI they are introducing into every area of people’s lives.

Thursday, May 11th, 2017

Programming Design Systems

This is a really intriguing book that combines design theory and programming—learn about contrast, colour, and shapes, with each lesson supported by code examples.

It’s still a work in progress but the whole thing is online for free. Yay for web books!

Wednesday, May 3rd, 2017

Build a Better Monster: Morality, Machine Learning, and Mass Surveillance

So what happens when these tools for maximizing clicks and engagement creep into the political sphere?

This is a delicate question! If you concede that they work just as well for politics as for commerce, you’re inviting government oversight. If you claim they don’t work well at all, you’re telling advertisers they’re wasting their money.

Facebook and Google have tied themselves into pretzels over this.

Tuesday, May 2nd, 2017

leaving the future behind – Al Robertson

Science fiction isn’t about technology, it’s about people …and how people change in response to technology.

So ironically, perhaps the only way that any piece of science fiction can be sure that it will remain resonant as the years pass is to make sure that any technical speculation can drop away once it’s no longer relevant. The science will fall back to Earth like an exhausted booster section, tumbling away from the rocket that will one day reach the stars. And then we’ll be left with stories about how people change when change arrives – and that, for me, is what science fiction is.

Monday, May 1st, 2017

Springer Nature frontend playbook: house style guide

I like it when organisations share their in-house coding styles. This one from Springer Nature not only has guides for HTML, CSS, and JavaScript, but it also has a good primer on progressive enhancement.

Thursday, April 13th, 2017

Digital Assistants, Facebook Quizzes, And Fake News! You Won’t Believe What Happens Next | Laura Kalbag

A great presentation from Laura on how tracking scripts are killing the web. We can point our fingers at advertising companies to blame for this, but it’s still developers like us who put those scripts onto websites.

We need to ask ourselves these questions about what we build. Because we are the gatekeepers of what we create. We don’t have to add tracking to everything, it’s already gotten out of our control.

Tuesday, April 11th, 2017

Reflections on Resilient Web Design - Scott Dawson

I’m genuinely touched that my little web book could inspire someone like this. I absolutely love reading about what people thought of the book, especially when they post on their own site like this.

This book has inspired me to approach web site building in a new way. By focusing on the core functionality and expanding it based on available features, I’ll ensure the most accessible site I can. Resilient web sites can give a core experience that’s meaningful, but progressively enhance that experience based on technical capabilities.

Monday, April 10th, 2017

Transforming Our Libraries from Analog to Digital: A 2020 Vision | EDUCAUSE

Brewster Kahle outlines his vision for library collaboration in curating and distributing digital works.

Recommended Reading: Resilient Web Design, a Free e-Book from Jeremy Keith – WordPress Tavern

A jolly nice review of Resilient Web Design.

After just a few pages in, I could see why so many have read Resilient Web Design all in one go. It lives up to all the excellent reviews.

Thursday, March 23rd, 2017

“What have they done to my library?” - Caitlin Moran

That library was a Pandorica of fabulous, interwoven randomness, as rich as plum cake. Push a seed of curiosity in between any two books and it would grow, overnight, into a rainforest hot with monkeys and jaguars and blowpipes and clouds. The room was full, and my head was full. What a magical system to place around a penniless girl.

Monday, March 6th, 2017

What should you think about when using Facebook? – Vicki Boykis

To be clear, every company currently does some form of this tracking of users. There would simply be no other way to measure operations. But Facebook has quite clearly been tiptoeing outside the bounds of what is ethically acceptable data business practices for a while.

A thorough round-up of Facebook’s current data collection practices and what you can do about it.

I swore I wouldn’t write another book - Web Designer Notebook

Thinking of writing a book? Here’s some excellent advice and insights from Yaili, who only went and wrote another one.

Let me say this first: writing a book is hard work. It eats up all of your free time and mental space. It makes you feel like you are forever procrastinating and producing very little. It makes you not enjoy any free time. It’s like having a dark cloud hanging over your head at all times. At. All. Times.

Thursday, February 16th, 2017

Be More Careful on Facebook | Incisive.nu

Much of our courage and support comes from the people we read and talk to and love online, often on the very networks that expose us—and our friends—to genuine enemies of freedom and peace. We have to keep connected, but we don’t have to play on their terms.

Monday, February 13th, 2017

Discovering Resilient Web Design with Jeremy Keith

In which I attempt to answer some questions raised in the reading of Resilient Web Design.

Tuesday, February 7th, 2017

Audio book

I’ve recorded each chapter of Resilient Web Design as MP3 files that I’ve been releasing once a week. The final chapter is recorded and released so my audio work is done here.

If you want subscribe to the podcast, pop this RSS feed into your podcast software of choice. Or use one of these links:

Or if you can have it as one single MP3 file to listen to as an audio book. It’s two hours long.

So, for those keeping count, the book is now available as HTML, PDF, EPUB, MOBI, and MP3.

Tuesday, January 31st, 2017

The Schedule and the Stream

Matt takes a look at the history of scheduled broadcast media—which all began in Hungary in 1887 via telephone—and compares it to the emerging media context of the 21st century; the stream.

If the organizing principle of the broadcast schedule was synchronization — millions seeing the same thing at the same time — then the organizing principle of the stream is de-contextualization — stories stripped of their original context, and organized into millions of individual, highly personalized streams.

Monday, January 16th, 2017

Bring on the Flood · thewalrus.ca

Most of these dystopian scenarios are, after all, post-apocalyptic: the bad thing happened, the tension broke, and now so much less is at stake. The anxiety and ambivalence we feel toward late-stage capitalism, income inequality, political corruption, and environmental degradation—acute psychological pandemics in the here and now—are utterly dissolved. In a strange, wicked way, the aftermath feels fine.

Wednesday, January 11th, 2017

Making Resilient Web Design work offline

I’ve written before about taking an online book offline, documenting the process behind the web version of HTML5 For Web Designers. A book is quite a static thing so it’s safe to take a fairly aggressive offline-first approach. In fact, a static unchanging book is one of the few situations that AppCache works for. Of course a service worker is better, but until AppCache is removed from browsers (and until service worker is supported across the board), I’m using both. I wouldn’t recommend that for most sites though—for most sites, use a service worker to enhance it, and avoid AppCache like the plague.

For Resilient Web Design, I took a similar approach to HTML5 For Web Designers but I knew that there was a good chance that some of the content would be getting tweaked at least for a while. So while the approach is still cache-first, I decided to keep the cache fairly fresh.

Here’s my service worker. It starts with the usual stuff: when the service worker is installed, there’s a list of static assets to cache. In this case, that list is literally everything; all the HTML, CSS, JavaScript, and images for the whole site. Again, this is a pattern that works well for a book, but wouldn’t be right for other kinds of websites.

The real heavy lifting happens with the fetch event. This is where the logic sits for what the service worker should do everytime there’s a request for a resource. I’ve documented the logic with comments:

// Look in the cache first, fall back to the network
  // CACHE
  // Did we find the file in the cache?
      // If so, fetch a fresh copy from the network in the background
      // NETWORK
          // Stash the fresh copy in the cache
  // NETWORK
  // If the file wasn't in the cache, make a network request
      // Stash a fresh copy in the cache in the background
  // OFFLINE
  // If the request is for an image, show an offline placeholder
  // If the request is for a page, show an offline message

So my order of preference is:

  1. Try the cache first,
  2. Try the network second,
  3. Fallback to a placeholder as a last resort.

Leaving aside that third part, regardless of whether the response is served straight from the cache or from the network, the cache gets a top-up. If the response is being served from the cache, there’s an additional network request made to get a fresh copy of the resource that was just served. This means that the user might be seeing a slightly stale version of a file, but they’ll get the fresher version next time round.

Again, I think this acceptable for a book where the tweaks and changes should be fairly minor, but I definitely wouldn’t want to do it on a more dynamic site where the freshness matters more.

Here’s what it usually likes like when a file is served up from the cache:

caches.match(request)
  .then( responseFromCache => {
  // Did we find the file in the cache?
  if (responseFromCache) {
      return responseFromCache;
  }

I’ve introduced an extra step where the fresher version is fetched from the network. This is where the code can look a bit confusing: the network request is happening in the background after the cached file has already been returned, but the code appears before the return statement:

caches.match(request)
  .then( responseFromCache => {
  // Did we find the file in the cache?
  if (responseFromCache) {
      // If so, fetch a fresh copy from the network in the background
      event.waitUntil(
          // NETWORK
          fetch(request)
          .then( responseFromFetch => {
              // Stash the fresh copy in the cache
              caches.open(staticCacheName)
              .then( cache => {
                  cache.put(request, responseFromFetch);
              });
          })
      );
      return responseFromCache;
  }

It’s asynchronous, see? So even though all that network code appears before the return statement, it’s pretty much guaranteed to complete after the cache response has been returned. You can verify this by putting in some console.log statements:

caches.match(request)
.then( responseFromCache => {
  if (responseFromCache) {
      event.waitUntil(
          fetch(request)
          .then( responseFromFetch => {
              console.log('Got a response from the network.');
              caches.open(staticCacheName)
              .then( cache => {
                  cache.put(request, responseFromFetch);
              });
          })
      );
      console.log('Got a response from the cache.');
      return responseFromCache;
  }

Those log statements will appear in this order:

Got a response from the cache.
Got a response from the network.

That’s the opposite order in which they appear in the code. Everything inside the event.waitUntil part is asynchronous.

Here’s the catch: this kind of asynchronous waitUntil hasn’t landed in all the browsers yet. The code I’ve written will fail.

But never fear! Jake has written a polyfill. All I need to do is include that at the start of my serviceworker.js file and I’m good to go:

// Import Jake's polyfill for async waitUntil
importScripts('/js/async-waituntil.js');

I’m also using it when a file isn’t found in the cache, and is returned from the network instead. Here’s what the usual network code looks like:

fetch(request)
  .then( responseFromFetch => {
    return responseFromFetch;
  })

I want to also store that response in the cache, but I want to do it asynchronously—I don’t care how long it takes to put the file in the cache as long as the user gets the response straight away.

Technically, I’m not putting the response in the cache; I’m putting a copy of the response in the cache (it’s a stream, so I need to clone it if I want to do more than one thing with it).

fetch(request)
  .then( responseFromFetch => {
    // Stash a fresh copy in the cache in the background
    let responseCopy = responseFromFetch.clone();
    event.waitUntil(
      caches.open(staticCacheName)
      .then( cache => {
          cache.put(request, responseCopy);
      })
    );
    return responseFromFetch;
  })

That all seems to be working well in browsers that support service workers. For legacy browsers, like Mobile Safari, there’s the much blunter caveman logic of an AppCache manifest.

Here’s the JavaScript that decides whether a browser gets the service worker or the AppCache:

if ('serviceWorker' in navigator) {
  // If service workers are supported
  navigator.serviceWorker.register('/serviceworker.js');
} else if ('applicationCache' in window) {
  // Otherwise inject an iframe to use appcache
  var iframe = document.createElement('iframe');
  iframe.setAttribute('src', '/appcache.html');
  iframe.setAttribute('style', 'width: 0; height: 0; border: 0');
  document.querySelector('footer').appendChild(iframe);
}

Either way, people are making full use of the offline nature of the book and that makes me very happy indeed.

Monday, January 9th, 2017

Resilient Web Design | susan jean robertson

Well, this is nice! Susan has listed the passages she highlighted from Resilient Web Design.

In the spirit of the book, I read it in a browser, and I broke up my highlights by chapters. As usual, you should read the book yourself, these highlights are taken out of context and better when you’ve read the whole thing.