 Cool, well welcome everybody to the next iteration of the UX SIG meeting, small group today. We have our typical items, obviously nobody new today, so we can skip past that and dig right into some updates here. So the first one, oh there we go, hey Jeremy. So the first one on the list here is called welcome screen UI, it's under this title of empty states and we'll see why in just a second here. So I'm going to share a brief design deck and then we'll talk about implementation. Shall I take the minutes, Joe, just the housekeeping notes, that would be great. Sorry about that, I forgot. Yeah, I'll take care of that then. Thank you. You're welcome. All right, so the item we're looking at here is the welcome screen UI in Jenkins. We had talked about this previously, I think, real briefly how we wanted to improve this. So here is what the design currently looks like. There are a couple of different configurations possible in Jenkins, depending on the user's permissions. But here's the current state, you know, grayed out all of the other elements here so we can focus on what matters. And here's the updated design. And to note here that this is very much still a static mock at this point, this is not being implemented yet and Felix can speak more to that shortly but this is very open to feedback at this point still too. So looking at this, some key takeaways here that this, the goal of this is to improve the usability by doing a couple of things, making the style here more consistent with the other components that we've redesigned. And also by providing additional context for the situation. Everyone on this call is familiar with this state. It's not an entirely common state, certainly. It's not even really arguably that confusing. But we have an opportunity here to introduce a formal empty state treatment. And so that's what we're trying to do. And we'll look at some more variations of that, but any questions or thoughts on that before we dig further? We have like an image, not just something to. Oh, sure. Is this, sorry, is this not showing up? No, no, no, I mean, what I'm seeing here is all text. I'm just wondering if, you know, we have a lot of empty real estate, can we just show a pretty picture or something? Gotcha. It's not. It's a pretty common thing to do that with empty states, right? And it offers an opportunity to inject some personality in there. I don't see why not. I personally lean toward keeping things more minimal and not overwhelming, especially since the configuration here could be a little bit, you know, depending on the permissions we might be offering three different options here with external links already. I could explore that if that's something we think would be useful or beneficial. Maybe we could get the Chuck Norris plug-in print still to the non-habit shots first image. That's what I'm not too sure about, but you know, but something agreed, there's an opportunity there. Whether it can be done gracefully in a way that doesn't push the more important detail is here out of the way, I can explore. So let me check into that and provide a mock-up for you in the next segment, actually, we'll talk about it sooner than that Jeremy and maybe like kind of like a line artsy kind of Jenkins figure, you know, like a light gray, just, you know, I don't know, just thinking something subtle, you know, yeah, there's there's an opportunity here. Yeah, I think I think there's probably not much more for me to stay on it right there or for now, except to say that that's worth exploring. So let me check into that. I quite like it. Like it's a lot nicer that I think from the existing one. I was wondering, the one bit that I'm not so sure about is how it's got like create an agent, configure a cloud and create a job. It's kind of like the first one is two different options. And the other bit I'm wondering about is whether CDF an agent or cloud should be as part of creating the first job. Yeah, it's a valid question for sure. My goal here was really just to to update the style of what we currently have. And so to provide those same options. This could be an opportunity to to reconsider those a bit. But I think that is a slightly larger discussion. But what would you suggest there? So one thing, so the first one, it's quite clear that you create an agent or configure a cloud to this one here doesn't really convey that it's one of the first two options. I could say that, yeah. I wouldn't get too hung up in copy text because this is just the same mockup. It will need to go through copy editing process anyway, so. Yeah, this is a good point. Thanks, Felix. It will need to be verified. The copy that we see here will need to be reviewed by the documentation writers to make sure that it's clear and consistent. I do see your point there, Tim. I'm not sure that we want to solve it right now. The goal really, the scope here is just to change the style. Yeah, I think it's a big improvement. That welcome to Team Kansas always bothers me that doesn't feel right. Yeah, ironically, I actually like the bit of personality with welcome to Jenkins personally, but I think it's more important to provide some context here and say what would actually be here and why are you seeing this message? Yeah, great. Yeah, Rungsha. All right, cool. So just to reiterate for my own notification, so, Jeremy, I'm going to take a look at what we could possibly do. There was something more visual and Tim, that's a good point. Let's keep in mind that we're going to have to review the documentation here about the copy, but I think we're not going to probably solve how these relate to one another right now. This is just more really stylistic for the moment. Yeah, even with the we're not going to have so much to say, but whether you can separate the top and bottom section a little bit of the agents and jobs as separate things. Yeah, maybe. OK, I will take this into consideration. And this is something, you know, I mentioned here that this kind of introduces a formal empty state that could be useful throughout the rest of Jenkins. So this is in a way just the start of a new type of treatment, right, that could be implemented in many other places. And we'll actually talk about that pretty in depth in the next meeting. But that's good feedback for for taking into that consideration of how we could have options relate to one another more more intelligently than just a stack of items, perhaps in the future. So just like with the current UI, depending on the users permissions, these options might need to change. So just a different iteration of this is just the option to create a job or an agent or even depending on the sign in state, the options to log in or sign up, again, not trying to introduce anything different in functionality here, just an adjusted style from what currently exists. And I think I may I may be repeating myself, but really important takeaway here is that just like with the rest of this initiative up until now, we are trying to improve these experience through improved style, improved design. So it's really key that the interactive states are as consistent as possible with the other components that we've implemented as well. There's some slight deviation in the treatments here. But this component also exists in a different context within the UI and it gets a different background than say a particular nav item in the side bar. So it does require some different treatment, but using the same color palette, the same text styles, that sort of thing. But somebody going to say something a minute ago. Sorry about that. It might have been made, but it's OK. Sorry about that. And the last item here was just seeing it in context. You can see that it relates back to the other improvements pretty nicely. So we're overall just like with other components, making a more consistent UI piece by piece. Nice. Any anybody else for now? If we can move ahead to the implementation detail discussion. For sure. Yeah. So I was doing some tech analysis of these improvements. And I did find out that this is something that if we approve and go ahead with this design, it will be tough to support the existing translations for the empty states. First of all, the copies change. We cannot do anything about it. But also the way the current translations are set, they are the each line is online. And the hyperlinks are in line within the translation. So what that means is that it's going to be tough to actually be able to implement it without breaking translations, without breaking internationalization for existing localities. I don't know if that's acceptable or if it's not what an alternative could be. So I appreciate any ideas on this one, especially with the theme. Do you think it's only for the welcome screen broken or for everybody who is using that concept? I know it's for the welcome screen. I would guess it's for everything. Okay. They use it as that state. So the translation is just default back to English, if the text is missing. Yes, but I mean, maybe we're for everybody to just see again if we were to a huge English block. I don't know. I mean, I think that's kind of, you know, just the reality of making changes to new elements that, you know, new translations will be required and we have a fallback to English. And the localization teams, if that's sufficiently motivated, it will hopefully come. This is one of the least seen screens by users. It's only seen by the admin when they first install it. Okay. Yeah, I just wanted to mention it then. So if everybody agrees, I can go ahead with a PLC. Yeah, I don't really understand the problem. I mean, I just don't want to break old, like I'm looking at them right now, almost 20 to 30 translations localize. So if it's okay with everybody, yeah, it's okay by me. I will go ahead with it then. And also something that you may have noticed, I mean you, because you may be the most interesting that I think this is an opportunity to sort of introduce some sort of card component here. We will try to make reusable components, not ad hoc stuff. We will try to do reusable stuff that everybody can use later too fast so that Jenkins can finally have some sort of card. And I dreamed big the other day and maybe I have the idea that for people with a more skill of extensions point at night, this could be a listed in this sort of screen, could be a good place for, for example, imagine that maybe the list of call to actions could be an extension point. So that plugins could register another own call to action. For example, the pipeline, create a new pipeline or a cloud agent, create and register your your agent or I don't know if Jenkins could have something. So that's just an idea I wanted to float. I don't know if necessarily that's a good one, but maybe it is sort of the least format could enable us to do it. Yeah, one thing I'm not understanding is the bottom line is this the title or what is the idea of the learn more about distributed builds. So typically you have a title for a card and not a bottom line. So I understand it as a card footer or a content block footer and it's more for the more bottom. Okay, exactly. It would be the equivalent of this item here. So if there's a relevant documentation or external link, it exists in a different place in the anatomy, but it's a card footer essentially. Yeah, I'm not sure if this kind of component will be used by so many plugins because this is the idea of Jenkins is to use everything by code and not by clicking around in the near future, hopefully. So this is something which is more a kind of wizard thing. And I'm not sure if we have so much requirements for providing such wizards. I think a lot of people are using Jenkins configuration as code to set up the whole instance. They don't want to use any UI to configure the Jenkins instance. I think this is more for the first time user day. I mean, this is probably not so much if you're setting up your 28th master, but I mean, I think the problem is if you've heard about Jenkins, you download it, you install it, and you have the now what problem, you know? And this I think is the good start towards that. And I agree with you that I mean, if you're experienced, you won't be using this. You'll hopefully be using some kind of automation you'll know what you're doing, but... Yeah, to that, I was also wondering then, just for this particular screen, instead of the title, No Jobs Created, I think that's already very specific. I mean, like, okay, we know that this should be where the jobs are listed and it's nothing there. So we want to create a job, but maybe just, you know, let's create a job or let's start building or something like that to be more towards what users can do or want to start doing instead of trying to figure out, you know, jobs, what are jobs? Yeah, you know, these kind of questions, you've got a really first time user, like Jeremy just said, this screen will be mostly used for. Yeah, I think that's really good feedback. Thank you. It depends a lot on how we're thinking of this and this is the first time that we're introducing like this type of card, right? But if it's specifically an empty state treatment, there are different ways of coming at that, but either way, this one does establish how we label these types of states. And I think it could be a title that's more geared toward something a little more actionable, maybe a little more positive, as long as it's specific in explaining why this state exists. So I agree and keep in mind too, this is placeholder text, but let me update the mock with something a little bit more appropriate and we'll see what the docs people have to say on it too. I think that somebody stopped me if we're not ready to move on and that's totally fine, but I think we may be for the next item, normalization of different colors. Yep. Okay. I just wanted to talk about I've been working the past few days. I was looking at the user of different colors, different grays, especially the grayscale on Jenkins. I found, but also about all of the hard-coded colors not currently stored in variables on Jenkins code base. And it's a bit of some sort of overwhelming task, basically. My initial goal was to try to, okay, I'm going to get all the grays fitting into these five colors that we have available in our palette. That's yet not possible because many cases, the design, the existing design of certain components depend on that. For example, the job configuration or the new item list, option list, the new colors don't look right. So that sort of needs a bit of a redesign and that's okay. So that said, I'm going to probably be landing a PR with some sort of normalization of colors or I think it can be a good chance to see how it will affect, sorry, how it could inspire other plugins to do it. Yeah, it was just an update of what's going on and what you can expect. And it will mostly be focused on the grayscale, grayscale and not on all the inline success grays and grays. Can you give a few examples of this? Yeah, let me look at it. Let me look at it and see if I can have something. The basic example of it is if you search the CSS and the Jenkins code, there's like so many different grays and some of them are using the variables and some of them are just using very slight different Yeah, but I mean, is this kind of, I mean, I guess what I'm fishing at is this a is this a problem from a code neatness point of view or is this a user experience problem for the end user that there's so many grays? I mean, I understand that it's obviously not nice to have CSS with part variables, part none and No, it's more of the former. But in the end, it leads to inconsistency. Yeah, sorry, it isn't directly a UX problem too, right? Because it's really important that so each one of those subtle different grays that we have in the palette we've established here with the sake means something and carries connotation. So having that inconsistency does harm the experience, generally speaking, over time. Sorry, sorry to interrupt. Yeah, so one example to continue something I touched was light backgrounds. For example, like we have like stripped rows, like the side panel Hover FX. That's a light gray color, which is a fade, fade, fade. There were really, there were a lot of similar several similar light gray colors that were not the same. Used across Jenkins. So what I'm doing is trying to consolidate all of those into using the palette one, the palette version of it. Also something that's something I was actually, I was able to do something that I skipped and I ignore was, for example, the colors of input elements, form elements, the borders, because I don't know how to do it without making them too similar to the secondary buttons, to the default buttons. And that's something, it's basically something that needs to have proper design attention, so I'm skipping it. It's not, it's less straightforward than I thought. Makes sense. I think, unless you have more to share on that for now, Felix, next item, I believe. Yeah, I think we'll change some design iterations. Okay, so we merged the tables, 1000 tables PR, there were some feedback. Congratulations. So now, thank you. We had some feedback. Feedback is spearheaded by Iuli. I sort of, I implement a few of those items, for example, I created a compact variant of the tables for the, for the, how do we say, the project view, the main view. And I'm wondering if we should, how we should proceed with that feedback or, because to be, I don't know if we should gather more feedback, more opinion on that, because there are many, there are many variants here. So somebody prefers the white header with, with attached tabs, white header with the attached tabs, white gray, light gray header with attached stuff. There are many combinations that I don't think not, not, I don't think everybody, any, everybody's agreeing on one. So, and I'm happy to just go ahead and do any change. So one thing I can do is try to make, to add variants in Jenkins with CSS, like I did with a compact option for the big table. I can add a white header option for the big table or a light, or a light gray header option. So that would allow table users to, sorry, plugin authors slash core developer users to add whatever flavor of table they want. Maybe that's not the best for general UI consistency, but they could have use. I can see how that can be useful. So in general, would this help or any idea of how to act on all of these different feedback? Wouldn't it make more sense that we start to provide more than one theme? So we have one theme. Now we have a dark theme, thanks to Tim. And then maybe we have a theme that has some kind of light borders theme. And we have a theme that is some kind of black header for table. I'm not sure. Hey, to be honest, I'd like to try to touch core changes from things as much as possible. I'm doing everything because the more we support things, the less we can move on and break stuff, basically. And right now everybody knows that dark theme is experimental, but if we just get everything into themes, so themes should be overrides, but we just still need to provide sane defaults. And if everybody prefers, if the consensus is a light white header with attached tabs, yeah, I'm fine with that. I really don't have a strong opinion on that one. But I don't know, creating a theme just for that, who should create it, who should host it? So there are many questions there, as I don't know. Yeah, there could be one path. Again, it's not something I propose for you to do this to Felix, but we have Neo2 theme, which is light theme and it's widely used. So if there was a contributor who would be willing to start migrating Neo2 theme to the new engine provided in the recent weeklies, then it could be a convenient way to have another light theme, because it's over the existing theme, which has some concepts, which could be adopted. Yeah, but what I don't understand is, I think it could be confusing. I mean, Jenkins default is the light theme. Why is there a need for a... Jenkins default is a light version. Dark theme feels a void, which is a dark version of Jenkins. For example, I don't see how it could be useful to spend, for example, just creating a theme and supporting it, because themes need support. Just for a light variation or something that can be done in Jenkins code. I think one of the main bits of those other themes is they fill gaps in the UI or UX experience. It's things like, it's the font, it's the sizing, it's the icons. And the icons are like a major part, because the icons and Jenkins are very dated. And some of it was just kind of giving out like a material UI look as well. But within the context of just a, within the scope of the header treatment of the tables, right? I don't know that that, my two cents anyway, that that justifies pulling that change or that variation into an entire separate theme. That's not to argue against themes in general or anything like that, just that I don't think this particular feedback justifies a whole different theme. I think one solution would be to do what you were suggesting, Felix, and make it customizable in that way. For me, I'm a little more opinionated about the style than, like, Felix, and that you're saying you could go with either one, and we just need to kind of decide, I think, but for me what it ultimately comes back to is which approach or which style, which one of those recommendations is most accessible visually for the most people. And I think in this case, it was the darker one. I'm happy to revisit that and make sure. But that's really what should be our deciding factor, because with these style discussions, it can be highly subjective, right? I have my biases. Someone else might have their biases because they use different tools. So that's all good and well, but it has to be the one that's most legible for the most people ultimately is my two cents on it. Yeah, so yeah, basically what I wanted to go is people, I'm fine with, I encourage having a discussion with and to see if we iterate. The point of iterating, of merging fast and iterating is to continue discussion. I just don't know what the best way to discuss those designs are, or how to gather more feedback or how to react to that feedback. So I'm a bit at a loss there. I welcome many recommendations on how to act on that feedback, because if the feedback there right now is different separate opinions, I don't know if I'm explaining myself. I just don't know how to gather it, or if there's any experience on this before on some sort of similar things. So I have not been in the Jenkins picture as long as everyone else on this call. So, you know, this is a very limited perspective, but we've had similar situations. This just within the UX to SIG, right, when we look back at the header bar. In fact, then it was certainly an issue of, there were some subject, subjective preferences, and it was an issue of compromise a little bit from my side, certainly, and ended up being a much stronger design element in the end. Thanks to the feedback of everyone here. So this may just be, you know, it's no one design, design choice will make everyone happy about it, especially when it's something stylistic like this. So I think this is one of those where we just kind of have to, that's why I try to come from the objective perspective of which one is the best for the most people, even more so than which one do I like better. I guess I'm not entirely sure how to proceed on it either, but Uli and Tim, I guess I would ask, does that sound like an acceptable approach given that we have kind of stylistic differences? What do you think on that idea of let's just go for which one is most visible to more people? Yeah, definitely. We don't need two options. We just need one that's good for most people. Yeah, but how do we obtain the feedback just from the mailing list? Sorry, which feedback in particular? I'm getting turned around a little bit. Yeah, for instance, to go for white colors or black colors on the borders. So I think in pull request, it was most of the people, or half people said it must be black and the other half said it must be white. So I think this is something which is screaming for, we need a theme for that. And we don't need an option that we have one table in this design and another table in another design that makes no sense for me. I think we should toggle all tables in Jenkins with one switch. And this should be part of the theme, I think. It can be done, right? A theme can happen. I know that this is just me speaking personally bandwidth-wise. I can't design additional modifications. I don't have the capacity to do that to support and constantly update a different theme. So that's totally possible. But I think for now, the goal is just to decide which one will be the choice by default, not whether or not that one style justifies a different theme, which it may. Yeah, I think mainly what Joe said is right. I mean, it is a bandwidth issue, I mean. Yeah. And obviously two themes means that you got on pretty much twice as much work to maintain it and test it. Yeah, typically, if we would have used Bootstrap, for instance, as a framework, we have 100 of themes available already. So I think, yeah, we have really a problem writing it on our own. So I think, yeah, it's okay. We don't need to support more than one theme. That is okay for me. So we should use one major theme for Jenkins. That is okay. That was one. And which one? Yeah. Bootstrap wouldn't work because the way Bootstrap is applied wouldn't work here. I can provide you with some variants. Can you send screen captures? You're getting some Docker containers going on if you can start up all or something on the on the main list. Yeah. I can provide you with all of those options. Personally, for example, I find the white header to have poor accessibility. The option is I find difficult on some monitors to see what's a header and what's not. If it doesn't have a contrast in the background color, for example. And I think defaults should take into account accessibility. That said, maybe the dark gray is too much. Maybe a light gray option could work possibly. Yeah. That's more of a maybe that comes in a statistic. Also, something that can warrant a change on header color is if we prefer to go to further iterate on the tabs and move ahead and create a detached tabs version. I want to remind everybody that we did not think there was a possibility or when we work on the designs, we did not consider the possibility of detaching the tabs because I thought it was a community choice or something that was wrong. If we want to iterate on the tabs as well, yeah, fine. I will try to provide you Uli with those variants, containers, branches, whatever we can or maybe just send screen captures and we can get amazingly thread or something going on. I don't know. I don't want to change it on my own. So please go ahead. If everybody else is fine with it, it's okay. I don't want to stop your development right now. No. I mean, what I mean is I have locally some style variants prepared, some CSS changes and some style variants prepared. And I can just share it. What I want is to see if should we question it, should we change something? If we change which option of tabs attachment and header color is it? Right now we don't have the bandwidth to go through a poll, collect all the people over everything. And that is a hard work. The easy job is just to make the changes and I have those almost ready. So I think I also shared some docker containers with that. Yeah, maybe it's just sufficient to have some screenshots. Yeah, okay. I will get those for you. If you ask Bootstrap theme plugin, think yes. We already have some styles similar to Bootstrap. Bootstrap is also changing continuously. And Bootstrap is more of a lower common denominator that many tools can use. Having Bootstrap just removes many some sort of personality for everything. Because everything everybody knows can smell Bootstrap. Yeah, I don't propose to implement it for the record. I just referenced it as possible option if somebody wants a challenge. Because yeah, you can take themes from Bootstrap. You can basically replace existing templates or similarly how we do in dark themes and potentially get theme plugin, which allows to use any Bootstrap theme. Yeah, most likely it will look like strange, but technically if someone is up for a challenge, it's possible. Yeah, I want to remind you. Yeah, the thing is Bootstrap, it's not a stylistic set of style of opinionated style. It's more of a Bootstrap-ish framework. It's a tool. And that tool does not fit well with the way Jenkins is done. So it's really awkward to integrate it into Jenkins code. Really awkward. And it will have no backwards compatibility options at all for anything. So there's the Bootstrap styles. There's no such thing as Bootstrap styles as a design guideline or something. They are just the default styles of a framework that everybody is supposed to if they want to change. So that said, if anybody wants to create as much themes as they want, the customizability is there. Lots of CSS variables. Everybody can go ahead and change everything. Yeah. Okay. So do we want to talk more about this topic or can we move on? Yeah, one thing from the Jenkins Core maintainer perspective. So we integrated the current implementation of tables and the weekly release. This weekly release, unless something goes wrong, is likely to become the next lcsb line. So it means that current dark headers are going there by default. If there is a decision by the seek to change that due to whatever reason, then we need to know about that. Let's say by the end of August. Because this change can be backported. But in principle, all styles and changes which we integrated into this weekly, most likely they're going into lcs. Yeah. The way you see it is iteration will happen every version. So we can iterate, we can go ahead with, in my opinion, we can go ahead with this. And then maybe for the next LTS or for the something, we can maybe we can try new headers. We can also try new icons. Hopefully we will try the new icons. Maybe a revisited header and breadcrumbs. So iteration can happen across versions. There are some stuff that I don't foresee we will change that will remain static. For example, buttons, hyperlinks, the sidebar. So there are enough elements that are going to be and that I have a high degree of confidence that aren't going to be changed. Yeah. So yeah, my point, I think in circles sometimes, I think we can safely go with this if nobody's against it. And we can iterate on the November release. No problem. Yeah, that's why I liked the LTS because let's say if there is strong negative feedback coming in the community, we still have an option to change it in LTS. Maybe even keep it as is in weekly and keep experimenting there. But if you want to do that, it's really nice to know about it by the end of August. The great thing about this is that these changes can also can be safely applied on the incremental on the releases and be reported. If we are only talking about variable changes, we can change it for a point two or something. Maybe. Yeah. As long as it's only variables. Thanks for pointing that out. I think we have different, within this group, we have different views on the stylistic preference, and that's okay. But since we since we are at a tiny, not a very big one, but a tiny impasse there, I think we having having it in its current state where it's more accessible of the solutions to more people is fine and we can change it in the future if that is correct. It's the right path for me. Sorry, go ahead, Felix. I was just, I was going to say, yes, we move on because we have 15 minutes. Yeah, we have an important topic, future work. Yeah, future work. I just wanted to share something that, yeah. So at the beginning, we, well, within CloudVis, we all together we created this roadmap. With roadmap, I mean, all these set of goals we went up to achieve. Headers, iconography, iconography, we went push down the line. Headers, typography, footers, buttons, tables, hyperlinks, side panels. And so we wanted to focus on core elements that would affect the whole UI. And we believe we are getting there. And we are comfortable ending this first phase of CSS only changes to end the CSS only changes or the CSS based changes after we maybe do the empty state buttons. Maybe we can revisit the header breadcrumbs and the table headers because the header and breadcrumbs need for visiting. And then I would consider this phase finished. I don't know, I cannot think of any more... It's still left as empty state, CSS. Sorry, I just want to get this. Iconography and revisiting header and breadcrumbs and table headers maybe. And I think we are at a great place, especially if we look at our before and after for the Jenkins UI was in January and now those bigger overarching changes. I cannot think of anything else that's better. And then we could start looking into deeper surgery as Jeremy likes to say to more important changes. What do we want to work on? Do we want to focus on forms? Because we have momentum working on forms. Do we want to work on the job history page? So that's sort of sharing. I don't want to start a huge discussion on what to do next. I just wanted to mention that we are meeting the end of what we want to call phase one. And that's okay. I like to have some closure. And to be able to say we are done, we have achieved. Yeah, just by the way, I'm in the process of writing a blog post for the CDF blog, which will be talking a lot about the work that's done so far and trying to get people to join the rest of the effort. So I think it's important that we have a good roadmap of where we want to go to next. Form seems like a logical one given the table to div kind of moves. Shouldn't we include table to divs on the list of spots still left? No, table to divs is a different initiative. I don't want to, we have this goal. I would like the ceases only changes. We have this goal. I don't want to have a scope grip. I just want to be able to have to compartmentalize maybe and say these different sub projects, we are done with them. It's better for everybody to have a scope grip there. Makes perfect sense. Sorry, I'm just watching the clock here. Tim, you added a couple items. Did you want to share a screen for these? Maybe for the dot thing, briefly. Okay, I'll stop sharing here. Yeah, I'm done talking. But how are we going to, I mean, I think it's important that we do try to define what's next because I mean, I think it's important for our first of all, our stakeholders at Cloudbees that pay your salary, that we have a clear, you know, pipeline. This is what we want to do next so they don't reallocate you to some other projects, which is always a danger. And second of all, I mean, I think, you know, we're trying to want to get people excited about this and to join if we have a clear road map. You know, we've done all this work. It's great. We've proven we can this shit. This is what's coming next. Come join us, you know? Yeah, 100%. I just don't think we have time on this call, but 100% agreed. Well, maybe we should put it as the main agenda item for in two weeks where we try to think of, you know, collectively brainstorm. Sure. Collective brainstorm. We can also look at the road map and we can see if we have UX research capability to see what the actual user interviews, to see what the pain points are. There's lots of ways we can decide, but I agree with this topic for the next session. Okay. Let's quickly do a brief demo of the new dot thing release. All right. And so released 005 this morning. The main change in it was aligning with the tables change. So now support. So it works with the latest weekly. And without this change, it didn't look very good. So that's done. And also added the text area handler, which is the drag down and adjusted some texts, adjusted the dark link colors and alerts. I'll just quickly show that. So this is the, this is the new alert used to be quite a light yellow. It still stands out, but kind of experimented a bit. And it was quite difficult to I think it looks quite good. And it's not everybody's gonna like orange, but I mean contrast well with black I think. So we've got success info, warning and danger. Okay. I definitely don't like warnings and error colors, but I guess it's the best thing for warnings because you may want to get rid of them. Yeah. So 100% open if anyone wants to do any experimentation. So the theme and capability for it's now in Jenkins core. So anyone is welcome to fiddle with the colors. They're more, I think they're more readable now than they used to be. But it's something. Improvement. Yeah, I started with this. I think it might be worth, this is nitpicking Tim. So feel free to tell me to not. It might be worth bumping down the brightness on the orange and the blue just a bit so that that white text is a little bit more legible. And it won't look quite as appealing. But this is definitely an improvement from where it was. So good stuff. Yep. Yep. You can certainly give that a try. Cool. So that's, that's the alert. Hold there. Hold there. Making a screenshot. Thank you. Got it. So alerts. So the next bit was the, where should I pick this page? Yeah. Almost there. Yeah. One question about alerts buttons. Do they have colors adjusted to alert colors or are they independent? The buttons haven't been changed at all. They just used the standard. Okay. So basically it will be darker blue buttons on any warning screen. Yeah. It seems same as in Jenkins. Yeah. There is nothing. There are no but alert button variants at all. Yeah. That's why I was asking because after that I may have missed this change. Yeah. So next bit is this little handle that you use to drag down text areas is now themed and matches the rest of the input colors. The dark link colors changed from the blue primary color to the regular text color. It's mostly was done because the blue primary was very light on the timestamp here. It wasn't very legible. But now it's quite a lot easier to read. I've re-based all the changes against the pipeline stage view pull request. I think I must have made a mistake in the red here but apart from that it looks just looking far better. Yeah. Definitely. It would be great if we could get Wow. And as much as the pipeline stage view looks good at all. But that's a different problem. Looks better than in stock. Thank you. True. Yeah. I mean it's used a lot. Yeah. I know it's used a lot. I mean it's something that you know even though we're going away from it would use a little bit of love I think. Yeah. I think is that a texting contrast? Yeah. So that's it. So not very much in there but just mostly paper cuts just trying to improve it. And the JUnit plugin is still open with the for the JUnit results. So I need some review over there as well. And the I think the e-charts and the Bootstrap API plugin are all merged and released. So e-charts work out of the box and I think so warnings MG looks fine now. So yeah, warnings MG was fixed but that wasn't there was no change to the dark theme plugin for that. And the CloudBeast supports plugins also been fixed as well. This has been a few issues closed recently. The question if you don't mind. What changes were made to the core for better support for theme ability or Word only? Because that sound didn't quite follow. In this release or in general? Well in general for the black theme. In general it was changing from CSS, changing from SAS variables to CSS variables so that we could change them at runtime. I've got an upcoming post for the CDF newsletter which I can share with you in case you're wanting to include any of us in your update. Sure, share it and I will read it at least. Yeah. Yeah so basically it was changing from SAS variables to less and overwrite and adding variables where there wasn't. So some places weren't using it. That was some of the gray that we were discussing earlier. Sorry it was less not CSS variables but LESS variables. So moving from less to CSS and in some places CSS needed changing. Bootstrap needed removing from some places. Right so it's kind of just like cleaning up core but to make it easier to make. Yeah core in plugins. The number of plugins have been changed for it as well. For example in CloudBee support plugin the changes are allowed to get rid of custom JavaScript and other bits which complicate the maintenance and it's not the only plugin where you're already able to optimize how your reward works. Yeah. Do you have anything really quick to share about the tables to this? Yeah really quick to share is that the CSS PR has merged for it. So both the CSS and JavaScript changes have been mainlined. The CSS changes haven't been merged back into it yet so it's conflicted but once that's done the diff should be just jelly files and very small CSS and JS changes. Are you still going to go ahead with the follow-up option? Sorry to be a pin option. Feature toggling out? Yeah or should we just try to power through it for the all in August? I'm not sure if I can be bothered doing the feature toggling approach at the moment. I don't have time but possibly just taking a look at some of the other issues and trying to fix them. Yeah I agree. Better use of the time. Yeah I agree with that. If we can, I say if we can unlock that layout breaking by issue we can just match it at the beginning of August in my opinion. Oh yeah yeah yeah I think the only way that I see the fixer is to adjust to change the layout and then change the layout everywhere and then patch the JavaScript because I was able to get it to not break by removing one layer of nesting but then a lot of JavaScript needs to change and God knows what the impact is. Well if it's what it's needed. Oh you just change a whole bunch of plugins. It's not, it doesn't break very many of them. Yeah. Okay so I think we are almost over the time. I think we'll don't call it a meeting. Thank you. If there's anything else anybody wants to say. Okay then thank you everybody for attending. I'll see you all in August in two weeks. Enjoy the beach Tim. Yeah exactly. Bye.