 I gave you the presenter role and yeah, exactly on time, let's welcome Nicolò with his presentation. Take it away. Okay, thank you. So, hi everyone. And as you can see, this is my presentation and that's pretty much it because this is the only slide. But before we get into it, the actual slide, let me say a few words about myself. I am Nicolò Venerandi, the leader of the consistency goal as you might know at this point. And I also have like a YouTube channel where I post stuff about KDE which you can find by Googling Nicolò Vey on YouTube. And I'm also in the VDG and promo rooms for, you know, promotion stuff and that kind of the sort of stuff. And I want to share with you a video that I've done regarding consistency. It was published yesterday on my channel. So just give me a second like this and we should all see it together. Let's try it. Okay, and that was it. Let me actually get back to the presentation. And I've seen some people saying, let's hope that YouTube doesn't block the music but actually this music is done by a KDE contributor. So it comes from KDE itself and I think that's really cool. So I've said that this is my only slide but that's actually a live because there's a second slide. Let me get to that one. It's completely empty. So I thought that it didn't count. So the first thing that I wanted to talk about mainly about consistency is design consistency or how do we design something that's as complex as a desktop while keeping things consistent pretty much. So what we do is that we get to the whiteboard and we get a pen like this. Let me try it out. And of course it broke just before. Just give me a second. I know this. Hello. I'm back. I hope you hear me. Of course everything breaks when you actually try to use it but still high. And so as I was saying we get to the drawing board and what we try to do is draw something that should represent our desktop environment while not actually drawing anything from the desktop environment. I'll give you an example. So something that we might want to draw is like this thing. Like this. And this could potentially be anything of course. And this is the most general concept that we have that should be applied everywhere in the desktop. And mostly what we get from this is around the corners. So we know that our design is going to have rounded corners regardless of what it's applied to. And if we decide how much rounded should the corners be, then that is going to be the design that's going to be used everywhere. So this is the most general idea that we can draw on a whiteboard without actually going into the actual use cases. And then we can decide to take that concept, make it a bit bigger so you can actually say it like this. And then try to apply to something a bit more specific like windows or outlets could be anything still at this point. So of course, if it's windows, we might want to have a title, some buttons, some other buttons. And usually at the top you have like the most general buttons regarding the content. Whereas in the content you have the actions themselves and the content of course. So we might want to take all of the title information about the thing itself and general actions and enclose them in a separated design element, which is going to be a header like this. And right now we still don't know what this header is going to be used for. It could be anything, but of course if we have a header, we might as well get a footer because we might want to have some actions and information that are at the bottom, such as the status bar or in fonts actions that are actually closer to the thumb of the user. So we also get a footer. And what we've seen is that it's also really useful to have a sidebar so that you have a central content, but also some side content that helps you understand or navigate through the central content. So like this. And then you have actual content here. So this is the most general idea I could think of for the environment. And the question is, where do we use this? And before the consensus goal, every element had like its own design, but now this simple design is used pretty much everywhere. If you look at all outlets, they use this design. Or if you go look at, I don't know, not outlets, but windows. We now use this design with the header footer of the sidebar. There are still some tweaking to be done in application like Dolphin where the sidebar is either not divided by the line on the right or inside of a frame. So that's something we are working on. But the general idea is this one. And we also use it in dialogues. Or the stuff you call when you actually pop up overlay sheets. Sorry, they're called overlay sheets in Kuri Gami. So you've got the thing that pops up and it has the header, the footer and the content. It does not have a sidebar yet, but it's mostly because it's smaller than other components. So usually we don't need it. So this is the first component that we can think of. And then we might say, sure, this is cool, and we can draw a lot of things. But when you actually draw the content, you might want to have some preferred kind of content which could be, I don't know, clicked, focused, hovered. There are many stuff that should indicate that the user is interacting with that specific type, smaller content in the general content window. So what we've done is that we got back to our four lines with random corners. And we said, okay, so we want the content that the user is interacting with to be more visible. So we are going to give it a different color and which is the highlight color, which is blue. Of course, you can change it if you don't like blue for any reason. I won't say that blue is the best color, but it is. So please don't. And we're going to have a solid blue outline plus a bit of transparency in the inside so that it pops up even more if it was just the outline wouldn't be so visible. And now you have here like the icon that you're selecting or stuff like that. And just like this, we have a design for Windows or stuff like that and a design for content that the user is interacting with or stuff like that. Now, there's an issue with this. If you actually try to make this in the panel, as you know, Plasma has a, I hope you know Plasma has a panel. So you have like an icon, another icon, another icon, another icon, the Plasma icon plus the task manager. You mount to that user. Things like that. No, because we actually come to this. So we can just throw it like this. And so I'm not throwing particularly pretty, but and the issue is that it doesn't look good. And the reason it doesn't look good is that we've got a frame, which is the panel and inside of it that. And inside of it, there's even another inner frame. I hope everything is going right with the presentation. And inside of it, there's another frame, which is the highlight. So this is an issue. And it's why we designed another kind of highlight, which is this one. So the outer line became a strong blue line at the top. And then there's transparent blueish in the center. And just like this, we have designed a new highlight like this, which fits much better into smaller flames. But now we have an issue. We started off with a cool concept of how to indicate that content is being highlighted. And now we have two. So when do we use one? And when do we use the other? So what we need to do right now is step back and think, when do we use this one? And when do you use this one? And the best idea to discriminate between these two is to say, OK, this one is going to the left. It's going to be used when there's a big frame and we're selecting just one content inside a big frame. That's the one in the right. It is to be used when there's a smaller frame that has a side near the highlight. The highlight is going to attach visually using this blue line to that side and the highlight element, which looks simply prettier. And that's very fair. We now have an highlight as well. And now that we have two components like this, we can move on and actually apply them. And here we have the first success story, applets. During the first two years of consistency, we completely redesigned pretty much all applets. So if we think that, you know, we've just decided that the general look is going to be this one. So let's throw it as an example. And then we might want to have a sidebar. So let's add the sidebar as well. And of course, the header. So let's add that one. The header is going to have a title, some actions, some minor actions. And then there's going to be the content like this. And maybe at least to the left, because why not? And maybe one of the content is going to be highlighted. So it will have the consistent highlighted we decided on. And maybe also release will be highlighted. So it will be like this. And if you look at this, if you think this is the highlight, the content, I don't know. I didn't throw it perfectly, but this is the calendar. This is exactly the design of the calendar. If you open it up, the newest, we just redesigned it. So of course, this is not what we've done when we decided to redesign the calendar. But that's the general idea behind it. Heather, content, highlights. And before the redesign, it was not like that. The highlight was, didn't have on the corners. It was just filled and there was no sidebar, no heather, stuff like that. It was inconsistent with the rest of the highlights. But now it is. And if we draw another one, this time, I don't know, a bit taller and wider. And at rounded corners, we can have the heather, the title, actions, maybe a footer with other actions. And this is pretty much all widgets of the system tree. The system tree looks like this. There's usually also a list with one element being highlighted. And that's, I don't know, sound applet or the volume one. I just said the same thing. I meant Wi-Fi, sorry. Or the clipboard or et cetera, I could go on. So we took applets. We took some general concept that we had and we applied them for all applets. And now there are consistency, just like magic. But of course, it's very pretty when things go well, but they can also go wrong. So let's start actually a failure, sorry, of one time where we screwed up. And that is views. Sorry. Views. And specifically switching between them. So let's take an example application that we decided was going to have this look. And let's say, okay, so as an application maker, I want to switch between views. And the heather, as I said. And maybe a footer now, let's stay without the footer right now. But we have some content. And I want to implement something to switch pages. As an example, if you have a clock, you want to switch between the alarm pages, the time zone settings, stuff like that. Switch between them. That's very simple. And what we've thought about is we can do something like making a list of all views in the heather. And then you can just switch between them. And the current heather is going to be highlighted with the all rounded corners highlight, which makes sense. You have the bigger frame, which is the heather. And inside of it, the smaller frame, which is the selected view. And this is a possible design. Let's call it A. And then there's also another possible design. Let's make this one with rounded corners. Sorry. These rounded corners are not that pretty. And same thing as before, but now we are actually on the phone. And when you are on the phone, you want actions to be close to the user. So we thought, OK, so the views need to be on a footer because that's closer to the user thumb. So same thing. And we put the list of views. But now there's a problem. The footer has just the views, which means that it's a frame with a smaller frame inside of it, which would be the highlight. So we need to use the other one. So not this look, but the other look, which is the one like this. Is it working like this? And this is option B. They're both valid options. And we basically need to choose whether we're going to use this highlight or this one. And at the end, like we discussed a lot and eventually B1. And this is the current design of the component that manages swiping between views, which is called a swipe navigator, sorry. And then we actually take a query application and say, OK, so we have this component, which is the view navigator, which we just designed and looks good. And let's go see how it's actually used because in theory we have this flow chart, which is we design something and to fast for the design. And then we actually do a component like this and finally we use it. So in this case, the design part of it was very confused because there was no clear consensus. And even in the MR that introduced the swipe navigator, there were some criticism. But still, we introduced a component. Next step, we need to use it. If you actually go to see plasma wire applications like the clock, you will see that they have the views represented by three icons, three as an example icons with labels under them. And in order to show that they're active, they don't use our swipe navigator. They use a different color. And they say, OK, you know that this is the active view because it's blue instead of gray, which makes sense. It was a possibility. And problem is, it's not the component that we've just designed like five minutes ago. So what happened is that the component that we've done didn't fit the needs of the people actually making apps. And that's a big issue. And I think the big issue here is that we left with a confused design state because we didn't discuss enough even with the people that were going to create the apps using the component. And the result is that those people didn't use the component that we had just created for them. And more importantly, they have decided to show that a view is active using a different color for the text and the icon. And if you go back to the three kind of highlights that we discussed, which was this one and then this one, in no way did we say, sure, let's also change the color of the icon and of the text. That's something that was not discussed. And surely it was not in the mock-ups and stuff. So when it actually came down after all of this discussion to actually implementing something, what we implemented is completely different to the components we have and what we've discussed. And this is not to say that app makers got this wrong. Obviously they didn't get it wrong. If they use this look, it means that the look that we had designed for them didn't fit them. And that's an issue on our side. So what we can do regarding this is go back to the whiteboard, fetch those contributors of application that should be using this component and tell them, OK, let's try to figure something together that both is pretty for your applications and also works, you know, actually works and also fits our consistent design idea that we've got since the beginning, which is having these two kind of highlights. And that's pretty much it for this Web Navigator. So this is an issue that we are working on because it's not nice to only say what we've done right. Let's also say what we've done wrong. So next topic is what we can do, not just to have some design consistency, but also to have code consistency. And my main takeaway here is components. I got to say that I will not use big blue, but as a way to make art from now on. OK, components. And the thing is that when we do something that we realize could be used in many parts, we should do a component that will make it actually able to be used multiple times. And let's see a couple of examples where we got this right and a couple of examples when we got this wrong. So the first example of us getting it right is the hamburger menu, which has just recently landed into plasma hamburger. And that is we have this issue, which is KDE has some complex applications, even simple application like PDF viewer or file manager are actually very complex. We need a way to present it so that it's consistent and easy for the user. And we've done the hamburger menu, which is like adaptive. So depending on what you have on your toolbar, we change it, we change the content of the hamburger menu. And it also allows to hide and show the menu bar and it also allows to look through all applications. So it empowers the user to actually have a simple layout by default, but also being able to use all functionalities of your application. And it's a component that can be used anywhere on QWidget's applications. Of course, we cannot like expect third-party applications to like this, like adapt our components like it won't happen, but we can do our best to be consistent throughout our vision. Another example, if the big button lets me draw it, is the HUD, which is that very new component that pops up when you control Alt high. And it's basically a search box when you actually search through the actions. And it solves exactly the same issue as before. But complex application, we need to break it down in an easy way for the user and we let the user search between the actions. And that's really useful. And this component can be used everywhere in QWidget's applications. And the third one, which I actually forgot, sorry, which I had forgotten about is the expandable tool tips, which is even newer, I think, I saw it in the last blog post from Nate yesterday. And what this does is basically you hover an element, you will get a small tool tip saying what that element is, and then press Shift to learn more. And you press Shift, you get a bigger pop-up saying, okay, this element is to be used for X, it works like Y, and so on. And again, that's because we have complex application that we need to break down in a simple way to the user. So if a user doesn't recognize an icon, just move the mouse over it, wait for the tool tip, and then press Shift to see all the content in the tool tip. And this is consistent throughout KDE application. So this we've done right. So as for things we've done wrong, of course, that's why Navigator goes into that list. And it goes into that list because this time we actually have the component. The problem is that apps are not using it. So that's an issue. And another one is Chats like this. And the issue with chat is that we are currently working on at least three or four chat applications. And if you look at them, chat bubbles, as an example, they all are different. And that's very annoying because you're doing the same thing with the same concept, displaying messages, and they all behave differently. What we should do is try to do a component like a chat bubble as an example that can be used throughout KDE chat applications. And that would make sense. It's just an idea just to represent the bad side of it. There's the good side and bad side. Of course, it's more difficult. It will take more effort to do it, but maybe at the end it will be worth it. And regarding components, I want you to say that there's a billion-dollar mistake that was introduced in computers that killed consistency, and that is the control C and control V shortcuts. Because now every time that you want a component that's from another application, you just copy paste, make it work, and that's it. And what you do in that way, you introduce redundancy in the code, and if you change your component, it's going to be different from the one you just copy pasted from, which means that different applications will have the same design elements, maybe copying a bit from each other, but they will be fundamentally different. And that kills consistency as a whole. How much time do I have left? And next thing is wallpapers. So let's actually type down wallpapers. And this is the final point, and then I'm done. And the thing is wallpapers, you might say, yeah, sure, there's just something that stays in the background and should be pretty enough to ignore it. They're not, because they also, from a promotional point of view, give a feel to your desktop. So if we go from one style of wallpapers to a completely different one, we lose that look and consistency. And that's why pretty much all Plasma 5 wallpapers are all based on this simple design element, which is the triangle. If you look at all of them, they're all made from triangle. Except one that's hexagons, but we don't talk about that one. So triangles everywhere, and that was our look and feel. And it pretty much roughly stayed the same throughout Plasma 5. But now we actually want to change our look because once in a while it's worth it. And we are doing a wallpaper contest for Plasma 5.23. So stay tuned, because in a few days we will announce on our Twitter and social media that there will be a wallpaper contest where everyone will be able to send their own wallpapers and maybe be selected for Plasma 5.23. There will be three winners that will get three months free of Blender Cloud, which is both a learning tool and also is full of assets to learn more about 3D rendering. So it's a big opportunity for artists to expand their knowledge. So if you're an artist and you want to characterize look and feel of wallpapers, this is something that might interest you. And that was actually pretty much it. So let's delete everything and say the final thing, which is... Boas... Ion... Okay. Hello. Hello, Nicolas. So we have two questions for now. So the first one is more like a comment, but also a question from Felipe. It's about talking about components. We should definitely have a kirigami.settings page or something like that. Yes, I totally agree. And it's never enough components in my opinion. Someone will disagree, especially those that have to maintain those components. But if you have a specific idea of either how it should look or behave, then try to write it down. There's the HIG documenting those sort of stuff. So that's something that can get you started. And then you can actually try to contact like either VDG or trying to find a developer if you don't know how to implement it in QML for kirigami. And if you know how to implement it, then we can just discuss it and then you can get started. Okay. Thanks. So there is another question from Marco asking, are there cases where there is too much consistency? For example, cases where things are showed up, are showed upon a visual model that doesn't completely fit and become confusing, how to spot them? So yes, there is, which is something that I don't usually talk about for reasons. And as a practical example of it, if you open up kickoff right now, bottom left, you will see that it has a blue line to indicate that it's active. And then next to it, there's the task manager where you have the top line, there's also a blue background over it. And the reason is that it would be, in my opinion, very confusing to have both kickoff open with that highlight and the task manager with your open window with highlight because the highlight should indicate the one content you're interacting with and instead it's true or something like that. It simply doesn't look good, which doesn't mean that we won't do it in the future. I think that Marco himself proposed to do it. It would be fair, but it's just an example to show that sometimes it might be an issue to use the same exact thing everywhere. And of course, the real question is, when do we spot those cases? And it's not easy at all. And there, of course, isn't just one answer for everything. And we need to go case by case and, of course, try to ask to actual users, hey, this is our design, can you navigate through it or does this consistent UI element confuse you? That's the best I can think of. Okay. There are no other questions right now. Are there any, I guess there are several buffs going, which will be during the next days. Do you remember some specific dates, something you want to advertise even more? Right now, actually, no, because I haven't yet set up the consistency buff because I'm a terrible goalkeeper. But except for that, the actual date will pop up shortly, I think, and then we'll have a nice buff. So stay tuned. I think that buffs are mostly for people that are very interesting in the topic. If you go to the buff page and you press F5 tomorrow, it should be there.