Link tags: tool

251

sparkline

Data Design Language

I like this approach to offering a design system. It seems less prescriptive than many:

Designed not as a rule set, but rather a toolbox, the Data Design Language includes a chart library, design guidelines, colour and typographic style specifications with usability guidance for internationalization (i18n) and accessibility (a11y), all reflecting our data design principles.

Folk Interfaces

Folk creations fill a gap. They solve problems for individuals and small communities in a way that that centralised, top-down, industrial creations never can. They are informal, distributed practices that emerge from real world contexts. Contexts where individuals have little or no control over the “official” means of production – of furniture, urban architecture, crockery, artwork, media stories, or taxonomies. In response people develop their own unpolished, unofficial, and deeply practical creations.

Now apply that to software:

Only professional programmers and designers get to decide what buttons go on the interface, what features get prioritised, and what affordances users have access to. Subverting that dynamic is the only way people can get their needs met with the computational tools they have at hand.

Utopian project kickstarter — Figma

Do you like the ideas behind Utopia? Do you use Figma?

If the answer to both those questions is “yes”, then James has made a very handy Figma community file for you:

This work-in-progress is intended as a starting point for designers to start exploring the Utopia approach, thinking about type and space in fluid scales rather than device-based breakpoints.

Reflections on Design Systems and Boundaries - Jim Nielsen’s Blog

Jim shares his thoughts on my recent post about declarative design systems. He picks up on the way I described a declarative design systems as “a predefined set of boundary conditions that can be used to generate components”:

I like this definition of a design system: a set of boundaries. It’s about saying “don’t go there” rather than “you can only go here”. This embraces the idea of constraints as the mother of invention: it opens the door to creativity while keeping things bounded.

The Case for Design Engineers - Jim Nielsen’s Blog

This is really interesting. I hadn’t thought too much about the connection between design engineering and declarative design before now, but Jim’s post makes the overlap very clear indeed.

Min-Max-Value Interpolation

Here’s a really nice little tool inspired by Utopia for generating one-off clamp() values for fluid type or spacing.

Changing with the times · Chris Burnell

I think, with the sheer volume of functionality available to us nowadays on the front-end, it can be easy to forget how powerful and strong the functionality is that we get right off shelf with HTML. Yes, you read that right, functionality.

Contextual Spacing For Intrinsic Web Design | Modern CSS Solutions

To complement her talk at Beyond Tellerrand, Stephanie goes through some of the powerful CSS features that enable intrinsic web design. These are all great tools for the declarative design approach I was talking about:

Progressively Enhanced Builds - Jim Nielsen’s Blog

Rather than thinking, “how do I combine a bunch of disparate content, templates, and tooling into a functioning website?”, you might think “how do I start at a functioning website with content and then use templates and build tooling to enhance it?”

I think Jim is onto something here. The more dependencies you have in your build process, the likelier it is that over time one of them will become a single point of failure. A progressive enhancement approach to build tools means you’d still be able to launch your site (even if it’s not in its ideal state).

I want to be able to view, edit, and if need be ship a website, even if the build process fails. In essence, if the build does fail I can still take all the source files, put them on a server, and the website remains functional (however crude).

Be the browser’s mentor, not its micromanager. - Build Excellent Websites

This one-page site that Andy has made to illustrate his talk at All Day Hey is exactly what I was talking about with declarative design.

Give the browser some solid rules and hints, then let it make the right decisions for the people that visit it, based on their device, connection quality and capabilities. This is how they will get a genuinely great user experience, rather than a fragmented, broken one.

Design Systems Aren’t Cheap

Just like jQuery dominated the front end yesterday, React dominates it today. There will be something new that dominates it tomorrow. Your design system team will continue doing the same work and incurring more and more costs to keep up with framework churn. And let’s not forget the cost of updating tomorrow’s legacy apps, who are consumers of your soon to be legacy design system.

Inertia - CSS-Tricks

Here’s a thoughtful response from Chris to my post about Svelte, Astro, and React.

Web tech is better. Developer norms are worse. | Go Make Things

The web historically moves in waves.

Libraries are created to push complex features in an easier way. Then the libraries themselves get complicated, often more so than the benefits they provide.

Eventually, (some of) the core features of those libraries make their way into the browser itself, but the libraries linger like water on the shore, slowly receding.

And before the sand has a chance to fully dry, a new set of libraries washes in to push the web even further.

Modern CSS in a Nutshell - Cloud Four

I like this high-level view of the state of CSS today. There are two main takeaways:

  1. Custom properties, flexbox, and grid are game-changers.
  2. Pre- and post-processers are becoming less and less necessary.

This is exactly the direction we should be going in! More and more power from the native web technologies (while still remaining learnable), with less and less reliance on tooling. For CSS, the tools have been like polyfills that we can now start to remove.

Alas, while the same should be true of JavaScript (there’s so much you can do in native JavaScript now), people seem to have tied their entire identities to the tooling they use.

They could learn a thing or two from the trajectory of CSS: treat your frameworks as cattle, not pets.

htmx - high power tools for html

I really like the progressive enhancement approach that this little library uses—it’s basically the Hijax approach I was talking about back in the days of Bulletproof Ajax but all wrapped up into a neat package that you can use entirely via HTML attributes.

Can I include a tag to a tag? Based on HTML Spec WHATWG

A neat little tool when you need a reminder about what elements can go in other elements.

My Challenge to the Web Performance Community — Philip Walton

I’ve noticed a trend in recent years—a trend that I’ve admittedly been part of myself—where performance-minded developers will rebuild a site and then post a screenshot of their Lighthouse score on social media to show off how fast it is.

Mea culpa! I should post my CrUX reports too.

But I’m going to respectfully decline Phil’s advice to use any of the RUM analytics providers he recommends that require me to put another script element on my site. One third-party script is one third-party script too many.

Tiny Helpers

A very comprehensive collection of standalone little tools for web design and development—tools that do one thing.

🧠 ct.css – Let’s take a look inside your `head`

I love a good bookmarklet, and Harry has made a very good bookmarklet indeed.

Drag ct.css to your browser bar and then press it whenever you’re on a site you want to check for optimising what’s in the head element.

New principle: Do not design around third-party tools unless it actually breaks the Web · Issue #335 · w3ctag/design-principles

There’s a really interesting discussion here, kicked off by Lea, about balancing long-term standards with short-term pragmatism. Specifically, it’s about naming things.

Naming things is hard. Naming things in standards, doubly so.