This looks like it could be an interesting library of interface patterns.
A starter list of Fractal examples and links. You can expand it.
What we get from the pattern library is time and freedom to be creative. I’ve seen people claim pattern libraries are the death of creativity and innovation in design. For us, it’s the opposite of that.
I like the questions that the TELUS team ask about any potential components to be added to their design system:
- Is it on brand?
- Is it accessible?
- Has it been tested?
- Can it be reused?
They also have design principles.
The Gov.uk design system is looking very, very good indeed—nicely organised with plenty of usage guidelines for every component.
Guidance on using components and patterns now follow a simple, consistent format based on task-based research into what users need in order to follow and trust an approach.
- Know where you stand before starting the journey
- Make sure everyone is speaking the same language
- Integrate the right tools into your team’s workflow
The steps that the Canva team took to turbocharge their design ops.
I’ll talk about why creating a shared design system has boosted our organizational productivity—and how you can help your teams improve product quality while reducing your company’s ‘design debt’.
I really like the way that this pattern library includes research insights to provide justification for design decisions.
No longer focused on recreating the wheel (or icon), designers can turn their attention to different types of challenges.
It’s so great to see the initial UX work that James and I prototyped in a design sprint come to fruition in the form of a progressive web app!
In the case of this web-app, if the tablets go offline, they will still store all the transactions that are made by customers. Once the tablet comes back online, it will sync it back up to the server. That is, essentially, what a Progressive Web App is — a kind of a website with a few more security and, most importantly, offline features.
Part one of a deep dive by Nathan into structuring design system documentation, published on Ev’s blog.
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.
I like the idea of “design bugs”:
Every two weeks or so, a group of designers would get together for a couple of hours to fix what we called “design bugs.” These were things that didn’t hinder functionality and wouldn’t have been filed as an engineering bug, but were places where we were using an old component, an existing one incorrectly, or a one-off alteration.
- What problems will a component library solve?
- Is everyone on the project behind the component library?
- How will the component library be used?
- What tool(s) will be used to build the component library?
- Where should the component library live?
- How granular should the library be? How should it be organized?
- How will component code be scoped? What about page layout?
- What data will the library use? What else should it have?
A step-by-step account of trying to find a way to keep Sketch files in sync with the code in a pattern library. The solution came from HTML Sketchapp, a more agnostic spiritual successor to AirBnB’s React Sketchapp.
The contract was incredibly straightforward—as long as you generated HTML, you could import it into Sketch.
After some tinkering, Mark Dalgleish came up with a command line tool to automate the creation of Sketch libraries from HTML elements with
It’s designed to read as a progressive enhancement when you look at the HTML it’s addressing.
Off-site backups of humanity’s knowledge and culture, stored in different media (including pyramidal crystals) placed in near-Earth orbit, the moon, and Mars.
We are developing specialized next-generation devices that we call Archs™ (pronounced “Arks”), which are designed to hold and transmit large amounts of data over long periods of time in extreme environments, including outer space and on the surfaces of other planetary bodies.
Our goal is to collect and curate important data sets and to install them on Archs™ that will be delivered to as many locations as possible for safekeeping.
To increase the chances that Archs™ will be found in the future, we aim for durability and massive redundancy across a broad diversity of locations and materials – a strategy that nature itself has successfully employed.