From walled gardens to open fields: Why we need open standards in design

Nathan Curtis: So let's get to our next talk.

I'd like to introduce Kaelig.

He is previously at, I believe, The Guardian, but at Salesforce Lightning is when I met him.

And he was doing great work on tools like Theo.

And he worked at Shopify, Polaris, also on their DevTools.

He's the co chair and, driver of many conversations around the Design Tokens community group.

He's really injected a lot of his, considered thinking to lead that team, to help us all norm on how tokens work in our community, and I'm indebted to him for that.

and today he's the Principal Software Engineer at Netlify.

So please help me welcome Kaelig, who's going to talk about From Walled Gardens to Open Fields, Why Open Standards Matter in Design.

Kaelig Deloumeau-Prigent: Okay, cool.

Hello, Clarity.

Before you choose what you're going to eat for lunch, let's talk about standards.

But first, let me introduce you to, two people who inspired me to pursue the career I'm in today, as a builder and an architect.

This is François, or Papy Prigent, as I call him.

My grandfather on my mother's side.

Where I spent, he built the countryside home where I spent most of my spring breaks and, summer breaks.

And I didn't think much of it at the time, but he built that house with his hands and, of course, some tools, but that was quite the feat.

Let me introduce you to Roger.

This is Papi de Lumo, as I call him.

he's my grandfather on my mother's, on my dad's side.

He was a surveyor at an architecture firm, and because it was a small firm, he dabbled quite a bit in architecture plans himself.

And on the side, he designed and built wood furniture, so our entire family has furniture from him.

Today they're both in their late 80s, and they've put down their pencils and their tools, but their passion lives on through the new generations.

We're a big family.

The way they design and build was bound by a set of requirements, a set of standards.

France has a centralized specification consortium, and they define what construction drawings, buildings, spaces, building elements, and components should look like.

a bit of context.

Standardization in France really began during the French Revolution.

The variety of measures and weights was enormous, resulting in considerable confusion.

And this is how we now have the metric system.

I love this guy in the middle over there.

Look at him, completely confused.

This is me when I'm trying to convert inches to centimeters since I moved to the U.

S.

Fast forward to the 20th century.

I stumbled upon this book.

The French Standard System, as it works today, is well accepted.

Hardly anybody questions its structure or advocates any change.

If French people, we have a tendency to challenge authority.

So for a standard to be accepted, it needs to carry weight and bring value.

Standardization is considered a public service, and this often results in very close cooperation amongst industry, users, consumers, government, and other institutions.

This is what brings legitimacy to these standards.

And that ensures adoption.

So let's talk about the value that these standards are meant to bring.

Again, from this same report from the US Department of Commerce in 1980, standardization in France is viewed as a tool for implementing national policies such as increasing the competitiveness of French products in international markets.

But, and without getting too deep into the details, what this means is that, France can set the bar for environmental footprint, safety, quality, inclusivity of products coming from other countries and being built inside of France, too.

And our, French Minister of Digital Transition and Telecommunications recently said, we can So we're really looking towards the future now, we're not in 1980 anymore.

We cannot have metaverse platforms that will be inaccessible to users who do not have the right equipment.

So for newer technologies, the number one issue is interop, interoperability.

I will refer to it as interop because it's a very long word that is a tongue twister for a French speaker.

Very recently, we started a metaverse standardization process.

There's a commission that was created to bring the ecosystem together and ensure that we have interop leading to open, safe, inclusive experiences in accordance with European and French values.

Another huge challenge is competitiveness and creating a level playing field as illustrated by this quote.

tomorrow's voluntary standards must be written today, otherwise others will write them for you and these competitors will become the market leaders.

We are builders, we are architects, just like my grandfathers and just like me today.

And just like them, a lot of what we build is predicated on the existence of standards.

Thanks to millennia of discoveries and inventions and we use them, we use those standards every day without even realizing it.

And they're still standing.

Let's look at a very simple piece of code.

This is SVG.

It represents a red circle with a black background.

It's based on the SVG open standard, which itself is based on the XML standard.

Both are free to use for everyone, and today, this file is readable everywhere.

Both are free to use for everyone, like I said, and from operating systems to browsers, to probably your fridge that has a smart screen on it.

And, of course, design tools.

Not only can you view it now, but you have a guarantee that you can open it in a program of your choice and edit it in the future.

What this gives you is freedom and control.

Now the web design community has not always walked the path of standards.

Some of us choose to design and develop in closed environments.

When we do, we depend on proprietary software.

let's talk about that.

Not so long ago, in an era of complete world domination for Adobe, in both web and graphic design, they acquired a company called Macromedia.

And nothing could stop them.

Oh, wait.

Rest in peace, Flash.

The industry moved away from Flash, a platform riddled with security holes, accessibility challenges, and performance issues.

They built a nice walled garden for themselves, and that didn't really work out the way they thought it would.

So you had to use Adobe's tooling to build Flash animations and games and applications.

To open those you depended on their runtime and as a single actor controlling the entire end to end platform They were starting to act in their own interest Today we're fortunate to live in a time where we enjoy freedom and access to the best design tooling we've ever had To give credit where credit is due.

I'm thinking of two particular players who contributed in that golden era.

First, Sketch, who helped us move away from Photoshop.

And Figma, who has brought us into this age of collaboration.

The most observing one of you will note that, Figma is built on some of the pillars we talked about earlier.

Maybe not USB, but, laughs So, it works, it runs in a browser, so it runs everywhere from your Mac, PC, Chromebooks, and again, smart fridges, I don't know why I keep thinking about those.

While it's incredible to have such power at our fingertips, I want to outline that Figma has essentially saturated the market by now, and when one platform becomes so dominant It naturally brings up the question about competition, innovation, and what that means for the future of an industry.

Thankfully, at least for the moment, Figma is very far from being a walled garden.

It has a strong community, a vibrant plug in store, it is based on standards, it has open APIs.

they use TypeScript, for example, for their plug in system, so that is something to be noted.

And of course, they're not the only game in town.

They still have some competition.

I want to mention emerging platforms like PenPot, that is fully open source and completely embracing web standards.

So let's talk about the future.

I'd like to ask you, what if we can have a composable product authoring experience that fits your exact needs and feels like a unified whole?

What if you could navigate between levels of abstraction at any point during your product development life cycle?

Between development, coding, engineering, design, sketching, prototyping?

My friend Devin Huang, a luminary in the field of design systems and development tooling, no code, low code, full code, he's done it all.

He believes the future is going from, of going from idea to production is going to be one thing, rather than an entirely separate design experience on one side and a development experience on the other side.

I'm not talking about a single tool here.

He's really referring to multiple tools weaved together, thanks to Interop.

And I think he's right.

I'd go as far as saying that we need that more than ever in the age of AI.

And today when I try to move my work between multiple prototyping tools, design tools, coding tools, user metric tools, It feels a bit like the Tower of Babel, where instead of making the work happen, I'm spending a lot of time translating.

And it feels like those people in France in the 1700s, uh, before we got a standardized U.

S.

metric, metric system.

Not in the U.

S., sorry.

In my past talks, I've referred a lot to building bridges between design and development, to help people and tools speak the same language.

But as AI is growing, I'm starting to think a lot bigger and starting to think of bridges that would be totally impossible to build with the kind of primitive tooling that we've had so far.

And so you can see in this beautiful image generated by DALLE.

A lot of this doesn't make conceptual sense, but that's what I'm trying to dream about.

I want to ask you, do we own the tools we use, or do the tools own us?

the good news is, we as a community have the power to define the open standards that unlock Interop.

And to ensure that the companies building the tools we keep building, let me, okay, for the recording.

we, as a community, have the power to define the open standards that unlock Interop.

And we can ensure that companies building the tools we use keep building them in our interest.

And so that's what we've been working on at, Design tokens W3C Community Group.

That's a mouthful.

, we're writing a specification in partnership with the entire ecosystem.

a bit reminiscent of that, standardization group in France.

I, and what we strive for is that we want us to all be able to encode design decisions in a way that can be shared across all of our tools.

And therefore, all the folks working to build products.

This is the URL.

Consider, going to this URL.

So it's tr.designtokens.org/format.

this is where we host the draft of the specification.

people involved include all the companies I just, I just mentioned and more.

So let's wrap up.

And then you can go for lunch, after a couple of questions with, with Nathan.

From measurements and weights to file formats and protocols, open standards and lock capabilities, and elevate the quality of what we build as builders and architects.

Second, we have amazing tools.

I love seeing so much innovation in this space.

Especially with the rise of AI recently, we see so many cool projects.

what an age do we live in?

That said, we also know the risks of over reliance on a single tool.

And this abundance and the freedom to move across them is far from being guaranteed forever.

And third, it is our duty to uphold all our design tools and all the design tool makers.

And to supporting standards, because this is where our freedom lies as practitioners.

So we can tear down the walls between our disciplines and build these impossible bridges.

So what we've learned today is, interop doesn't just happen by itself.

We all know how hard it is to create specifications and standards, to seek their adoption, and to iterate on them.

And we know that some bad things happen when a single actor and a major leader builds proprietary solutions that suit their own agenda.

I believe that thanks to open standards, interop, we have the freedom to vote with our feet when a design tool doesn't act in our best interest, or their values don't align with our own.

what I ask you today is to challenge our tools, to build Interop at the core of their products, and say no to walled gardens, yes to open fields.

Thank you very much.

Nathan Curtis: Thanks for your talk, Kaelig.

Hello.

Hello.

there's some pretty heavy stuff in there, but I want to start where you started, which is sort of family and a reflection on yourself.

What drew you to standards?

Like, when did you start to see that about yourself?

And why did you find yourself going into this place?

Kaelig Deloumeau-Prigent: the way I learned, the job I'm in today is through open standards and the openness of the internet and the first vision that the web stemmed out of.

And I was drawn to that.

It feels like an undepletable source of knowledge, and I tend to be very curious and to fall into rabbit holes pretty frequently.

And this one I couldn't get out of.

Nathan Curtis: That's great.

Partway through your talk you talked about principles of open, safe, and inclusive.

I wonder if I could challenge you, are those principles that you would order, is one more important than the other if they came into conflict?

Open, safe, and inclusive.

Kaelig Deloumeau-Prigent: you can't have the two, you can't have safe and inclusive if you don't have open.

that's what, we see with a lot of, standards out there.

and I'm blanking on giving like super strong examples right now, but that's, I would put open in the first, place.

yeah.

Nathan Curtis: if you have something that's closed, it's by its nature unsafe or exclusive?

Kaelig Deloumeau-Prigent: all of a sudden, it's very hard to challenge it, and to, to give feedback, and to participate in that, the consensus based approach to a lot of open standards.

That said, some open standards are driven by a single company.

There is a, bit of a, spectrum of openness on standards, and each country, and even its jurisdiction, sometimes has a different definition.

as I was researching this, I thought, I found that the U.

S.

and South Africa, for example, have totally different ways of describing what an open standard is.

And I would lean more towards the South African way of, saying things, which is check a, checks a lot of boxes on openness, open source, free or very low, barrier to entry, those kind of things.

Nathan Curtis: How can we as practitioners really predict or see what might become tomorrow unsafe or closed or exclusive?

what are we, what should we look out for?

What are signals?

Kaelig Deloumeau-Prigent: some signals include, in, in a monopolistic, vision of the future, you end up being at risk of the incentives for that company to be misaligned with the ones of its community.

so we've seen that with companies like Unity recently, and that's a good sign, is that the way they, they changed their pricing model, is that they wanted to charge game developers using their framework at the installation level.

So every time somebody would install your game, you'd have to pay Unity some money.

So imagine if an actor in our field said, Every time you deploy a website, you have to pay us.

Every time you ship pixels somewhere.

You gotta pay us a cent somewhere, or whatever.

I feel like that's pretty predatory.

And so that's one of the signs.

Another one is a refusal of discussing standards with the rest of the community, which we haven't seen right now.

there's very few players who are saying no or staying away from the Design Tokens community group.

very happy to see that.

Nathan Curtis: That's great.

You described a fusion of roles into a single role.

By your colleague that you were talking about with no code and so on.

and if that was to occur, like these roles of engineer and designer were to fuse into a single role that is, enabled through a tool woven environment, how would that change how people like us here should view ourselves and our future?

Kaelig Deloumeau-Prigent: yeah, I think technical literacy is going to be, a big one, but also design literacy and being able to describe problems in a very fluid way and to break it down so that something like an AI can really help you ship the best experiences.

So I would say there's still going to be code and design.

I'm not suggesting that we're never going to, or that we're going to end up in a world that doesn't exist.

I would say that it's going to be easier to have an idea and to put it in front of people and the barriers of entry are lowering little by little.

And so if you want to be that kind of person and not be boxed in one of the two roles, either engineer or designer, getting a bit of a sense of how to do that is going to be important.

Nathan Curtis: admitting my bias, towards Figma, like I'm a plugin developer that has a paid upgrade and I love the ecosystem and I endorse it and all my clients to use it because it's so powerful and engaging.

I love the product, but there's a dark cloud that I see or I sensed in what you're talking about and what should we fear could happen with Figma?

Kaelig Deloumeau-Prigent: Yeah, I didn't want to center it too much on Figma because, I love what they do, I have good friends who work there and I'm not opposing at all what their current strategy is, but yeah, for the, potential looming dark clouds, what you can do as a plugin developer is be, careful of what they're, what they're pricing and, their revenue share strategy starts looking and also a lot of platforms end up adopting features that plugin developers have built, or like app developers, that gets built into the operating system, those kind of things.

And so I don't know if the community wants to, if you have an appetite for putting patents out for what you're building either, to protect yourself against bigger platforms.

So it's a, it's like you.

Yeah, I don't know.

Nathan Curtis: It's a tough question.

I think that we all need to be at least thinking about it, our relationship with tools as they continue to evolve.

And my last question is more around the token working group and something I actually selfishly want more.

your group has done a great job in helping us norm on how to describe visual attributes and how to interop them across all the tools that we have.

Is that just a precursor to the bigger thing I want to see, which is, how about for components?

Are components too complicated?

Or is there a way to describe the rich, tapestry of all the things that go into making a component?

And, should we bother if AI is going to do it anyway?

Kaelig Deloumeau-Prigent: the way I look at it is, yes, it is the next step.

Not necessarily for the Design Tokens Community Group, but for, probably Open UI and a few adjacent groups.

but structured data is an awesome way for AI to be, doing good stuff quickly, because you want to train your AI on, give it kind of guardrails.

And having that structured data and, ways to describe your entire design system in that, format is gonna help you leverage AI much, much better.

is AI gonna decide what that structured data looks like.

I wonder, maybe, AI is going to write the standards of tomorrow.

who knows?

But, yeah, that's my view on it.

I think it is the next step for sure.

Nathan Curtis: Thank you so much.

Let's give a hand to Kaelig.