Tags: mp

Intentional and Emergent Design Systems | Jordan Moore

This is a really interesting distinction:

An intentional design system. The flavour and framework may vary, but the approach generally consists of: design system first → design/build solutions.

An emergent design system. This approach is much closer to the user needs end of the scale by beginning with creative solutions before deriving patterns and systems (i.e the system emerges from real, coded scenarios).

It’s certainly true that intentional design systems will invariably bake in a number of (unproven?) assumptions.

Taking shortcuts ･ Robin Rendle

How Robin really feels about Google AMP:

Here’s my hot take on this: fuck the algorithm, fuck the impressions, and fuck the king. I would rather trade those benefits and burn my website to the ground than be under the boot and heel and of some giant, uncaring corporation.

4 Rules for Intuitive UX – Learn UI Design

1. Obey the Law of Locality
2. ABD: Anything But Dropdowns
3. Pass the Squint Test
4. Teach by example

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.

Amphora. — Ethan Marcotte

There’s no sugar-coating it—AMP components are dreadfully inaccessible:

We’ve reached a point where AMP may “solve” the web’s performance issues by supercharging the web’s accessibility problem, excluding even more people from accessing the content they deserve.

The 2019 Design Systems Survey by Sparkbox

The good folks at Sparkbox ran a survey on design systems. Here are the results, presented in a flagrantly anti-Tufte manner.

Turing Tumble - Build Marble-Powered Computers

Boolean logic manifested in a Turing-complete game

Seamful Design and Ubicomp Infrastructure (PDF)

Seams:

Seamful design involves deliberately revealing seams to users, and taking advantage of features usually considered as negative or problematic.

The web without the web - DEV Community 👩‍💻👨‍💻

I love React. I love how server side rendering React apps is trivial because it all compiles down to vanilla HTML rather than web components, effectively turning it into a kickass template engine that can come alive. I love the way you can very effectively still do progressive enhancement by using completely semantic markup and then letting hydration do more to it.

I also hate React. I hate React because these behaviours are not defaults. React is not gonna warn you if you make a form using divs and unlabelled textboxes and send the whole thing to a server. I hate React because CSS-in-JS approaches by default encourage you to write completely self contained one off components rather than trying to build a website UI up as a whole. I hate the way server side rendering and progressive enhancement are not defaults, but rather things you have to go out of your way to do.

An absolutely brilliant post by Laura on how the priorites baked into JavaScript tools like React are really out of whack. They’ll make sure your behind-the-scenes code is super clean, but not give a rat’s ass for the quality of the output that users have to interact with.

And if you want to adjust the front-end code, you’ve got to set up all this tooling just to change a div to a button. That’s quite a barrier to entry.

In elevating frontend to the land of Serious Code we have not just made things incredibly over-engineered but we have also set fire to all the ladders that we used to get up here in the first place.

AMEN!

I love React because it lets me do my best work faster and more easily. I hate React because the culture around it more than the library itself actively prevents other people from doing their best work.

The Real Dark Web

Charlie’s thoughts on dev perception:

People speak about “the old guard” and “stupid backwards techniques”, forgetting that it’s real humans, with real constraints who are working on these solutions. Most of us are working in a “stupid backwards way” because that “backwardsness” WORKS. It is something that is proven and is clearly documented. We can implement it confident that it will not disappear from fashion within a couple of years.

Don’t build that app! – Luke Jackson - YouTube

This is a fascinating look at how you can get the benefits of React and npm without using React and npm.

Here’s an accompanying article on the same topic.

Approachable Tooling | TimKadlec.com

It’s fantastic that our web plumbing has gotten more powerful—tooling today is capable of so much. But all too often, that power comes with increased complexity that negatively impacts developer efficiency. Sometimes that’s unavoidable. The simplest approach doesn’t always win. But that should be the goal—to make things as simple as possible while still accomplishing what needs to be done. Like excellent plumbing, these systems should be as mostly invisible—chugging along, doing what we need them to do without getting in our way.

What I Like About Vue - daverupert.com

Dave enumerates the things about Vue that click for him. The component structure matches his mental model, and crucially, it’s relative straightforward to add Vue to an existing project instead of ripping everything out and doing things a certain way:

In my experience Angular, React, and a lot of other frameworks ultimately require you to go all in early and establish a large toolchain around these frameworks.

Progressive Enhancement

This post was originally written in 2015, but upon re-reading it today, it still (just about) holds up, so I finally hit publish.

Frontend Design, React, and a Bridge over the Great Divide

Brad describes how he has found his place in the world of React, creating UI components without dabbling in business logic:

Instead of merely creating components’ reference HTML, CSS, and presentational JS, frontend designers can create directly consumable HTML, CSS, and presentational JS that back-of-the-frontend developers can then breathe life into.

What’s clear is that the term “React” has become as broad and undefined as the term “front-end”. Just saying that someone does React doesn’t actually say much about the nature of the work.

When you say “we’re hiring a React developer”, what exactly do you mean by that? “React developer” is almost as vague as “frontend developer”, so clarify. Are you looking for a person to specialize in markup and styles? A person to author middleware and business logic? A person to manage data and databases? A person to own build processes?

How using component-based design helps us build faster

A case study from Twitter on the benefits of using a design system:

With component-based design, development becomes an act of composition, rather than constantly reinventing the wheel.

I think that could be boiled down to this:

Component-based design favours composition over invention.

I’m not saying that’s good. I’m not saying that’s bad. I’m also not saying it’s neutral.

Intrinsically Responsive CSS Grid with minmax() and min()

When min() gets better support (it’s currently in Safari), we’ll be able to create container queryish declarations like this:

grid-template-columns: repeat(auto-fill, minmax(min(10rem, 100%), 1fr));

Shape Up: Stop Running in Circles and Ship Work that Matters

A short, snappy web book on product development from Ryan Singer at Basecamp.

Like Resilient Web Design, the whole thing is online for free (really free, not “give us your email address” free).

Chaos Design: Before the robots take our jobs, can we please get them to help us do some good work?

This is a great piece! It starts with a look back at some of the great minds of the nineteenth century: Herschel, Darwin, Babbage and Lovelace. Then it brings us, via JCR Licklider, to the present state of the web before looking ahead to what the future might bring.

So what will the life of an interface designer be like in the year 2120? or 2121 even? A nice round 300 years after Babbage first had the idea of calculations being executed by steam.

I think there are some missteps along the way (I certainly don’t think that inline styles—AKA CSS in JS—are necessarily a move forwards) but I love the idea of applying chaos engineering to web design:

Think of every characteristic of an interface you depend on to not ‘fail’ for your design to ‘work.’ Now imagine if these services were randomly ‘failing’ constantly during your design process. How might we design differently? How would our workflows and priorities change?

Bridgy for Webmentions with Brotli—zachleat.com

This is good to know! Because of a bug in Google App Engine, Brid.gy won’t work for sites using Brotli compression on HTML.