I quite like this change of terminology when it comes to making fast websites. After all, performance can sound like a process of addition, whereas efficiency can be a process of subtraction.
The term ‘performance’ brings to mind exotic super-cars suitable only for impractical demonstrations (or ‘performances’). ‘Efficiency’ brings to mind an electric car (or even better, a bicycle), making effective use of limited resources.
A library of UX components is one common part of a design system, but the system itself is something bigger. A good system is also a shared set of strategies for solving visual and interactive communication challenges, a playbook rather than a script.
I like this way of putting it:
The problem is that treating a design system as a pantry full of widgets is, in and of itself, a failure of both craft and imagination. Think of it like a language: if a writer’s only engagement with it is grabbing words from the dictionary and heaping them together until “message” is achieved, things are going to suck. Language is more than a bag of words.
AI becomes a stand-in term for whatever technologies and techniques are new, shiny, and just beyond the grasp of our understanding. We use it to gesture at a future we cannot fully comprehend or currently realise. As soon as we do, it will no longer be “AI.”
Here’s a remarkably in-depth timeline of the web’s finest programming language, from before it existed to today’s thriving ecosystem. And the timeline is repsonsive too—lovely!
You don’t need to write for anyone else. You don’t need to share, or even keep it. You just need the act of it. Writing is a particle collider for reality and the imagination. And new discoveries are the result.
(That’s why I write here, of course. It’s how I think.)
It me.
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.
This piece by Giles is a spot-on description of what I do in my role as content buddy at Clearleft. Especially this bit:
Your editor will explain why things need changing
As a writer, it’s really helpful to understand the why of each edit. It’s easier to re-write if you know precisely what the problem is. And often, it’s less bruising to the ego. It’s not that you’re a bad writer, but just that one particular thing could be expressed more simply, or more clearly, than your first effort.
A new programming language where you pray to Greek gods.
An invocation has three parts: the god’s name and adoration (praising of that god), supplication to show the humbleness of the asker, followed by a request to add one or several of what we ordinarily call “commands” to the program.
Here’s the source code for “99 bottles of beer” in Olympus and here it is transpiled into JavaScript.
My talk, Building, was about the metaphors we use to talk about the work we do on the web. So I’m interested in this analysis of the metaphors used to talk about markup:
- Data is documents, processing data is clerking
- Data is trees, processing data is forestry
- Data is buildings, processing data is construction
- Data is a place, processing data is a journey
- Data is a fluid, processing data is plumbing
- Data is a textile, processing data is weaving
- Data is music, processing data is performing
How a writing system went from being a dream (literally) to a reality, codified in unicode.
An opinionated blog about writing. I’ve subscribed in my feed reader.
I only just found this article about those “mad libs” style forms that I started with Huffduffer.
Whatever the merit of the scientific aspirations originally encompassed by the term “artificial intelligence,” it’s a phrase that now functions in the vernacular primarily to obfuscate, alienate, and glamorize.
Do “cloud” next!
I’m glad that Heydon has answered this question once and for all.
I’m sure that’ll be the end of it now.
This is a great combination of rigorous research and great data visualisation.
A good post by Andy on “the language of business,” which is most cases turns out to be numbers, numbers, numbers.
While it seems reasonable and fair to expect a modicum of self-awareness of why you’re employed and what business value you drive in the the context of the work you do, sometimes the incessant self-flagellation required to justify and explain this to those who hired you may be a clue to a much deeper and more troubling question at the heart of the organisation you work for.
This pairs nicely with the Clearleft podcast episode on measuring design.
As part of my content buddying process, I am henceforth going to typeset all drafts in this font. I just tested it with this sentence:
We can leverage the synergy of a rich immersive user paradigm shift.
A very handy collection of organised notes on all things JavaScript.
The discussions around data policy still feel like they are framing data as oil - as a vast, passive resource that either needs to be exploited or protected. But this data isn’t dead fish from millions of years ago - it’s the thoughts, emotions and behaviours of over a third of the world’s population, the largest record of human thought and activity ever collected. It’s not oil, it’s history. It’s people. It’s us.
This old article from Chris is evergreen. There’s been some recent discussion of calling these words “downplayers”, which I kind of like. Whatever they are, try not to use them in documentation.