All right, hello, everybody, and welcome to another day of Faustem.
We're going to get started here with our next talk.
We have Pablo from Spain, the founder of Penn Bot, talking about open source design,
the wake-up call for developers.
So thank you.
Let's have a warm welcome, we're going to have a place.
All right, hello, everyone.
Welcome to my amazing talk on this very great main track.
So yes, this is the talk for today, open source design,
the wake-up call for developers.
Who here is, by the way, a developer.
No surprise.
So yeah, I'm Pablo with Muthgith.
I'm Ciong of Honor of Penn Bot.
And this is my 18th Faustem.
First one was 2006.
And I think when you, so it's not 18th in a row,
like I had to miss a couple.
But when you keep attending Faustem for 18 editions,
I think there are two things that
the two perspectives that you are entitled to share.
One is climate crisis.
There is a change in Brussels.
We can feel it.
For those of you that we're here, like in 2012,
or even in 2008, there is a sad shift.
I miss the harsh winter of Brussels.
If you can say something like that, I can say that.
But the second perspective is that some things have
not changed in how we build open source.
And one of those things is how we treat design
in open source, how we treat the user experience.
So up to 18 editions, I think I can contribute to that conversation.
And I'm going to try to convince you about these three ideas.
One that we have been dispossessed of good user experience,
of good design in open source.
It's face it.
We're not famous.
Open source is not famous for having the best design in Absofa.
Then I will try to convince you about how important is to rethink
or think for the first time what is a design contribution.
We know what a code contribution is, but what is actually
a design contribution, and why solving that matters.
And then finally, of course, I'm going to deliver this key point
about that, for me, open source has to have both open source code
and open source design.
It is when you have both that you can really
be proud of speaking about open source.
So let's start with the first one.
This process, we've been dispossessed in a way it's our fault.
I think when you come from a scientific and technological background,
you might think that from small principles, everything
important will eventually emerge, including the interaction
with the user.
And so I'm here to tell you that good user experience doesn't
emerge just because we have a collection of specifications
and requirements as a solid foundation.
It is something that you have to consider from a more cognitive level
and then go down.
So as long as we think that we can solve design
with this spec-driven approach, we won't really
have true user experience or really meaningful user experience.
And you can think of how we've
treated technology programming languages, different tools
to solve different problems.
We know how to respect the right approach to the problem.
Design is no different.
Now, also, I have this feeling that we have done
play the value of design.
And I think in some ways, we can consider this a natural consequence
of the fact that open source started with developers, not with designers.
And so statistically, you're going to find open source developers,
not open source designers.
And so developers are not required to understand design and many other
things.
But the fact that you don't understand something, sometimes
leads you to think that is not that relevant.
At least if you are in this privileged position where you're
a developer, you have a lot of important things
to consider already.
So I think that is sad.
But I can understand what that happened.
And also, let's face it.
If you don't have good open source tools to solve some problem,
you might want to avoid that problem.
Because you might not be feeling comfortable using
proprietary tools to solve something that even if you feel
it's important, you consider it to be problematic
to use proprietary design tools.
Next, this second idea I want to discuss with you today
is why design contributions is something
that we have to really consider.
For some people, we were like enjoying internet in the late 90s.
We saw the emergence of our coal contributions,
a fashion control system, and decentralized
was a fashion control system.
Because suddenly, it was not just a license attached to a software
that you could just give away with some physical device,
like a CD or something like that.
You actually, if you wanted to have contributions in open source,
you need to understand that the whole internet at the time
a tiny, tiny portion of what is today, of course,
should be able to contribute.
So we created ways to understand what I call contribution
is and how to make that scalable.
And one thing that code has that is amazing when you contribute
is that the fact that it's so easy to undo and massive commit
actually allows you to be bolder.
Sometimes the fact that you can do something, you can go wrong,
allows you to never go wrong because you're bold
and you're right being bold.
But that's safety net, that's from the mental safety net
allows for a lot of developers to actually do crazy stuff,
just because it is cheap.
There's no waste in the undo.
Now, in this eye contribution, what should that look like?
How can we make design be bold?
How that makes sense in that rule and workflow
of our contributions?
Because, of course, we want designers to be bold.
We want designs to be as bold as we developers are.
And then if we're going to solve the problem
of what is a proper design contribution,
of course, recognition matters.
Recognition has always been at the heart
and the core of why we do open source.
Not necessarily as an egotistical obsession.
But the fact that you can point to something
and say, I did that.
It has my name or my nickname or whatever.
There's a license choice.
How do you do that with design?
How can a design, a particular, actually,
go and say, that is my contribution there?
And it's obvious for everyone, that is a design contribution.
So these are questions I have for all of us here.
I'm not going to give you answers.
But this is to start the conversation.
And then finally, this is a core idea
that I want to share with you today, of course,
is that open source has to have both code and design.
Otherwise, it's limited.
It's fundamental to limited.
You can do open source code and then use
probably target design tools.
But that means that your conversation with the user
is mediated.
It's sponsored by a proprietary tool.
Your design, data is not yours.
Your design decisions are not yours.
You have basically outsourced the design agency
in your project.
And you can say, OK, well, I won't use any design tools.
I just use code.
But then, of course, you are working with a huge handicap.
It's like, I don't know, if you are coding
and you're using a lever off is right.
It is a text set.
But that's not the tool that you would use to code, right?
So tools matter.
Well, this is PEMPOT.
Of course, we have obsessed about all this.
This is an open source UI design tool.
It's a, we think it's beautiful.
I don't know what you think.
I think it's really nice, good UX, good UI.
Here, you're seeing the user's method for more or less.
If it's more capital, it's a bit broken on purpose, where
you have some information to the left, design
tokens in that case, and then design components,
and some designs.
And then to the right, you have code.
In this case, that would be CSS.
This is talk is not about PEMPOT, but this
is a way for us to express how we see design and code
working alongside.
Here, after all, and if anyone is interested in understanding
why we had to build PEMPOT, is because we
wanted a developer tool that was actually a design tool.
So it's kind of a hybrid approach.
And this had to be built by open source developers
and open source designers.
Otherwise, PEMPOT wouldn't have existed in the first place.
So am I saying that developers should learn how to design?
Because let's face it.
There's a lot of conversations online saying that designers
should learn how to code.
Lots of tutorials.
And of course, no, I'm saying that.
I don't think we have to continue to build this solo
perinerative that can do everything.
I can monetize things that are not in their skill set,
but they kind of have to know who other stuff
beyond their core knowledge.
I think we should have specialized people in different areas.
Also, there is this question, perhaps what we can do
as developers is just use a lens as a way
to design for ourselves, build you eyes.
You can, in a way, you can brute force your way
with a little lens.
You can do that.
But there's nothing really different from glorify templates
and UI kits.
There's not design with a capital D.
And LMS are very good at understanding code,
but design has a very cognitive and visual
and neo-cortex approach that not necessarily code,
the written code can express.
Anyone here interested in philosophy of language
will understand that you think and you speak,
but that not exactly the same artifact.
So you can think of when you think that's design
and when you write or speak, that is code.
And so there are different renditions of an external element, right?
So no.
And then should we break hard property design tools
in our teams?
Should we have this active assistant?
OK, I mean the team, I know they're using these
so the property design tool should I actually say,
I'm not going to work until you change that property design tool
and use whatever all the tools that have to be a pamper.
And of course, no, I'm not, I'm sadly no, no.
Because then you are a jerk if you do that.
I mean it's a sense that you have to have some empathy
for your peers.
They are used to some tools.
But so no ball cutting.
You can constructively criticize what they're using
and perhaps office alternatives.
Better, I'm not suggesting that we go a boycott mode.
So this is what we can do.
This is my constructive proposition.
But first, let me drink a bit of water here.
OK.
Anyway, who here was in 2012?
This blizzard.
Do you remember the blizzard?
I was, yeah, Jela.
Wow.
But that was the first person for someone.
They would probably say, what is this?
Then, you know, amazing.
My nose, I don't know, 10.
So this is what we can do.
Treat design and design practitioners are through our lives.
I think we all remember the drama
between back in and front and 16 years ago.
Front in is not that serious development stuff.
Things like that.
Fortunately, we are past that stage.
Similarly, I think we have to understand designers
and design practitioners as through our lives.
And that actually means that we have to give them agency.
We need to have them as co-founders of open source projects.
We don't have to treat designers as the people
that we ask for stuff like, this is what I need.
No, they should be proposing or discussing the problem.
You don't give them the question and then they reply.
You actually allow them to ask the questions and perhaps come up
with their own solutions.
So that's giving away a lot of power, you know,
open source.
That's giving away a lot of privilege, you know, open source.
But I think if we don't do that,
then there will be kind of an outsourced,
I don't know, a logo creation, you know,
the population, right?
So of course, this is not about asking a better logo.
Or can you fix my design, but actually having them really
on board from the very beginning of that is possible?
And then how that means in terms of how the design
can contribute to your project that means in terms of road
map, strategy, design contributions, et cetera.
Just rethink it, don't have that as an afterthought.
A good example of this is Blender.
Anyone here knows Blender?
I hope a lot of people know, yeah.
So Blender uses Pempo to design Blender, the Blender UI.
Anyone loves here, the Blender UI?
Yeah, it's an acquired taste, I guess.
But what they do is they use Pempo to redesign the UI
in Blender, it gets updated more often than in the past.
This is very cool because they share the stream,
the live stream, how they are rethinking the design
or the Blender UI.
In this case, they're using design tokens.
And it's very fun.
If you see the low fidelity there, checked that's a token set,
but if they had activated the other one,
then there would be values over it
and for border radius color opacity.
And it would look high-res, final, polished result.
It's amazing what you can do with design tokens.
This looks like low-res for having a conversation
of wife framing.
And then if you activate the other set,
it just is a final product.
This is very interesting because the conversation
you have are simpler depending on what are you discussing.
You don't want to have excessive level of detail,
because it is distracting.
So this is a good example of a good alliance
between code and design in the Blender project.
Next, I suggest that you explore the limitless space
between design and code.
That's a wonderful place to be, by the way.
And here are some tips design systems,
are a great hybrid framework.
Design systems are something that designers
borrowed in a way from engineering,
also from other design arts like architecture,
where you actually define smallest elements
like about the radius, up to components, dialogues,
and even bigger design artefacts.
This is good because it gives you a structure,
but also there are intentional and they're reusable.
And you can export in as libraries
that you can be consumed for the people, not only yourself.
Now, not all design tools are created equal.
When you go to manage huge design systems,
there are tools that were born 10 years ago, 15 years ago,
and they haven't been able to understand,
fully understand what design system is,
and they can give you a design system oriented design tool.
And one of the things that actually
makes some design tools better than others
for this limitless space between design and code
is whether they are favoring imperative design paradigms
or declarative and semantic design paradigms.
So very quickly, the imperative design paradigms
is about controlling exactly how everything works.
Where's the declarative design paradigms is a rules-based.
And that means that I only care about the goal,
but not exactly how to get to the goal.
We all experience the creative design or language
when we go into the street because the road signs
are actually declarative.
When you see a stop sign, it is very clear what the intention is.
Like you have to have speed equals zero when you get to this stop
sign, but doesn't say anything about how you should get
to that speed equals zero or on what vehicle
you should be traversing the street.
CSS is a declarative design language.
And so for layouts like Flexbox and Grid CSS,
that is a very obvious way to express the declarative designs
about the rules.
But no exactly obsessed about how you do that.
That doesn't mean that you can only do the declarative design
if you do web, not at all.
But we can borrow concept from CSS.
And semantic is about the taxonomies.
You saw before the design tokens,
that's draft standard for W3C.
I recommend that you look into that.
That is a way to express the passivity type of
reference for dimensions, everything,
in a way that you can combine them because you can reference
one token to other.
Like I bought their ways could be three times the opacity.
And then you can change the passivity
and have multiple opacity values with the same name.
And you basically override those values depending on the set
you have activated.
And that gives design systems a lot of an expressivity.
And finally, please, please.
Do consider something beyond design to code.
And this would be more important for a designer audience
that you start designing and then you get to a code.
You design and you code.
That is very old-fashioned.
But we can go from code to design these days,
design to code, design to design using an open source
design tool.
A good example of design systems is the KDE.
KDE, anyone?
No, it's KDE.
So KDE uses this to build their design system.
It's called Ocean.
And later today, in the open source design track,
and the embeds is going to describe,
he's going to discuss how they're building their massive design
system and KDE using panel.
So good example there.
And finally, she prioritizes the non-tangual users.
Yeah, I was leaving, rather, the most controversial,
or not, there's hardly the most controversial.
But the most commented topic in open sources
what about non-tangual users, what about software
that is not intended just for ourselves, as developers might.
And I think this is just my way to encourage you
to think outside our own bias.
Of course, it's very comforting to be building something
for ourselves.
But I think it's also very exciting to be able to go outside
our own cognitive bias and think of tools and software
of apps that are not necessarily for ourselves
by for other people that we actually don't.
We care about them, but we don't really know them.
And this is a very neat way to have positive impact
through technology that is explicit.
That reaches out the global audience.
We have all been confronted with people saying,
but OK, I love open source, but can you tell me
a great open source product that I am using?
So I open my eyes.
And normally, you would say, well, in Firefox,
we'll see, do you know, Blender?
I very quickly, you start going to the very technical.
And I think we need to own the whole software stack
in the world.
I will need to own everything, and that includes
silly apps that do nice to have things.
So that will make better software for everyone.
This is a great example.
This is Tenzu.
This is an open source project management tool.
You don't need to be technical to use.
You're also using them to design, see,
very kind of accessible interface,
to be able to use a very powerful one
when you actually use it the right way.
So you can do agile, agile project management,
using open source.
That's Tenzu.
But then, finally, I want to express that fundamentally.
You have to, I'm sorry, but you have to be aware.
And we are very heavily aware.
Strongly, we're here in this room.
I know we are aware of so many things.
So many things are actually, for me, it's
kind of depressing.
I'm aware so many things that are going wrong
that I feel like I just want to go and hide myself
in some dark corner or whatever.
But this is one of the ones I would suggest
that you prioritize.
It's being aware that we keep avoiding good design
and open source design.
This is a precious territory that we are giving away.
And this is the cognitive level.
This is the conversation with the user that we're giving away.
And if people are saying, look, I do developer tools.
I do database, I do frameworks.
That's fine.
Your user is a developer.
But let's do more than just your user is your developer.
Just look at that and when you do that,
if you don't have a great user experience,
unfortunately, it is a differentiator.
People are going to shy away your open source product
because they cannot use it, they cannot enjoy it.
So they introduced me as a public, I'm from Spain.
So anyone here from any Mediterranean country?
OK.
So we have olive oil in Spain, really good olive oil in Spain.
We say that we have a water and olive oil in our houses.
You can just open the tap.
And olive oil is a crucial element in our cuisine,
in our gastronomy.
Good olive oil, basically, is the fabric of dishes.
This is relevant for me because open source was thought to me.
I started open source in 1997.
And I, of course, I had to read the recipe metaphor.
Like recipes you read it, you can fork it, you can contribute,
all that.
And I think a lot of open source is olive oil.
It just makes the dish feel amazing.
It contributes greatly to the experience,
but has one issue.
It is invisible in many ways.
If you know, olive oil isn't in the dish,
you can appreciate that.
You can ask, what is this olive oil that I'm enjoying?
But normally, it is hidden.
It is a pity because it's so important
in how we consider our gastronomy.
So we have wine.
We also have great wine in Spain.
And the good thing about wine is that you put an in front
of the person that is having the dish.
So at the same time, you are having something
that gives the dish the right fabric.
But then you own the conversation.
You have a direct conversation with the user
with a particularly bottle of wine that they can enjoy.
And, of course, many days, not obviously,
with olive oil.
So I think we need to have both.
We need to have code, and we need to have design.
We need to have the control over what is running,
but also we need to have the conversation with the user.
No matter who the user is.
And so that is for today.
Thank you very much.