 Okay, I'm gonna go ahead and show my screen. All right, can you all see that? Yeah. Perfect. So we have a very brief agenda for today. We're gonna take a look. Actually, let's go through a point by point like we usually do. Does anyone have anything that they'd, I think we all know each other in this particular group, small group this week. Does anyone have anything they'd like to add to the agenda before we dig in? All right. No worries then. The first item we'll look at is just gonna be a relatively brief design deck looking at some button explorations and interactive states. And then Roman, you wanna talk about your exploration on the alert banners tiles. So let's take a look at this deck first. And please, let me know if, actually I'll go ahead and just make this full screen here. We're gonna skip past since I think everyone on this call has seen this, the standard slides with the regular information and we're gonna start here. So essentially something that I surfaced a couple of weeks back in a previous SIG meeting was that with our April goals, one of those elements that we wanted to tackle before the end of April was button styles throughout the Jenkins interface. And that the first step in doing that was to conduct sort of a style audit to see what existed currently throughout Jenkins and then what functionalities were tied to those different button styles, kind of bring them all together. And for lack of a better expression, sort of audit them. And it's really important to be able to see where we're at now and what those buttons all do right now in order to be able to move forward and maybe introduce some more formality to it here. So this, what we're looking at here is one of the results of that exercise. I could have put a whole bunch more screenshots up of things we collected and there will be some of those on one of these next slides, but not super necessary. And this is what it has boiled down to. And I should point out, like with most of these meetings, what we're looking at is a work in progress. This is subject to change and we can talk about it. This is why we're talking about it here, right? For feedback and that sort of thing. So this is not set in stone necessarily. There may be things that I've missed certainly. There may be things that we haven't thought about yet. So with that said, we have identified three different categories of button. And we'll take a look at those in just a second and I'll give those examples. But those are what we're calling standard, expandable and submission buttons. And within those three categories, we've identified the need for distinct button styles, primary, secondary, warding and transparent. And now for each of these styles, of course, there will be multiple different interactive states such as the enabled state, disabled, hover states, oops. My mouse is misbehaving. For each of these styles. Now this gets a bit perhaps a little bit unnecessarily complex looking at it. So we will look at it graphically just in just a moment. But first I wanted to review the idea behind these styles. So the primary style is the most high emphasis style button, right? It's what we would think of as usually those blue buttons throughout the UI right now. But it's not the default style because in most cases, we don't want more than one of those primary buttons on screen. So our default style would be actually that secondary that has a slightly less intense design. So we're for a slightly lighter emphasis. Hey, Yuli, welcome. But it's a lot more common throughout the interface. This notion of a transparent style is something new here. It's very low emphasis. Hey there, it's very low emphasis. And it's essentially, it has interactive states that resemble a button. But it's just primarily in its default state appears as text. However, not the same thing as its text to link. Again, we'll look at this in just a second. The final style here being warning, this is high emphasis and it's very similar to primary. However, it merits a distinct style because we don't want to start introducing a whole bunch of different variations and edge cases to the primary style, which should really be just one color from the palette across the board. So that's why warning is a distinct one. So let's back up for just a second and look at, this is just some screenshots essentially, but this is what we're thinking of when we describe standard buttons throughout the interface. So these can include these primary or secondary styles, but this is that standard category, right? And this is the current iteration, the first iteration of the redesigned buttons. So we have four rows here for each of those four styles, the primary, secondary, the transparent and the warning. Again, as I said, these are the most common throughout the Jenkins interface. And the idea here is that they exhibit really standard button behavior. So they have really standard typical interactive states, right, enabled, disabled, hover state, you focused state and a down state. Now we think, and again, this is just the first pass, but we think that this variety of styles and these various interactive states should cover all of the use cases we've identified for this standard button category throughout Jenkins. Anyone have any thoughts or questions on that before we keep going? Just a question about the intent between the two disabled states for the primary and the warning. They are not very different. Do you expect that or it's just, it's disabled so we do not care actually? It's a good question. You know, I saw that it would be a little bit abnormal to have a distinct disabled state when really it's just a color difference between these two. They're both high emphasis, but I think that the fact that it was a warning style to begin with is certainly lost here. So I think that merits a little bit more exploration, like you're saying. Yeah, because if it's disabled for whatever reason, the user does lose that insight into the fact that it was a high stakes element to begin with, right? That it was a warning of some type that's completely lost in the disabled state. We don't want that. So great question. Let me look into that. And just another feedback there. You are using blue and red for the color differentiation between the primary and the warning. We have some colorblind user. Do you think it's sufficient to differentiate the two? So what I've done so far for testing is I've tested the text in various weights against the colors and that works. But let me go ahead and also do that for sure. Text the, excuse me, run these two buttons side by side through the various filters. I have a tool that allows me to do that really easily and I'll double check. But I believe, and of course these colors are all coming from that palette we looked at a few weeks ago. I believe that that shouldn't be an issue, but I'm gonna go back and double check. That's a great point. Thank you. For sure. I have a question about industry. Mark also had a question first. Okay. So my question is just clarification. So are these buttons only applicable to the refreshed UI or are we also planning to apply them to the old or standard UI of Jenkins? So the idea here is that sort of like with everything that comes through these SIG meetings, right? Is that it would be implemented into the current interface and that we're updating it piece by piece? So these would become live at some point in the near future, you know, there's no PR yet, but it could be because this is just the first iteration, but these would become live inside the current interface. Okay. As well. Yeah. And in fact, we started looking at it inside of the current UI and that already revealed some inconsistencies, right? Like we've already identified a couple of places where these need to be improved as straightforward a design as they are so that they don't clash too much with the current UI. So these will be improved as we go here. Yeah. But as I said, if we find out they break a plugin or something, we will put them as a part of the new UI, but our intention, we always aim for it to be integrated into the main line enabled by default. Awesome. And then here we have a second variation here. So everything about this next screen is the same except that these buttons have a paired on with them. So we have some more work to do around defining how we treat icons as part of this project, right? We have a lot more investigation to do there, frankly, but one thing we do know is that we're leaning very heavily on the material design library. So these states are the exact same, these styles are the exact same, but you wanna be able to incorporate the option of having a paired icon using material again, because, excuse me, again, because material has widely recognized, widely standardized iconography to improve recognizability and understandability of what's going on in the interface. Anything there, any thoughts or questions? Yeah. There's something I want to mention here. So here the objective is to show how we would style by default icons within buttons. It's not like we are going to say, okay, this button with this class will have this icon automatically by default. No, if would you put an icon, a certain class within an icon, it's going to look like this. Okay. You still need to manually put the icon intentionally. Great point. That's very nice that you're proposing that capability. I will just suggest you that you are also creating some guide about which icon to use, to which usage to keep some consistency across the application, because if you just let the maintainer or developer choose any icon they want in the set, you will have a lot of different things that are not good in essence. Yeah. But I think that's a compensation for the icon, for when we take it on the iconography. And first we want to get through the buttons on the sidebar, because iconography is going to be a really complicated task. And we included these definitions and everything. So I want to, yeah, I don't want us to be blocked waiting for that, for something else going to come after. Yeah. We definitely need to provide those guidelines but it's just a bit, but yes, you're absolutely right. And I'll work on that, just not next, but very soon, because you're right, having that, those usage guidelines standardized goes a very long way. Yeah. One question, do we really need guidelines or do we just need a template library or whatever supplied by Jenkins so that the users can just get these controls? I think you can go, I think that's fine. Both. Ideally what we would have is a storybook, something about the commutation place for the UI, for UI widgets like Woodstrap has, like well, any other tools have. Let's say that's labor intensive. So, and that's something we will not be having any time soon. So at least we want a place where we can say, you want to put icons like this, you want to see what icons are available. Look at this page from material. Other than that, I really don't know. It really depends, there's much we can do but all of the alternatives to document these processes take time basically. I know that's a non-answer by the way, but yeah, sorry Oleg, I know that's a non-answer Oleg, but it's really complicated to find the venue, how to document something when we don't have a framework to document a component library itself. Yeah. So we have jelly tags. Maybe it's not an ideal approach, but jelly tag clips has automatic generation for documentation. So if you take a look at Jenkins right now, you basically get some documentation. Obviously it's not perfect for front end because it's basically Java doc like thing. It still provides some documentation. Yeah, we also had Jenkins design language, but Jenkins design language documentation would need a manual maintenance, which is not something I would advertise. Yeah. To be honest, for what it was, all worthy options to display a component library are manual. Basically, okay, you create the S-item, the markup is like this, you need to add manually how it is. And that's sort of unavoidable. I have one question. What is about the size? Are we intending to create buttons only of the same width? Or is this still up to the users? Because I think currently our layout is totally strange because some buttons are 25 pixels, some buttons are 200 pixels. So from my perspective, it would make sense that we also define a default size of each button. I think that's defining a default and then allowing the flexibility is probably the right path forward. We haven't really answered that yet, but I don't, do you have any more thoughts on that Felix? I do. What I'm doing, doing my POC implementations is removing all button styles from Yahoo UI. Well, I'm styling the buttons through the Yahoo UI classes, but I'm removing all existing button styles so that they are clean slate. And for example, there are duplications on certain UI widgets. For example, buttons are restyled on with hit arrow lists or on repeat developments, are restyled on Java forms. I'm trying to remove all of that and make them plain basically. Make them the same everywhere. That said, we will break some display. So when the back reports coming, I will re-enable the specific styles for specific widgets, but that's when the reports, for when the reports come. All right, something that just popped into my head here as I'm looking at the screen. A lot of these colors for some of these states that we see between these two screens are very light and close to white. And that's because they don't always need to stand out against their background if they have a stroke. But the reason I point that out is because, depending on your particular monitor configuration, as we're looking at these, the styles can look very different. So we provide these decks and you can always pull this up on a different device or we'll look at it after the call because I think even as we're looking at things together over Zoom, they can be translated differently. So I thought I'd just point that out and you can always check these out after the meeting. All right, that is about it for this deck. The next styles that I'll be sharing with you in a future meeting will be for this category of expandable buttons. I understand that name might not be perfect and that's okay, but that's sort of this grouping of buttons who, excuse me, of buttons that have this functionality where you can drop down and select something from an item list. And that third category being submission buttons. I think still thinking about the existence of this category, this might not merit its own thing. Perhaps they should just be primary and secondary buttons on the bottom of a field and that's okay too. So doing a little more investigation there, but these are for the next styles that we'll look at together as a group. Yeah. Just a comment on the submission button. Correct me if I'm wrong, Oleg, but I think these buttons are present only on the job creation page and nowhere else. So perhaps if you want to just rewrite a bit that page or to keep that aside for the moment, it could be potentially very valid to not spend UI resource on things that will be changed after all. Yeah. So regarding Cabos Submit and apply buttons, you can use them in any form because it's a part of formal main space in Jelly Tags. You can create custom form, custom configuration and there are examples of such kinds in Jenkins where you reuse basically the same buttons. Okay, good to know. Yeah. Also system configuration and job configuration, I believe they use the same buttons now. Awesome. And that's... I'm sorry. I think I want to mention is that Joe just said we will probably be updating these style guidelines really soon. I mean, please, but we will not be sharing them. I don't think we will be discussing them in a future sick meeting because we want to move ahead with the buttons. So probably you can expect draft PR before Monday or Tuesday. The code is a bit complex, but at least we want to create the PR and to have it out there because the button is something that should... It's really different from looking at the designs and actually playing with them. So hopefully we will be... The initial PR will contain at least the normal buttons and the dropdown styles and the submission buttons if you want to call them that way, we'll maybe make them later. But yeah, so... Good point. That's right. Especially with the cables. Monday or Tuesday. Maybe even the weekend if I have time. Yeah, man. One question. Do you plan to modify the Jelly layouts or do you plan to touch JavaScript layouts? Nothing. Just, I'm just changing the styles on the Yahoo UI classes. I'm not even adding new classes, new CSS. Okay. I would like to, but it's useless because all the buttons right now, all the plugins, everything use the dot UI dash button. I even want to complicate it. I just want to do the... Okay. Fine with me. So, Homa will use this of them. We'll get update. Everybody. Okay. That's fine. Awesome. And then I think these other items added here are not actually correct me if I'm wrong. Not agenda items, just sort of notes from the discussion. So I'll move them down here later, if that's right. Oh, nobody was taking minutes. Damn. It's a brief meeting, but we can add stuff there using the recording, so. So is that right, Oleg? Are we good to move on to item number four or was there something else to talk about there? No, nothing. I was just putting some notes during the discussion. I just joined, but I started putting notes. Awesome. So I think the next thing for today's call is Roman, you wanted to share. So I'll go ahead and stop sharing my screen. All right. I think someone has to give me permissions to share or do I have that already? I'm not used to this. No, you should be able to share already. Oh, yeah, green button here. Okay, sorry now. Okay, sharing my desktop here. Can you see my screen? All right, so this is the pull request on improving the alerts that we have. So there was this ticket reporting some weird behaviors in our existing alerts. So we had this at the so-called success alert that appears when you apply the changes to an existing job, for instance, you will see this. So it was broken in the sense that it seems that the map bar had changed its height, but the alert hadn't. And also notice, at the same time, this was maybe using a bit strange colors and the icon was definitely like, was a small size PNG icon that didn't scale very well. And the same thing happened in other cases, like in this particular case, which you are copying a token, you would get these alert also looking weird. So I was doing some research and found there are several, there are at least four alert states. So the green one for success, the default one used for copy, but for other stuff as well. And then we had warning and errors. So initially what I was doing was looking at bootstrap alerts, the colors they had, I think I linked it here. So I can show. So it was taking these as kind of sort of standards, applied them. There was some discussion in the PR and I think Uli provided this good resource, this idea of the react material, material packing. It was kind of similar to the bootstrap, but it included icons with different colors and I think make alerts more visible, noticeable and nicer as well. So I went ahead and apply those changes. So these are the resulting alerts, the successful one, the default, which is used for copying that use case that I showed before, warning and error. I used the material icons that we had already included in Jenkins. So Jenkins already had some material icons in the source code. So I just reuse the ones that were already there, just took the ones that were more similar to the ones that I saw in the example of the react material packing. Apart from that UI visible changes, a discussion with Felix, we were using, maybe you can show that quickly from the files changed. So basically all these behavior was embedded in a JS file, had some behavior that was using Yahoo UI animations. So everything was in the JS file, the JavaScript file. So all the colors were right there. So it was kind of not very nice to maintain. So Felix said it was to move them to CSS classes, which I did now. So I include these CSS classes for the different notifications and also same thing for the animations, right? So then all we are doing in the JS file is each state has a class, also the default class and the icon. And then we set, remove or add the class accordingly when hiding or showing. So just to show these running, I have Jenkins running here. And now if you click apply, it will show the new other, with still with the fade in, fade out effect, very similar to the one we had. Now it's a bit shorter in the fade in. It definitely matches the height. And I think the colors are much nicer than the ones we had. The icon is SVG, so it's scales. So I think I'm quite happy with the result. And that's why I wanted to show this small change, but I think every little helps. So hope you like it. I think it's a dramatic improvement Roman. I think it's awesome. And thank you for working on this. Happy to help and contribute. I'm trying to find this page again, just to stop sharing my screen, but I kind of find it. Yeah, Zoom hides it. Zoom hides it. Okay, let me try to find it. Thanks a lot for doing that. We have something like two months before the next LCS baseline cutoff. If you deliver many such features in there, I believe we can make a really big difference in the next LCS baseline. The recent one, which was shipped last week, it also contains some improvements. Special thanks to Felix for font changes, because Jenkins looks really different now. When you deep dive, and such minor changes really improve the situation a lot. And actually I had a question. I'm not sure if this is what you mentioned, Oleg. So the LTS Jenkins, so how do we, how are we including, because in the past, I think I remember this PR goes to LTS. Is that still the thing, or are we doing it differently? So there is a back-porting process is documented on Jenkins website. I can show you some examples if you want. Just a second, I'll share my screen. Well, so, Roman, just for clarity, I don't think you want to backport this change. I assume you want it to go forward in the next LTS, and it will naturally be included in the next LTS. Just naturally, so no need for an LTS candidate. LTS candidate is used for things that we port backwards to a release that has occurred previously. Okay, okay, okay. I wasn't sure about that. Okay, I appreciate the clarification. Yeah, so basically we backport fixes and improvements. Well, small improvements could be theoretically backported, but generally we target the next base lines. So right now, the week, second week, five stage. So we just released dot one LTS last week, and we are rolling towards the schedule. So you can see that there will be decision-making in five weeks. We shifted the dates, so we will be choosing the next LTS baseline in five weeks. Commonly it would have been in seven weeks, but taking the recent issues, we made it with respect if I'm not just for that. So yeah, five weeks is enough to deliver some things here and there. Great. Okay, does it answer the question? Yeah, thank you. Awesome. Thank you again, Roman, for that work. That was actually the last, oh, oops, it was being added, nevermind. Oh yeah, just added one quick item. So if everybody has some time. Sure. Okay, sure. Yeah, you may have already seen that when I started changing the screen. So this dashboard is exactly why you don't let me work on UI, but yeah, long story short, we are working on making a public Jenkins road map. So basically community driven way to highlight the more of the stories which are critical to the Jenkins community. And right now we have a story for UI UX revamp there. Basically it represents what happens in user experience, special interest group. And I wanted to get your feedback whether it's enough or whether we could add more items. So for example, if you go to the recommendation which is linked from here, yeah, assuming that it works in my development version. Yeah, so here basically there are two milestones. So one is CSS revamp, another one is full rework. So for example, we could split it to two items in the road map or we could add more items if there are interests from other SIG members, but it really needs feedback from those who work on this area. So right now this road map is not complete. We are just working on that. But if you see something which could be added, please let me know. Okay. I have a, go ahead Felix. Yeah. Um, you may be right. You do have a point saying that it may make sense that separate just pure styling stuff from more complex changes. We are still discussing within cloud is what to propose to go next after the next launch of styling. Probably we'll include just the styling things. We will keep doing styling probably, but we are also looking at more deep changes. Maybe it will make sense to create another entry for those. If you also want to create an entry, for example, maybe it can be good to put tomorrow, to give more visibility to the just sort of changes for the forms, they are really big. I think it's great to call attention to those because they will be a huge change for the Jenkins experience. Just changing those forms. Okay. I think those are relevant enough. Yeah, my two cents were along those lines that would probably be good to have some more granular items so that people feel that we are actually delivering stuff because if we have to be of a task, maybe it takes a very long time to be completed. Yeah, for instance, what Felix mentioned, like changing forms from tables to dips, maybe that's something that we can mention. Maybe other stuff as well. Yeah, so idea for this roadmap is to hint stories on the top level because there is a lot of initiatives happening in different areas. And yeah, this list is not complete. It will look completely different by the release. Sorry about that. But yeah, for example, how it works, there is URL. And for example, he points to UX ongoing projects. So if somebody is willing to update this page to highlight key stories, like once by Josh, maybe a story that Uli is working on in terms of JavaScript libraries, et cetera, we can point to that. So visitors can go here and discover more details. Same, you can reference Jira issues, Epic, so GitHub issues, basically whatever you want, it's just a URL. That's good. Well, just think about what you would like to add, whether it's related to user experience or not. But yeah, we hope that in a couple of months, we will publish Amola's final version which we can present to Jenkins users. Cool, thank you, Uli. Anybody else have anything for this meeting? All right, then I will see you all in two weeks and I expect everyone will have very creative Zoom backgrounds by that point. I will certainly try to make some. And I hope everybody will have tested and they give even feedback for the buttons. And maybe the sidebar who knows. Yes, okay. All right, thanks everyone. Thank you for the joy to see you. Bye-bye. Bye-bye.