Tech Over Tea - KDE Makes Traditional Desktop Design Modern | Andy Betts

Episode Date: November 28, 2025

Today we have Andy Betts on the podcast from the KDE Visual Design Group to talk about how design happens in KDE and how things are improving behind the scenes even if you can't see it.==========Support The Channel==========► Patreon: https://www.patreon.com/brodierobertson► Paypal: https://www.paypal.me/BrodieRobertsonVideo► Amazon USA: https://amzn.to/3d5gykF► Other Methods: https://cointr.ee/brodierobertson==========Guest Links==========Website: https://kde.org/KDE Design Wiki: https://community.kde.org/Get_Involved/designKDE Fundraiser: https://kde.org/fundraisers/yearend2025/==========Support The Show==========► Patreon: https://www.patreon.com/brodierobertson► Paypal: https://www.paypal.me/BrodieRobertsonVideo► Amazon USA: https://amzn.to/3d5gykF► Other Methods: https://cointr.ee/brodierobertson=========Video Platforms==========🎥 YouTube: https://www.youtube.com/channel/UCBq5p-xOla8xhnrbhu8AIAg=========Audio Release=========🎵 RSS: https://anchor.fm/s/149fd51c/podcast/rss🎵 Apple Podcast:https://podcasts.apple.com/us/podcast/tech-over-tea/id1501727953🎵 Spotify: https://open.spotify.com/show/3IfFpfzlLo7OPsEnl4gbdM🎵 Google Podcast: https://www.google.com/podcasts?feed=aHR0cHM6Ly9hbmNob3IuZm0vcy8xNDlmZDUxYy9wb2RjYXN0L3Jzcw==🎵 Anchor: https://anchor.fm/tech-over-tea==========Social Media==========🎤 Discord:https://discord.gg/PkMRVn9🐦 Twitter: https://twitter.com/TechOverTeaShow📷 Instagram: https://www.instagram.com/techovertea/🌐 Mastodon:https://mastodon.social/web/accounts/1093345==========Credits==========🎨 Channel Art:All my art has was created by Supercozmanhttps://twitter.com/Supercozmanhttps://www.instagram.com/supercozman_draws/DISCLOSURE: Wherever possible I use referral links, which means if you click one of the links in this video or description and make a purchase we may receive a small commission or other compensation.

Good morning, good day, and good evening. Welcome back to the show. Today, I have had discussions about design in KDE quite often. People will bring up these ideas of KD looks old and outdated, all of these ideas that I'm sure you've come across many, many times. And today we have someone who is involved in the design of KDE. So how about you introduce yourself and we'll go from there. and hopefully we can answer the question of why KDE looks the way it does and how things are improving.

Oh, that's a lot. That's a big question. But yes, my name is Andy Betts and I am a designer. I work in UI and user experience for, well, I don't work for Plasma. I have my own, you know, side job where I do my daily things. but I've been a volunteer at KDE for about 25 years now and I my focus has always been on on graphics but by day I am a quality a software quality manager and I make sure that software goes out to the public the right way and yeah so and like I said I've been at KD for a very long time

I'm from Chile originally, but I live in the United States, and yeah, excited to be here. Yeah, it's an absolute pleasure. As I was saying, before we started recording, I have talked to KDE people, and the idea of KD designers always come up, the KDEVDGs come up a number of times and all these things, but I've never actually had anyone who's heavily involved in that. Obviously, Nate's going to have like some sort of, you know, attachment to it because he's involved in a lot of KDE things and I'm sure Neil is around these spaces a lot of the time and I'm sure a lot of KD people that are in the programming side are obviously involved in

the design side because it's like what is actually viable to implement but someone who's actually focused on UI and UX that's that's a new one so I think the best place to start here is how does the design make its way into KDE? Oh, we disconnected? Lovely, what a great start that was. That one will be cut out. But I only heard how and then it stopped.

Okay, I was saying if we're talking about some core, KDE application, whether it be plasma or some other core thing to the environment. How does the design make its way into that? What is the, what is the process that happens when you want to do some sort of big design change? Yeah. So, I, there are a couple of ways to answer this question. And I think the most common one is that developers or volunteer developers join the

the community in an effort to put out some kind of improvement to the code. And in those cases, at least a KDE, or let's just say plasma desktop, they submit a merge request into our Git, right? They clone our repos and they, like, submit a patch or whatever they want to do. Most of the times, it seems like developers create their own UI and process their own ux based on the feature they want to put out ahead of time and so when they put in the merge request most of the times they already have thought out of a ui for this and they request the feedback of the community and that's when it comes to you know most of the times they go

on on git lab and in our case and if it's necessary they tag the vdg or the visual design group team at Plasma. When that happens, a few of us actually get a notification. We go into that merge request and we evaluate the change they want to make. And so that's usually what I do most times. I just go into a merge request and I give advice on the UI. I try the best I can not to actually redesign everything in my head. I try to, you know, I do my best to stay within constraints because at the same time, we have to understand that we're working with volunteers that are doing this

on their spare time and that, you know, they, just as I am not a developer expert, they're not necessarily a UI or UX expert, and we have to balance those things out. So that's the one of the most common ways. Sometimes there are people who preempt their idea and they submit an issue ticket to our channels. And they say, hey, I have this crazy idea.

I want to make this awesome feature. And, you know, I've been thinking about X, Y, and Z. Here are my thoughts. And here are some early mockups or whatever they make. And they put it on either on GitLab or bugs.kD.org. And again, same process. It gets tagged for the VD. One second before we.

I want to sidetrack there for just a moment. a lot of people will assume that the bugzilla is just for bugs. It is, yeah, and for the most part it is. However, you can go on Bugzilla for plasma and you can actually submit, you can submit a ticket that is a wish list ticket. So instead of saying, you know, this is a bug, you on the category section you put that it's a wish list or, and that basically tells us that it's an idea,

that it's a thought, that you're proposing something. At the end of the day, though, I think if there are specific changes, we would channel those changes into GitLab anyway. But it is okay for people to begin discussions around improvements and design changes, either on Boxzilla or GitLab. I mean, we get people submitting ideas on discuss. So, you know, it can come from anywhere. But eventually, we would work with that volunteer.

here and bring them over and see if they can actually execute the code that they are looking for to integrate into plasma. Yeah. So those are some ways that people submit things. So what's an example that you've actually worked on that would be something that the VDG is concerned with? Yeah, good question. So I comment on just about anything that relates to the VDG. but for example, one that I always remember because it was something that I pushed for is the current layout that we have in system settings is something that I came up with originally a few years ago. Now, of course, system setting since then has seen a lot of changes and I'm not going to take credit for something I haven't done, but by and large the organization

that you see today, the layouting, is something that I came up with. And we had discussions around this. Back then, I think when we proposed this, things were a little bit different. So it wasn't quite as a workflow that we have today. So things were sort of a little faster to production. And as long as I had somebody, a developer who believed in the vision of these changes, they were able to implement it. So, but for example, I commented just about anything, like the panel resizing, the edit mode

in plasma, I worked on the calendar widget, I worked on the weather widget, I worked on the, like, just about anything that is tagged VDG, we go in and give comments. So I take that as work for myself. So yeah. Before you go too far on, it's probably worth explaining like what the VDG is. is and how people actually get involved with it. Yeah, absolutely. So the VDG stands for the visual design system.

It was created a few years back in the 2010s. And it was the intention of it was to basically concentrate all discussions that were related to user interfaces and experience. And basically, the angle at the time was to basically work it into breeze. so that breeze design was sort of pushed forward and with the help of a lot of volunteers and so we formed this group it was really cool it was led by other people in the beginning I was just a regular contributor and commentator but yeah the our purpose is basically to bring only UI-UX related discussions into this chat and sometimes

Of course, not everything is monolithic like that, but we derive into other types of discussions, but by and large, we just discuss graphics. How do you execute this type of, you know, look, these colors, how do you work with animation? It can get very technical, but in many instances it gets very sort of on the surface, right? like we talk about front-end very extensively and how we want things to be perceived. If we struggle with a certain design decision, we talk it out. I struggle with that sometimes,

but it's helpful. But yeah, that's mainly the angle of it. And if there are any other discussion, sometimes, like, you know, we have things that deal primarily with our frameworks or bugs, and we just sort of try to redirect those to their appropriate channels. So our channel is mainly, mainly directed to working with UI front-end work, basically.

But obviously functionality is going to be kind of directly tied into that, especially when you start talking like UX stuff. Like a user experience is a mix of both graphics, the front-end visual design, along with the functionality. Yeah, absolutely. So when we when we talk about UI, you know, if the question is, what color should I use in this situation? That's an easy UI question, right? But if you're talking about why blue is a good color for people on a computer, that's a, that's a UX question, right? And so when I, when we receive questions in the video, that relate to, for example, let's see, for example, most recently we were discussing how to deal with Do Not Disturb. In Plasma, Do Not Disturb appears on the task bar, you open it up and you turn it on, but as you turn it on, immediately you get a pop-up a context menu that tells you these are your options. you can enable this for an hour until next morning or indefinitely, right?

And so, however this was designed, I looked into it and I felt that there were a couple of user experience problems, right? For one, in our guidelines say that switches need to be instant apply. And this switch does not do that, right? When you click enable, it shows you a menu, and you have to click a second time to enable one of the options. So if I'm thinking of, you know, UX is from a user experience perspective, I have to think for the user, for the regular user, and I have to think within certain parameters. For example, I have to think that most times users want to click the least to achieve the most. And so if we go by that type of guideline, preventing people from instant apply on do not disturb defeats that purpose because you don't get it applied immediately. You get it applied after a second click and that is called interaction cost.

So your interaction cost goes up and users, I'm not saying this is the biggest problem of the world, But, like, users will get slowed down by trying to achieve the most common thing, which is to just enable indefinitely, and then you can choose additional parameters to stop it automatically. So I suggested a few things that, you know, you could do to solve that. So you see how the questions are different, right? Like, one is about, you know, graphics, colors, applications of such. And then the other is more like, how do people perceive what you're putting out in the front end? And so, and there's a few guidelines that you want to follow there.

So you mentioned, like, this is not the biggest change in the world. But I think it's important for people to remember that even little changes are important because each little change adds on to the existing changes that are there. For example, let's say the use of color, right? Katie likes to use color to indicate pop-ups. It's like, here's a, you know, if you go into the, the, what do they call it? The place where you can download, like, themes.

Oh, get hot new stuff. Yeah, yeah, yeah. It's like, I'm pretty sure there's like a prompt there that indicates something. And when there's like, when there's things where there's, hey, it's a warning, oh, this is going to be a certain color. When there's an error, this is going to be a certain other color. And these, like, this use of color is very small. But because it's consistently, mostly consistent, there are issues that have, of over the years.

Exactly. And that's sort of my point. When it's mostly consistent, but you see these little bits which are wrong, the little bits stand out a lot more. So even though it might not necessarily be that important in a vacuum, when there's this one thing that stands out from the rest, it can feel really weird. Yeah, absolutely. And here's, you're actually speaking of something that is very common in user experience, which

is like, you know, the principle of familiarity with other systems. So there's a rule in user experience or a guideline, not a rule, but that says that users spend most of their time in other websites. And what that means is people are experiencing interaction in other places that needs to be replicated in your own. And with the moment you're different than that, it's harder for the user to understand and be familiar with what you want them to do in your system. So this actually speaks to the idea of, and this happens often, but people suggesting like, why don't we do things more like macOS? Why don't we do things more like Windows or some other awesome, you know, UI for Linux? Well, it kind of explains why from so long Katie had single click.

Because when I spoke to Nate about that, he's like, oh, on the web, on phones, you do single-click to do interactions. Exactly. And the thing is that, well, if we are honest about all this, double-click is probably more ancient than one-click. But at the same time, the web, they wanted to be faster. They wanted to be instant. And, you know, you just click a link and you go on. And that takes less time to do, even though it may be just one less click. So anyway, so the idea is that basically that users need to feel familiar, need to feel at home,

need to interact in similar ways that they do to other systems. And the moment that you change that, you break the familiarity and it's harder for them to figure out how to do it. And again, your interaction cost goes up because now you have to spend time thinking. how do I build the disconnect lovely lovely are we going to reconnect did I just what happened here

who disconnected someone disconnected uh god damn it this is going to be it's going to be it's going to be it's going to be one of these days isn't it all right there you go it's going to be one of these days

yeah don't worry What part did I cut out? I can repeat all that. You're talking about similarity in systems, and that's kind of the last bit I heard. Yeah, I can tell them more. Let's see. So basically, as your interaction goes up, you're making it harder for users to complete their tasks. And so you want to always think, even though sometimes, you know, the types of arguments, get devolved into, oh, let's just be like macOS or let's just be like Windows.

I think what people really are trying to say is, let's behave in a way that is consistent so that we are not lost. And so we have to take that into account. We have to give it that perspective. And so anyway, at the end of the day, you want to make sure that your system feels familiar, yet it's its own thing, and you want to balance that out. But there are certain things that basically you don't want to touch, like, for example, the way that a link, a text link behaves, right?

Like you click it and you go to a place. You don't want to change that because the moment you do, you're like the outlier and you're very different than like 99% of the internet. And so as a user experience designer, you want to think through that. And whenever we get merch requests, I try to explain that. If it's in a way breaking the rules or the guidelines or it feels too different. Sometimes we are challenged on those standards and those guidelines, and that's okay.

But for the most part, I try to explain that with a good backup, hopefully, but in a way that makes sense. So yeah, that would be reasonably like, you know, why we talk about familiarity and behaving like other systems in a Linux system. It's a very different field, but I think it works as a comparison. as well. This idea of sort of offloading that mental workload is something that applies to literature as well. Like you see a lot of these fantasy series that are very heavily inspired by token work, right? Where you don't need to explain what these fantasy races are because you can assume that people have some sort of background knowledge on, you know, what a hobbit is or what a, what an what a dragon is like that that assumption is already there so you don't need to worry about it

and it's the same thing here where you don't need to explain what a link is because if you're doing it correctly if you're doing it the way that everyone else is that is just assumed behavior absolutely and you want to be attentive as a user experience designer you want to be attentive to those types of conundrums because it it's important that that if you want to break a rule or a guideline in user experience, that there is really good reason for that. And that the result is a better outcome than the one that is the standard, right? And so a little bit of UX deals with the idea of show, don't tell.

So for example, I think every now and then we get merch requests that are, like, I don't know, we're implementing a drop-down, for example, that does X, Y, and Z. And it just so happens that it's a bit complicated. So we're going to add a big old paragraph right above it that says, this works like this. And that is probably not the best thing because users want to go fast. When they have to read, users want to read the least and understand the most. and so you want to either do away with the text and just leave the drop down there or you want to work on the text or the labels in your drop-down so that they're more

understandable if you're doing something wrong yeah by all means put a warning there but if you're just going through regular use you want to cut away from text and so that's what I mean like try to make sure that your UI encapsulates the social experience that you want users to have and how fast they want to go, how easy it needs to be, how powerful the interaction needs to be, and work on that rather than, you know, here's all the added information that you want to watch out for before you touch one of our controls. And that most of the times leads users to step away from the system rather than dive in. So, yeah, users want to read less, basically.

How would you effectively use tooltips then? Because they're still a fairly common, like, UI element. Yeah, tooltips, well, they have a specific function, right? So their function is to have additional information about the one specific item that you're about to click. and that is not the same as explain what this button does. It's additional information. And sometimes we don't do a good job at this. I admit, you know, that sometimes we say, yeah, use a tooltap so that you can explain what's going to happen.

That's probably not the best approach. The best approach is usually to explain additional information. So, for example, some type of warning, some type of, you know, know, a little gimmee gimmick that it's important to use here. And you also want to make sure that your text is the short as you can. Because also text gets translated and usually when text gets translated to anything other than English, it gets longer. And so you also want to shorten your sentences.

You want to use phrases for the most part. But the angle of a tooltip is to use it for additional information. If there is something that the user cannot understand from the UI itself, a tooltip will not fix it. You want to work on the UI itself to make it more understandable, more part of a natural workflow for people. And text is not the only way that you can portray information to the user either. I brought up the example of having your, you know, warnings be colored a certain way, your errors be color a certain way, so that that's also something you can rely on. But I think the important thing with there is you can't just rely on that because there are users who either are going to theme their stuff or, you know, they might not have, they might be colorblind and those colors might not, you know, they might not be able to distinguish certain colors. Yeah. In fact, we've been working really hard at this. We bring this up often, especially because right now at Plasma, we have a goal to develop a more accessible desktop. And when we do that, we have tried to catch those instances in the UI where we're saying, oh, we're just going to give you a red button here, and you'll understand that that's a warning. And that's not always the case, right?

In fact, there is a guideline in user experience that says that color alone cannot be the only piece of UI that, you know, communicates meaning to users. And it's one reason why, in fact, not just in plasma, but in other many UIs, particularly in phone UI, where you see, even though you have a colored button, you may have an additional graphic like an icon with an arrow that's telling you if you click here, this happens. Why? Because you can color the text and the arrow in different ways than the button. And that way, the user that may have trouble seeing the color blue can see at least the arrow on the label. And so you skip that idea and they get past it and they can complete the interaction they're trying to do. So yes, it's really important. But also there is the whole other side with psychology of color, where you want to apply color, that mean something to people in regular life, like red for dangerous actions, blue for easy

actions, green for completion, yellows or oranges for warnings and things like that. Like those things matter for the people, for the majority of people that actually can see colors without a problem. But at the same time, there's been instances that we've caught where there was nothing but color. And we needed to work on that. I'm sure it's going to get better. And when we talk about the design system in a few minutes,

I'll tell you how we may actually have answers for that. But yeah, exactly. You're right. Like, we have to think of all of this. Honestly, at the end of the day, the role of a user experience designer is just to convey social interactions, but in a digital form. And what are the expectations of regular users to complete actions on a computer as they do in everyday life,

like, you know, to do laundry, to do wash your dishes, to clean your house, things like that. So where does sound come into play with KDE? Because I know if you go back in the, you know, a lot of early desktops

in the early 2000s, late 90s, everything made a sound. There was sound everywhere. You can see there's this, there's somebody who put a compilation together of every single sound effect from, I think,

KDE2. and I don't even know how any sound effects that desktop had but it modern desktop don't sorry a product of our time but sound is also another thing

that can also portray information assuming you're not doing whatever was being done back then I think yeah absolutely I mean sound is it's core and it's important I think very recently this year we worked on our login

and logout sounds and they were revamped and but by and large I think over time desktops and you eyes have gone the way of

silent interaction and warnings are more they're more like you know very specific because they need your attention and one reason for that is because in today's age with our phones

with our tablets, we're bombarded by notifications of all kinds. And to have the mind space for each of them and give them their space is not as effective. Like the more notifications you send, the more turned off as a user, you'll be about reviewing any of them because it's just, you know, it's like a feed, it's just constantly like putting out new information. And so I think desktops in general have tried to basically minimize the use of sound so that it actually is effective when it comes up. So, for example, we do this very much like macOS and like Windows.

When there are errors in the system, we bring it that up with a sound. And when we log in, we welcome the users with the sound. When we log out, we exit the place with the sound. But I think those are generally the most recommended areas where sound wants to be. Because at the same time, another idea is you have to think that these spaces are personal. And when you take your personal space, your laptop, your phone, whatever, and you go to a public space, then you are very loud. and probably you won't be, you know, the most pleasant person to be next to. And so there are situations that you want to mimic, and I think that that's one of those.

It doesn't mean that maybe sound is not important anymore, but I think that it seems that users prefer a quieter space, a more peaceful space, rather than one that is constantly seeking attention. So from that regard it makes sense. But at the same time, you also want to be very careful of omitting sounds when there should be a sound.

Like if there are important messages in the system that just sort of fly through your desk screen and you don't do anything about it because you could have missed it or you walked away from the computer, but you definitely needed to hear it.

Then, you know, that's that's something that we want to look at. I don't think we've encountered situations like that, but we're always, I'm sure, you know, our large user base will probably bring something up and we're happy to hear that. So, yeah, absolutely. Like, we want to be careful how much we use it.

Okay. I guess you kind of want to shift gears into talking about design system changes. So I guess we can go into that. I don't know where you want to go with this. So lead the way, I can explain. So I've actually been doing this for now, about two years now. And as a designer, so I don't know if you know about all the sleuth of new applications

that deal with design system organization graphically. So the most notable applications in this space are Figma. But there's also, you know, previously there was this a Mac application called Sketch. and there was AdobeXD, the earlier players. And what they aimed at doing was to bring the same level of organization that you have in a development space with frameworks, with code, but in a graphical idea meant for designers, for graphical designers. So that you can actually do all the design work to the level that a developer would expect.

But for all you know, you're just working with graphics. But at the moment that you hand off that design to a developer, they can read the code for that design, and they know that it has the appropriate variables, the appropriate color names that you can just apply in your system. And so, and previously when we were working with Breeze, this was at a time when we didn't have a applications like these, they work with vector graphics, so SVG, and our best solution at the time was to work with Inkscape. Now, however, overtime Inkscape has remained more of an illustration type of application with, you know, SVG at the core. And but this whole side of UI development with graphic design exploded. And we now have applications like Figma, it probably is the most, the dominant player out there.

And along came other derivative applications that try to do what they do and a few others like Webflow, like Framer, like, you know, try to fill in the gap for animation and other stuff. But there was nothing truly open source until there were a few other open places like, Now, Penpot is a serious contender for the open space. And we have basically, with that in mind, I took this idea, and a couple of years ago, we were talking about how we use 22 pixel icons in our desktop as the base icon size. And 22 pixel is not a sin, but it actually is very different than most other systems

that use multiples of eight to size and resize items on the desktop. Because multiples of eight generally do better when you do division. And so not only that, 22 is rather small. For example, in our system, we have icons that, and I'm just speaking icons for now, but we have 16, we have 22, and then we have 32, and then we have 48, 56, and so on. And so our 22 was sort of the odd man out, and we made them that way in the beginning because our screens were smaller, less resolution, and we needed to make our stuff smaller. So we started a discussion about how can we make these icons be more standard size?

and I said, okay, I'll just jump in. You know, I'll see if I can, I try my luck and I'll try to edit some of the breeze icons. And soon I realized that the icons, we truly don't have sources for the icons. And what I mean by that, what I mean by that is something different than, you know, having like a Git repo.

Sources exist. People can go to our Git repo. and download breeze icons, for example. Not a problem. But the moment a designer downloads a breeze icon and you open it in an editor, you realize that there are no layers. It's just a flat image. Right.

And there's a problem with that in that you have a real hard time editing any of the shapes. So your solution as a designer is to recreate the icon. And so, I mean, imagine, right? Like, you go to a painter, you purchase their paint, their picture. And, but you're not interested in the picture so much as you're interested in the brushes, in the paints that they use in the bag. Like, that's what I'm interested in. And so we didn't have any of that.

And not only that, I think, kudos to the previous designer that worked on these icons because they had to do all of this on Inkscape. and InScape is a single instance type of window, and he made thousands of icons just one window at a time. So that's a lot of work, humongous work. But I had a realization at that point, and I thought, what is my angle? Do I want to recreate icons, or do I want to provide sources, create the new size, and also replicate. good design in our icons and so with that in mind I thought it might just as well be easier to create a whole new system uh of icons and with that in mind we picked up an earlier idea that

we had we wanted to evolve breeze into a theme called ocean or ocean breeze it's received a few names but um nothing really came out of that effort eventually it was we had some mock up and some ideas here and there, but nothing really truly made it into code, as such, as ocean, as an evolution of that system. So with that in mind, I started creating a bunch of icons. I formed a team around that, and we started a Matrix General called Ocean or Plasma Next,

dedicated to the ocean style. And additional to that, we started a design system where we took, templates that are freely available online and we put them in Figma particularly to see how we could execute a whole design system. What I mean by a system is, by a system is like the the Figma document contains buttons, sliders, colors, typography, all the elements that put together a UI, but in a very organized way, in a very thoughtful way. and also explained in variables invariants so you can actually easily swap between graphics and it just makes it so much faster so anyway we started doing that we worked on creating buttons all the stuff all the sliders and the idea is that we finally bring a new design into plasma so that we can deliver things faster and better in fact and you spoke of

this in your previous post about our discussion, we're also partnering with the team around Union because Union will, as the name states, will unify the frameworks and provide a common engine for developers to call their components and build their UI. And what we're trying to do is to basically be one-to-one to that idea. Graphics will replicate what Union can provide. And we will, we're hoping that all of this machinery that's created in the design system makes it into code so that there is a good one-to-one relationship between people making graphics and then exporting that to build their UI. Right now, that's not possible. It wasn't possible with breeze. It wasn't possible in previous iterations with oxygen or anything like that.

So, and why are we doing this? Because there's a huge, huge, huge. huge divide between skill level, time, and then delivery. Our users, for the most part, want big things, big changes. They want us to execute, I don't know, dark mode, the easiest way we can. But our system is complex and we don't have, like our developers are not, they don't spend all their time designing things and I don't spend my time developing. So how do we marry this thing? And so what we do is basically to look for ways that we can interpret what code needs to do, but in a graphical way.

And that way users export the graphics. They contain all the variables they need to use. And then they just need to apply the cool feature they want to make. And that is now actually through Penpot, not through Figma, but we're leaving that system. is just to get us started. But through PEMPOT, we can actually distribute the designs that we make, and anybody can actually take this library with our assets and build their own UI up to the standard of plasma that we're trying to set.

And so hopefully this can actually attract more designers into plasma, and it actually can drive developers as well, if they feel so inclined to also design things first, and then try to code it up. That way, the cost of development is not so high. I think what happens today, maybe this has been brought up in your channel before. There are many instances when our plasma developers,

because of our many frameworks, have to design the same thing four or five times. Yeah, I was just about to ask you in regards to what union is doing there, just to explain that. My understanding is, over the years there's been... I don't know, three, four, five different frameworks for building KD applications. I don't know the exact number.

The answer is more than one. This leads to redesigning things. This leads to designs changing in one location but not being updated in another location. And when people talk about inconsistency, a big part of that is, yeah, on the back end, the way it's implemented, actually is kind of inconsistent. And imagine a developer whose forte is networking, for example, trying to battle the UI and see how you can actually execute in one, and then it does not work the same way in the other framework. And you have to design it to look similar, but you don't have the same set of tools. The cost of development is huge. and I can see how many people get burned out by this because when the product comes out

and I review it, for example, I can immediately say, oh, you know, that does not look like it should and that's really difficult to process for a developer, right? Here is a lot of hours of work, you know, breaking your head open for stuff that it's hard to achieve and finally something comes out and you get all this criticism. So that stuff is really difficult. And same for me. I'm guilty of this all the time. I've made so many mock-ups with random graphics from all over the place.

And when I present that to developers, they're like, where are you getting this from? This is nothing like what we have today. And you cannot expect us to make this line like this because that doesn't work like that. And so on both sides of the argument, you see people who, who struggled to make the connection between graphical UI and the code. And so Union will solve that for developers, mostly, right? Union will say, you know, as a developer, I'm requesting a drop-down component. Okay, here's your drop-down.

It will look the same in all of our frameworks. You just use this drop-down. Go ahead. But then again, all of that kind of work needs to be backed up by a solid, design system that is telling you these are the appropriate elements to use and these are the appropriate looks that you should use in your system. At the end of the day, we want to abstract design work from developers so that they focus more on the execution of their awesome idea. Rather than dealing with, oh my goodness, this button is blue and then it used to be red and

I can't fix it. That's a tough that we need to remove that from the equation. Right. Okay. Um, going back a bit, you were talking about how when you didn't have these source files for the icons. So if people wanted to modify it, then to remake the icon from scratch, I assume that's a big part of the reason why, you know, I've heard people talk about wanting to do icon redesigns for a long time, but it's a lot more work than I thought it would be to do so. Absolutely. I mean, in the past, as I was explaining before, like you bring up inkscape, you create a square and then you start putting all your graphics in there, then you export that. And it just so happens too that ink scape has its, like it can export plain SVG, but it also has its own inkscape isms that are difficult to parse in other systems. So their way of doing graphics is a bit, you know, very personal to them that may not always translate really well to other systems. But that aside, the other thing is that these shapes and forms, I believe at least for Brise, they were flattened out before export as well. and so there were no layers when you got the file anyway. And what that makes it difficult is that, for example, I as a designer would like to, I don't know, let's say the brightness icon,

I would like to make the sun rays a little bit bigger, but I can't select all their sun rays and just give them one more pixel. I have to work with nodes because these are just flat images. is. And so with the system, the design system, that's another guarantee that I'm trying to kind of sell to our community is that you will have access to actual sources that you can manipulate rather than just exported items. So for example, if the brightness icon has a circle in the middle and you would like the circle to be a half circle, well, now you can click all the way down to the circle shape and very easily manipulated to be just a half circle,

and you're done, right? And then you just export, and the export, yes, the export will be flat and will be ready for use, but at least you have that source that is easy to manipulate. And not only that, with design systems, you can componentize every piece of a graphic. So you can say my corners are six pixels rounded. You can say, but tomorrow, I just happen to like four pixels. So you go to your source component and you just change you to four. And every button in your whole design system changes to that.

And that's hours and hours saved of clicking and going to every item. So I think that that's one area that it was difficult for me because I was thinking of how can I just. create graphics that are reusable, that don't depend on me because sometimes design is just very personal. I have my own setup in my own machine, but how do I give that to the next person so that they can manipulate the work just as easy as I can? And so through applications like Pentpot, for example, you can do that. You can just give somebody else a library of all of your components and they have the same experience that I do on my system. To put in the context, how

How many icons, just speaking on icons, how many icons does KDE actually have? About 20,000, but, but I will caveat with that with many of them are links, are sim links. Okay. Many of them. Yeah, a ton of them. Just because the needs of the, so sometimes, you know, an application may say, I'd love to have the checkmark icon, but we don't have a checkmark, checkmark that SVG icon. we have something that says positive that SVG,

well, we create a sim link to so that the name reroutes to the right graphic. But in our effort to make new icons for the ocean design system, we have made about 8,000 of them, 8,000 actual graphics. Yeah. Wow. Wow. It's a lot. And I'm sure I'm going to have arthritis by the time I turn 43 next year.

But it's a lot of work. But, you know, I think something that is really cool about this, like I said before, is you set up your system. You behave in many ways just like a developer does. A developer creates a system that works all the time. And they spend a lot of time at the beginning, the front load, a lot of the development to create something that is workable. designers for the longest time have not worked like that we work on just pretty graphics we just like you know we put a flower on top of everything and we just send it off to the to the sunset and that's very non-methodical and so through design system mindsets and applications like these you can actually

think more like a developer and you front load a lot of the work of graphic design but then all you do is just click on the sidebar and you say give me button, you know, size Excel with, you know, like in a warning state versus and with, you know, like, I don't know, like with a label or with an icon at the end, not at the front. And so it's that easy. But yeah, you have to do a lot of work at first. Right. So you like we're doing development stuff, you front load the work and then the tool does the basically all of the stuff that all of the boilerplate stuff that you've already dealt with yeah absolutely in fact in in design system applications like penport for example you can export CSS of all of your assets so if you click a button and you say you want to give it to

a developer you just give them the code and the CSS will work exactly as it appears on the screen. And then also most recently, they've developed this thing called tokens, which are basically a concept that came up that is used mostly in material design, material three, material two for Android. And the token is basically a variable that you put in a large index file. And you say, I don't know, you can call it whatever you want, but you can say color one equals. hex color number, whatever. And the way that you name these tokens is very helpful because that way you can signal stuff to developers to say, this is an outline, this is a button label, this is the color for button or the color for shadow or whatever. It's all set up as variables and then you hand those over.

And many of the systems that work with, for example, React.js today, a lot of them, especially for web, they just read that file and that file is synchronized with your design system. So the moment you change something about your design, it immediately propagates to your website or gets approved to your website. I don't know that we would have something like that for plasma, like that kind of immediacy. but having that backup of design systems on a place where you can actually look at code, that's excellent. Like we designers have never been good at providing that type of detail to developers. So I'm excited for that. So you're saying before you kind of hope this brings more people into doing the design side.

How many people right now are actively involved? in the VDG? Well, if we're counting by the number of people that we have in our channels, in Matrix, for example, we have something like 300 people. But can we say that they all contribute? I don't think so. I think we have varying degrees of interaction. But through the plasma next channel, we have something like 100 plus people that joined our chat.

but I would say the only a few of them were able to execute designs on PemPod and some of them have changed over time. So I would say, you know, as a core team, maybe something like between five to ten people have contributed over time. I would say for my involvement, it has been probably the most prominent involvement. I spend the most time on this. But I'm super grateful to all the previous volunteers in the current. volunteers that are actually helping me. I mean, right now we're trying to migrate all the

components that we can from Figma into PMPO. PEMPO does not have the same kind of support as Figma does. So not everything can be done, but at least what we can, we have asked a few designers that have joined our chats to help us out. And I think we have maybe something like five people that jump in whenever we request work that deals with graphics. Yeah. So long term, once all of this new design stuff is done, if somebody wanted to make an app for KDE, what should change between what they're doing now and what's going to be more streamlined then? Yeah, good question. So I think my personal goal would be to have a design first kind of shop that we're getting to. the habit of trying graphics first so that, you know, the cost of your, of your idea is not so

high, especially when you have limited time and you're a volunteer and you have, I don't know, junior experience into developing for plasma or Linux in general. So that's my hope. It may not happen that way, but my hope is that anybody can just clone a repo, download the penpot file, uploaded, they have all the graphics they need, and they can simply put them together or request help from the VDG to execute their idea graphically. And then the ideal workflow would be you export or you give this code to a developer or yourself, if you're the developer that's working on this, and you focus on calling up the right backing items that you need, the library, and all the stuff, and you focus on that rather than the UI.

And then you submit your merch request as you usually do. I imagine that there may be people who want to discuss designs first, and that's more than welcome. They can submit that into our systems, into our locations, and you can actually discuss that. But I see that there may be also room for the current type of work that we do where people submit a merge request first. And in those situations, I think it would be much easier for a designer to go to our design system,

extract all the graphical components that this user is proposing in their merch request. And you can say, okay, look, here is, you know, how I would execute your idea. And, you know, this is the workflow. These are the things that, you know, you would probably figure out. And it would be a much easier discussion because, that developer can say, okay, give me the sources that you put together to build that thing. I want to implement it. And so you give that over. That way, they are helped. It's a faster help. They have less of a development burden. And hopefully, you know, if we stick to our own

guidelines, we make things more consistent and easier to use. So the idea is sort of making it so graphical prototyping is considerably easier where you can do that design work before you fully commit to writing all the code and hopefully produce better applications because of it. Absolutely. Absolutely. It's a much easier discussion at that point, right? Because the development burden is lowered. And not only that, designers have a much easier time building graphics. for something because they're just pulling components and putting them together rather than designing every icon, every label, every button, that's just way too much for us as well. And I think it's part of the reason why sometimes Plasma in general just does not deliver

major, major design changes. It's because the burden is so high for developers particularly, but I think for designers because we just have never had a very organized shop in the first place. Yeah, I think a lot of people kind of took note of that with the swap from Plasma 5 to Plasma 6. There was, I'm sure things did change, but it was a very, it was a very subtle shift. Yeah. Especially if you compare it to the last time it happened, going from 4 to 5. I think a lot of people kind of have the idea of 4 in their head and what,

was it? I've said this before. I think a lot of the opinions on KDE stem from the opinions they have with the first release of KDE4. Yeah. And actually, I participated a little bit as a commentator on KDE4 when it was being developed. And it was, I mean, if you think about it, again, it was a time when we were a smaller team delivering for a smaller audience in a very niche type of product and so the risk taking level was higher right like you want to work with people to impress and I know that the designer for KD for sorry for oxygen in plasma and they did a ton of work insane amounts of hours just spending and grinding and making sure that something works and it was very rewarding but at the same time not only was the design very

different in kd4 a lot of new technologies appeared in kde4 that you know put all together account amounted for a release that was not the best the most stable right and and we understand understood that. We knew that that was going to be the case. But I think at that time, the risk taking was easier. Right. And the cries for making a better, I think, you know, were not as loud as they could be today. So, but then at the same time, you know, going from five to six, we discussed this. We talked about, you know, what are our users expecting? What are the things that matter to them? What are, what are the points that, you know, she would focus on just being new for the sake of new or do we want to be stable and you know really like tackle all those pesky

bugs that make plasma crash and that really deter from the main experience which is to use the system and so i personally was more on the side of like let's do a redesign everyone i'll i'll make some graphics but i think i was convinced by many of the arguments that were provided and of course I'm just one guy, so, you know, the community spoke on this. And I think that their mindset was plasma is in so many places right now. It is recognized as probably the most popular desktop in the Linux world. And for that, to earn that place, you have to make some compromises. And one of those is you can't put breakages in the head.

hands of users. Right, right. And at the time between five and six, there was a lot of stuff that Breeze had not resolved. And not only that, back-end technologies were not the best. And so a lot of time needed to be spent on fixing that if you want to. And then if you think about it from just a mechanical perspective, adding more graphical work or U.S. work on top of all the bugs that are difficult to work on, it's just, it's makes the work cost exponentially higher.

And so with a small task force that we have, it's not that easy to say, please design me a new system. And so I think it's important. But yes, I think in many, like I said before at the beginning of our conversation, sometimes the perception of our users is, you know, it's quite different than what we think of.

And so for them, they're like, well, you know, five and six, what changed, right? Like, give me something. And, of course, I mentioned this to our teams as well. It's like, we want to be ready for those types of questions. We want to be ready with good answers because, you know, I'm sure that most users in the wild associate version number changes to major UI changes as well. So that was not the case in our side. But through that, we'll refine. breeze quite a bit. I think our system is quite stable. We have, you know, the most support, we made the move into Wayland faster than any other place. And so it's something that speaks to the resiliency of our developers and the focus that they have. And I think I just commend them on that.

But yes, it's difficult to explain this to, you know, anyone and say, sorry, we don't have a whole lot of flashy things to show you today. Well, yeah, the big, the big change is kind of the fact that things didn't change. Going from cute five to cute six without there being a big shift is actually a big shift in and of itself, really. Absolutely. I mean, you just don't see it as much. Yeah, for, for newer, these newer developers in our team, they had never experienced the process

of going from one major version to the next. And so you want to be attentive to that and understand that they are also experiencing some of these things for the first time and to mount so much work on them to figure out. I mean, the burnout is real. So I don't know how they do it, but it's humongous work.

And you would think that a volunteer organization doesn't spend that much time, but there's a core group of people here that are like 24, I don't know how it works, but they're always here. They're always working, and I'm so appreciative of what they do. So anyway, but that's one reason why we just simply did not go flashy desktop on 6th. But fingers crossed, if the design system and union are able to be executed before 7,

I would love it would be my dream to see a new style and not only a new style, but a new development platform if we can speak of that with union and design together well when we talk about a new style a new look what

this is probably a really big topic by itself what would you want to change and is the goal to radically shift things because I did want to get to the idea where people, I'm sure, you know, we've talked about the, the forum post, KDE looks old and outdated and people have brought up this idea many, many times before.

And I'm sure you've got plenty of thoughts on, on, like, plenty of thoughts on this. I think of, have you ever seen the, have you seen the picture of, um, a customer explains a swing they want to have developed? And then it's like what each of the different stakeholders think the customer is trying to explain, and then it's like what the customer actually wants at the end. I feel like a big part of KDE looks old and outdated is exactly that. They have this idea that they want something to change, but they don't actually know exactly what it is that they want to change. And the first thing comes to mind is it's an older design, therefore it looks old. Yeah, yes, this is a can of worms. But

the i think what is important to mention in in this regard is that users are right like users are okay in expressing their feelings about how they experience their systems and that if their systems are not helpful to them then they're not good systems and i think like i know that sometimes uh you know anybody that gets a little bit of criticism or or revision from an online nobody or like, you know, some random nicknames somewhere out there in the ether, it's difficult to say, to give validation to that, right? And to say, sure, you're right. Like, I'll do exactly as you say.

I struggle with that myself. So, like, but I think what in user experience, what is important is that you want to understand how users feel and why they feel that way. they may not be able to articulate that but the feeling is there their feeling is real and so how do you work with that so one of the things that i do is when i speak to people that you know come in the chat and say hey i want to you know i want you guys to change your whole desktop it's not great whatever it is okay let's talk about you know what are the areas where you feel the most friction what are the spaces where you know you want to do this and that and

and what's stopping you from doing it? Like, what is the rock in the shoe that you're talking about? And so they explain, of course, in their own terms or through social media, how they feel, whatever. Okay, I pay attention to that. In fact, I spend a great deal of time watching videos on YouTube that review plasma releases because that's the moment when a lot of people sort of take it to the internet to say, these are the things that could be better. But yeah, they will probably not be able to explain it to you

in a way that is developer-oriented or graphic or user experience-oriented and it's just kind of our work to sort of filter those types of comments and get to the main point. Then the other side of that question is, God feelings are also generalized perceptions. And you want to work with people in a way that their generalized perception is positive about your system. And so one of the things that are important to do is we want to take that feedback

and think of ways that you could apply a change. And then you want to think through that change and why people are saying that. Also something we do often is we try to check, is this a one-off type of comment or is it a generalized kind of company. Does one person feel that way and they just happen to be very loud about it? Or is there a group of people that totally agree with this and they should change that? Then in those cases, we try to balance it better. But at the same time, you know, again, we hit this wall often, which is basically, can you

do something right now with the tools that you have and the setup that you have? Or do you have, can you afford to ignore it or maybe wait? until something easier comes along the way or somebody submits a merge request. So you have to balance those questions. And I'm sure that, you know, not just our volunteer shop, but also companies experience this where you can't just do everything and execute everything any customer or user says. And so you have to filter those out.

But at least for myself, yes, there are people who definitely troll and they want to just, you know, gather attention by making negative comments about something. I personally try to filter for those, but also look at the core and basic understanding, the gut feeling that people are looking into and why they feel that way. Not only that, there's a third component of this,

which is the appearance of newness, which is a kind of, of a psychological perception, right? Like if we, for example, said, uh, think about it this way, Apple should have stuck to the, to the iPhone 4 design because it's been beloved so much, right? Sure. And all they need to do from then on until the end of time is just update the internals and keep the same UI. How would you feel about that in today's world, right? No matter how much you fight it, there is a feeling of this is old. And old is probably not as enticing. And so why do companies and groups and circles try to develop something new is because they

have goals in mind about, for example, attracting new users, make simplifying your interactions, tending to new modes of distribution. For example, like famously, KDE runs on the Steam Deck. KDE can run on phones, can run on TVs, and the TVs are not going to stay the same. The phones are not going to stay the same. And so do you want to tailor to that? And I think there is a, I struggle with this

when I want to hear from users, but I feel like there's always that feedback in our community when somebody says you should just can you make something new can you you know can we be more like macOS or whatever whatever the argument may be and we sort of jump in and dismiss that and say well you know we're not making changes just because macOS does it right it's enticing it's it's they have world class designers over there so like you know fantastic work um so it's enticing and and you feel a little bit like left behind. And so there's also that psychological aspect of changing things. And so, but sometimes

as much as I love change as a designer, I also have to filter for those things and think, is this person really looking for just a coat of paint or are they looking, are they trying to resolve a user experience workflow that just is broken and it's not working, right? And in user experience, there is a concept that says that well-designed interfaces tend to be perceived as more usable. So you may not have changed anything about the interaction in your UI, but because you change the color palette, people think, oh, this is better. This is cool.

Like, I like it. It seems much easier to use. And you could easily tell them, like, nothing has changed, right? And so the visceral reaction to some of these visual changes is really good and it's well perceived. So we want to generally work on stuff like that. And I know it's not the best argument for 100% of people, but it's a good argument that keeps things fresh. And in my mind, I think that with the design system, we would be able to attend to those types of discussions way easier than we do. today because somebody could just simply go to the design system and say, okay, I want my buttons

to be around now. So I'll just change them all, export, and present that to the developer, something we probably cannot do today. So that would be a long-winded answer for why changing things is important. There's two things I want to mention there. One, you mentioned how changing color palettes can make it feel like something has changed, even though really it hasn't actually been that much. And that just reminded me of a, I think it was a presentation about Counterstrike source where people were complaining about ping issues with servers and how everything felt really slow. And then one day the devs just decided to take your ping number and just divide it by two. And all of a sudden people felt like the game was suddenly so much better.

The ping was so much less lag. So there are like obviously that's, a little trick and that you probably shouldn't do that if there actually is an issue but yes you know taking it taking a user experience minded you can think numbers are psychological signifiers to people right so in fact there is there's a principle in user experience that says that you generally want to make users type less make users think less of you know like of steps in between actions so sorry

one thing I just heard my door but I think I have a packages showed up yeah okay I got you I got you

sorry about I just didn't leave it out there in the rain no no that makes sense especially if it's raining okay

so let me see where I was I at oh I was explaining like you know changes that are minimal but they have huge impact so

coming back to it so when you actually like make changes that are not truly making the experience better, but you signified that your, for example, your input lag was huge. Your ping time was huge. It's a problem of a UX perception in socially rather than real.

So, for example, a person that maybe at that company went and thought, hey, ping levels are just fine, but our numbers are rounded in such a way that it makes people think that you have the longest thing ever. And, you know, in the day where gamers actually love to have little overlays on their screen saying, you know, every move is being recorded and being tracked for efficiency, you know, those types of things matter. And so, yeah, absolutely.

You can go back and say, yeah, this problem is not on our systems. The problem is a social perception. And how can we make that social perception better? And you do it by changing things like a number. But yeah, the way people react is very gut feeling a lot of the times. If I can just put it in a simple way. And sometimes when you tailor to that gut feeling, it's a much easier discussion with people than to bring them down to the specifics.

And like I was saying before, like there's a call. concept in user experience called Good Enough, which basically means that you don't want to overburden your users with too much information that is not benefiting them. And so why is it that, for example, in a drop-down menu for the size of a window, we say small, medium, and large, rather than 200 by 600 pixels, 600 by 800? those are much harder things to parse and they require more thinking and they require less like more time making a decision and in a user experience world you want users to make faster decisions and so you want to simplify so if that worked out for that company then maybe that was the right

move but yeah it's kind of like a slight of hand like oh it would used to be two milliseconds now it's 1.5 like it's just it got better The other thing I wanted to say is sometimes designs how would I say it? You wrote up the idea of the iPhone 4 and sometimes a design becomes so old that it

feels like a it kind of feels new again or it feels timeless right? Like you look at like a 200 year old piano for example and you're like this is an incredibly made piece or, you know, a really old painting, or there's a, you know, you see a, someone has like a handmade table that their grandparents made, for example. And even though it is really old and doesn't fit in with modern design trends, you can still appreciate what that product is and what has been created there. And I feel like we're getting to a point where graphical interfaces have been around long enough,

that we're starting to see some of that sort of come around where these older designs, and maybe some of it's nostalgia, and that's also an important part to consider as well, but some of these older designs are actually starting to feel like they're a new, interesting thing again. I know a lot of people are talking about, like, how, you know, minimal design, maybe this has gone too far, and maybe there was something good about skemorphism, even if at the time people were like a bit weird about it. Yeah, well, so if this is, this is a common feeling in all of us, right, like that the old things are, or that there were better times before kind of thing. And yes, so yes, actually a lot of these, a lot of the people that do design tend to look into the past so that you can bring in some of the nostalgia in, because nostalgia is a feeling that you sometimes want to evoke in people, especially because nostalgia feels familiar. And so it's a lot easier, at least in your eye work, to look back at something that was done very effectively in the past and say, we can do that here too. in the present. So, yes, it is very important. And designers generally tend to think of that,

tend to like kind of wonder around, okay, what was good? Who is my audience? Are we working with like 30-year-olds, 40-year-olds? And if so, what was good for them and effective for them when they were younger, right? Like, for example, we've seen the research, we see this everywhere. We've seen the resurgence of the Walkman, for example. We've seen, for example, we've seen, for I was looking at recently at the Volkswagen ID bus, which is basically a retelling of the old Volkswagen SUV kind of van, a little bus. I was not aware of this one. Yeah, they've remade and it's now electric too.

And I've seen a few here in the U.S. So, but what is that tailoring to? That's tailoring to a familiar place that certain types of demographics, no about. out. And I'm telling you right now that in user experience, generally, demographics are really important. So understanding your audience is really important. So they tailor to that. But I would say that where the, let's say where the money is or where the big return on your development comes from is in making something that feels familiar, easier to use, yet it has a freshness to it. That makes it look enticing and easy to use.

And so you want to balance that out. In fact, actually, for example, in something as simple as icons, we still use the floppy disk as the icon that represents to save. We still, for example, use circular standing webcams to represent an actual webcam that's embedded on your screen now. So it's not the same. But yet, we familiarize with that. Or, for example, when we talk about Wi-Fi, we most times talk about it as some kind of signal, strength, antenna-looking radio bands. Why?

Because that's what it seems like. But if your computer is plugged in, you show a plug. And so you try to bring in some of that. When it comes to, for example, a retelling of design elements, like, for example, going from schemorphic design, into something like flat, well, that was kind of an overcorrection too, right? Because the designs for schimorphic were extremely detailed and beautiful, right? Like great at that. Very expensive.

Yeah, exactly. Two representative of the real world. And imagine the cost to the system, right? Because not only are you talking about just regular graphics, but you're talking about layers upon layers upon layers of just graphic work that needs to behave in a certain way and then how much how much weight or how many kilobytes or megabytes that one graphic is and then you put that in your system and it just feels like bloat and so not only that when you have to troubleshoot those types of graphics they tend to be very complex and so to drill down to the one graphic that's

causing your problem is much more complicated. And not only that, I think if you have a house where all your walls are covered by books, it will feel like you have nothing but books in your house, right? And so there is an element of clearing things out, cleaning and organizing and making room that feels very awesome in your hands. And so I think that designers at the time, and I'm telling you, flat design was not new when Apple put it on the iPhone, I think there have been other representations of that and minimalism has been around for many years. And so it's not a thing about like what you can, it felt like a lighter feeling in

your hands and you could actually understand flat design. Of course, some people went real crazy with flat design like Windows 8, right? And it was nothing but squares. But I think over time they learned from that and they represented a few other things in better ways. And I think they're now coming back to a little bit of the 3D, especially because they're backed up by stuff like design systems. So it's not so hard to make your icons or your designs complex because now it's backed up by a system that can act in ways that are predictable and it's easier to export complex things out. Well, you also have hardware that can better handle these more complex designs as well.

Like Vista, for example, Vista, if it had released five years later, I don't think it would have had half the complaints. Most of the issues of Vista were that people didn't have, like, it just wasn't common to have enough RAM to handle it. I mean, and Windows had to go around it, right, and tell users like, hey, your heart, had a hardware qualifier and to say, like, yeah, your machine is unfortunately very old, so you can't run this. And, you know, like, that's one thing that I love about Linux, which is just so flexible

and we really focus on efficiency. So stuff like this is generally not an issue on our side, although, you know, if you're careless, it can be. But, but yeah, like, so Windows, you know, I mean, their majority of most computers use Windows. if not, you know, come pre-installed. And so the push for a company this large to tailor to so many people at the same time is humongous, right? Like the pressure, just imagine the comments, the types of comments and the amount of comments that they get on their design. And so as a big old company, you always feel the pressure of like we need to deliver for the true mass market.

like Windows is on 90% of personal computers and so it's it's that much that's the level mm-hmm oh sorry just open the window and then the the the uh open the window and then the video chat just vanished for a second oh my gosh i can see you no it doesn't close the window or anything i'm using um right now i'm using neri it's a scrolling window manager i don't know if you've yeah i saw your video yeah okay Um, yes, so I usually have a, when I do these, I don't like to see my face when I'm talking, so I have a browser window over my face. So I just completely lost everything. Well, that's fine.

I completely forgot what you just had said before I got distracted. We were talking about Vista. Ah, yes, yes. So we've talked a number of times Actually, so before we get to that What would you like to see What are some big changes you would like to see happen As we go further along the Plasma 6 life cycle

And then five, six, seven years from now Whenever Plasma 7 ends up happening What would you hope the state of things to be in by that point? I'm hoping for a lot of commonality, like a lot of interactions that feel the same across our systems. That is, you know, building an ecosystem that is more seamless across form factors. I think this comes, you know, if I'm speaking purely UI, I think we definitely need to do much more work at bettering our layouts. And make, see, the, the struggle of plasma has always been how to provide as much functionality in the hands of users with the least interaction cost or the least annoyance to the users in their experience. And so you have to think more carefully about that. I think there has been waves at plasma where we've just taken anything that appears.

and without a whole lot of, you know, processing on the experience side. And that leads sometimes users to be overwhelmed by the amount of options that we provide. I am not saying by this that I expect KDE and plasma, you know, the whole ecosystem, to sort of become a minimalist system where you hide options because you don't trust your users, right? like that's not the angle what i'm speaking of is simplifying interactions and when you simplify interactions when you when you want to unburden your users from the cost of dealing with your system that leads to a lot of innovation in the in the ui space and so you want to tackle it the right way you don't want to think i just want to change the graphics no you want to think i

want to make users have an effective system and so that's a different discussion and most of the times it's what is where creative ideas are born when you have a set of constraints and a set of parameters that you have to build around and work with it so I think in five or six years I expect that the plasma will be more more the same in every form factor or at least looking and behaving the same but at the same time, I see that there will be quite new approaches to the desktop that we can tackle, and it'll be much easier. I don't have a whole lot of that in my brain today. I think I'm just thinking of mostly what we can do in terms of delivering our design system to build that

foundation that will propel us to a much easier design approach. But if it was me, I think we would definitely want to explore, you know, 3D spatial UIs. We want to definitely, you know, be in more devices, maybe with a light version that adapts more easily to a certain form factor. I mean, who knows? We could be in a watch in the future or in a home assistant, like the ones from Amazon with a screen or Google with a screen, and our system is there. Or even automotive, imagine that, you know, these days, a lot of people, for example, take cute libraries and they build UI for cars, well, how come Plasma couldn't be there and, you know, support certain aspects that are open out there.

I just see a whole lot of possibilities, but I don't know exactly today how much we would change the desktop. I think the desktop feels very familiar, but maybe we can throw a curveball out there at some point and just say, you know, try this new thing. I think most recently we've had a lot of discussions about tiled window managers and how we could execute that

and basically be effective at it because at the same time, I think, you know, there is a case to be made about tiling window managers that tailor to a very specific audience and they may not be quite as usable for the larger audience in your system. And so do you want to build a niche type of interaction or do you want to build something that's more broad? It depends.

But that's what I mean. I just want us to, I feel like today I have a brick and cement to build the shop. And maybe tomorrow I'll have a paintbrush. And it will look much better than it does today. Speaking of other form factors, I did have one of the people who was sort of involved in reviving Plasma Big Screen on, I think, a couple of months ago. And Plasma Big Screen is not new for anyone who's unaware of it. That's the smart TV version of Plasma.

It's just the shift to five to six, things didn't really happen. Yeah. People left the project. It kind of just got stuck back in five, and everyone kind of just forgot it existed for a while. So there are other form factors that do exist. like to see something like that actually become a more viable interface to use. And I hope that project goes well as well. Absolutely. In fact, I know who you're talking about. I don't remember their name, but I know that they have made huge strides on making the whole TV UI feel much more

like what you see in other paid systems, for example. And the results are beautiful. I mean, and I personally envision a time when we could just hand that developer components from our design system and be like, hey, here you go, apply these and it'll be the same as it does in the desktop on the phone and it looks just as good, if not better, right? But kudos to them. I mean, it's humongous work and the UI looks very pretty. Like, take the best, kind of like, uh, uh, skin for, uh, I don't know, like Plex and that's, that's Plasma TV today. So it's looking much better. Are you talked about sort of simplifying UI elements? And I know that there has been the removal of features, but these are more like settings, which are, there's a correct choice and a wrong choice

and you shouldn't have a situation where the user can just select the like there shouldn't be a situation where there's an option where there is just a wrong option for your system like that if that's an option that's available there should be something in the background that is sort of automating that away

that's not providing that setting there so as to not let the user put themselves into a broken configuration. Absolutely. So one of the biggest things that you want to be aware of in user experience is to avoid error, user error. So when you create user workflows, you want to think about how could a user mess this up? How can they go the wrong way? And if so, you want to actually correct for that and anticipate the problem and fix it in the workflow.

So, for example, a common example of this is when you have an option in your system, that when you turn it on, there's a warning about it. Or the system says, sorry, we can't do that. Like, for example, we've debated about this, but like in plasma, whenever you plug a USB device or some external device, sometimes the system may or. may not show you the system settings page for it. So, for example, if you unplug the, I'm just giving you a random example, but if I unplug a USB drive, then I go to system settings and I don't see the USB drive settings.

And so the debate is, do you want to show it and make it disabled, or do you want to always show the page or not show the page or show it on command? And I think the debate is out there, but those are one of the things that you want to avoid. Also, you want to think of warning messages. Like if your UI is sort of, you're selecting an option and suddenly that option gives you a warning,

I tend to see those as some sort of, like it's more work for the designer rather than for the user. So in those cases, for example, you want to say, okay, why is there a warning here? If the user wants to achieve a task, why would you want to show them a little stop sign and says, hey, watch out. Like, don't touch this. I think, again, going to pure gut feeling, I think a lot of users get turned off by warnings. And so they step away from the interaction and they're like, don't touch that, right?

In fact, for example, I had an example of this recently where we worked through this, but the greeter, the wizard, that appears when you first install plasma now that got developed, it had some elements there that kind of paragraphs that were telling you, like, if you do this, watch out, because this might happen. And I took those, and I commented about it, and I said, well, we cannot lead users into error. So maybe either we remove this option that we're calling out as a problem, or we make it in such a way that the feature doesn't interrupt the user workflow. But warnings basically are deterrents, and people feel like, you know, your system has thorns, you can't touch it because it's delicate. That's not the feeling that you want to convey to users.

You want to convey the feeling that this is a stable system, reliable. it works the same every time it's bug free well of course no system is bug free but definitely you want to generate that feeling so that people feel at home when they're using your system so you want to avoid

I'm not saying warnings are bad I'm just saying unnecessary warnings need to be like worked on a little more yeah unnecessary I think is the important part there because there are necessary warnings for example you change the resolution of your display

that inherently is going to create a situation where you can put yourself into a kind of broken setup if you go from a 4K screen and you set it down to, I don't know, 480P. Like that's inherently going to break things but you don't want to take away the user's ability to change the resolution of that display. Exactly.

And so it's more what happens after the change that you want to account for. So, for example, like in older systems, when you change your resolution, sometimes your windows were no longer invisible because they were somewhere down there in the non-visible pixels of the digital space. And you couldn't sometimes bring that window back to the center of your desktop. So, you know, that would be kind of for the developer to find those instances where you do not allow off-screen pixels. and you want to bring them back into view no matter what the arrangement is

because people may not necessarily want to replicate, they understand the screen is shrinking, therefore everything will be smaller or crammed, but you definitely don't want to remove things from view because that disrupts the user's ability to continue their work. In fact, I remember fondly when KDE, and I'm talking years ago, you used to crash often and you would lose your title bars.

And so now you have relied only on key combos to move your screen. I mean, how accessible is that, right? And so those things are kind of like, you know, you want to build for resilience that cannot be a situation where you lose the ability to move your windows, right? And I think we've solved that. But back in the day, that would happen often. And especially when you installed proprietary graphics drivers that didn't play well with X, 11.

So anyway, but that's long gone in my mind. I think it's much better today. But those are the things that you really want to pay attention to you. What I mean by that is, yes, the system can tell you that there are problems or that they may be warning. There are things that you want to be careful to do. But on the other side, you want to solve so that there is no, like, there is a way. way out or a way to avoid the error. That's a very, very specific user experience task.

You want to avoid error and you want to move people, avoid people going in circles and loops in interaction. Fair enough. Fair enough. So one thing we haven't touched on, and I do think is important because a lot of people do really care about it, that is where does, you know, you know, you know, you know, you know, user theming come into play with this? Because obviously the main focus of KDE is Breeze

and then obviously the Breeze Dark variant as well. But user theming is also something that has always been present and by all accounts seems like it is always going to be present. So with design system changes, with improvements to that, where does these custom themes fit into play here? Yeah. So it's likely that they will evolve in that they may not necessarily be exactly the way they're done today. But for example, for icons, this is something that I am told very consistently is that we follow the free desktop standard for icons.

And so we name them in a certain way. They work in a certain way. and people who build icon themes for plasma follow this standard because it's easy and they can just easily swap an icon for another. I do not believe that's going to go away, but I do think that there might be efficiencies gained by using a design system where you can actually execute a design change in just our graphical components and then you hand over that to someone. Or you can actually, in a design system, there is a, I don't know if you've ever heard of atomic design, but basically what you do is you separate the layers of your design between the most basic thing to a bigger thing than to a button, then a button in a form, then a form, whatever, right?

It gets bigger than from that. If you have the ability to go to the design system and tackle the foundations, and you change type, foundations is composed of typography, spacings, shadows, and blurs, and buttons, no, wait, hold on. Well, let me just name those for now. But there's like five or six of elements of the foundations. But when you change those, pretty much you've changed the way that your system works. Oh, and colors, my bad.

So the color palettes. So if you change all that, your systems has changed. So now you've changed anything that deals with the foundational elements of your system and you can just export just as easily or replicate that into plasma. If you were to change, for example, something a little more complex, like a button, a slider, progress bar, things like that. And you want to style them in a certain way. You can also go to the design system and just find the most primitive version of that item,

change it however you like, and then you will apply all of our colors or your own set of colors, and you can just export the same way. But I foresee maybe changes in the workflow, changes where the designs change. Like you go to Pampot rather than tackling the code. but it seems to me that the ability to theme the desktop will probably be enhanced not only by the design system but also union because union is likely going to be able to ingest CSS and it may have better support for SVG changes and so the simplification of it would be much easier to understand not only that I am proposing through the design system

that we expand the range of color variables that we have. Right now, we don't have as many colors named out. But if you change all of the, if you expand that and give them easy names, it is much easier to change and apply than in other instances. So today, I think we're just exposing, at least in the colors system settings page, we're exposing just basically what the system uses underneath to call. like the window color, the border color, and things like that. And so those names are not always easy to understand.

So we may see efficiencies gain there. And I can see that in my mind, I feel like we're going to simplify the way that users can contribute to theming in Plasma. But do I know exactly how today? I don't think so. but from my birdside view into the design system and what I understand about union is it might actually make it easier. So you feel like ultimately it's probably going to break existing workflows but simplify the process long term so that it's easier to do the theming in general? I think that there is a world where we may be able to support both old and new approaches.

I think plasma is one of those systems where our team is really good at, you know, translating and keeping support for old work. So I wouldn't, I wouldn't say that, yeah, we'll break yours in favor of the new thing. But I will say that maybe as people adapt to the, to the optimized ways of building theming, that they will naturally. abandoned previous versions and kind of, you know, move them forward. I think this was one of the difficult things that we experienced during 4 and 5, right? Plasma 4, KD 4 and 5, which is basically the fact that that we sort of left a few people

behind and a few, you know, graphical engines like, I can't even remember. Like, I remember one called Domino that I used a lot, just simply didn't work. And they could not port any of their styling into Plasma 5. So it's known to happen. We want to minimize that. I think that I'm sure that if we bring this to the table, that there will be a lot of good discussion about what we should support versus whatnot. And I'm sure that, as we always do, whatever we decide, we publish it, we explain it, we try to give a good reason for that.

Sure, there may not be 100% of the people satisfied with that, but taking all the, I think that our team does a very good job at thinking widely. And when we come up with a solution, it's something that generally is well thought out. And we understand the risk and we understand that there may be people who simply don't accept those changes. And it's tough. But yes, I imagine a world where we support both, but I believe that there may be people who see the benefits of the new thing

and they'll naturally move and feel that it's an easier transition than whatever we did from four to five. Okay. Do you think there's anything we haven't really touched on yet that we probably should get to? Well, I can tell you a couple of things. Thanks. So recently we had our Academy conference in Berlin. This was the second year that I presented on the design system and the work that we did. And this year, unlike the other years, I released four items for the desktop as it works today in Breeze, and then one for the design system. So for the for the desktop we released a collection of icons like what I mentioned before

about 8,000 icons that get plugged in and they turn into 20,000 but a whole new set of icons more streamlined shapes and we released it to make sure that people can submit bug reports on them and hopefully you like the new looks at least it's a small thing but it's a very pretty thing Where can I find those if I can just show them? Yeah, you can go to my GitLab. If you go to invent.cari.org and then you put slash and detocene, like my username, you'll see a repo called Ocean, Plasma Ocean or Ocean Design, and you can copy those down, clone them for yourself. We also released a color scheme based on the designs that we have in the ocean design.

system. Now, do you have to be careful, though? I have to caveat this with the fact that we are applying ocean design colors to an older Bree style desktop. And so it may not look perfect, but once we have the rest of the pieces in place, it will feel it right at home. But you can at least experience what kind of color palette, the tonality that we're going for. And then also, So I released one for light mode and for dark mode. And the last thing that we released was a plasma style, which basically styles your task bar, your widgets on the screen, your kickoff and all the task manager pop-ups that you see, the notifications, basically anything that's sort of the shell in the system.

And yeah, you can experience that. Of course, it has some bugs and we're happy to hear from you about. the bugs, but if you want to install it and give it a spin and see how things go, we created a few things. We're still missing application icons. They're colorful and they require more time, more thinking. But we're little by little. I think we have something like 15 application icons built and people are jumping in to build more and basically retell the story of some of our icons, but all the monochrome icons that you see in the Plasma desktop are now replaced with that new system and you're welcome to use it. And additional to that, if you want to jump

into the world of pen pod and design systems and SVG design, you can download the penpot library from the ocean design system that I just updated today, by the way, with new stuff and people can start basically playing with it and see how they can execute some designs. Awesome. I feel like this was a good episode overall. I hope people, I guess, learnt something about how design actually happens within KDE, how ideas form, how processes are actually done, and whilst there might be issues, because all software is going to have issues, it's not like developers are just throwing things at the wall and just seeing what sticks. There actually is a process that happens here, and there are people that do really care about design.

Absolutely. Far from that reality, you know, our team is thoughtful. Our team is, they really like hunker down and just really work on it. I mean, I was just in Gratz, Austria, earlier this year for our plasma sprint. And, you know, I was just there, probably the only graphic designer at that meeting and everybody else was working so hard on just ironing away all these bugs and implementing new things and I was just making graphics. So kudos to them. I think that they do a fantastic job

and I couldn't be prouder of what people do at Plasma. Okay. We probably should have mentioned this at the start, but we're here now, so now it's as good as time as I need to mention it. There is the KDE fundraiser also happening. So if you would like to go support the project and you're not a developer, you're not a designer,

you don't want to work on documentation, this is the next best way to do so. Yeah. I mean, this is how we fund a lot of our activities, right? Whatever keeps us running, we work with. Sometimes we even hire additional staff

that can help us with very specific tasks. And that money comes directly from fundraising. Not only that, but there are times when, you know, we need a venue to work and meet for our sprints, for our get-togethers, for our academy conference,

and all of that requires, you know, money, unfortunately. But at the same time, we are very grateful to everybody that's contributed to us. I mean, last year we broke records on our fundraising. Yeah, 100,000 years during December. Yeah, so proud of that. Everybody that worked on it. And, you know, people in the fundraising team have done an excellent job. And not only that, I think people who donated to Plasma,

they realize very quickly what the value is. I was once a board member for KDE and I know that we use our money effectively and we are supposed to spend it on activities that basically make plasma grow. So I'm just, I think it's whatever you submit to us is in good hands. Awesome.

I guess if people want to get involved with design or they want to see the work you're doing, can they go where they can, where can they find all this stuff? Yeah, absolutely. So if you just actually, if you just go on Google and look for KDE visual design, you will very likely end up on our Get Started page. And our Get Started page contains all the elements that we can explain right now about how to get involved in design for Plasma.

Additional to that, we have links to our Matrix channel where you actually can go into the VDG channel and basically ask any questions related to design. or if you want to contribute, tell us what you want to do and what your skills are and where you feel like you would be our best help and we'll get you started. And there's a few people there that will do their best and guide you through. But I would say the get started design wiki is a very good place to understand the spectrum of where we work. And also most recently we put together a wiki for the ocean design system. And again, it's evolving.

It's early days. But if you want to learn about ocean and help with the design system, that's also available there too. Okay. Nothing else you want to mention? We can sign off. I think it's been a great conversation. Thank you so much, Rodia.

A pleasure to be with you. Yeah, it was a pleasure to meet you. And I'm more than happy to have another one of these in the future. If you want to talk, I don't know when oceans further along or whatever else happens to come up. Oh, absolutely. I mean, I'm speaking about user experience today on Plasma, but user experience is very universal, so there may be many other subjects that, you know, apply to this. I'm happy to discuss, yeah.

Great. No other links you want to direct people to? I think this would be, you know, the main ones for visual design at Plasma, but there is also KDE.org for our, to learn about our project. There is also, you know, if you go to Documents.kid.org, then you can also learn about anything developer-oriented and design and just really dig deep into our APIs and our variables and all the things we use to build our systems. So I think we attract a lot of that audience, so I'm happy to send you there. But kd.org is a main space for that.

Okay. I guess I'll do my outro and then we'll sign off. All right. Sounds good. Okay, so my main channel is Brodie Robertson. I do Linux videos there six-ish days a week. Sometimes I upload a stream as well. So check that out. Lately, I probably should do something else, but lately I've been doing a lot of cosmic bug testing. So if you want to see me go around finding really dumb bugs in Cosmic, go check that out. It's getting better. It's coming along really well, but it's still a beta. So there's still a lot of fun things to break in it. If you want to check up my gaming stuff, I stream over on Twitch, Broody on games, also YouTube, same name. Right now I'm playing through Yakuza 6 and Silk Song. And if you're watching the video version, this, you can find the audio version on basically every podcast platform.

Just search Tech Over T. It's on Spotify with video as well. But the other video is on YouTube, Tech Over T. I'll give you the final word. How do you want to sign us off? Oh, just thanks everybody for the opportunity, especially to speak to you, Brody. And also to talk to people about design in open source communities, which is something so cool that you can democratize the way that design is made.

So I'm grateful for that and for the platform. But other than that, I just want to just thank everybody that supports Plasma. We're turning 30 next year. And we are going strong. We're happy for all the support that we have. I think that would be it for me. Okay. I like the message.