Tuesday, July 30th, 2019
Tuesday, January 22nd, 2019
This is yet another great explainer from Ire. Tree shaking is one of those things that I thought I understood, but always had the nagging doubt that I was missing something. This article really helped clear things up for me.
Tuesday, June 26th, 2018
The horror …the horror.
Tuesday, May 29th, 2018
The transcript of a talk that is fantastic in every sense.
Fans are organised, motivated, creative, technical, and frankly flat-out awe-inspiring.
Monday, May 7th, 2018
Talking about scaling design can get very confusing very quickly. There are a bunch of terms that get thrown around: design systems, pattern libraries, style guides, and components.
The generally-accepted definition of a design system is that it’s the outer circle—it encompasses pattern libraries, style guides, and any other artefacts. But there’s something more. Just because you have a collection of design patterns doesn’t mean you have a design system. A system is a framework. It’s a rulebook. It’s what tells you how those patterns work together.
This is something that Cennydd mentioned recently:
Here’s my thing with the modularisation trend in design: where’s the gestalt?
In my mind, the design system is the gestalt. But Cennydd is absolutely right to express concern—I think a lot of people are collecting patterns and calling the resulting collection a design system. No. That’s a pattern library. You still need to have a framework for how to use those patterns.
I understand the urge to fixate on patterns. They’re small enough to be manageable, and they’re tangible—here’s a carousel; here’s a date-picker. But a design system is big and intangible.
Games are great examples of design systems. They’re frameworks. A game is a collection of rules and constraints. You can document those rules and constraints, but you can’t point to something and say, “That is football” or “That is chess” or “That is poker.”
Even though they consist entirely of rules and constraints, football, chess, and poker still produce an almost infinite possibility space. That’s quite overwhelming. So it’s easier for us to grasp instances of football, chess, and poker. We can point to a particular occurrence and say, “That is a game of football”, or “That is a chess match.”
But if you tried to figure out the rules of football, chess, or poker just from watching one particular instance of the game, you’d have your work cut for you. It’s not impossible, but it is challenging.
Likewise, it’s not very useful to create a library of patterns without providing any framework for using those patterns.
I would go so far as to say that the actual code for the patterns is the least important part of a design system (or, certainly, it’s the part that should be most malleable and open to change). It’s more important that the patterns have been identified, named, described, and crucially, accompanied by some kind of guidance on usage.
I could easily imagine using a tool like Fractal to create a library of text snippets with no actual code. Those pieces of text—which provide information on where and when to use a pattern—could be more valuable than providing a snippet of code without any context.
One of the very first large-scale pattern libraries I can remember seeing on the web was Yahoo’s Design Pattern Library. Each pattern outlined
- the problem being solved;
- when to use this pattern;
- when not to use this pattern.
Only then, almost incidentally, did they link off to the code for that pattern. But it was entirely possible to use the system of patterns without ever using that code. The code was just one instance of the pattern. The important part was the framework that helped you understand when and where it was appropriate to use that pattern.
I think we lose sight of the real value of a design system when we focus too much on the components. The components are the trees. The design system is the forest. As Paul asked:
What methodologies might we uncover if we were to focus more on the relationships between components, rather than the components themselves?
Wednesday, March 21st, 2018
Tal Leming’s thoroughly delightful (and obsessive) account of designing the 90 Minutes typeface for U.S. Soccer.
FIFA has strict regulations that govern the size and stroke weight of numbers and letters used on official match uniforms. This made me unbelievably paranoid. I had a nightmare that one of the national teams would be set for kickoff of an important match and the referee would suddenly blow the whistle and say, “Hey, hey, hey! The bottom stroke of that 2 is 1 mm too light. The United States must forfeit this match!”
Friday, December 1st, 2017
24 Ways is back! Yay! This year’s edition kicks off with a great article by Hui Jing on using
Chances are, the latest features will not ship across all browsers at the same time. But you know what? That’s perfectly fine. If we accept this as a feature of the web, instead of a bug, we’ve just opened up a lot more web design possibilities.
Friday, August 4th, 2017
Oh, how I wish I could’ve been at Web Directions Code in Melbourne to see this amazing presentation by Charlotte. I can’t quite get over how many amazing knowledge bombs she managed to drop in just 20 minutes!
Tuesday, July 4th, 2017
Dave explains how Jekyll Includes are starting to convert him to web components. The encapsulation is nice and neat. And he answers the inevitable “but why not use React?” question:
I like that Web Components are an entirely client-side technology but can be rendered server-side in existing tech stacks whether it’s Jekyll, Rails, or even some Enterprise Java system.
Monday, June 12th, 2017
A really great introduction to web components by Monica. But I couldn’t help but be disheartened by this:
Web components tend to have dependencies on other web components, so you need a package manager to herd all them cats.
For me, this kind of interdependence lessens the standalone nature of web components—it just doesn’t feel quite so encapsulated to me. I know that this can be solved with build tools, but now you’ve got two problems (and one more dependency).
Wednesday, May 31st, 2017
It’s no substitute for testing with real devices, but the “device wall” view in this Chrome plug-in is a nifty way of getting an overview of a site’s responsiveness at a glance.
Friday, October 7th, 2016
I heard nothing but good things about this talk from the Fronteers conference. There’s some great stuff in here—I really like its historical perspective.
Charlotte is a big fan of feature queries.
Thursday, October 6th, 2016
Eric walks through a really nice use of CSS shapes and
@supports on a page of the An Event Apart site.
It’s a nice little illustration of how we can use advanced features of CSS right now, without the usual wait for widespread support.
Tuesday, August 23rd, 2016
A thorough explanation of
@supports from Jen, with plenty of smart strategies for using it in your CSS today.
Friday, July 15th, 2016
From the ARPANET to the internet, this is a great history of the Domain Name System:
Root DNS servers operate in safes, inside locked cages. A clock sits on the safe to ensure the camera feed hasn’t been looped. Particularly given how slow DNSSEC implementation has been, an attack on one of those servers could allow an attacker to redirect all of the Internet traffic for a portion of Internet users. This, of course, makes for the most fantastic heist movie to have never been made.
Saturday, March 2nd, 2013
Thursday, December 13th, 2012
In a very mundane take on the cliché of a climactic showdown, I’ll be having a chat with Paul Boag at the top of Spinnaker Tower in February. Come on by if you’re in the neighbourhood.
Wednesday, September 17th, 2008
Animals and sports in serendipitous moments of FAIL.
Thursday, July 5th, 2007
Watch the adventures of Derek and Kathryn Featherstone in the run up to IronMan Lake Placid 2007. Check out the route maps: very slick.