Tags: development



Tuesday, March 20th, 2018

Brendan Dawes - Post from Instagram to Kirby

Brendan shows how he uses IFTTT and a webhook to post to his own site from Instagram. I think I might set up something similar to post from Untappd to my own site.

How Fast Is Amp Really? - TimKadlec.com

An excellent, thorough, even-handed analysis of AMP’s performance from Tim. The AMP format doesn’t make that much of a difference, the AMP cache does speed things up (as would any CDN), but it’s the pre-rendering that really delivers the performance boost …as long as you give up your URLs.

But right now, the incentives being placed on AMP content seem to be accomplishing exactly what you would think: they’re incentivizing AMP, not performance.

Announcing Windows 10 Insider Preview Build 17623 for Skip Ahead - Windows Experience BlogWindows Experience Blog

Well, Microsoft really buried the lede in this announcement:

…we will begin testing a change where links clicked on within the Windows Mail app will open in Microsoft Edge…

Yup, no matter which browser you’ve chosen to set as your default, hyperlinks will be hijacked to open with Edge. This is disgusting. It feels like a return to the shitty old days of Microsoft’s strong-arm tactics, just when Microsoft were gaining trust and respect.

Monday, March 12th, 2018

Swapping Images with the Sizes Attribute | Filament Group, Inc., Boston, MA

The hits just keep on coming from the Filament Group. Here Scott shares a really clever technique for creating an image magnifier using the sizes attribute of the img element.

Saturday, March 10th, 2018

Useful accessibility resources

A whoooole bunch of links about inclusive design, gathered together from a presentation.

It’s Dangerous to Go Stallone. Take Glyphhanger | Filament Group, Inc., Boston, MA

You’ll need to be comfortable with using the command line, but this is a very useful font subsetting tool from those clever folks at Filament Group.

Campaign. — Ethan Marcotte

Ethan is understandably dubious about Google’s recent announcement regarding the relaxation of the AMP’s iron fist.

Because it’s great to hear the AMP team make some overtures toward a more open web—and personally, I’d like to thank them sincerely for doing so. But if we’re swapping one set of Google-owned criteria for another set of slightly more permissive Google-owned criteria, I’m not sure how much will have changed.

Friday, March 9th, 2018

A workshop on building for resilience

In February, I tried out a new workshop two times—once at Webstock in New Zealand, and once in Hong Kong.

The workshop is called The Progressive Web: Building for Resilience. Here’s an excerpt form the blurb:

This workshop will show you to to think in a progressive way that works with the grain of the web. Together we’ll peel back the layers of the web and build upwards, creating experiences that work for everyone while making the best of cutting-edge browser technologies. From URL design to Progressive Web Apps, this journey will cover each stage of technological advancement.

Basically, it’s the workshop version of Resilient Web Design. If that book is the theory, this workshop is the practice.

Tim recently posted his tips for running workshops and there’s a lot in there that resonates with me. Like Tim, I’ve become less and less reliant on slides. In fact, this workshop—like my workshop on evaluating technology—has no slides. Instead it’s all about the exercises and going with the flow.

After starting with a warm-up, I canvas the room to see if there any specific topics, tools or technologies that people are particularly interested in covering. I’ll note those (on post-its slapped on the wall) for reference throughout the day, to try to make sure that those particular things are touched on at some point. Then I start with a thought experiment…

First of all, I get everyone to call out websites, services and apps that they use almost every day: Twitter, Facebook, Gmail, Slack, Google Docs, and so on. Those all get documented on the wall. Then it’s time to ask of each product, “What is the core functionality?” The idea here is to get beneath the surface-level verbs like swiping, tapping and dragging to get to the real purpose of a service: buying, selling, sharing, reading, writing, collaborating, and so on.

At this point I inform the attendees that the year is 1995. And now we’re going to build these services using the technology of this time. This is a playful way of getting answers to the question “What’s the simplest technology to enable the core functionality?” It’s mostly forms, links, and lots of heavy lifting on the server.

Then the real fun begins. “Enhance!” Moving forward in time, we get to add styles, we add interactivity with JavaScript, then Ajax, and then we get to really have fun with technologies like web sockets, geolocation, local storage, right the way up to service workers, notifications, and background sync. And the beauty of it all is that, if any of those technologies aren’t supported in a particular browser or device, the core functionality is still available.

Next, we apply this layered mindset to a new service. I split the attendees into groups, and each of them gets a procedurally-generated startup idea …generated by shuffling some cards. This is an exercise I first tried when I was teaching in Porto:

I made five cards with types of sites on them: news, social network, shopping, travel, and learning. Another five cards had subjects: books, music, food, pets, and cars. And another five cards had audiences: students, parents, the elderly, commuters, and teachers. Everyone was dealt a random card from each deck, resulting in briefs like “a travel site about food for the elderly” or “a social network about music for commuters.”

The first few exercises are good creative fun: come up with a name, then a logo, then a business model. Then it’s time to build. It starts with URL design. Then it’s content prioritisation (for a representative URL). Then it’s layout (sketching!). The enhancements have begun. “How might this URL benefit from Ajax?” “How might this URL benefit from geolocation?” “How might this URL benefit from offline storage?” “How might this URL benefit from a service worker?”

Workshop team 4 Workshop team 3 Workshop team 2 Workshop team 1

At this point, we’ve applied the layered, progressive approach at the scale of an entire service, and at the scale of an individual URL. Finally, we apply the same approach at the level of a component. It might be a navigation, or a carousel, or an interactive widget. In each case, the same process applies: “What’s the core functionality? What’s the simplest technology to enable that functionality? Enhance!”

Along the way, there are plenty of rabbit holes we can go down. Whether it’s accessibility, or progressive web apps, or pattern libraries, I go along with whatever people are curious about. But all of it ties back to the progressive, layered mindset I’m hoping to foster.

By the end of the day, I’m hoping that an attendee has one of two reactions:

  1. “What a waste of time! Everything in that workshop was blindingly obvious!” (in which case, excellent!—they’re already thinking in a progressive way), or
  2. “That workshop has completely changed the way I think about building on the web!” (I’m being hyperbolic here, but at the very least I’m hoping to impart a new perspective).

Having given the workshop a few times, I’m really pleased with how it went (and more important, I’m pleased that people enjoyed it). If this sounds like something that your company or team would enjoy, get in touch and we can take it from there.

Thursday, March 8th, 2018

Standardizing lessons learned from AMP – Accelerated Mobile Pages Project

This is very good news indeed—Google are going to allow non-AMP pages to get the same prioritised treatment as AMP pages …if they comply with the kind of performance criteria that Tim outlined.

It’ll take time to get there, but I’m so, so glad to see that Google aren’t going to try to force everyone to use their own proprietary format.

We are taking what we learned from AMP, and are working on web standards that will allow instant loading for non-AMP web content. We hope this work will also unlock AMP-like embeddability that powers Google Search features like the Top Stories carousel.

I just hope that this alternate route to the carousel won’t get lumped under the banner of “AMP”—that term has been pretty much poisoned at this point.

Wednesday, March 7th, 2018

Boxy SVG

This is impressive—a fully featured graphics app for creating SVGS right in your browser.


Metaballs, not to be confused with meatballs, are organic looking squishy gooey blobs.

Here’s the maths behind the metaballs (implemented in SVG).

Parallax scrolling with CSS variables | basicScroll

Don’t let the title fool you—this isn’t just for parallax scrolling (thank goodness!)—it’s for triggering any CSS updates based on scroll position. Using CSS custom properties makes a lot of sense. The JavaScript/CSS bridge enabled by custom properties is kind of their superpower. (That’s one of the reasons why I don’t like calling them “CSS variables” which makes them sound like Sass variables—they’re so much more than that!)

How we’ve made GOV.UK Elements even more accessible

A nice run-down of incremental accessibility improvements made to Gov.uk (I particularly like the technique of updating the title element to use the word “error” if the page is displaying a form that has issues).

Crucially, if any of the problems turned out to be with the browser or screen reader, they submitted bug reports—that’s the way to do it!

Measuring the Hard-to-Measure – CSS Wizardry

Everything old is new again—sometimes the age-old technique of using a 1x1 pixel image to log requests is still the only way to get certain metrics.

While tracking pixels are far from a new idea, there are creative ways in which we can use them to collect data useful to developers. Once the data is gathered, we can begin to make much more informed decisions about how we work.

Frequently Asked Questions [CSS Working Group Wiki]

Rebuttals to the most oft-asked requests for browsers to change the way they handle CSS.

Tuesday, March 6th, 2018

Minimal viable service worker

I really, really like service workers. They’re one of those technologies that have such clear benefits to users that it seems like a no-brainer to add a service worker to just about any website.

The thing is, every website is different. So the service worker strategy for every website needs to be different too.

Still, I was wondering if it would be possible to create a service worker script that would work for most websites. Here’s the script I came up with.

The logic works like this:

  • If there’s a request for an HTML page, fetch it from the network and store a copy in a cache (but if the network request fails, try looking in the cache instead).
  • For any other files, look for a copy in the cache first but meanwhile fetch a fresh version from the network to update the cache (and if there’s no existing version in the cache, fetch the file from the network and store a copy of it in the cache).

So HTML files are served network-first, while all other files are served cache-first, but in both cases a fresh copy is always put in the cache. The idea is that HTML content will always be fresh (unless there’s a problem with the network), while all other content—images, style sheets, scripts—might be slightly stale, but get refreshed with every request.

My original attempt was riddled with errors. Jake came to my rescue and we revised the script into something that actually worked. In the process, my misunderstanding of how await works led Jake to write a great blog post on await vs return vs return await.

I got there in the end and the script seems solid enough. It’s a fairly simplistic strategy that could work for quite a few sites, but it has some issues…

Service workers don’t perform any automatic cleanup of caches—that’s up to you to do (usually during the activate event). This script doesn’t do any cleanup so the cache might grow and grow and grow. For that reason, I think the script is best suited for fairly small sites.

The strategy also assumes that a file will either be fetched from the network or the cache. There’s no contingency for when both attempts fail. So there’s no fallback offline page, for example.

I decided to test it in the wild, but I expanded it slightly to fix the fallback issue. The version on the Ampersand 2018 website includes a worst-case-scenario option to show a custom offline page that has been pre-cached. (By the way, if you haven’t got a ticket for Ampersand yet, get a ticket now—it’s going to be superb day of web typography nerdery.)

Anyway, this fairly basic script seems to be delivering some good performance improvements. If you’ve got a site that you think would benefit from this network/caching strategy, and it’s served over HTTPS, then:

  1. Feel free to download the script or copy and paste it into a file called serviceworker.js,
  2. Put that file in the root directory of your website,
  3. Add this in a script element at the bottom of your HTML pages:

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

You can also use the script as a starting point. You might find issues specific to your particular website. That’s okay—you can tweak and adjust the script to suit your needs.

If this minimal service worker script proves in any way useful to you, thank Jake.

Monday, March 5th, 2018

Winning on Mobile

This looks like a handy tool for doing some quick’n’dirty competitor analysis when it comes to performance: create a scoreboard of sites to rank by speed (and calculate the potential revenue impact).

Many factors contribute to an engaging mobile experience. And speed is chief among them. Most people will abandon a mobile site visit if the page takes more than a few seconds to load. Use our Speed Scorecard to see how your site stacks up to the competition.

Australian Government Open Language for Design

The design system for the Australian government is a work in progress but it looks very impressive. The components are nicely organised and documented.

(I’ve contributed a suggestion for the documentation in line with what I wrote about recently.)

Sunday, March 4th, 2018

CodePen - Instagram.exe

I’m not sure why but I genuinely love this Windows 95 style interface for Instagram coded up by Gabrielle Wee.

Accessible By Design | Sparkbox | Web Design and Development

A primer on accessible colour contrast with links to some handy tools for testing.