Tags: work

484

sparkline

Saturday, February 25th, 2017

Social Media Needs A Travel Mode (Idle Words)

We don’t take our other valuables with us when we travel—we leave the important stuff at home, or in a safe place. But Facebook and Google don’t give us similar control over our valuable data. With these online services, it’s all or nothing.

We need a ‘trip mode’ for social media sites that reduces our contact list and history to a minimal subset of what the site normally offers.

Tuesday, February 21st, 2017

The Five-Tool Designer » Mike Industries

Mike lists five tool skills he looks for in a designer (not that every designer needs to have all five):

  1. Visual Design & Animation
  2. Interaction Design
  3. Getting Things Done
  4. Teamwork
  5. Leadership

Swap the first one out for some markup and CSS skills, and I reckon you’ve got a pretty good list for developers too.

Flatris

Tetris in your browser. Visit it once and it works offline (if your browser supports service workers) so go ahead and add it to your home screen.

Send messages when you’re back online with Service Workers and Background Sync – Twilio Cloud Communications Blog

This example of using background sync looks like it’s specific to Twilio, but the breakdown of steps is broad enough to apply to many situations:

On the page we need to:

  1. Register a Service Worker
  2. Intercept the “submit” event for our message form
  3. Place the message details into IndexedDB, an in browser database
  4. Register the Service Worker to receive a “sync” event

Then, in the Service Worker we need to:

  1. Listen for sync events
  2. When a sync event is received, retrieve the messages from IndexedDB
  3. For each message, send a request to our server to send the message
  4. If the message is sent successfully, then remove the message from IndexedDB

And that’s it.

ongoing by Tim Bray · Geek Career Paths

Tim Bray lists the options available to a technically-minded person thinking about their career path …but doesn’t mention the option of working at an agency.

Some good long-zoom observations in here:

The bad news that it’s a lot of work. We’re a young pro­fes­sion and we’re still work­ing out our best prac­tices, so the ground keeps chang­ing un­der you; it doesn’t get eas­i­er as the decades go by.

The good news is that it doesn’t get hard­er ei­ther. Once you learn to stop ex­pect­ing your knowl­edge to stay fresh, the pace of in­no­va­tion doesn’t feel to me like it’s much faster (or slow­er) now than it was in 1987 or 1997 or 2007. More good news: The tech­nol­o­gy gets bet­ter. Se­ri­ous­ly, we are so much bet­ter at build­ing soft­ware now than we used to be in any of those oth­er years end­ing in 7.

Monday, February 20th, 2017

The Secret History of Hypertext - The Atlantic

The latest excellent missive from The History Of The Web—A Brief History of Hypertext—leads back to this great article by Alex Wright on Paul Otlet’s Mundaneum.

Friday, February 17th, 2017

PWABuilder

A useful tool to help you generate a manifest file, icons, and a service worker for your progressive web appsite.

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, January 30th, 2017

Resilient Web and Tools — David Larlet

David picks up on one of the closing themes of Resilient Web Design—how we choose our tools. This has been on my mind a lot; it’s what I’ll be talking about at conferences this year.

That’s part of my job to ease processes and reduce frictions. That’s part of my job to take into account from the early beginning of a product its lasting qualities.

There’s a very good point here about when and how we decide to remove the things we’ve added to our projects:

We spend our time adding features without considering at the same pace the removal of useless ones. And still the true resilience (or is it perfection Antoine?) is when there is nothing more to take away. What are you removing on Monday to make our Web more resilient?

Sunday, January 29th, 2017

We built a PWA from scratch - This is what we learned

A nice straightforward account of building and testing a progressive web a… I mean, website.

I think every website from now on should use some of the Progressive Web App features. It’s even confusing to call it “Apps” as it applies to all websites and apps.

Friday, January 27th, 2017

A practical guide to Progressive Web Apps for organisations who don’t know anything about Progressive Web Apps : Records Sound the Same

Sally gives a really good introduction to using service workers as a progressive enhancement.

✨Implementing “Save For Offline” with Service Workers | Una Kravets Online✨

A great little script from Una that’s perfect for blogs and news sites—allowing users to explicitly save a page for offline reading.

Monday, January 23rd, 2017

Charlotte

Over the eleven-year (and counting) lifespan of Clearleft, people have come and gone—great people like Nat, Andy, Paul and many more. It’s always a bittersweet feeling. On the one hand, I know I’ll miss having them around, but on the other hand, I totally get why they’d want to try their hand at something different.

It was Charlotte’s last day at Clearleft last Friday. Her husband Tom is being relocated to work in Sydney, which is quite the exciting opportunity for both of them. Charlotte’s already set up with a job at Atlassian—they’re very lucky to have her.

So once again there’s the excitement of seeing someone set out on a new adventure. But this one feels particularly bittersweet to me. Charlotte wasn’t just a co-worker. For a while there, I was her teacher …or coach …or mentor …I’m not really sure what to call it. I wrote about the first year of learning and how it wasn’t just a learning experience for Charlotte, it was very much a learning experience for me.

For the last year though, there’s been less and less of that direct transfer of skills and knowledge. Charlotte is definitely not a “junior” developer any more (whatever that means), which is really good but it’s left a bit of a gap for me when it comes to finding fulfilment.

Just last week I was checking in with Charlotte at the end of a long day she had spent tirelessly working on the new Clearleft site. Mostly I was making sure that she was going to go home and not stay late (something that had happened the week before which I wanted to nip in the bud—that’s not how we do things ‘round here). She was working on a particularly gnarly cross-browser issue and I ended up sitting with her, trying to help work through it. At the end, I remember thinking “I’ve missed this.”

It hasn’t been all about HTML, CSS, and JavaScript. Charlotte really pushed herself to become a public speaker. I did everything I could to support that—offering advice, giving feedback and encouragement—but in the end, it was all down to her.

I can’t describe the immense swell of pride I felt when Charlotte spoke on stage. Watching her deliver her talk at Dot York was one my highlights of the year.

Thinking about it, this is probably the perfect time for Charlotte to leave the Clearleft nest. After all, I’m not sure there’s anything more I can teach her. But this feels like a particularly sad parting, maybe because she’s going all the way to Australia and not, y’know, starting a new job in London.

In our final one-to-one, my stiff upper lip may have had a slight wobble as I told Charlotte what I thought was her greatest strength. It wasn’t her work ethic (which is incredibly strong), and it wasn’t her CSS skills (‘though she is now an absolute wizard). No, her greatest strength, in my opinion, is her kindness.

I saw her kindness in how she behaved with her colleagues, her peers, and of course in all the fantastic work she’s done at Codebar Brighton.

I’m going to miss her.

Sunday, January 15th, 2017

Modernizing our Progressive Enhancement Delivery | Filament Group, Inc., Boston, MA

Scott runs through the latest improvements to the Filament Group website. There’s a lot about HTTP2, but also a dab of service workers (using a similar recipe to my site).

Browser Support for evergreen websites

Oh, how I wished everyone approached building for the web the way that Rachel does. Smart, sensible, pragmatic, and exciting!

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.

A Tale of Four Caches · Yoav Weiss

A cute explanation of different browser caches:

  • memory cache,
  • service worker cache,
  • disk cache, and
  • push cache.

Monday, January 9th, 2017

The Futures of Typography

A wonderfully thoughtful piece from Robin, ranging from the printing technologies of the 15th century right up to the latest web technologies. It’s got all my favourite things in there: typography, digital preservation, and service workers. Marvellous!

Friday, January 6th, 2017

From Tape Drives to Memory Orbs, the Data Formats of Star Wars Suck (Spoilers) | Motherboard

As always with sci-fi interfaces, the important part is telling the story, not realism or accuracy. Personally, I liked the way that the World War II trappings of Rogue One extended to communications and networking technologies.

Productivity in Terrible Times

When a solid 67% of your soul is engaged with battles elsewhere, how do you continue on with our ongoing, non-revolutionary work?