Yeah, thank you. Hello, everyone. I don't know these audience very well, so I'm just
going to ask a couple questions from you. How many of you are Katie users here? Okay, by the
end of this talk, how many people are going to be Katie users? That's the question, that's
the question. Okay, cool. So, I'm Andy Bitz and I'm a designer for the Katie ecosystem,
I guess, but mostly for plasma, for the plasma desktop. And I've been with the team for
about, yeah, 25 years. And I'm originally from Chile, but I live in the United States. And
yeah, that's what I do. Oh, my day gel though, I'm a quality assurance manager, so I do something
completely different. I'm going to use my phone a little bit, because I have my notes here,
and I just want to hit some points, and I don't want to forget. So, I'm sure a few of you
are familiar with design systems. Yes, no. Yeah. Okay, cool. Design systems is basically nothing
more than basically your UI encode, but expressed in graphical means, right, for people like
me who don't understand code very well. So, we look into design systems, because most of
the times, our work is kind of random, and very variety. And, you know, if you have 10
people in a room, there'll be 10 different designs, right? And so, you have to find a way
to bring everything together, but it's not just graphics. I think one other thing that is
very important for design systems is to have an ideological foundation about what you want to do.
A lot of people, so in this happens often in open source, right, we code first, and we think
UI later, and we think users, much later, right, or sometimes we think that maybe the things
that we are assumptions are correct, right? We think, for example, well, you know, if I,
my users want to have, I don't know, an application that can play music,
therefore, anything that looks like a play button will be good, right? You have to figure it.
So, and so, these assumptions sometimes can play into the way we think, and as, you know,
you just saw in the previous talk, sometimes you face a reality of, I build this giant thing,
and it's amazing for like what we think, it's amazing, but then you put that to regular people,
and that teaches you a lesson, right? Sometimes it's hard to come back from that, but the
design systems aim to organize all that thought, aim to basically express graphically what your
users need, and you basically have a much better time translating your work to actual code.
That is actually what's been for me, one of my biggest issues, like I can make graphics all day,
but I can't code the way that my peers do, the plus, my team, and so, trust me, I've tried,
and it's not that easy, and it could also be them, because they make an amazing work. But the
thing is that one of the biggest limitations in my ability to be successful with the plus,
my team has been transferring graphics into code. So, we thought also, and I think this is
pretty real, that you can automate a lot of stuff with design systems, right? For example,
I don't know if you all know, but in KDE, well, plasma, we have the breeze theme, yeah? You get it?
Okay, cool, we're talking about the same thing. And in the past, for example, many years ago,
we built our current icon system, and the way it works, code wise is perfect, but graphics wise,
it's not. In fact, when I started working on design systems for plasma, that was one of the
biggest challenges. Our icons are just everywhere, and they don't have any kind of, you know,
sort of like visual consistency, and not only that, technical consistency. So, in the application
that they were built back in the day, there is no sharing of information between one or the other
icon, although they may look very similar. And so, design systems are able for help you create patterns,
componentize your patterns, and then apply very quickly, right? So, one of the things that we did
in plasma, for example, is we created icons that have little like variant-oriented designs. So,
basically, they vary the meaning of the icon, and we placed them, usually at the bottom, right,
of the icon. Well, all of that you can componentize, right? If many icons use the plus sign,
the minus sign, the acube, a circle, whatever it may be, you can just make a component that actually
cuts the icon in that corner and places whatever you want. And we can do that very quickly, right?
So, one of the cool things, actually, that I want to try, and we're going to talk about this
later in PEMPOT, is I wanted to basically have a way to export my work and show it to developers in
an easier way. Right now, I don't have that, but the people from PEMPOT have been working on
implementing an MCP server for the PEMPOT application, and you can actually follow some steps to
export your work into a website builder thing called Storybook, and others can actually
produce your design system that way. Developers, particularly, they just see the values that they're
looking for since it's all coded or in the application. So, this idea of automation in design systems
is very important. It can really speed up the work, and not only that it can make one designer feel
like Superman, right? Because you can do so much more with a smaller team and repeatable sustainable
is super cool. Now, the issue is, I think, and I hinted at this earlier, that we have an
environment in open source that is generally code first. Code first, I mean, I'm going to help you
process this idea. Code first is should be code last, okay? So, code last, why? Because
when the designer, the cost is high, right? When developers are working on a giant,
you know, application or feature, whatever it may be, usually the challenge is mostly about
executing the idea, executing, you know, the feature that you really want to work on.
And then, you push that onto some, I don't know, let's just say, I get help ripple where your
application can be, you know, reviewed by an entity, in our case, it's Plasma, right?
And the comments come back down to you about how you, UI, doesn't follow certain guidelines,
how your labels are not right, how, you know, the placement is weird, how, you know, sometimes
something that I do, I try to tell people about, you know, behavioral patterns that regular
humans have, and these are universal generally. So, and we say, okay, well, users tend to go to
want to go faster, they want to read less, they users want to, you know, they prefer choices,
but choices are a powerful rather than thousand choices, right? So,
and then the developers confronted with this idea, and then you think, oh, gee, I don't want to
do any of this, this sucks, I don't want to code anything, I do this application, sometimes I've seen
it too, like people get burned out because the UI becomes such a problem to you as developers that,
you know, you just feel like, oh, gee, I mean, all I wanted to do is just develop a feature,
I'm done, like, this is not worth it, right? And so, in my mind, I think, at least in Plasma,
it's not always possible, but I feel like with a design system backing up or work, it may be
much easier for designers in our group to connect with our developers and say, what is this
idea that you want to work on? Let's build it in an inexpensive way, right, man hours,
not coding, and this is, you know, you can destroy graphics all day, but you can't destroy an apple
day, right? And so, we can work on the graphics first and get to a conclusion on what you need,
and then move on to the actual coding, and might actually make it much easier for you to code,
because now you have a plan, right, when you don't have a plan, you work way too much.
So, another issue that we see in the landscape is that graphics is not a focus of open source,
I'm sorry if I'm saying that, and there are some sensitivities here, but it seems to be that Linux
in general, Sanica system is geared towards, you know, high demand type of workflows.
But we all want the year of the Linux desktop, right? So, we are always looking into ways that we can
bring this type of technology to just regular people, everyday people that can use this.
I can say that maybe more of the United States, that it's the situation, I know that in Europe, a lot of
people actually live and breathe in open source all day, so that's fantastic, but in my landscape,
it doesn't seem that way. So, I think that design systems have the ability to connect a lot of
basically bridge the gap with this problem of code first and working with
the design system, sorry. All right, so cool. Now, let's talk about plasma specifically.
So, when we were looking at some of the applications that we wanted to use for this,
in fact, we didn't really start thinking about building a design system from the get go. We were working
on other graphics, and that led us to work on a design system after.
But the landscape is also a bit lacking, right? We have things like Figma, and there were other
applications like Linux CEO or Akira that kind of tried to do similar things to what Figma is doing.
And then, of course, Bempot came along, and they all have their strengths and weaknesses, right? Figma
is a good application, but it's a paid application, and it's diving into this world where
they're locking up, or they're developing new features, and they're all locked. And so,
your basic plan no longer affords you anything. So, then, for example, other applications like
Linux, or Akira, they just sort of got a good start, but then they sort of mellow it out, and from
what I can tell they're not being developed very much. And then we landed on Pempot, which basically
has most of what we need, if not all in some aspects. So, that's the tool we chose.
We started in Figma, but now so far we have migrator, all of our graphical assets into Pempot.
Now, another problem that I think we have in the KDE Plasma team is that
I can say that maybe we have like true graphic designers, it's probably a very small number,
like maybe three or four people in our group, whereas we have like a 90% coverage of developer work,
right, and at a developer. So, that's a big thing, a big mountain to climb, especially when
you want to talk about, you know, how your development needs to go. Not everyone takes that very
easily, but what that means also is, for example, in Plasma, we generally spend a huge effort
to just get off the ground with code. And then, generally, because of our geography, I guess,
in our team, it's hard for us to basically bridge the gap, because in Plasma, I don't know if
you know, but we have like more than four different frameworks that we use. And so, generally,
our developers tend to code multiple times so that the same application looks the same in different
frameworks. And of course, as you know, not all frameworks are created equal, so you may have
something that looks really good in KDE Plasma, but looks terrible in KDE Plasma, right,
and you have to make it work. So what, at the end of the day, what that amounts to is that there
are developers who are spent a great chunk of time, just coding. And that in itself makes us
basically develop smaller features, just smaller changes for the public, and we can't scale.
So, the scientists actually have the ability for you to sort of remove the UI aspect and the UX
aspect away from developers that they focus on coding. So, that's generally the gap, and
we were talking about some of the applications that we're working on. But next is our strategy.
So, what is our thing? We're going to, we started by making icons, like I mentioned before,
we actually don't use a standard 24 pixel icon as our base, we used 22.
And that's probably a sin in the graphic world. So, we decided, so somebody asked me if I could
create 24 pixel icons to up the level of our 22 pixel, and just move them out of there,
because they're not divisible by eight very well. And so, I started doing that very quickly, I realized,
hey, the base of all these icons is not great. You know, we should do something much bigger than just,
you know, make 24 pixel icons. So, what I did is I redesigned all of them. So, I was like,
let's just toss it all out and just start over. So, we did that, and not only that we created,
basically, that's where the system started creeping in, because we started making icons of
where we're repeatable. So, with just small variations, I was like, I just need to go faster.
So, I started making icons different components, and from then on, we made the jump to an actual
design system. So, our icons are done mostly. I'm finishing application icons, and those are the
pretty ones, right, that you see mostly on our taskbar, on our panel. And I'm also, and then we started
building just basically the main things that the power of design system. Typography, color,
shadows, focus rings, all these stuff. Typography, did I say that? And then we moved on to the
next layer, which is asset creation. So, we built buttons, progress bars, scroll bars,
drop-downs, text fields, checkboxes, radio buttons, all of that, with the power that by tokens.
So, super cool. And, like I said, we ended up moving into pinpot, and now we have a more
federated location where more designers can go into. I can provide access as well. I created
a repo where all of these assets are posted, and you may be thinking that I was building
breeze, but actually we're building a new system that looks different than breeze, and it's called
ocean. So, if you would like to see some of that, you're welcome to check out the visual design
system, or just my repo, just go to invent. The kiri.org slash A&Di, T-O-S-A-N, and D-To-S-N. Okay, A&Di, T-O-S-A-N.
And you'll get an early preview of our icon. I'm new icon style, our new typography,
our new plasma style, and our colors. So, take a look. Now, I will caveat that by saying that
all of that is applied into breeze, and breeze does not look like ocean. So, take it with a grain of salt,
but at least you can see some of our icons. So, all of that leads us to where we are now,
and we're in a much more robust location. We're building a design system that is soon to be applied.
I don't know if you've heard also, but in plasma, we're working on a new engine, a coding engine,
called union. Yes, no. Okay, I'll let you know. So, in union, we're trying to unify our four to five
frameworks, so that developers code once, but it looks the same in all frameworks.
And ocean will be coded in use in union. But union still is working on a developer preview,
so we're also waiting on union. But after that, and I got some assurances from the plasma team
earlier this week, that we may be seeing more construction of ocean assets in about three or four months
from now. But so far, we have a button. So, that's a good start. Now, from all of this,
I think we've learned a lot of stuff, and that it's, you know, first of all, we need to improve a lot,
we need to do better, we need to do a lot more than what we have, but our design system as far
as ocean goes is mostly complete. We're just basically today, we're just building like more complex
UI in the design system, but again, since none of it is actual real code, there's not a ton
of incentive to just, you know, kind of pile up and keep growing this design system, because I'm
pretty sure that when we try to apply some of this, there's going to be a lot of challenges,
and we're going to have to change things. So, I just want to keep it at that level for now.
And so, like I said, if you have any questions, reach out. I will, like I said, you can go to our
repo, you can connect with me there, you can also join our, our KD visual design team,
and have I convinced you yet that you can use or install KD on your machine?
A bit? A bit? Okay, I heard it. Yes. That to me is a yes. Okay. Awesome. Well, that's my talk.
Thank you so much.
Ten minutes for questions. Okay, cool.
So, you guys move from stigma to example, how was the group? That's the shift that I know that we
are also looking forward to. Yeah. We just want to get prepared. So, you'd like to know how the
stigma transition to pimpo was. It's actually pretty seamless. So, we, so a few months ago,
pimpo released, remind me, yeah, no, the variance? No. Yeah, there is. So, now you actually can
sort of do the same process that you do on Figma, where you create one asset, then you link
another one below it and you make some modifications and another and another. You can do that in
pimpo too. So, with that, we built our, I don't know if I can show it. Do I have it? I know,
I put it away, my bad. But, we put all of our stuff there. So, once we were able to do that, it was
much easier because at the end of the day, the census systems are nothing more than state representations
of your assets and once that was available, it was easy to just like create a button and then create
20 more that with different states and just be done. And then the other thing was tokens. Figma
actually has tokens kind of on the side. It's sort of a side menu to them and they have a combine
with their variance idea. And for us, tokens is better because tokens is actually what the
developers are going to use to implement something. So, in Figma, I mean, sorry, in Pempo,
they integrated token studio, which is just a plug-in in Figma, but in Pempo, it's actually native.
And so, you can build tokens natively from the get-go and we already set up all the ideas around,
you know, how we name our tokens. We're actually following many of the ideas found in Android
design systems because it seems to them the most complete and available thing you can read.
So, we're using some of those ideas as well in Ocean. So, yeah, it's super easy. I think go ahead and
do it. Give it a shot. Yeah. How does it work? The function are from between developers and designers.
How does the flow work between devs and design? Yeah. So,
for example, you use Pempo, or? Yeah, exactly. So, absolutely. Yeah.
Yeah. So, he's asking, like, one minute left. Okay, I'll go fast. So, the question is,
how do you, what is the transfer between design two code? So, generally what you do is,
you would create out of all of your tokens, you can export this list of tokens and create a
JSON file that just describes all of them. That's all it is. And then, somewhere in your development
locations, you can decide where it's best to put your files, your design files, whether to break them up,
or whatever you want to do as a developer. And then, somebody, an integrator, some kind of designer
developer, an in between, can actually code your designs by referencing either the Pempo UI
because you can actually click one of the, any of the assets and see all the details and replicate it.
Or the other option was what I was talking about earlier is you can actually export the
well, you can, you can run an MCP server on Pempo and collect all the data that is needed to
create something called a storybook, which is basically a UI, a web-based UI explanation of
your assets. And developers can actually reference that and since it all runs on the web,
you can actually, for, in some instances, for some of the components, you can say, okay, well,
the radii of this one should be like 24, 25, and you can experiment with that there without ever touching
the graphics. So, those are two methods that you can do. We're actually going to investigate
some of that when we're done when we actually can get off the ground, but as far as the developer,
that was working with me on building the button that we have for Ocean, he said it was
much easier. All he had to do was just look up the variables. I mean, sorry, the token and design
tokens that we created and that's all that they needed. Thanks!