If you want to use Brad’s Atomic Design naming convention—atoms, molecules, etc.—and you like using Fractal for making your components, this starter kit is just for you:
Keep what you need, delete what you don’t and add whatever you like on top of whats already there.
The bait’n’switch is laid bare. First, AMP is positioned as a separate format. Then, only AMP pages are allowed ranking in the top stories carousel. Now, let’s pretend none of that ever happened and act as though AMP is just another framework. Oh, and those separate AMP pages that you made? Turns out that was all just “transitional” and you’re supposed to make your entire site in AMP now.
I would genuinely love to know how the Polymer team at Google feel about this pivot. Everything claimed in this blog post about AMP is actually true of Polymer (and other libraries of web components that don’t have the luxury of bribing developers with SEO ranking).
Some alternative facts from the introduction:
AMP isn’t another “channel” or “format” that’s somehow not the web.
Weird …because that’s exactly how it was sold to us (as a direct competitor to similar offerings from Apple and Facebook).
It’s not an SEO thing.
That it outright false. Ask any company actually using AMP why they use it.
It’s not a replacement for HTML.
And yet, the article goes on to try convince you to replace HTML with AMP.
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.
I think about 90% of the JavaScript I’ve ever written was some DOM scripting to handle the situation of “when the user triggers an event on this element, do something to this other element.” Toggles, lightboxes, accordions, tabs, tooltips …they’re all basically following the same underlying pattern. So it makes sense to me to see this pattern abstracted into a little library.
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
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?
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.
This design system takes an interesting approach, splitting the documentation between designing and coding.
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.
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.)
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?