Tags: work



Progressive Web Apps - My new book is available! | Dean Hume

This looks interesting—a new book by Dean Hume all about progressive web apps. A few chapters are available to download.

Amber Wilson: What Am I Looking For?

If you’re looking for a Brighton-based junior developer, you should snap up Amber right now!

Network based image loading using the Network Information API in Service Worker | justmarkup

This is clever—you can use the navigator.connection API from a service worker (because it’s asynchronous) which means you can have a service worker script that serves differently sized images based on bandwidth.

The Fallacies of Distributed Computing (Applied to Front-End Performance) – CSS Wizardry – CSS Architecture, Web Performance Optimisation, and more, by Harry Roberts

Harry cautions against making assumptions about the network when it comes to front-end development:

Yet time and time again I see developers falling into the same old traps—making assumptions or overly-optimistic predictions about the conditions in which their apps will run.

Planning for the worst-case scenario is never a wasted effort:

If you build and structure applications such that they survive adverse conditions, then they will thrive in favourable ones.

Salva de la Puente - What is a PWA

Here’s a nice one-sentence definition for the marketing folk:

A Progressive Web App is a regular website following a progressive enhancement strategy to deliver native-like user experiences by using modern Web standards.

But if you’re talking to developers, I implore you to concretely define a Progressive Web App as the combination of HTTPS, a service worker, and a Web App Manifest.

The Burden of Precision | Daniel T. Eden, Designer

I think Dan is on to something here—design tools that offer pixel perfection at an early stage are setting us up for disappointment and frustration. Broad brushstrokes early on, followed by more precise tinkering later, feels like a more sensible approach.

With the help of a robust and comprehensive design system, I am certain that we could design in much broader strokes, and concentrate on making the finished product, rather than our design outputs, highly precise and reflective of our ideal.

Relative Requirements – CSS Wizardry

I really like this exercise by Harry. I’ve done similar kinds of grading using dot-voting in the past. It feels like an early step to establishing design principles: “this over that.”

By deciding what we value up-front, we have an agreement that we can look back on in order to help us settle these conflicts and get us back on track again.

Relative Requirements remove the personal aspect of these disagreements and instead focuses on more objective agreements that we made as a team.

Post Pinging and Webmentions at Midlands Maidens Nottingham Escorts

Okay, this is somewhat odd …it looked like I was getting spam webmentions from an escort agency to an old post of mine. It turns out that technically it’s not spam—they’re genuinely linking to my post from this post on their blog which is actually about webmentions.

And that, your honour, is how this site ended up in my browser history.

Jeremy Keith on Evaluating Technology at SmashingConf Barcelona 2017 on Vimeo

I think this is the best delivery of this talk I’ve ever given. It was something about being in that wonderful venue.

I got quite worked up around the the 32 minute mark.

Jeremy Keith on Evaluating Technology at SmashingConf Barcelona 2017

Inside Design: Clearleft

A profile of Clearleft from the nice people at InVision.

Although there is this:

The Art of Comments | CSS-Tricks

Great advice on writing sensible comments in your code.

Airplanes and Ashtrays – CSS Wizardry

Whenever you plan or design a system, you need to build in your own ashtrays—a codified way of dealing with the inevitability of somebody doing the wrong thing. Think of what your ideal scenario is—how do you want people to use whatever you’re building—and then try to identify any aspects of it which may be overly opinionated, prescriptive, or restrictive. Then try to preempt how people might try to avoid or circumvent these rules, and work back from there until you can design a safe middle-ground into your framework that can accept these deviations in the safest, least destructive way possible.

Netflix functions without client-side React, and it’s a good thing - JakeArchibald.com

A great bucketload of common sense from Jake:

Rather than copying bad examples from the history of native apps, where everything is delivered in one big lump, we should be doing a little with a little, then getting a little more and doing a little more, repeating until complete. Think about the things users are going to do when they first arrive, and deliver that. Especially consider those most-likely to arrive with empty caches.

And here’s a good way of thinking about that:

I’m a fan of progressive enhancement as it puts you in this mindset. Continually do as much as you can with what you’ve got.

All too often, saying “use the right tool for the job” is interpreted as “don’t use that tool!” but as Jake reminds us, the sign of a really good tool is its ability to adapt instead of demanding rigid usage:

Netflix uses React on the client and server, but they identified that the client-side portion wasn’t needed for the first interaction, so they leaned on what the browser can already do, and deferred client-side React. The story isn’t that they’re abandoning React, it’s that they’re able to defer it on the client until it’s was needed. React folks should be championing this as a feature.

Can You Afford It?: Real-world Web Performance Budgets – Infrequently Noted

Alex looks at the mindset and approaches you need to adopt to make a performant site. There’s some great advice in here for setting performance budgets for JavaScript.

JavaScript is the single most expensive part of any page in ways that are a function of both network capacity and device speed. For developers and decision makers with fast phones on fast networks this is a double-whammy of hidden costs.

Transpiled for-of Loops are Bad for the Client - daverupert.com

This story is just a personal reminder for me to repeatedly question what our tools spit out. I don’t want to be the neophobe in the room but I sometimes wonder if we’re living in a collective delusion that the current toolchain is great when it’s really just morbidly complex. More JavaScript to fix JavaScript concerns the hell out of me.

Yes! Even if you’re not interested in the details of Dave’s story of JavaScript optimisation, be sure to read his conclusion.

I am responsible for the code that goes into the machine, I do not want to shirk the responsibility of what comes out. Blind faith in tools to fix our problems is a risky choice. Maybe “risky” is the wrong word, but it certainly seems that we move the cost of our compromises to the client and we, speaking from personal experience, rarely inspect the results.

Voice Guidelines | Clearleft

I love what Ben is doing with this single-serving site (similar to my design principles collection)—it’s a collection of handy links and resources around voice UI:

Designing a voice interface? Here’s a useful list of lists: as many guiding principles as we could find, all in one place. List compiled and edited by Ben Sauer @bensauer.

BONUS ITEM: Have him run a voice workshop for you!

Mozilla Developer Roadshow Asia Jeremy Keith - YouTube

At the 14 minute mark I had to deal with an obstreperous member of the audience. He wasn’t heckling exactly …he just had a very bad experience with web components, and I think my talk was triggering for him.

Mozilla Developer Roadshow Asia: Jeremy Keith

Failing to distinguish between a tractor trailer and the bright white sky | booktwo.org

James talks about automation and understanding.

Just because a technology – whether it’s autonomous vehicles, satellite communications, or the internet – has been captured by capital and turned against the populace, doesn’t mean it does not retain a seed of utopian possibility.

Service Worker Registration  |  Web Fundamentals  |  Google Developers

Hmm …seems like I should probably wait for the load event before triggering navigator.serviceworker.register().

Defining design principles at EMBL | Journal | The Personal Disquiet of Mark Boulton

Mark describes the process he favours for creating (discovering?) design principles, like the ones for EMBL (I must remember to add those to the collection).

All you do is be mindful of when the team repeats design desires. This could be several members of the team say the same thing in a slightly different way, or that you keep circling around and around a problem but struggle to articulate it. By being mindful at all times to this a team can quickly pull together principles that are derived from doing the work on their particular problem rather than principles which are imposed on the work. An important difference.