 Hi everyone, welcome to the July 8th, Jeremy can you start recording please? Jeremy is not here. It's already recording. Okay, thank you, hi everybody, welcome to the July 8th UX Seek meeting. So today I'm going to go over the agenda. Everybody, we are all, we've all been here before and one of these meetings, so no presentations are required. So first of all, I wanted to give some updates on the status of the UX Seek work. I want today to go over the status of the Forum Tables to Deep Initiative VR. And I want to present the tables changes, tabs and tables changes agreed to appear today, we'll go into it later. And then I want to discuss if there's comment of every bit, if that's anything we can do for the next LDS, anything else. Okay, so does anyone want to have anything else to the agenda before we start? Okay, let's go. Everybody can see, well my screen, right? So, regarding tables to this, I've been putting, what did we leave it last week? So, basically, we decided that it was maybe a bit too soon to decide whether it should go into the LDS or not, or it should be merged or not. We decided to talk about it this week. Unfortunately, I tried to unblock the PR to fix the table UI breaking issue. I wasn't able to do so. I worked one or two, almost two days on it. I wasn't able to unblock it. I did put a noticeable amount of work into running ATH tests, PCT tests and doing a comprehensive code search. I've reported issues with almost around, I think it's around 30 plugins and there are just some plugins I didn't even report them. I need to do it. So, there was some work done. Timo also did some great working. He, in forward reporting, the JavaScript answers changes. The JavaScript changes are already in, into the Jenkins master branch. So, that's going to solve any possible need to rollback the PR and to simplify the, well, to reduce the final complexity and risk of the merge. So, that's where we left it this week. Did I miss anything? Okay. The JavaScript was released in the last version, so it's out there now. Yeah, definitely. Yeah, JavaScript was released in 2244. Yeah, so this week if we can get someone else to review it. And that just makes it far easier to rock to other feature toggle or rollback if we need to. Yeah, it's still weird recommend I think that the JavaScript, the CSS changes need a bit of fine tuning still. So, hopefully we will get to do it before in next week, probably, but we just didn't, we wanted to merge it before because it was getting stale. It was doing no good being just there. Okay, so if we've been trying to look into the, so I want to talk about the tables to the status of the PR. So far nothing has, from my point of view, nothing has fundamentally changed the breaking issue is still there. We did lots of groundwork so we have cloud is able to say that we cloud is we don't recommend it merging it before the next LTS or included into the next LTS branch. We would recommend it having a date done by the next LTS cycle, maybe merging it at the beginning of August. That said, we will of course, in no way shape a form, try to delay it. I try to delay it if the if the breaking issue, the breaking issue is fixed, or delayed merge delayed any inclusion in any in the LTS. We will support the community of course. We just recommend against it, and we may not use it in our cloud is in our Jenkins based products, because we cannot just there are lots of standing issues in in many plugins. Well, some of them I many of them I reported in the into the data tracker that we just don't have the reason we just don't have the resources to commit to fixing them in this summer. We will work on that after after the summer and in fact, we have already started some work with the idea. I did the comprehensive comprehensive code search and testing issues and reporting of issues with the tests. And we are already working on fixing some ATH errors, looking into errors, for example, right now we're looking into errors with formalizations and the promoted builds plugins. We just don't think it's we are just not confident into guaranteeing the quality by the September release. So we will let me reiterate, if the community wants to if team only you and the rest of the community you think it's a if the layout fixing stuff is ready, you think it's ready to merge. We will support you, of course, yeah, we just don't think it's right. You said one question. What if we added the feature toggle? I think it's a lot easier now that we've managed to separate the JavaScript and CSS changes. And yeah, similar to the bootstrap plugin, which has a just has basically two versions of the tags. Yeah, I mean, with a feature, it could work. Right now, I don't know how hard it would be. When I looked into it, for some changes to optional block, I don't think changes to watch, for example, optional block or radio block where forward ported, right? So, or advanced. So those we just two versions of the tag and just, yeah, I don't know, we don't have the resources to commit to it right now. As cloudies, we are not able to work on it right now. Full capacity, I mean, in the capacity needed, but if if somebody comes up with that, I will make it a priority to test it and to verify and to review it and, of course, from my side, I can commit some time for review and testing. But yeah, my bandwidth is also very limited right now because my time mostly goes to Jenkins governance stuff at the moment. Yeah, I'll do my best to review that. Most likely it will be just happening sometime on weekends. Yeah. Cool. I mean, once the CSS changes merged, I can take a look and see if a feature talk was feasible. It wasn't feasible when the JavaScript was there, but I think it's a lot more straightforward now. Yeah. Okay. Yeah, maybe maybe just a PLC with the entry advanced optional block. Yeah, so those videos are just showing high stuff, you know. Yeah. Okay, so yeah, I will, as long as you have a draft, I will look at it. I will make it a priority to look at it. Yeah, yeah, once, yeah, I'll take a look once CSS changes are in and I don't want to just to get the diff as small as possible. And I'll take another look as well just to see if there's anything else that can be removed is just to reduce it down as much as possible. Okay. So anything else? Do you have any opinion on this topic? You're muted. Actually, no, I'm not really using these fields very much since we everybody's now using pipelines and yeah. Okay. So for me it's good to change it. And yeah, I'm not sure if it's good to change it before the LTS, but yeah, I don't really care. It's okay to change it now. And we need to fix some plugins anyway. Yeah, okay. Okay, I can fix my plug in. So, yeah, I did report a few. Yeah, I didn't report some issues on the warning. Yeah, that's okay. Part of the code I looked into two years ago. So, yeah. Yeah, but if it's behind a feature toggle like Tim is proposing. So at this and the current state, the feature would be opt in at least for now, maybe even enabled by default and experimental UI, because why not. And we basically make it opt out once we have more plugins stabilized. Is it right? Do we want to enable it by default? We'd need to have just a review of the plugins and see whether there's any major plugins that weren't turning it off initially, probably turning it off initially is that no one's going to use it so you're not going to get any feedback. But if we've got some fixes in flight, it could make sense to just have it merged to make it easier to test and then enable it once a few fixes have been released. Yeah, that's a fair point. We have no way to promote experimental features. So, yeah, we can write a blog post or whatever but still the feedback would be not that high. So it's nothing like in GitHub where I literally get this big little blue thing up in the corner of my screen that tells me all there's a new feature and turn it on two minutes after they've released it. Well, I wish to implement such identification engine. But now we don't have one. I think that it would be really useful in general to have it. In my opinion, too many key plugins and high use plugins may break in or for me to comfortably recommend that it's opt-in. Sorry, opt-out instead of opt-in. But I mean, that discussion can take place once we are sure that's visible. I mean, I don't see a point. Maybe it's not that useful to discuss it right now. But the notification is good. Maybe I don't know if it's appropriate to leverage the current notification bell. I don't know if that's appropriate for that use, but okay. So, yeah, so is there anything else to talk about this topic? Does anyone want to chime in? Okay, so if nobody has anything else to say, I'm going to go ahead and move to the table changes. So not very big updates. Joe is cooking some things up in the design front, but he will show them. I'm sure he will show them next week. Sorry, in the next meeting. So today I created a draft PR for the revamp of tabs and big tables. One of the reasons he's in draft is that I'm not sure of some API choices I made. And because I haven't uploaded the design briefs that Joe showed us last week, I haven't uploaded to the JIRA issue. And I don't want to take a PR out of draft status without the proper design documentation. I think that's a good practice to do from now on our side. See the PR is there. Everybody's welcome to actually encourage everybody to take a look at it, at least from the code and everything. So I'm going to go ahead and do some quick showcase of it. This would be what the new tables would feel like. I truly believe that these new styles were really fitting within the rest of the UI, especially if you take into account the side panel, the hyperlinks and everything else, basically. Especially with hyperlinks. Maybe it's because I'm biased. I really, really like it. So this is what the planning table would look like. For example, let me go to all here. You may notice that I have a right and left align all these columns, because in order to improve legibility and accessibility. I have also, for example, here you will see that these colors, these color is the same as the breadcrumbs as the footer. This hover color is the same as the ones in the, that's not showing up. It's the same as the one in the sidewalk here. So it's, we're also moving towards a more consistent color palette, which is good. Yeah, and these are the tabs, basically. I encourage everybody to try. I really am really proud of the work Joe did with designing, and I think it's really nice. But we are open to feedback. Of course, everything can be improved and iterated upon. So we encourage everybody to give their feedback. Can you click on the updates tab? Yeah. So for some reason, this table feels fine to me, but the job table just seems to be a little bit funny with the header. Which one then? I don't know why this one seems okay. But if you go back to the main page, for some reason, the header bar just seems a bit out of place for me there. And where do you see the top left active tab? What does Celo just place it up? I think it's, possibly the color is a different color to everything else. I'm not sure. It just looks a bit funny at first glance to me. But I do like the design of the rows a lot more. I think that looks quite a lot nicer. Yeah, I think maybe it's because what you see here, you may notice that this is, there is this underlying this table doesn't, this step doesn't completely blend into the, into the header. And that's because otherwise it just wasn't possible without changing the styling of the table in relative to the, to the, to the tabs. Tabs were a difficult component to style, to be honest. I had some trouble working on them. But yeah, they are not perfect. I also introduced the ability to have a tab baseline to have just standalone tabs that have a whole, that span the full width of a container and then everything underneath them. One of the things I wanted to people to try and give feedback is because I wasn't sure how to do them is, for example, cases where the app by a part of the page has tabs but uses a pain frame widget. For example, this case, this is the thing I'm probably looking feedback or alternatives into what we should do because this is a weird one. I think that for this particular page, our strategy is to get rid of that move it to some way to global configuration. And as long as you keep it working, it should be okay. Yeah, I don't know. I just wanted to keep to styling. I would first remove the border but the reason I couldn't remove and then I realized this was supposed to be outside of here. But I don't know. I wasn't sure how to do what to do with this. What I probably do is I probably create a follow up PR in a few weeks, walking on the pain frame, maybe adding another border. I don't know, removing the border radius. If this goes through, of course, if not, if everybody thinks he should work on the pain frame now. I will, of course, depending on the people. We worry about this page too much. It's a kind of expert page. It doesn't work now anyway. Ah, yes. Yeah. Yeah, but also some user experience issues included, for example, HTTP proxy configuration. It's kind of figurable in a plagued manager, but actually it applies globally for your Jenkins instance. Yeah, it's so weird. So this part definitely has to move elsewhere. And for the rest, upload plugins, etc. Yeah, don't look too much as long as it works. Yeah. I mean, I use it all the time like that. As long as it works. I think it's overall, it's a huge improvement. If anything, I would invest your time on making those tabs look a little sharper. I mean, the underlying at the bottom, I mean, the border at the bottom of the tabs is more disturbing to me than the pain frame. Yeah. Yeah, let me work on this a bit. I think it was difficult, but I mean, just if you have a bit of time, that's, wow, to me that's the most visually. I did go into several options and that's the best I could do, basically. It's the best I could do. So something that I could try is, yeah, let me, so something that could be that I could try is, you know, just making something. Okay, I need to do something like this, you know, having a full width baseline. This is something that I actually added an option to the top bar to show the baseline. And it can also be shown by default. That's what they put look. So there is no way to make it look right right now in Jenkins, but I think that's a nice compromise. What I would actually do is I would put all of these on top. And on the other pages, for example, I would nest, I would keep the top bar on top and put everything in, beneath it. But that would mean a follow up PR, of course. I mean, overall it's straight ahead of what it was. I mean, it's much better. Yeah. Yeah. I have also created the corresponding issues into the dark team plugging. I don't know if you noticed him. Yes. So yeah, I encourage everybody to try. Everybody to give their thoughts on. And if there's any blocking thing, for example, if the top stuff is a blocking thing or something like that, then I can work with it. If not, we can iterate it into in the future. But yeah, I appreciate any feedback on this one. We just need two tables. And tabs. And with tables on me, I mean, big tables. Yeah, they will skip the big table class. So is there any other big table classes? So there's the jobs. So there's like the. This page. All of them. Basically, all of them, for example, this credential table. And yeah, let me go. This one, this one. Information. So all of these are effective. This one, for example, this one, this table revealed the need to use a proper semantic markup to separate the heading as the footer and the body of the table. Something that I may create a PR in there. I will probably create a PR after this one. To. To allow for. To have the body and the foot elements with proper styling. The users table decision information stable. And I found many other plugins that use this. So it's, it's, it's a target in the big table class was a allowed us to consistently improve the look and feel of all tables basically across the Indians. I don't really, I don't know how it would look if you just started the big table class to the to the other bootstrap tables. I don't know how it would look to be honest. Yeah, I should probably be okay. I'll try it. Normally, the things I'm using are not so young. It's not so black and full of color. It's more light, you know, lines and which I'm not sure if it matches correctly. So I'm wondering why are you using the black header of Jenkins and not the blue one. You don't like the blue one or it's actually not the same black black. It's actually what the secondary button color, the secondary text color. The header line, the Jenkins header line, you are always using the old style and not the blue one with the, you know, because yeah, I'm because I'm showing in this off my local Dev environment. And I just, it just makes the, the, the command line entry 30 or 40 characters longer. So that's why I'm not running it. I'm getting revisited at some point soon about either better rating on us or enabling it by default. Yeah, I have something we want to talk into. Let's have a, let's have another point of order for today for now. Let's talk about the new header. So do we have anything else to talk about tables and tabs? Okay, so let's talk about the experimental header. So I think we already covered this a few, a while ago, Joe may comment on this one. We always say that the beginning that the header that we were 110% open to iterate over components, and that's something that's probably needed. The header and breadcrumbs components were developed at the beginning of the project. We didn't really have the full picture of where we wanted to go, what the color palette was going to be, what the design season was going to be. For example, we started using the robot the font and then when they probably will change it to the system phones. That will what I want to say is that it needs to be revisited to see and determine if it's consistent with the how the design system evolved. And if we want to keep it, if we want, for example, do we want to keep the blue header? Do people actually use it? Is it the right shape, shade of blue? Is it better to have a more darker shade of blue like we now have in the primary color? What do we do with the logo? That's something that should be discussed. Definitely. Because it needs to be turned on by default, otherwise you get very little feedback. Yeah, I mean, yeah, exactly. The feature flag UI that encourages people to turn along. Yeah, because right now, one of the things, one of the points of the feature flag of the UI feature flag was to enable just to hide changes that would be too controversial of the code break plugin. Turns out we were lucky and we didn't do that we didn't need it. We all the changes that we've been working on for the past five, six months, we were able to integrate into the mainline. Minimizing the effect they had on plugins. So, does experimental, does just a header color and logo change warrant, especially a feature flag? I mean, I don't think so either. So that's something we should talk about. Maybe we can make it a point to, Joe, do you think we can, do you think you could have a look at it and have a proposal or something for the next meeting? Yeah, for sure. In fact, Felix, this is something you and I haven't discussed yet, but I've been working on this sort of on the side and have updated designs for this, like we kind of talked about a couple weeks where the logo treatment is adjusted, the color treatment is adjusted, and also, if I remember correctly, font size on the breadcrumbs has some tweaks to feel more appropriate in the space. So yes, definitely, and we can take a look at those changes in the next six. Okay, great. So I will add it to the agenda right after this meeting. So, does, is there anything else to talk about this topic? One comment. So, yeah, there is a header. There is experimental your flag. First, I would prefer to keep the experimental flag regardless of whether it changes header or not. So for example, for tables to leave so we can use the same feature flag to enable that. And maybe for future improvements. Yeah. Yeah, I mean, what I want to say is that the right now, I don't want to fall into Jackney. Right now it's not. That's what I mean, and the flag is called Jenkins UI refresh anyway. So, I mean, for changes are big enough that I think they were on their own flag, or their own setting. And, yeah, I don't think I think just keeping the flag, we could incur into technical debt. I mean, if it's not needed, if it's needed and we find more users for it, of course, in the future. It also introduces a documentation burden and everything. Yeah, that's why I'm thinking about keeping a single flag so that we can document that he if you're interested in experimental you can set this flag. Yeah, the document would exactly include. Yeah, well, if we have more stuff, sure, right now. I think people are not people who say, okay, use this flag to enable the experimental Jenkins UI and they just see a color change in the header. People are not going to be impressed by that. Basically, so I think it's too little to warrant it. We can keep it and use it in the future, of course. Okay. So, if nobody might say we can move on to the next topic. Yeah, something I want to change. Well, what I'm not able to dedicate proper the need of the amount of time that they was to this. I do have some spare time. No, maybe I wanted to raise the point to see if there's I wanted to raise the question to see if there's any quick win. In UI wise or UX wise, we can do in Jenkins, something of tasks, a few tasks that take more or less a day or something like that. That we could do in preparation for the next LTS just small things that would be nice to have there are any ideas on this topic. I just wanted to flow to the question to see if anybody has any ideas on this one. It's the monitoring plug and link. It's not broken right now. Okay. Oh, well, that's something that needs. Okay, let me write it down. It's completely escapes its container. It looks horrible. Which one was that Tim? Sorry, could you repeat it? I'm monitoring management link on the managed Jenkins page. It was part of the managed Jenkins page rework. Broke it worse than it previously was. I don't have it. I don't, I don't think I have it. Yes, I, I, yes, that's the issue I recall an issue. Yeah, that was a bit of a misuse. If I recall correctly of abuse of markup that yeah, that's something that doesn't really look right. Doesn't look right. It's very broken. I didn't want to be harsh. But yeah. Okay. I was just browsing my instance looking for weird things. Yeah, I mean, one of the things that for example, I, I don't know. I think, I think that they would, I think we, we have a comprehensive set of changes with the sidebar tables and tabs and hyper things for the next year that users will definitely see change and the dark with the dark theme, of course, not, not a one day change but move blue ocean into regular Jenkins or something. Yeah, that's going to be hard. Yeah. Yeah. I think there's something in the community road map for that, but I'm not sure. Yeah. I'm not yet to be seen. Well, we've got a lot of feedback for Jenkins pipeline browsing improvements is a part of your years hug fest. Someone is interested to try and hug this topic together. I would be happy to scale something maybe in August and September. But yeah, right now there is no confirmed plan for that as far as I can tell. It's so hard to develop on it's so heavy. It's so difficult to even start it. For what is worth. Yeah, I just wanted to joke about blue bus microhug. I wanted to actually create a really small fork of lotion which would squash all the complexity that the rate of editing features actually just leave browsing and remove all the crappy dependencies like jr plugin so that keep it really concise and have it as a separate plugin. But yeah, I haven't went much beyond the concept. I tried to one of the, I, I, a while ago I tried to, to use the react to create a react with yet that you would use the lotion API and the lotion components to render them to render the the chart on a normal Jenkins plugin. You know, sorry on the classic can just be right. It wasn't that easy to reuse those that stuff I think we shared to just copy and paste the code and created from scratch. Yeah, that's not that's my insight because I did try it for a few days and they got nowhere. I've had a bit of a hack on it on dark theme work and they did manage to get development work by going but it was a pain and stuff didn't work for very well and it needs some dependency updates as well. The latest node and gulp don't work and stuff. Yeah, nothing is a tough one because I feel bad because every now and then I break it. Yeah, I don't want to break it that much dark theme is an incubating project. So personally, I'm perfectly fine with any breakages, especially if it helps us to facilitate feedback and to help and helps us to deliver something stable for the next LCS baseline. Yeah, dark things really easy to fix if you break it and it's also really easy to be compatible with both versions as well. So it's not really an issue. Yeah, but but what I bought and maybe what we could do is to add an official entry to a documentation entry. How to guide for for plugins to support dark theme. Because but what we would need because I'm pretty I'm afraid some plugins with just use the CSS variable without the fallback value. I mean, the plugin just will not work in terms of right. So that's something I'm afraid of. And also, for that we would need to choose official minimum CSS API a support the CSS variable API, and just productize it. I don't know if that's the right word. Yeah, make it official. It's just still being developed right now. So, yeah, the CSS API we can start documenting it, for example, in a web browser support policy, because we have this page so we can include something there. Yeah, yeah, I don't know what my point is for example right now we have around the theme file has around 200 300 CSS variables. I think it's in the order of 200. But I wouldn't call those as stable API maybe 30 of them are stable like link color link color all of those variants. But we just cannot say okay you can you have plugins to it's okay if dark theme uses them. It's a different thing if plugins depend on variables that are maybe refactored out. That's great. Not sure if it's worth several in the stable and experimental. But yeah, it hasn't been too much of an issue plugins. Yeah, you're possibly a page will be useful and putting the dark either in the dark theme repo or Jenkins for theming. Yeah, I think dark theme could be a good starting point. But technically, we can edit to developer guidelines because it applies to anything. For example, if we update now to seem to CSS variables will be exactly the same keys. You already have a theme management for users. So we could create theme development best practices page in the plugin developer guidelines. And after that, yeah, we can create a blog post or whatever to just highlight that or maybe developer meetup. I'm not sure. Yeah, but that would make that would make it sort of official. That will sort of be a sort of officially support themes. Well, you already documented themes support policy on the Jenkins interface with disclaimer so that we don't guarantee compatibility, etc. Yeah, sorry, what I say is that you would officially show an API. I think if I don't know for me it would feel as long as you publish an API and you document an API, it changes everything right in the flexibility you will have to iterate and everything. I'm not saying it's valid. I'm saying it should be done with care. Well, we can avoid the document in KPA. We can document best practices. So for example, if you develop a new theme use Jenkins version or whatever plus you see CSS variables, support, but fall back so that Internet Explorer compatibility is retained. So something like that. Sounds like a great idea. And providing the dark theme as a reference implementation that if you want to follow example, the look at dark theme. Yeah. Okay, yeah, you I think you're right. You do make a great point. I think maybe. Okay. Maybe we're gonna see this recommendations. We have updated the info at least for maybe things should be updated every LTS. At least maybe things should be. Make that. Yeah. Let me let me write it down. Okay. Yeah. Anything else somebody anybody wants to talk about. I've got dark theme working with each hearts and the bootstrap plugin. When I see you. Would you would you share your screen with it? No. So this one is the bootstrap plugin with warnings in J. So signal that but So this is the warnings. This is running the warnings in G build. It's not perfect but I spent quite a while getting it reasonable. I overrode some of the bootstrap size stars with the Jenkins variables. So there's already a Jenkins style which makes it look better on Jenkins. So you see some of the problems that the CloudBees Jenkins health advisor plugin has. The bootstrap API plugin doesn't have it because it's got this file which makes everything fit in a bit better. So basically the section here just resets some of the bootstrap styles back to Jenkins styles. Yeah. Yeah. About the CloudBees health advisor. I mean, it's I think it's a completely different thing because it uses bootstrap just to show alerts. It's going to be fixed as a bump baseline. This is a much more complex case. Definitely. I think I will try to look into this plugin something I've been wanting to do for quite a while is looking into the bootstrap plugin. And for example, for me, it makes no sense in well, it would make little sense to. Let me phrase it would be better in my opinion. To that the version of bootstrap that ship that the bootstrap for API plug-in ships. Do it does not contain a typography resets and basic style resets and everything. It just includes, for example, table widgets. You think it would scarves anything to everything else. But yes, they shouldn't override the typography of the page, for example. And that's something I think can be done to modularly load the CSS file. So that's something I wanted to look into the future and that would reduce the need for you to work on. For example, the body, then the changes to the body tag. You shouldn't need to do it. Yeah. Because the plugin will always run within Jenkins. And Jenkins will always provide. We know Jenkins will provide a set of base styles. Yeah. I didn't have a lot of pressure just dropping it back and seeing what was in use. But there were quite a lot of things in use just around the table. It's another icon out of it. I don't know if I probably wouldn't have time to do that full strip back. No, no. You should do it. I think it's great. Yeah, I think it's. Yeah. Yeah. Yeah, it looks great, actually. Did you, were you able to try it on Internet Explorer 11? I could if it though. I haven't currently. So it's next for a little bit. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. She's getting good with that. Yeah. Yeah. Yeah. Yeah. Yeah, yeah. There we go. Uh, So it's an X for Aliva and should just look like what it looked like before, so none of these styles should get applied. Yeah. This is just so anything that's not missing should fall back to what's certain bootstrap. The other one is the e-charts plugin, so this is, I've only done the trend chart so far, but this is like the JUnit plugin, and then these are the warning and warning into G charts. The only thing I've set is the text color. Without these changes, the text color was two faders. I think it looks great, but that's my opinion. Literally, it's just this line here, it pulls the text color and then pulls back to this, if it's not available, and I've tested it on old versions of Jenkins and it works fine. Yeah, I love the way CSS is run, the way that you can access CSS variables from JavaScript. Yeah, the hardest bit is just the e-charts documentation is very, very, very extensive, and it's very hard to find what you want. It's like API documentation, but it's not very user-friendly, put it that way. I found the right variables in the end. Mm-hmm. Okay. Those have all got core requests open, and so that's the JUnit one. The latest state of the JUnit one is the top one, which I showed last time. Looks great. I think it's a nice approach. I'm wondering, Uli, were you able to work with the new color palette in Java as well? Yes, I tried it. I posted some pictures, but I didn't find much time this week. I thought it would make more sense to have it some kind of toggle, so you can simply switch it in the user interface. Otherwise, it's a little bit hard to change and look at it and change and look at it. I thought it would make sense to make it simpler to configure, because the current colors are a little bit, let's say, I don't find the right English word there so hard, and the old colors are some more smooth and some not so... Yeah, I understand what you say. And the same is, maybe it's comparable to your new tables. The new tables with this black, everything black, it's very hard if you look at it the first time. And if you look at tables in GitHub, for instance, you just have these small lines, and now we have these hard blocks everywhere, and the same is for this color palette. So I think the colors should be a little bit more not smooth, it's a little bit lighter. Or how do you say it? Warmer, maybe? Yeah, warmer. Or softer? Yeah, softer is better. Yeah, softer. But I think I'll try to find a way to make them configurable. Then it's maybe easier to click in the UI and then change a slider, and then you see how the colors will change. It's easier to see, I think, rather than compiling and deploying, and then you see the new colors, and then you can't compare to the old colors. So... Yeah, you should be able to hotswap that. Yeah. Yeah, it's a bit annoying that those colors don't change live when you change CSS or anything. Yeah, currently it's in Java, the colors, but maybe I think there is a way to replace them in the in the JavaScript part. Yeah, possibly there could be CSS variables as well. Yeah. Mm-hmm. That would be much simpler. Doge charts has a theming capability included, so you can change the colors of the charts using a different theme, but I'm not sure how this would work with our theming concept. I'm not sure if that works, that we can use Jenkins themes to style the charts, because I think for the black theme, you need a different color for all these things, otherwise it looks a little bit weird. Sure, that's something we can do. Probably we can use them. We have a wrapper for the each charts API, right? I think we can use the CSS variables there, probably. But I don't know. I haven't looked into it. Uli, may I share my screen for a second? So is what you were saying something like this? Pardon? I don't know. What are you asking? The table color, I mean the table heading color, something more... Yeah, I'm still thinking all modern UIs don't use a background color, they just use lines to style tables and tabs, like the calendar and my tab. This is just a line and no color. You have a look at GitHub, when they use... I think the color is so... Yeah, it's so highlighting everything, but the table header is not the interesting thing, the table is the interesting thing. Yeah, here they use lighter gray. Yeah, and if you look at the tabs, for instance, in GitHub... Yeah, they use... Yeah, they have different tabs. Can you click at code? I think in code you see some tabs inside. No. I think it's in issues maybe or in pull requests? Yeah, this... No. I don't know. To be honest, I'm not informed. Sorry, can you open one pull request? Just... Okay, I'm dark theme plugin. You're one of the closest ones, it does not matter. Just... Here's... Just open it and here you have these tabs. And these are the typical modern tabs, I say, where you just have one line which shows the surrounding. The same is in Bootstrap, they also use just a line. And I think this using a background for all these tabs is so hard, somehow it takes the focus off with the eyes. And I'm not sure if it's so good. So in GitHub you see it's everything is so kind of light and soft. And using a background color for the tabs is somehow... And the problem I found is that, for example, tabs in Jenkins, these are great if the tabs are standalone and just section everything underneath them. But here in Jenkins we have tabs attached to tables. That's actually what it's... Yeah, I know. So maybe we can add a top variant. It's easy enough to create a top variant color. I actually quite like the way it looks, I mean, just to be contrary. I mean, I think... Yeah, maybe she just... It's my issue with it. Just looking at that screen, my focus goes straight to that header. Yeah, because I think it's because this header isn't a primary color. I think it's... I very much prefer this. I think using this in this way, I think the header is neutral enough in the color of the top. It's definitely less eye grabbing, but it still does draw you there. Would you prefer to go with a gray like this one, for example? I prefer this color to the one you had up before. What if it wasn't... What if it was no color, though? No color. Yeah, I can... Let me sketch something out tomorrow, okay? I'll see what I can do. It's going to... It's not... Let me give it a try, okay? So under you are actually... Can you have any insight of the current to design trends regarding this element or of colors or anything? I don't have any preference in terms of color. I think that I feel like generally speaking, having tabs, you really only need the border to make it feel like it's all included, and then the table can be a separate element. When it's like a combined tab and table, it's difficult because you're trying to make the header the same color as the tab. But if you just move the table into the tab section, it might be easier to understand. Header into the tab section. So you need to find it in the tabs on the headers. Yeah, like separate the table, like move it down into the tab, so the tab is just like a container. Yeah, okay. Yeah, I see what you mean. Actually... I think you need to understand. Otherwise, instead of a tab, maybe it's like a toggle? I don't know. Yeah, I think this is a good case because it's only present maybe here and in another place. And the problem with these tabs is that it was sort of... I recall seeing... I was doing some research yesterday or today to see where this was implemented. Only, I think there was a piece of feedback from you that argued in favor of putting together the tabs and table and removing separation. The problem with putting an underline, by the way, is that it looks really weird having a different color line between the tabs on the header. Yeah, I don't think that you need necessarily to make a border underneath the tab. Just maybe if you considered the tab as sort of like file folders, what they're kind of modeled after, and then the table is inside of it instead of putting tabs onto the table. Mm-hmm. It might just make more sense as a container, but other than that, I mean, this works. I think it does just fine. It just sort of is like putting two different mental models together, right? Yeah, so what we did is try to work within the framework we had. If we want to go on a more radical... So, yeah, I found out this PR. Wait a second. So, there was an existing PR a while ago, six years ago, basically, that created this. The first thing was this. I found this earlier today. So, in chain, well, we can follow this discussion. I will put it on the minutes. So, basically, it eventually became this on this discussion. So, do we want to reopen this discussion? I'm asking, yeah. Yeah, you can also have a look at the tables from the warnings plugin. For instance, they use quite a softer model. So, the tabs and the tables. And, typically, in tables, you also have a search and a filter and things like that, which are currently not used in Jenkins, but they can be used. So, yeah, okay. Wait a second. Okay, we're over at the time. I don't want to delay this any further. Yeah, so, you're using this? Yeah, yeah, exactly. Like this, right? The tables in the tab, instead of being part of the tab. I, let me say that I very much prefer this one. Also, we just started to work within the framework we have. What I suggest is let me try to come up with some alternative heading colors with maybe a black, sorry, a full white heading background. And let's validate it. Maybe I will share a few screenshots tomorrow on the PR as part of the discussion. I will ping you, Uli and Tim. And, yeah, we iterate. Nothing stops us from shipping something now and working it next print. Yeah, absolutely. Because what I'm afraid of is that we have, I think, I don't want to delay any meaningful improvements of tables for the next LDS or something that we can just iterate. Sure. So, do you agree with this approach, Uli? Yeah, that's good. Okay, great. Yeah, and we're over the time. Thank you, everybody. I think this has been a great meeting. See you in two weeks. Okay. Awesome. Thank you. Thank you. Bye. Bye.