 Well, all right, welcome. Very small group this week, but welcome to the Jenkins UX SIG meeting for June 24th, 2020. We had a good number of topics to cover here today. I know Tim is pretty, pretty vital to the first item on the list, so maybe I can jump over to the design deck to get a start at Felix. Does that work? No, we can mention the other stuff. Okay. So let's just do that real quickly. I won't put this full screen. Everyone here has seen this before or this content up here before. So we'll just jump into the new stuff. So we have a work in progress new color palette resource. We had five categories of color palettes is how we've been thinking about the color strategy as we build a long term system. One that was suggested or requested a couple weeks back more than a couple weeks back actually been wanting to do this for a while was to have a data visualization specific palette. And this is very much a work in progress, but very straightforward. Essentially, this is a palette for data visualization and UI needs. So this is going to be something that once it's done is very helpful for creating consistent visualizations for plugin authors throughout the community, but it is again a work in progress. Part of the idea here is that we would have a set of primary swatches and primary is a misleading label so I'll change that. But primary swatches that can be used in representing multiple data sources. And then we have brightness variations so that if you need to represent different data points from one source, you would use in this case, different variations of brightness. Now really complex data visualizations can make use of combinations to represent more in depth data. This is again really still a work in progress. I think this what we see on screen does not really meet the needs of Jenkins UI data visualizations yet it might for some plugins but not for all. So we'll get there and especially with a with our smaller group today I'm going to post this and get her after the call and try and get some feedback there. But any thoughts or questions on that one. Cool. All right, so we're going to take a look at some table and tab styles. These are UI styles of course they're a very small portion of what's actually been done to refactor tables in the UI this is just what people see hey Tim. This is just what people would see when they're clicking in the UI but there's a lot of more important frankly structural work happening and I'll let Felix and Tim speak to that in just a second. The intent here is of course updating the table styles in the UI with a more modern aesthetic so that should result in a more user friendly experience and show people that we're investing in Jenkins the Jenkins project UI. While we also work on more fundamental improvements. So some things to highlight here, taller rows, greater visual contrast with the new palettes that we previously defined, not the database palette but the others that we've looked at in recent weeks. Adjusting cell padding. And of course we'll have to be type styles and colors and hyperlinks things. This is an example of a piece of a bit of UI where a lot of these different base styles really coming together for a big improvement. Also, let me just tag through here. Also part of the idea here is sort of starting to define the anatomy for tables in the UI and, and for tabs in the UI. How do we think about them. How do they work what are their limitations and courses involves a lot of iteration between myself and Felix going and seeing what the actual technical constraints are these pieces right now. But this is a certain. And we have interactive states that follow the same treatments as other elements that we've been working on like the sidebar for greater consistency throughout the UI. Yeah, one question. I'm talking about existing cut tops or introducing new tops. So, basically, we're talking about updating the top bar widget in jelly, the top bar really widget. I'm aware that are well now that what is here there are plugins that write their own tabs like, for example, the new security plugin update has their own tabs. So that would not be affected. We will stay the base steps provided with you provided by Jenkins core. Basically, that's what we'll do. And we will be very conservative with the markup changes. In this case, very conservative. And thought tables we are going to tackle again. The big table class. Basically, more technical detail, more technical details, the big table we've been paying frames for those for developing developers. So those are the two things we will touch. Nothing else. Thank you. Thank you for the design of the header to be left aligned. That's so nice. Yeah, I try to, I try to make them to be able to write a line columns, for example, for numerical columns to be able to write aligned them. But it's, it's, it's a bit difficult to align also the header of those columns. I couldn't manage to the property. I will try though. If we don't have any more thoughts or comments on this for now, we'll switch back to our agenda. And Tim, Felix and Oleg, do you want to speak to you tables to do status. Yeah, team we talked to you here in this talking point. And I sure do not. Yeah, I wanted to bring two weeks after yet again the mergers to discuss the merge status of the of this PR and talk to see if we can set a or we can decide or maybe consider what with the reasonable sort of a deadline for it to be merged before the next LPS for example, what a date where we think it's sensible that if it's after it may be your part of this other plugins or the September release. So, right now the be the status of the PR, the PR is blocked is right now has to block a blocking problem that causes some plugins some problems that need to be adapted but they are not if they are not adapted they break the configuration layer. I may be able to dedicate to today's this one day this week one to two days next week to see if I can unlock it. For now, but right now this is a this is a blocker many of us consider it a blocker, but also some of us believe that if this is solved, it could be merged after a few days of intensive testing. So, my question is that this is a context that said imagine what would be the I would like to hear your opinions of when it would be too late to have it merge assuming we fix all of what I just mentioned before it's too late to. Sorry, when it will be too late to match it in time for the LTS release, not technically but I know it can be made into the release even if it's match mid July to the end of July but what would be sensible to do. Can you team, we are very interested, I would like to hear your opinion very much because you're the main person driving this one. When's the next LTS. Sorry. So when is when it's when it's the next LTS version selector. 20 something of. Yeah, 27, so if I recall correctly, just second time opening calendar but it should be. It's the 29th of July. Plus two more doesn't fit. Yeah, so 27 says basically everything is merged to master so that we get it theoretically. At least, so this is just a cut off date. Not sure if it and LTS was released in what September or so. Yeah, it will be released in six weeks after the decision. So be the current process. I mean, even if it does make it into the LTS, then it's still got six weeks should be time to fix plugins or. Any improvements we can find in the quarter. Compatibility. Is the aim to get it in before the LTS or will not. Ideally, it's like we get it in as soon as it's ready. So I don't think it matters too much either way, either it makes it or it doesn't. And if it makes it then we may have some improvements to make when issues are detected. Yeah, my my main question is, for example, I. I don't know if I would suggest making it merging it if by the end of July, even if it technically is possible technically will have six weeks to do it. Maybe up for merging it this week or maybe in the next. I, because, well, for me, it's better for peace of mind. I don't know if. So, that's what I want. That is why I wanted to bring this up. Yeah, the longer we have the better sure. So, yeah, I don't know the only issue is that table issue. So that's the browser that's changing the DOM. It's not easily flexible. Yeah. So basically for one blocking kisha and the decent risk that you and if it's fixed, they will be plugins which are not fully compatible, right? Yeah, it depends on if we need to do more testing with popular plugins. I haven't had any issues. Possibly I could create a full dimension run up with my full set and say, but definitely the default plugins don't have any issues. Yeah, I can probably stop instance, which would cover something like three or 400 plugins. It's my biggest number of plugins testing setup. And we need to update the plugins. But the problem that I can commit to do it this week and next week, week after maybe. And the other problem that you still need to monitor click a lot of things because it's not something like opening configuration. Think whether everything something breaks. It may break on the drop downs on drop downs of the drop downs. Yeah, not even mention other things like my legs, talking and whatever, which seem to have a few drop downs. But yeah. Yeah. So it will need some careful testing. At the same time, yes, ship within weekly. But yeah. So in the worst case, we have an option to reverse that. And that is, I mean, the pull request. Yeah, if we find something critical, we can always refer to it or possibly. It's not easy. I was going to say exclude it from the RTS one, but it's probably very, it's very invasive in the styles. Yeah. And I think this is up here. That's not easily revertible. Because it will, at least in the, in the JavaScript and CSS part, it will basically make it impossible to or very, very difficult to roll anything back after it. So one thing that we could do possibly even this week would be to see if we can mainline the JavaScript and the CSS release the JavaScript changes. Should be safe. Most should be safe to mainline as they have to be compatible in both ways anyway. Yeah. And the CSS probably not mainlineable, not possibly some of it is mainlineable. Yeah, maybe if we are willing to handle a bad merge conflict, we can extract the form CSS and isolate it. It shouldn't be a merge conflict if we just pick it out. No, I mean, doing anything master and then merge it into the, into the form branch. Yeah. I'll see if I can, it's probably, I'll see if I can, hopefully this week, just see if I can pull some changes out just to make it smaller. Because it gets the jelly changes that would be need to be reverted and that's reason for it. But the CSS changes may be a bit more intricate as well. Okay, so my, I have a suggestion to make if it's okay for everybody. If we make it, if we are able to unlock the, the PR, so solve this breaking this block, this blocker, this week, maybe we can consider safely merging it. Right, right now. And if we are not able to unlock it in the next one to weeks, maybe we, we have this, we, re-evaluate, re-evaluate in the next week meeting, maybe. Yeah, yeah, so we're all right then. So the next topic, did you say that there's at errors on table to div? Sorry, I think I need to speak a bit louder. Because updates 3B tables to divs, at errors. Ah, see, at errors. Ah, yes, I, I've run the, that's something that I also wanted to mention, maybe it's relevant. I've run the, I was able to run the ATH suit and the PCTs against this branch. We did a lot of cloudies. And we found that, for example, right now, there is, I think, around 10 breaking PCT errors. Sorry, 10 broken PCT tests that are broken just because of this branch. Or, sorry, that are breaking this branch but not in other. Also, there are around 20 ATH failures that do the same. And the total amount of affected plugins may be around 15 at breaking tests, maybe. I will report all of them in, 10 to 15. I will report all of them tomorrow in the, the breaking tests in the, to the, to the epic. Keep in mind, these are breaking tests that appear on these branches that do not appear on other branches. They don't necessarily mean that they are breaking because of this. Okay. So we may need to examine them. We have clouds, we'll examine most of them. It could be just markup changes as well. I had to, I had to fix one of the smoke tests. Yeah. Because it was doing a strict equals on the class rather than checking if the class was there. Yeah, exactly. So many tests are brittle. Well, it's good to be a failing because we can fix them anyway, even if the branches merge, even if it's not merged. Better tests are always welcome. So I will be also be reporting everything I can. I will also be working on doing code search, doing code search for possible errors. For example, looking for a specific overridden widgets. For example, there are several widgets plugins. I have reported those today, by the way, there are several plugins that rewrite widgets. For example, the Kubernetes plugin, the HTML properties are a plugin. There are, and I will also be searching for HTML, sorry, for occurrences of table markup, especially the infamous case that causes breaking issues. I will be searching on the code across the whole Jenkins organization. I will focus mostly on the most relevant unused plugins, of course, and I will try to report everything I find. It will not be perfect, but hopefully stuff will appear. And hopefully, that will inform us better what the scope or the actual breaking breakages. All right. We can skip, we looked at that. And item D here is, I just kind of wanted to mention this to the group and see what people thought. So we've established a lot of base styles in the UI. And we've looked at them together in previous SIG sessions. I think some of these things are getting to a level of maturity where I would personally I would feel comfortable sharing them on Jenkins.io as design guidelines for plugin authors for anyone who may be interested in understanding the language that we're trying to build in Jenkins. So I just thought to myself, well, I went and looked around at the IA of the site. It makes sense it would be under documentation. And the idea here is not to do a huge release or anything like that or a huge publish. It would just be to start with basics and we would contribute to those gradually wouldn't we feel that a certain element is stable enough or secure enough or is represented inside of Jenkins and release. And then gradually grow those. So, does anyone have any thoughts on that good idea, bad idea, anything like that? Neutral is fine too. I think it's a good idea to show stuff like palettes, type scale, icon recommendations. Yeah, definitely. Yeah, stuff that is actually technical, like for example, if we go into detail like button styles or button variants, those are more difficult because the better example is done using the native widgets provided by CSS classes instead of having people trying to replicate those. Yes. The abstracts, as I like to call them. The abstracts definitely. Yeah, there's two sides to it is the actual code that's needed, which I think really belongs in Jenkins and a you're in a development plugin sort of thing, which shows you how to develop views and others us samples but I don't think splitting out is the best because it needs, it needs to be linked to the Jenkins core. And it also means that you don't, you don't update us samples when you update Jenkins My opinion needs to be brought into Jenkins core bug. Yeah, I think it used to be in Jenkins core and it was probably moved out, but I think it needs to move back to But there's also a problem that plugin developers don't use the latest Jenkins core so they're not going to get the latest guidelines and tools but I guess what they do get is they do get guidance tailored to their version of core Things like the jelly tags that you need for icons and actually using them and showing that they work and having the code next to it and CSS classes for alerts. Yeah, that one was painful on trying to help Arnold with it a few days ago and just having to dig back through and get history to find when CSS stuff was added and it was completely undocumented. I'd love for us to be able to provide all of that, as you say, inside of Jenkins and on the website, right, I don't see why I couldn't live as long as it's maintained equally in two places for visibility to start this would just be really low level stuff, you know, but And ideally minimizing people having to do PRs to Jenkins core and the IO, if we can, because then there's problems like you're going to have to track when it's introduced in core and So like what when the CSS class was added and That sort of issues. Yeah, one thing to help you that is to create a new UI samples and to the command to minimum version right inside your samples. I agree. Yeah, we wouldn't be able to start with that at least we could wait right we could wait until it's more useful and more in depth and not just some basic color guidelines and type type of structure. And then publish something more thorough that's totally fine. Yeah. What I would like to say in that sense. I would love if people if there would if there's in Seattle Jenkins.io. If, for example, I'd like to decide where to be integrated into Jenkins that's what we already mentioned because of the it's coupling with jelly markup. If anybody could go into Seattle Jenkins.io and go somewhere within the public environment and that's running LTS. I write and check what the proper markup is for that LTS what the proper widgets are for that LTS. That would be amazing. If not, they can always download the Jenkins development version of the Jenkins and beat on Jenkins core installed the proper version of Jenkins core is the proper version of the plugin and have the proper samples. So that's that's what I would like to do to say online docs on Seattle Jenkins.io. There should be should be able to install that UI samples plugin there. Yeah. It's just not really maintained. Yeah. And I guess it was separated so that anyone could add stuff to it more easily but then no one maintains it so I one of the arguments I saw that it was too invasive invasive in the sense that he put an entry in the main sidebar. I would just hide it with a flag and put a footer entry with a footer decorator. Yeah. Just have an environment variable or feature flag or something for us and then put it in the sidebar if it. So it never end up in a production instance unless you're specifically enabling it and then in the development plugins just automatically enable it. Yeah. Maybe maybe so maybe the next first step is to update the say update the UI samples plugin set examples for I don't know. Try to do it after after the September version. Sorry. Yes, because we will have better stuff to show right better how to indication how to have buttons how to have tables how to have this variation hyperlink. Yeah. I guess I don't think if they will make it but yeah so we will have more stuff. And then we will try to keep to be updating and if that's successful. We can try to look to look into making it back into the Jenkins main language. Yeah. Another issue is worth it is that it's no one installs it. It's not it's not a new development instance when you spin up your plugin you don't have it. I didn't even know about it for a long time. Yeah. I only knew about it because somebody brought it up in a sick meeting. Yeah. A month ago. Yeah. Well it's something fixable. We could update maybe an HPI plugin to include your samples plugin by default when you start in development mode. Why not. Yeah. Yeah that could. Yeah. There's probably two options. One is just moving it to core and the other was and then having made me an HPI enabling it or the other one is maybe an HPI automatically including it. I believe it was done at some point. I'm not sure why it changed. Or maybe it was actually embedded. I know it was embedded into the Jenkins core and it was being enabled by Jenkins based on conditions. Yeah. So instead of that we could do it in maybe an HPI plugin. The problem is you need to match Jenkins baseline version over the thought. So it's probably not the easiest and doing the maybe an HPI plugin to which version of the plugin you install. Which is why it makes sense in core. Maybe we can go back and find out why it was moved or maybe we can just propose moving it back. I guess it was retouching within Jenkins to the zero because we thought that all plugins were bundled into the Word file and you had more flexibility with regards to that. So my preference would be to do it in maybe an HPI plugin. These are the consequences that if you develop a plugin in Groovy then you won't get it. And second consequence that you have to run in the development mode. Why would you not have that in core? Well, we just stopped bundled plugins. They don't have it as a plugin, just have it as part of core. Why not? Why, yeah. So technically it would simplify things a lot. Especially since we could require, however, contributes new UI, new control to create a demo within the same full request. Yeah. It would be an improvement. And they can use that to demonstrate their components as well. So even if it's something for a plugin, they can demonstrate it in core. Yeah, also we could modify TugLeap recommendation for JD controls because they could point to a demo. Yeah. So if somebody moves that, I think it would be quite a good improvement. Yeah. Let me just check how many changes have been done to it. Or maybe we can just, instead of moving it, we can start it from scratch. Yeah. If it's less complicated, because if I recall correctly, there are some good, useful stuff on the UI samples plugin. Nothing that can be replicated and it needs to be modified anyway. It needs to show, for example, sample jelly markup next to the actual. Right now it only shows what the widgets looks like, a living version of a widget, for example, a progress bar, right? But it doesn't show the use of the progress bar in jelly. So the samples that are right now are good. But maybe it's better to just rewrite it from scratch and to start it back again. If it's less complicated. If it works for someone who wants to rewrite it. Yeah. So it truly depends. UI samples, it's a bit obsolete on its own. Well, it's not obsolete. It looks like it gets like one or two updates every three years. It's basically barely been touched since it was splurred. I did run it a few like before the UXX had it on. Everything in there seems good and useful. And we're good that it was maintained better and more available. Yeah. So moving to Jenkins code. Anyway, you have to increment an engine, which would inject the UI samples. So one of the ways to just have UI samples plug-in as a submodel because why not? So basically a submodel within the Jenkins repository. I mean Jenkins code repository. So it's basically copy a paste of plug-in and replacing parent home pointer. And after that, you need to apply some magic in a word runner to inject this plug-in as a dependency. So it could be done. Yeah. Hi, Mark. So yeah, okay. I was going to say you all took my idea of starting to list them on the site and made it much more advanced, which is a good thing in this case. As far as next steps, you know, what do you think Felix or Oleg or Tim. We have several ideas here and I've been kind of taking notes for my own sake here, but what do you all think as far as moving forward and deciding how we want to think about documenting all of this? I think the right now the UI samples long. I think it's summer. We have bigger fires to work to focus on, especially the form tables to divs. It's going to take more. It's summer. We are low in development work maybe. And we will be short, probably short in community contributions. So I'd say just go ahead with what your plan was. Createable requests against maybe the commutations part with the abstract with the base colors. Typography is not that important, I think, but color, the color palette is the most important one, I think. Do that again, the planning documentation as your plan was and we will follow where whenever we were able to. Yeah, just add the stuff that people need. I think it's very kind of just comes. You can document it so that people know it, but it's. Yeah, for example, right now, Woody Haffner, he wasn't able to come today, I think. He has mentioned before he needs those colors, he needs that palette in order to work on the visualization plugins. There's no, no reason for to make him wait. And other visualization plugin authors and other people interested in using any color palette. Sounds good. All right. I'll follow up on our next succession with some progress on that but I don't expect that to be, you know, very complicated or anything like that. Since we're starting so simple just colors. Cool. Does anyone have anything else for today's session? I can do a quick demo of the J unit plugin using each hearts. Oh, great. How are you able to finish that? Cool. I got it working. Yeah. Needs some cleanup that works. It took a bit of time. Yeah. Oh, that looks amazing. It no longer, it no longer has a fixed width of 500 pixels, right? That's, that's a history J, I think. Canvas, it's Canvas. Okay. Yeah, it's 500 pixels. I hate it. Okay. But it looks great actually. It looks really good. And we can always set the expand button or full screen button. We already have some graphs that we should support that basically just pop up, which shows a full graph. Yeah. There is one, the existing one. I haven't added it to this. I wasn't sure if we needed it. I like this a lot more is you can just hover over some understand it. I struggled with the other one. Can you go to a build if you click on it? Yeah, you can. Because that's what I do basically. I just click on it. Yeah, so that one. Maybe you can add a pop up. I'm sure the HRS allows you to write a pop up or something. It's linking. Okay. Yeah, that's great. Do you mention something that you changed the same visualization? It's no longer stacked. It's more of a productive. It's the main but one change up in going here currently and I was looking for input was it's currently showing past rather than total. Previously there was two axes that was failed and total. Yeah. And this is showing past and failed with no total. I wasn't really sure what made the most sense. So this is what it showed previously. So it was total eight tests with three failures. And it doesn't, and it doesn't overlay them. Whereas this one overlays a little bit and I need to, I need to add skip on there just to see what it looks like when it's got a skip one. So if I'm correct here, it's, sorry, it's easy to see what it's easy to appreciate what the actual proportion between total past tests and failing tests are, right? Yeah. Yeah. So Tim, you changed it from a stacked bar to a to just a bar. Is that what it is? I'm not, because if the number of past drops below the number of fail won't on this current layout won't the blue line become invisible. It will hide behind the red, won't it? Possibly. Possibly. You'd still be able to say it here. But then you get the same. With the other one you just get, you get a big failed blob. So back here, if the failed was hard and blue, blue would disappear as well then. If there are eight tests and eight tests failed, this would just be red at the top. But if seven tests failed and one passed. In this old presentation, there would be a one, a one wide bar at the top and. Yeah. Okay. All right. I don't have an especially strong opinion, but I like it being a stack in the old just because it would show me the top of the bar was the sum of all tests, right? So I could infer the number of tests running just by reading by looking at the. Yeah, I can have a play with that and see what it looks like. So they would change it from just didn't quite sound right to me to show total and failed. It's not going to be total unfair. It can be total and stacked under them. But you would end up seeing the total. And I think what Mark said, for me, it has been useful in the past to see what the actual date delta of test coverage is. It's an increase basically over time of how see the higher the body is the higher your coverage gets. It's an appropriate something that they've found useful in the past. Yeah. That is beautiful, Tim. Thank you. That is, and this is using each arts instead of the old the old code. Jay free charts as well. Most of the other charts use hasn't been up hasn't had a release in three years. Well, let's refresh dependency in this in the Yankee spray. It comes in early, all earliest work on friends X and warnings in G. Yeah. Yeah, warrants and is almost as much as popular as the unit plugin. So I don't think that we'll be putting additional dependency everywhere. Yeah, and getting more things to look like warnings and G sounds like the right approach to me. Yeah. So the mates of the inspiration for doing this was was dark theme really because if I look at every look at the also my production instance. This is probably what looks the worst right now is the J unit plugin. As it's on every build page and it just looks horrible. Yeah. This doesn't look great on dark theme yet, but it just needs to change to the each arts plugin to change the colors a little bit. Yeah. One question. What about the support there? In order to support, for example, dark theme engineering plugin. Will we need to add any changes on the unit plugin side? So on the each arts plugin side. Okay. So each of sort of the integrates of the changes for the controls. Yeah. So there is. So basically, there's a whole API for using it that really is designed. All of this sort of stuff. And then there's a, I think it might be in the thing. It's here is just this check. This is a trend chart. You can go custom and go nuts. If you want to. But this pulls everything and into an. We call it the adjunct things. And I hear we wrapped JS. Trend chart. So there's some configuration down here, which needs to be made more generic for. Well, it needs to be made themable in some way. So we'll be forking the, we'll be forking the. The library. No. So this is, this is just JavaScript calling the each arts API. Oh, okay. So this is. So this is planning. This is not library. JavaScript. This is a Jenkins. API plugin. So we just need to just need to make that thing will properly. But we don't. So Jane a plugin doesn't touch any JavaScript. Jane a plugin just uses the jelly tag. And when the, when the plug in the each arts plugin is updated. So, you know, I will just keep the theme and automatically. Okay. I'm pretty sure you can, you can read the value of the CSS variable on three JavaScript. Yeah. I just haven't looked at it. And you can always fall back to. Yeah. Yeah. So this is the line that needs changing. That's where it looks a bit off at the moment, but it looks much better than before. The other side of that is there's a few widgets and core, but there's a few of the ways to use j free chart and what do we do there? I thought the standard answer that was burn them with fire, but that's probably the wrong approach. Right. So I don't know what they are. Oh, oh, this would load statistics. Okay. Yeah. I think this one is a J free chart as far as I know. There's also, I think system and I think. So, So these are using each house. So these are using J free chart. So at some point, we need to do something about these as they are not being able to. I got a flood of issues reported by Daniel in the weekend. Half of them with the J3 charts. Yeah. I'm not sure what the fix is. We can fix plugins for us. But whether we bring E-charts into the core, or whether we detach these charts out to plugins and then do it. I'm not sure if anyone has any opinions. To be honest, I think this is not need not only a library update, but maybe a, a, just a recent actual, I don't know, UX improvement US, pre-designed because for example, if I look at this, what is this showing? I can guess from usage use with the plan, but for example, the other one, the load and the road statistics chart. It, for me, the difficulty interprets. Maybe I'm not used to it. So maybe, maybe the pro and maybe it's nice to change the, the, the charts, the chart library. But I think maybe we need to look into the chart itself. Well, this chart combination is to block this page entirely. Because these charts on the real instance, it takes a lot of time to work them. And easily if you talk about these charts, I would rather prefer to redesign how we build them. So maybe incremental data update, maybe a shorter time frame by default and ability to zoom out, etc. But as this, this load statistics is not usable on a real instance where you need the load statistics. Yeah. And so maybe each house does load it asynchronously, which is nice. Maybe it's a nice time to, maybe it's something that we can ask in the meeting is good to consider moving it into a plugin. It would be useful, especially since this visualization doesn't require EPS. I mean, yeah, it can be moved even without marking the thing as a detached plugin. We can add some magic, for example, keep the URL in Jenkins core at an extension point so that whoever goes to this page, they can go to statistics plugin to the listing of statistics plugin, not only these load statistics, we have useful plugins like cloud stats, which could be embedded in the same interface theoretical. So, yeah, I'm plus 100 for moving it out. Yeah, I don't think there's any useful charts in Jenkins core, or great charts in Jenkins core currently, maybe useful, but not great. Yeah. And if it's moving to a plugin, it's easier to locate each house. Yeah. Yeah. Maybe a plugin there that's travel to do the HR thing. Yeah, I cannot imagine. So if we are able to keep Jenkins core lightweight, I mean, still keep fancy UI there, but without depending too much on JavaScript libraries, it would be a good advantage. Oh, yeah. Yeah. Yeah. This is not like, this may not be more a platform feature. Like, for example, if configs code is out, why is this thing? So it's a less platform thing. Yeah, we already need to think how, what we do with the recommended plugins, whether we want to ship Jenkins with some plugins bundled again. Because for example, if you ask me whether I would like to ship plugins like cloud starts or configuration is called out of the, out of the box. Yes, I would. But it's a completely separate topic. And here we can keep the touch and things. Yeah. Yeah. Let me just have a look. I think it's just the two chart. Plus. In core anyway. I know there's a few others. Yeah. Yeah. So I think, yeah, there's not, there's only those two charts that I know of. So it looks like your GitHub extension already works with the new interface. Yeah. It always works. You mean they were, you know, the fine to get her whatever this one here. Yeah. Yeah. It didn't break. I was surprised to just kept working. I thought I thought it would break. Hello. The, um, they did not test this with, with wide lenses though. So that's completely off-center and all that's very strange. Somehow it doesn't bother me very much, but I think the tabs, they click most of the releases tab. So if you speak for you about user experience, one thing which concerns me that the new UI, though, is old as well. If you have a big number of files, then you have to scroll down to get to read me. So it's probably something I would like to see changed in the repositories. But yeah, definitely unrelated to Jenkins. The only thing I'm struggling with is this button here. I'm so used to commits being over here. And I keep getting lost with that one. It took me a while to get adjusted to go to file because I use go to file pretty much every day. I always use the keyboard shortcut for that one. T. Aren't you all embarrassed at the amount of muscle memory that you have just disclosed that you have the commits button, the go to file. Oh, the muscle memory amongst software developers is frightening. Was there any way other than presenting to do it? I think there might have been a menu hidden somewhere. I'm not sure. But yeah, I don't know. I use this all the time since someone showed me. Yeah, by the way, I am finally finishing the UI UX hackfest for user interface blog post. So I will hint a dark theme and many other stories there. Also, we have an online meetup tomorrow where again, we will bring up some of these stories. So I think that maybe starting from next week, we could think how we promote table studies if you want to facilitate contributions. And yeah, I think that dark theme, et cetera, they could also be promoted. Yeah, definitely. It's getting some adoption. It would be interesting to see the usage stats when they get published for June. See how many people have installed it. On tomorrow's webinar, Joe, I did not. I made a mistake and didn't invite you and Felix to be presenters on tomorrow's webinar. You are welcome to be there. You're welcome to chime in. It's got a piece that is your system fonts work. So you certainly were contributed to it. My apologies that I forgot to invite the two of you. No apology. Oh, Mark. No, no, no, no. I need to go on that thread and yeah, and see if that works for me. But, but yeah, no, thank you for the reminder, but all good. Yeah. It would be also good to announce it in the developer mailing list and other channels. I'm not sure whether you have been with for that mark. I do. And I will announce it today there. I just did it in the getter channel. I will do it in the developer list as well. Thanks. I think I'm also going to do it in the user list. It's worth, it's worth users knowing that these capabilities are coming. They should think about it. That's one. So we've got a decent number of registrations. You can push a bit, but definitely we'll have people joining this session. So it's one time. Just registrations now. So Tim, thank you for being willing to present. Oh, like, thank you for being willing to present. Much appreciated both of you. I will look at those slides. Hopefully soon. Yeah. And you can, you can replace them if you need to with something else. That's what I used to talk. I've been on the phone the last six, seven hours. Okay. Yeah. So Mark, I just did it. Oh, what's next slides. So basically I considered it as a part of presentation now. And I put it into the agenda. I agree with it. It is part of the presentation. Okay. All right. I think we have on time here. Yeah. Okay. Thank you all for a good session. Sorry. No, let's, let's, oh, I think I'm my closing thought is let's pay attention to. To the two tables to the, to request and think about it for the next six meeting. If we don't, we don't manage to get it done. But I'll try to work on it. Yeah. I think I just noticed it today. I didn't report it yet. It looks like it breaks for two installations. When you use Oracle JDK tool installer plugin, which requires a license. It looks like there is another aggression there. Yeah, I will report it. Yeah. You say that's in table to do or that's in two dot. Okay. Yeah. It's just table to div is so much more attractive. It is absolutely the way to go. Yeah. It's also way scarier. Well, I remember Jeff 200 times. It was also scary. Yeah. After two week, they release us. How can we enter ratings? Perfect. Yeah. Jeff 200 is, is a good reminder. We can do big things. Yeah, Jeff 200 is changing all the old civilization of classes over XML over demoting channels to permit us. You're looking great. Thank you. Okay. Thank you everybody. Thanks everyone. Thanks. Oh, I just realized nobody was taking minutes. I will try to transcribe the minutes tomorrow. Yeah. Yeah. Thanks.