Tags: library

148

sparkline

Thursday, August 22nd, 2019

AccentDesign/Fractal-Atomic: An awesome starter point for your Fractal UI component library

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.

Thursday, May 2nd, 2019

AMP as your web framework – The AMP Blog

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.

Wednesday, March 13th, 2019

Unpoly: Unobtrusive JavaScript framework

This looks like it could be an interesting library of interface patterns.

Friday, December 14th, 2018

GitHub - frctl/awesome-fractal: A curated list of awesome things related to Fractal

A starter list of Fractal examples and links. You can expand it.

Thursday, September 13th, 2018

Magic Paintbox – Illuminated – Medium

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.

Wednesday, July 25th, 2018

Beyond style guides: lessons from scaling design at TELUS

I like the questions that the TELUS team ask about any potential components to be added to their design system:

  1. Is it on brand?
  2. Is it accessible?
  3. Has it been tested?
  4. Can it be reused?

They also have design principles.

Tuesday, June 26th, 2018

Introducing the GOV.UK Design System - Government Digital Service

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.

Wednesday, June 20th, 2018

The three lessons that changed how I think about design systems

  1. Know where you stand before starting the journey
  2. Make sure everyone is speaking the same language
  3. Integrate the right tools into your team’s workflow

Tuesday, June 5th, 2018

5 ways having a shared design system has helped us ship our designs faster – Product at Canva

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’.

Monday, June 4th, 2018

Bulb Design System

I really like the way that this pattern library includes research insights to provide justification for design decisions.

Saturday, May 26th, 2018

No, design systems will not replace design jobs — DesignSystems.com

No longer focused on recreating the wheel (or icon), designers can turn their attention to different types of challenges.

Tuesday, May 22nd, 2018

Easy Toggle State

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.

Monday, May 7th, 2018

Design systems

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

  1. the problem being solved;
  2. when to use this pattern;
  3. 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?

Tuesday, April 10th, 2018

Why Suffolk Libraries chose to build their own self-service app.

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.

Wednesday, March 21st, 2018

Hudl Uniform

This design system takes an interesting approach, splitting the documentation between designing and coding.

Documenting Components – EightShapes – Medium

Part one of a deep dive by Nathan into structuring design system documentation, published on Ev’s blog.

Tuesday, March 20th, 2018

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.

Monday, March 5th, 2018

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

The People Part of Design Systems – Related Works – Medium

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.

Friday, March 2nd, 2018

Questions To Ask Before Building a Component Library | Chromatic

  • 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?