What design tools get wrong

The purpose of a screwdriver isn't to make working with screws more accessible, it's to make it possible and convenient. The purpose of power drill isn't to be more accessible than a screwdriver - it's to enable working faster and easier with screws, and to enable working with screws and materials for which using a screwdriver isn't feasible.

This brushes my primary annoyance about modern software - the current trend is to focus on making the basic, entry-level tasks accessible, at the expense of tasks that a proficient user might want to perform. The more advanced tasks are not just made more difficult - they're often made impossible.

> Design libraries are also limited in the type of things they share: just components or symbols. This works great if all your design work is just clicking together new screens with the same components, but anything new will see designers clicking into components and copying over things like colors, font variants and checking spacing just to copy that over into new components. When you copy over things, you’ll invariably make mistakes (we’re just human after all).

Ideally, a component system means you’re black boxing some function.

Unfortunately every component system I’ve ever seen has a hard boundary at some “material” transition:

A UI drawing that can be used inside a design program

A React component is bounded at the DOM and can’t handle server side concerns

A CSS component is bounded at styles and can’t handle HTML concerns

A middleware component that handles authentication, but can't reach outside the routing phase.

etc

Inevitably then, you end up having two or more tightly coupled components:

A front end component + the server API that it knows how to talk to

A little HTML widget + a microservice that it feeds with it’s own persistence

A container for wrapped content + a little middleware meant to be added to the app that serves the content

A button + a delayed job + an email template to get sent when it's done

etc

In order to do this, instead of just having one module with a tight set of concerns inside it, you have to implement some of your concerns in two places, and you also have to map data into the component interface, and then back out again. In some cases this can be 4x the complexity ("code" vs. "code + write to component interface + decode component interface + variant of code on other side of interface").

If the component could span both domains, it could just move the data exactly where it needed to go, as efficiently as possible, since the data is all internal to the component.

The conclusion I’ve come to is something like "components want to be free."

I.e. components want to have concerns that can span the entire stack, and implement procedures in arbitrarily disparate kinds of source locations.

This of course precludes ALL of the component systems which are confined to a specific material domain. It means the boundary of a component has to look something like arbitrary source code. Component interfaces can’t conform to a single template.

That raises the question “what is a component at all?” If the boundary of my component is just a set of function calls, it’s just a module. How is it a component?

And maybe it’s not. Maybe components are a local maximum in code cleanup, and I’m advocating people move past them and just write really excellent single-concern modules instead.

I don’t know. This is as far as I’ve thought it through.

(I do maintain an NPM module called browser-bridge that lets me build arbitrary client/server components, along an event sourcing library called a-wild-universe-appeared for doing persistence in an isomorohic way, and then something called bridge-module for getting dependencies in the browser... All of which let me experiment with what I'm describing, but those are all in a pre-1.0 mostly beta state. The basic interfaces are all stable though.)

So modern tools like sketch work for grids, mobile responsive, yada yada which is much better than using photoshop as the design sits closer to the canvas it will be rendered on. As a developer, yay that works great for me! And also it's a huge middle finger to those designers who just built stupid impossible pointless UIs in the 90s and 2000s.

But it's also very constraining for the designer, especially given how far standards have come, and it's almost a given that someone is going to come along and Bauhaus the shit out of UI.

I really enjoyed the challenge of implementing a truly creative design on the web, but there has been a general convergence towards a convenient middle point where the designs are constrained by development requirements, at least in the way the tools are geared.

That's not to say a great artist can't create something amazing but if we have to teach all our creatives that they must conform to this particular way of thinking, then we're cutting the industry short in a bad way I think.

I guess the next thing will be a sass or js library called bauhaus.js. Or is that just DOM + CSS?

The tool isn't the screwdriver alone, it's the screwdriver and the screw, which allow for easier fastening than, say, advanced woodworking joinery. A powered screwdriver also allows non-trained people to get closer to the productivity of a trained professional.

What are some examples of that annoyance in modern software?

Uh huh. And how many years did it take to actually get Flexbox and CSS Grid? I mean...They're both still "Candidate Recommendations" in 2019. That's not even the penultimate level of recommendation. You definitely can't use Grid if you want broad compatibility; it was only first implemented in 2017. "People should update their software to the latest versions! And they should switch browsers to use one that supports my nonstandard features!" Oh, yes? Well they don't. And let's not even talk about Grid Level 2 which is implemented nowhere. We've gone through generations of faking markup with javascript because the dogma behind CSS has always been a terrible mess. "No tables for layout!" Ok, what else are you supposed to use to arrange things in grids? "Uhhh....give us a couple decades to get back to you on that."

When people say that CSS is terrible, they mean the actual standard parts, and they mean for the past 22 years.