 Welcome to the Jenkins user experience special interest group. It's the 16th of February 2022. Thanks for being here. So topics that I see on the agenda weekly status, an issue that Daniel Beck raised about image removal and existing plugins. Then we've had good sessions with young young and Tim sharing ongoing UI improvements. Uli added prism for source code highlighting and font awesome and code coverage plugin. Yeah, would you be okay if I moved UI improvements to the end so that we've got the most time available there. Okay, and Uli, are you okay if I do it that way. That's fine. Great. Okay. Any other topics that need to go on our agenda today. Okay, then first topic 235 three, the 2.335 weekly status. As far as I understand the build is in progress. I've seen entries written to tags, written to the or not tags artifacts written to Artifactory. I haven't run the release checklist to be sure that all the parts and pieces are done. This is the one that switches the Linux installer to system D from system five in it to system D that's not a you. There's nothing per se, but it is user experience and so I'm using that as the excuse to note it here. I intend to blog about that. Because I think it's a big deal. And I've got to make an update to the changelog. Any questions on 2.335. The next topic then was there was a concern I saw from Daniel Beck in terms of the image removal the removal of icons may break some long existing plugins. I wanted to get, get input from people in the UX is there something we should do about this. How would how would we approach it, etc. Wouldn't be the easiest thing to file a bug report and fix the plug in. So, I don't see a real problem with this, because, you know, I think we need to go forward with the UI, and this means that we will break things. So, if something is not really working yet, we can provide a pull request and these pull requests are quite easy. Maybe just a different URL for the images. I think we can go on. Sorry. And I think one of the things kind of going forward is plugins or want to get their icons anyway. If they want to fit in with the new style of Jenkins icons sell probably update by themselves shouldn't be too much of an issue. It's just down to removing all the images. Just in case team your make is not the expected one, I think. Yeah, we're not hearing. Sorry, I'm not hearing you. I get some hints that you're saying something. Try that. Yes, much better. I'm just having a nightmare with my headphones. Maybe that works now. I'm just saying that he the PR he raised on something only affected like two plugins. Okay. Yeah, I thought it was over the top the comment. Okay. All right. Well, so, so that it sounds like the consensus is then well or Vadaq you had a comment before we go on. Yeah, just about the response there that the pull requests are easy and things like this. I agree completely with that. My concern is mainly for private plugins. There are a lot of user of Jenkins that are implementing their own plugins. And in that case, they do not have the knowledge about what you know, in terms of what is easy, what they have to do and these kind of things. So it could be a bit more painful to do for them, the different update that are required there. So is it possible to have separate plugin with the legacy icon with the good links and these kind of things so that they can keep using their own private plugin with that legacy adapter transformer plugin in a sense. I'm not sure how easy it would work because the plugins, the images that are being removed from core, not from plugins. And they're coming from the core resource path. There is a migration guide published for any of these on how to adapt. It should be self-discovery there normally in a sense that if I imagine I have a private plugin, I'm using some links that are no longer available in the new version of Jenkins. Will I get the information that there is a migration guide somewhere like some 404 page with information. Hey, you can look at that migration path, this kind of thing or it just you have to guess you have to create an issue to look for the things in the website. Just thinking about the developer experience there as well. Yeah, it's just Jenkins.io and there'll be an LTS upgrade guide as well I assume. Yeah, see, and we usually do the LTS upgrade guide to focus towards users so this one might be somewhat of an exception then if we put it in the LTS upgrade guide saying hey look, this, this is part of UI modernization and go help modernize your plug your private plugins. Yeah, so users of private plugins may need to update their image location. Okay, so fine. Forget about what I said. That's good. Go ahead to you could you could possibly add in a hook for like what we had said. If it's one of those removed ones then show a special image or something. But it had to be quite small and probably still return 404 and linked but you wouldn't be able to link it or anything. It just opened the discussion if you had some thought that it was easy to do or things like that if it's not the case not all the effort I would say. I don't think so really. But thanks for raising it. Okay. So, so good insight so I think I'm back to the consensus being, we would prefer to have plugin maintainers repair it, make the changes, and use, use the migration guide as their as their guidance on how to do it. Is there a way that I could search through the Jenkins open source code base and see the plugins that need migration. I assume there is right that we could that that's a searchable thing. Alex already handled most of it. Oh, he did. Okay, all right. So for the main those two PRs was the main one that removed 300 icons or whatever, and Alex updated about 50 plugins or seven got the more released. And then there was the one that you saw that Daniel commented on, which affects like two plugins. Okay, so, so the the open source piece the non private plugins has has already been done and, and yes it was a known known thing it could be done. Thanks. Yeah, and there may be a couple of edge cases I think Alex has done a few follow up since it's released but the big majority of them was handled and before it was released. Okay. All right. I think we're back to the consensus is, let's continue submitting pull requests and documenting and point to the migration guide for plugins with icon issues with old icons and point to the migration guide. Did I, is that a fair enough statement. Yeah. Okay, great. The next topic then was prism for source code highlighting Uli. Do you want me to stop sharing my screen and we'll let you share your screen to show or. Yeah, maybe that's the best thing. It's just a minute or two though but it's easier to see it on screen, I think. Okay, so let me stop sharing. There is the stop share there it is okay got it. And let's So last year, I think I introduced the new plugin that can, yeah, highlight source code and basically, sorry. I'm using it in the warnings plugin to render the source code. So here is one example in in one of my warnings plugin fuse, where you will see the source code of a, yeah, of a warning and you see here the warning highlighted. And what I'm using here in the background is the prism plugin now, which is rendering the source code using JavaScript. What I this was part of the warnings plugin and now I created from this part of the warnings plugin a new plugin where other plugins can use it. So for instance, I would like to use it in the code coverage plugin, and maybe some other plugins can use it as well. So what I created now is I extracted all of these colorings into this plugin so it depends on the language you're using so if you're rendering C code, it will use a C code renderer if you're using Java code you can see the rendering or the highlighting with Java. So this is done automatically. What I decided is kind of system configuration. So we have here the prism syntax highlighting section. And here you can select the theme. So currently, these are all these themes that are supported by prism. Maybe there are some additional ones available but these are the ones I found on the plugin repository of prism. So if you want to plug in and if you choose a different theme, then the rendering will look different. So you can use if you have a dark theme you can use this one. If you have a light theme you can this one that it depends what you prefer. So it is only possible to configure it in the system configuration. What I'm going to add is to make it customizable per user. So a user can say okay I have a dark theme, or a light theme. Yeah, that would be easier if it can be changed per user. It would even be not much easier if we can change it automatically, but I'm not sure how to do this to get an event if the system is using a light theme. So on Mac OS you can switch and toggle. I'm not sure if I can catch these events and handle it in Jenkins. Basically the plugin is not really a special thing, it just provides prism.js for Jenkins plugins. So are there any questions on this plugin or ideas what to do? A couple of things I guess. It would be cool if it was integrated into theme manager in some way so that all the theme configuration was in one place. You probably need a new extension point in theme manager for you to be able to add your own theme settings. Yeah, that would be a good idea. Yeah, we had a bit of a look at adding it for configuration as code, but I think it seemed just a bit heavy because configuration as code tried to avoid dependencies a lot. I think it had a few dependencies like plugin util and a couple others. So we're not sure. We're thinking about it, but I think because part of it is it has a whole bunch for generating on Java code side, whereas in configuration as code we're just enriching a YAML file. The two things we were interested in at four was one, a managed version of prism API so we didn't manage it ourselves and the other one was the theme side of it. But yeah, just not sure if it's the best fit for that plug for the configuration as code plugin, but we were interested in that. Yeah. Yeah, maybe we can split this plug in in one, you know, JS part and the util part or something like that. I'm not sure. Yeah, that would certainly help. So Uli the prism API plug in today is is more than just the JavaScript, the prism JavaScript library. I see. Okay. Actually, it provides this view. So the idea is that if you change. If a lot of plugins are using the same few I don't need to reprogram these views. And if I want to change it I needed to change it only in one place. So the idea is like the bootstrap plug in. We have the Java scripting library and some add ons we can already use in Java. So, yeah. Of course, we can split all of these plugins in a simple JS layer where we only have the Java scripting part and the additional ones which provide some jelly fuse and provide some Java APIs. So currently all of these plugins contain Java code to help the Java developers. Yeah. And if someone just needs the Java scripting libraries it's not possible yet to split them. It's just a matter of work. So I want don't have so much time or so I have one component but yeah it would be possible to use two components for that. Thank you. Okay. Okay. Any other questions on this topic. Maybe then I switch to the next UI plug in which is just a note that I also have a plug in which provides the icons of font awesome. They have now a release six with a lot of new icons and a lot of new designs. I included these new icons now in the corresponding Jenkins plugin. So if someone would like to use icons which are not the tango icons but some looking better ones. Yeah, everybody can use the new ones of the 6.0 version of font awesome. Is it do I go to the plugin documentation on plugins Jenkins.io to learn more about how to use those or is there some other place I need to go to. Yeah, it's all I think it's in the GitHub repository everything. So it's a big read me. I think I wrote a blog post. Yeah, a couple of years. I don't know where I introduced all these Jenkins Java scripting libraries and I wrote a lot of, you know, examples on how to use them. Basically, so, yeah. Plug in this plugin is really simple. It's just provides the icons as an sprite and you can use them in your plugins. So if we have all ionic icons in Jenkins core, maybe this one is not needed anymore. But until then, yeah, maybe it's a good alternative for tango icons. I'm using it for instance here in the spot box plugin here on this or here on this side where you can have some nice icons without, yeah, without any configuration used to simply use the name and you can use it. And this is what I also mentioned on our pull request of yarn. So as a plugin author, I just want to use icons. I don't want to search in the internet for an icon and don't want to upload it in my plug in. I just want to use them. So this is the idea behind this plugin. And, yeah, maybe we have a similar concept in core sometimes then this plug in is not needed anymore. Okay. And the last thing I would like to show you is, you know, it's more to get some feedback what we can do. One of my students is currently working in the code coverage plugin to improve the code coverage views. And we are currently trying to incorporate a column in the main view or in this table where you see the code coverage. And I'm, you know, we are not designers. So I want to have an open question on what would make sense to show in a column of the code coverage. So currently, we are using the percentage here of the code coverage and a color. And the color has a, you know, a shading or how do you say it in English, a gradient where you more it's more green if you have a higher coverage, and it will go sometimes to red. So, but it doesn't really look like a nice with a new table. So I'm not sure if someone has an idea how we can improve such views or such sales here. Try using some labels tags, the thing that are just around with the background around the number. Like you can see on notification pills in general, with the exactly the same kind of color you have there with some red thing. If it's below 20 or things like that, you have the information about the color you have the number, but you are not fully filling the cell completely in terms of background. I mean, you're like the one here in the yeah, it's okay. Okay. A couple of things. I would drop percentage from the label of the column. It goes on two lines and it's pretty obvious because it has a percent. Do you need that not applicable color there? I guess it possibly trying to call out was a problem. But whether it's intended that all the projects have coverage, I would possibly just leave it uncolored. What I've seen is maybe this is a totally different example on the, sorry, let's see. When you look at CodeCuff, there is a tool which showed the coverage. I thought that we can see it here. Okay, it doesn't work now. Okay, sorry. They provide a background which is a kind of 50% of the background is filled and 50% is not filled and this shows a coverage of 50%. Maybe this is an idea which is not so currently the colors are too looking too high with high contrast and I think it doesn't really look nice currently. But maybe that's a good idea to use some patches or something like that. To go further on, Tim's theme, I wonder if the word we're just coverage at the top, let them infer a code. Yes, of course. The label still doesn't, it's okay. I already commented that on the pull request but I'm just wondering how the cells should look like. Because in the static analysis plugins, I have the same thing, so yeah, okay, this is a different thing that our tooltips don't look good. And how, yeah, show how can I show that a project has too much warnings or if the warnings are okay, something like that. We have it in different ways. It's the number of tests, the code coverage, the number of warnings, et cetera. I think we don't show only text. Sometimes it makes sense to show some more information on the screen. So it would be helpful if we have some concept that can be reused somehow. Okay. So this is just an impression. I keep you informed how we are proceeding here. And just to put some positive notes, it's a very nice thing. So moving there, it's very useful to search information. So great job. Thanks. Okay. Are there any additional questions? Okay, then I think I'm finished with my part. All right. So next, I think next topic then was, was Jan and Tim on UI improvements or current status. Jan, do you want to take over? And if you've got something you'd like to share or topics you'd like to discuss? Sure. I'll just share my screen quickly. Nothing major today. Just a quick update on where we are really. So kind of in the last week or two, we've had the forms stuff merged in. So hopefully you can see that. It's basically 90 odd percent of form components cross Jenkins and now using the new stylings. So things are a little bit more consistent now they have the same kind of focus states and colors and whatnot. So this was this is quite a pain getting in so thanks everyone for the help. I appreciate it. And so that's that's now merged. And there's going to be a fair few follow up merge requests to this just to update the odd thing. Such as the draggable cards they'll probably change eventually and stuff like that. Very recently the new icons have been merged in so users can now use the symbols across Jenkins. The settings page everything's using the same kind of simple icon basically it's it's quite flat and so on and looks like so. And then recently I've been working on the rest of the icons across Jenkins. So you'll see in the sidebar using the same style of icons and the RSS icons updated pencil. And also recently with the status and other icons and they look a little bit with a icon or get people excited. They're a little bit different to how the icons look at the moment but this is kind of working progress. So everything's a little bit kind of flat a little bit bolder. And the weather icons have their kind of distinctive colors back. A lot of people who complained about the weather colors get with their icons going to a single color. And so yeah that's that's pretty much it for me really just working on the new icons at the moment. We'll hopefully have some sort of pull request up soon. That's that's all for me really. Did anybody have any questions or anything. So, so is this the large view. Could you. Yeah this is the large view for the icons. Those are the they are are they are they significantly smaller than they were before or is it am I just misremembering is my recollection poor in terms of size of icon compared to text. I don't think so. I could definitely increase them in size if they are too small. As I look at them now I think I think you got it matched I just I had not remembered them being as well suited to the size of the text. Nice. It's probably good to have a selection of jobs with different statuses to show when demoing sort of thing as well. This is a message from Daniel just saying to open up. Sorry. So I like Jenkins.io. Yeah, my browser's just gone berserk. Because we have only a folders on the top level but if you select the job that's building on the left perhaps. They do look a little bit small I think they may have changed size when the table was redesigned. I think it isn't running the new version yet. So probably are a touch more than than this. Yeah. You're more obvious with more jobs. I don't know how many questions or anything. Perhaps stupid question. I really like that new set of icon. But at the same time there were a lot of changes in terms of icon that were done what two years ago something like that in the first kind of rewamp of icons. What could be the the guideline in general when we want to change something like this to prevent someone to reach change back in a sense in one year or things like that to be sure we are coordinating the effort in the good direction all together. Instead of having multiple conflicting direction in a sense. I think that project just got abandoned. It was at the very end of the CloudBase UX improvements. And it was the very last thing that was being worked on basically. I'm not saying it should be a follow completely. It just that I prefer that approach completely. It just what could be done to prevent this kind of situation in a sense. I mean, Jan's published a kind of a design sort of guide on to jinkers.io. I think it has been merged. Jan, do you remember? Don't think so. I think actually I think it was waiting for the weekly today. So it should probably merged after the weekly. But Jan's put up a guide on how to use these anyway as a starting point. Okay, great. Perfect. I was just about to ask what happened to the style guide documentation plugin developer thing that I asked for last year. And this is the first time hearing about this. So I'm really excited. Thank you. Yeah, there's a PR really to go. It was just waiting for the to do version to be filled in got held back because of the security release last week. That was all to me now before. And kind of somewhat on that topic as well. I've recently but very recently just forked the UI samples project and just to try and update that a little bit. Nice. It kind of looks like it's completely very, very rough. But the idea is that we'll have a kind of page for every component. And just developers can kind of pop on here and copy code and so on and get the right of template. Yeah, look in and so on. We talked about this a year or two ago about either just moving this back into core or or automatically installing it somehow in test jinkers or something. Just because it's a lot of people don't even know it exists because it's just some random plug in. And because it's outside of core, it's a lot harder for people to maintain it. So yeah, and could you pick one of those this looks this this gives me real hope. I was amazed at the number of things that surprised me and so this lets me now explore with the UI samples plug in and see source code to get a hint. Yeah, you should get jelly card as well. Yeah. I want to kind of restructure the pages anyway. Maybe you offer examples of both groovy and jelly at the same time rather than having them kind of split. But yeah, so for example, the copy button page shows you the preview of the component. I can also access the source code for it. And yeah, it's kind of a really early days for cover at the moment. So we'll see maybe for the next sake to see where it goes there. And if you could inline that so you don't have to click on the source file. If you could just do some sort of raw thing with a prism prism highlighting on top of it or something. So so and copy button in this case is showing the groovy is there a copy button jelly that's that's the same thing in jelly and that's what you would combine two things into one. Yeah, there isn't a jelly version yet but I can write that quite quickly. And now for as guidance for me, I think most people are preferring to write jelly. Is there a, is there a reason we should be pushing more and more people should should the get plug in for instance switch from the things where it's using groovy now in its UI to use jelly is there is there are their weaknesses and using groovy that I should be aware of. If you're using jelly, it simplified the work of the security team. Okay, just for that it could be a good argument because if you want, when we are looking for things in Jenkins, if you're using a completely different language, it just completely different for us to look for your thing in general. So if I can with a magic one to change all the groovy view to jelly, I will do it in an instant, because for us it just doubling the size in terms of results, rules to write these kind of things. Jelly views are supposed to be more performance so anything that gets called an awful lot is supposed to be in jelly groovy is supposed to have better ID integration and you can debug your views in the ID is an advantage of it but kind of also I've always found the groovy a bit harder to write. Great. Thank you. Okay, so that that lobbies that there are the moving away from groovy is a good thing and showing people like me how to do it with jelly will be a help. Great. Thank you. Okay. I think we're supposed to be more type safe views and a little bit anyway, the better ID support I think is one of the polls but I'll stop train my screen benefits. I've got the theme manager rework. So this is something that yarn started on earlier. Let me just find my screen. I've done this a while back, but kind of just left it because it depended on the form rework. But so you might have seen this before you will have seen that he's changed the built in themes from just a little radio buttons on the side here to actually separate them out into a theme, and then he's got like pulled in the colors from each theme and then it shows you which theme it is. And then if you click on it, it will actually change. So if I click to default, it will live reload and change to nothing. Same with dark and dark system. And then if I go to display dark mode, so I've just changed my display from light to dark mode. And then Solarize, Solarize dark. So just like live clicking around here. So yeah, I believe that is something that people like, but I think it should be quite nice. That's awesome. Okay, so, so my user experience is I can click around and see what the theme will, how the theme will appear to me if I choose that. Very nice job in the animation as well. That wasn't done nothing to do that. It just changes CSS class, not even CSS and data set. So it's based on this value up here, themes in our namespace. So it's a bit of a design change. So instead of only serving one CSS file, it serves all the CSS files on the pages. And then based on this value here, it's which theme it's going to show. And so now does this dramatically increase page size for people or? The CSS files are absolutely tiny. So not really an issue. Refresh the Solarized ones are under a kilobyte. And the dark theme ones are about live and kill by each and they will be cached heavily. Once I fix the dark theme, not caching stuff. As I see that Daniel use stapler. In a better way. Yeah, there's one bug to fix on the Solarized system. You see Solarized system isn't working. And I need to change something in core to integrate with this so that it gets the default color. Instead of the currently selected one. But it's pretty much there. I'll show you just a couple of main changes with the morphers. That's on my fork. So there's a new flag is namespaced. So this will only add all the themes if they're namespaced. So old themes won't automatically get added to this. So it means you won't get any problem with an old. So it's completely compatible. And old themes won't affect this new setup. I've done a bit of a hack in the dark theme. When I load the file, I add this prefers colors theme dark. Rather than how the other mechanism was before. And this is a couple of places and automatic. And so just does a finer place with that as well. Changes to dark systems. I've only got one CSS file. It's a bit hacky. But you see these these data theme equals dark selectors. That's selecting the root elements theme. And you'll also see the theme picker has a data theme element as well on it. So that's how I've got the colors coming in here. So it's just it's just using the SVG. It uses the same variables that are used for that the theme uses. And then this here is a more specific selector which overrides in the context of this window. And so you've got a local fork of the solarized one. Just pretty much the same thing. And I'll also try fix up solarized to work on system as well. And probably update material theme and core. But I think it's pretty much there. It's pretty close to ready. So I updated yarns poor question theme manager. There's one thing that is failing is the injector test fails because it doesn't allow you to do for equals on the label. The yarn switched from attached previous to four equals. But I think Jenkins core also switched from that. Jenkins core doesn't run injected tests. So I think we might just need to make to update through and remove that injected tests probably. You said four equals Tim that has some semantic meaning in JavaScript that. Yeah, so it associates a label to an input using the ID. You weren't allowed to do it before because of. Well, it was discouraging to do it because repeatable elements and. And guessable IDs wasn't so easy, but that's all handled for you inside of the jelly fragments inside of radio. If radio or whatever it is, it generates the ID for you and does the association. Whereas before there was a JavaScript function called which attached, which would try and find these and attach them. I assume you aren't changed that for some reason. It didn't work perfectly in some cases, I'm guessing. It's mainly just for accessibility. And then some of the CSS left has kind of got a bit wonky with that method. So kind of went a bit weird, but pretty much that. Yeah, so you need to fix that up because the tests are failing because of that at the moment. But hopefully should have all that tidied up out of this this week or next. It's pretty close to being ready. And for me, I have a question about for plugins. So what I'm using my plugins is a kind of color palette to show the warnings or to show the coverage. And I think that it would be perfectly if we integrate an extension point so plugins can provide a themeable thing. And then I can have different colors if we have, for instance, a black theme and currently the colors are look a little bit weird on the charts if we use the same colors in a dark theme. So we can automatically switch them though that would be a really good thing if it would be extensible. Yeah, I mean, you could certainly get the themes from theme manager already and you could just use the. I'm not sure if you could just map those themes or or just another extension point to integrate within some way. But like you could look up the theme and if you could say it was using dark you could or dark system or something you could just use that. Yeah, but the themes are have no semantics or they have just a name. Yeah, I mean should it would definitely be possible to add an extension point for it that a plugin can extend from the manager. Yeah, I'm not sure maybe it's it would be easier if we have a kind of color palette in a theme, which is independent of the plugins. So because the unit plugin needs something to represent a green thing and a red thing, the warnings plugin needs it the coverage plugin needs it and maybe a different plugin needs it as well. So it makes no sense to have 10 different theme at different color palettes it makes maybe sense to have one system color palette. We do do that now. Yeah. Okay. I'm just linking it to linking it here. I'll just share my screen quickly just a demo. Essentially, say for these icons, the screens dependent on the theme that you use. So if I try and good start quickly, you'll see the green will actually change slightly it'll go brighter. And the sun's disappeared for some reason. If I reload you also see the sun's also a slightly different color as well now. This is all possible to use in your plugins straight out of the box. Is this just two colors or is it because in a when you're using a chart you need more than your three or four colors. We have support between six colors at the moment but I plan to add entirely rainbow and more eventually. I've just been adding the colors that I've been using for the icons and whatnot, but look at a massive palette by the end of it. Okay, that's fine. So, yeah, and to be sure that that the palette definition then is shifting into the theme theming, therefore, Uli will eventually or other other things that are doing graphic rendering will be able to get their color definitions from something that is theme aware. Yeah, yeah. I was just calling the CSS variable and say Tim seems can override that easily so the update kind of magically. Excellent. Thank you, Tim or Jan. Yeah, Jan, anything else. Are you still working on the buttons PR Jan or any of the other, is there any other open ones. I mean, it's just the buttons and breadcrumbs right now. I think the breadcrumbs might just need one more review or something like that. And then the buttons just need the acceptance tests. Would you mind adding me to the to the branch for that just so I can try and fix it or something. I'm not really sure. One setting of the acceptance test is a bit limited, admittedly. Buttons. Yeah, I can add you to that. Yeah, and the unit test should be passing now. They went a bit dodgy due to with merge that I did but they should be fixed. I've added you. Yes. So your breadcrumbs is breadcrumbs. Yes, got three approvals. I'm not sure if Daniel if you were planning to have another look the combining of this separated was backed out. I mean, the combination was fine. I just didn't think it makes sense to add a new type to the hierarchy when it's more about the presentation. I can't really explain the reasons in the in the poll request. I haven't had a chance to take another look. Yeah, I think you definitely can. We just weren't we aren't wasn't sure on how to get it working without that I think the time newly suggested just backing it out for now to ship an interactive again. I think it makes sense. Sorry. Daniel go. Okay, what just wanted to say I'll take another look. Thanks for the pink. I wanted to say, I think we need some time to discuss the sidebar elements currently I think in much. There are many too many things on the sidebar which should not be there. And maybe we can define a new concept what is really shown on the sidebar and whatnot. So we don't have 1000 plugins that can add an action on the left and yeah you don't see the important things anymore. But maybe get maybe getting rid of the sidebar in some places or collapsing out or or sections in the sidebar and hiding things. I mean, to some extent this is a problem with the extensible nature right because if we say, well we only display things by default if they are an important action or something. Then obviously every plugin maintainer will say yes my plugin is definitely going to implement important action because it is very extremely important. And we have the same problem all over again like three years down the road. The get plugins quite bad at this I think it's attached last I noticed it attaches lots of build data, which becomes an action on the side. If you have interactive two or three get reefers I think you end up with like three things on the left. I mean there are strategies to to address that. Certainly. But maybe we can give some guidelines what is good and what is not good and this is currently really missing. So when I started my warnings plugins I also added a lot of actions on the sidebar but now I'm thinking maybe it would be better to have just one static analysis, or even if it doesn't need on to be on the sidebar. Maybe we need some totally different screen rendering. Yeah, I was going to look at that. Sorry. And one of the things I was kind of thinking of was kind of having plugins display as cards, kind of on the build page so for the static analysis warning, have a card for that so. So having an action users can see the cards straight away for example. So there's less clicking involved and hopefully showing more on the build page because right now it can be a bit empty at times. So that on the pipeline graph you plug in at some point. Somehow I lost my branch, but like I started adding a bit of that where you'd have like tests and coverage and static analysis would just get added would get like a section on the page or a tab or something. But I don't know what happened. I lost it in a stash or something I don't know. I'm not sure I wrote the card. Something we could look into could be that we show only some of the items. Now, there are a few ways we could do that I just mentioned the prominent or important action. So that would always be displayed and the others are you kind of have to click on an element first before they're visible or something like that. The other option would be that users can configure the stuff they want to see, which obviously means it's still a mess unless a user goes through the work of, you know, customizing their thing, which is probably not a great default. Another might be that we could look into like, can we track the actions actually used by a user in some manner, because we know when you click the, we can probably determine when you click the link to see an action and navigate there. Can we track that in your user profile obviously difficult impossible with the anonymous user and feels a bit like brittle magic. When people don't understand what's happening but just off the top of my head, these might be strategies we could employ without entirely throwing away this part of the UI. I think we presented a couple of months ago one of the bachelor thesis work of one of my students, where we had this pull request monitoring plugin, which showed how we can use some kind of, you know, drag and drop things to configure the screen. Maybe this is an approach as well. So maybe I show you the details. Maybe it's easy. So, this is where the idea was that we have these things where we can put these elements here and we can, I think it was here where can use different portlets and select the portlets. And what we did not manage was to say what is a good default, because everything is important for everybody so it's really hard to find. Yeah, which of these portlets are good or which should not be shown so yeah. This takes a little bit time, I think, until we get this finish. And then you get microservices and then you have 1020 30 projects, you're looking at, and then you don't care about individual, you just want an overall. Are there other topics that we should be discussing here before we conclude. All right, I take the silence as a, it's okay, thanks very, very much to everyone involved today thanks for the presentations, early, Tim, thank you, thank for your work on on 2.335 and on all the ongoing things. This is amazing. Thank you very much a recording will be available this within say the next 24 hours I'll get it uploaded. Thanks all. Thank you.