 So welcome everybody, I think everyone on the call here knows everyone else find this point. Yeah, it looks like it. So welcome to another sake meeting. I'm going to go and share my screen here and I'll kind of run the conversation a little bit. Let me know if you need me to zoom in at all. So we got a couple of agenda items here is some updates and some conversation around some community contributions. First, we usually do this does anyone have anything they'd like to add to the conversation before we dig in. Or to the agenda. All right. Sounds good then let's let's take right in the first update here is about button categories and interactive states, we're going to take a quick look at a design deck. And then we're going to, I think hand the screen over to Felix for a brief demo. And we're going to just talk about the sidebar UI a little bit, and then we'll move on. I don't have a full screen here but at any point stop me if I'm, if something is not visible enough. And of course we share this out after every call. So in the last meeting, we did take a look at buttons. At that point we, we had a pretty different idea around how buttons are categorized. There were some different categories, the approach to styles has remained pretty much the same. How are the style groupings have remained pretty much the same. But the actual aesthetics of them has evolved a little bit so since there are some updates here I thought I'd click through those and if we have any conversation. We can check those we can dig into that so standard buttons are of course the most common type of button throughout the interface. And we have three variations rather than two in this update. So the standard buttons with text labels, you know without seeing them side by side it can be pretty difficult to see what if anything has changed here. The most, most noticeable or the most important thing to mention probably is that we solved for a visual contrast visual accessibility issue that was present in the last iteration of these standard buttons. We did not, did not have sufficient contrast against the Jenkins blue color from our color palette by default. So what we did here is we have decided on a treatment where we've sort of rather than muddying up the color palette and introducing an alternative color. What we did is had what we would normally use as a hover blue as the default, and then oops, and then we go a bit lighter upon hover. The most expected behavior but it does help solve that accessibility issue. And it does help maintain a color palette without without like I said muddying it up and adding a new, a new item a new color with every little issue that we encounter that's a sort of behavior that we want to avoid otherwise that palette loses its value really quickly. So there are a couple other updates here I think probably since last time we looked at it text itself is a bit smaller the height of the buttons has been reduced if I from remembering correctly. So iterations, but very much the same. Then we have standard buttons with icon plus text label. You get the idea right, such as the same thing as what we just looked at, but these have an icon paired with them from the material design library is the intention. And then we have a large variant which is very, very similar to the standard one. In fact, I believe the idea is that all the interactive states would be the same, but these are a bit larger should stand out be a little bit more pronounced on the page is usually what we find that say the bottom of forms. It didn't make a whole lot of sense to create a really distinct style for this variant. We could have pursued that but didn't want to because and Felix, feel free to jump in there and correct me if I'm if I'm describing it incorrectly but my understanding is that this variant is hard. It's hard to say let's only use these at the bottom of forms for example, it's a treatment that can be applied in just about any plug in and it can be pulled into different places so we didn't want to do anything. Two different at the bottom of forms because that treatment could appear in in other places and other plug in UI and so didn't want to throw things off. Is that a right way of describing it Felix. Yeah, it is. I need my second cup of coffee personally this morning so anyone feel free to stop me and and we can dig into it more. The second category which we didn't look at last time was expandable buttons. We looked at the treatment for the actual menu that that expands from the button that that code effects those type of drop down menus throughout all of Jenkins so we decided that was a bit of out of scope for redesigning these buttons and instead we just have the treatment for the button themselves will be tackling those menus as a separate component. But this is the redesigned iteration you can see it's very straightforward. It's really important you know, not to have anything too flashy for buttons. Sometimes when you look at them in isolation like this. These buttons can seem, you know, in my own opinion, a bit a bit drab right gray dark gray text. There's a reason for that though. The previous iteration you might recall. These were for you to use an example right these were blue outlines these are blue strokes. A drop down button or expandable button with a blue stroke and it's say peppering UI there are many instances of that treatment throughout the form it can become a really distracting treatment really quickly. So that's why this is really paired back it's a conservative design. But we've tested it and placed it against the form treatments. We have to be mindful of the current UI, as well as where we'd like to take it. And this this checks both of those boxes. The last thing that is new here is this idea of icon only buttons. I don't think this is something that's incredibly common right now but this is something that we want to plan for over the long term. And as more features are built more plugins are built they might want to use this sort of treatment. Of course this leans really heavily because it doesn't have a text label on the implementer or the designer choosing an icon that affords that that correct functionality right. But this essentially uses that transparent style that we saw in some of the other categories, very straightforward. Yeah, because I've just been kind of rambling on does anyone have any thoughts or questions at this point. I think it's easy maybe after we show a demo to consolidate all of these, all of these exposition sounds good. The last thing I'll show in this slide that quick is just this we've all seen this before. These are items that we wanted to try and and work on by the end of April. So the next thing that we'll be looking at two weeks from today and maybe I'll be able to post something and get her a little sooner than that so we can talk about it ahead of time would be treatments for this sidebar which is of course a really big and really important part of the interface. Hopefully we will have a working progress be at as well. Hopefully. Yeah that's that's the goal. And that's it for this deck. I guess I'll stop sharing real quickly for you Felix. Yeah, so I will start sharing my screen. First of all, I said last meeting that I was going to share within a week pro that I was probably going to share within a week buttons, the buttons PR. Sorry about that I was not able to. It's much complicated and it seems. So. But I think the result was really polished. Everybody seen my screen. So, yeah, so this is like on the PR there's a snippet of jelly code then everybody can paste copy and pasting a jelly template to play around with the buttons. So one of the things that we achieved was not only buttons can be styled, but also hyperlinks can be styled as buttons. These are all hyperlinks that can have a button style. So here you can also see how other buttons with leading icons, trailing icons and icon only buttons how they feel. And I wanted to show them to show around different screens to see how buttons would feel. I think they feel really good once you get used to them. It's much nicer, especially whenever you go then back to the old buttons. So here we see that these buttons in this form are of a large variant, which is nice. So here we see all of these drop down all of these default buttons. They are much easier on the eyes. So drop down buttons everything behaves as usual. I think these planning pages are used that really benefit from the new buttons because they are a touch of color. That's really interesting in my opinion. And for example, you can see it here. This is much nicer. The only column is downgrade. So this probably could be a link style button. So you can navigate, see what's up. I think it makes the pages less sad if that makes sense. Also for example here we can add a new token in the API we can generate. Maybe it's because I'm biased, but I like it. Okay, so yeah, we have the delete buttons. As Joe said, this is not our primary color. I'm sure we will talk about this later from what I've seen in the agenda. But we needed two for accessibility reasons to go with a darker blue. But well, it's not that bad. I was something that I wanted to touch is I created this PR on this PR. There's a link to the, there's a link to the issue. In the data ticket I talk about the CSS API. I go into a bit of detail. What did I choose because for example, I did not style buttons by default. I kept the buttons within the joy button classes. I don't know if I should add default styles for buttons as I did for input types, input buttons. Well, I encourage everyone to take a look at these CSS API specification. And if anyone has any idea how to document this, I would appreciate it. Or maybe we should ask in the docs, because I think this is something that we should document. Yeah, it's definitely not something that should be just lift a tier a ticket or PR for documenting. Yeah, indeed it's not. I mean, for me documenting this, it can be a matter of three or four hours. It can go a long way to, you know, to enable people to use buttons with icons, buttons without, you know, so I appreciate any ideas on this. It needs some sort of component library dot really for something that has the CSS and shows you the CSS that's needed and the rendering. Yeah, I agree with that. I don't think we have anything appropriate right now really. No, we don't. No, I wanted to set up a storybook. But maybe I will take a look into it in the future in the near future. This is really complicated, especially getting the adjuncts to behave. Something also that I want to mention is people will look into the PR is that I removed some Yahoo UI calls styles from the Sorry, from the layout.jl file. So that's because I style the buttons from scratch. Basically, buttons are now a clean slate. So I think that removes a bit of quite technical depth. So yeah, I welcome any, any feedback. So, yeah, one question. It doesn't, from the PR, it didn't look like you had added any of the Any of the icons or anything into any of the existing buttons. Is there anywhere that could fit in as an example. So if you scroll down a little bit, you've got like the leading icons or the Yeah, any of the SCGs. And is there anywhere that would be appropriate just to add so that we're actually using it. I don't think there are any buttons using them. If I understand correctly your question, I don't think there are any buttons using this correctly. I just want to say that we, we have enabled this. Okay. Because, for example, we have an ad in a specification that we don't have a button with an icon that's a specific size for the Normal button and another specific size for, for the large button. So you get types of free. So I did this for SVG icons. And also I tax for, for those fantastic users. Do the help icons use the question mark link that you've got in the leading icons section. Can you please talk a bit, can you please repeat and talk a bit louder. And do the help icons use the new style help icon or was it using the old. I didn't check when I was looking like this one. This one I just took out of the material SVG. So you can see here I pasted this jelly snippet. And that, that basically generates this. And I'm using SVG the SVG icon helper with, with a material UI icons with that answers your question. No, it's just asking, do you plan to check? So if you go to manage Jenkins. Yep. Wait a second, please. Well, even, even though the job page you were just on had it and then configure system. The job page has it. If you don't want to wait, you can just go back to the simple Java Maven app. Okay. So you mean please. Yeah. Those probably could be a style. I don't know where those are generated, but those could, those are prime candidates for conversion from to actual buttons in deep. Yeah. I can leave it as a community contribution. Also, right now we only have a, a single style for icon buttons. Which is, which is the same as a hyperlink one, but if anybody can, can add, want to add a normal grade text color icon buttons, other styles, we can, I can help out anybody to, to keep it consistent with the icon catalog and palette. I think there's a chat message. Maybe I will, I'm sure we can document it there only. But I don't know if what with the proper section is. Yeah. We should make a new section. They are about UI things. So we have a lot of sections. So I think a good section would be about UI things or what to choose for widgets and etc. The color palette. These things are, I think good points in our documentation here on the website. Yeah. There's better tools for design and so being able to have the CSS and have the rendered components. Possibly we just grab the Jenkins CSS build time and then add the Jenkins CSS onto this page. Yeah, something that I think we can, I would like to set up a storybook. I will think about something but take me a while. So the problem is that if setting something up is easier if you have the CSS and JavaScript in the same place. But the problem we have here are the adjuncts. Basically, they make form CSS, the Roman CSS, all those pieces of code, they are all over the place. So the adjunct files. So that's what makes it difficult to create such catalog. I don't know if that makes sense. I can look into seeing if I can blueprint a catalog and then share it with everybody. Okay. Is there any other questions? Okay, great. I will stop sharing then and go back to Joe. Sure. Right. So the next line item here was just sort of a comment, maybe a couple of comments from myself and Felix. I mentioned earlier that the next big piece of the UI that we're looking at is the sidebar and I hope to share some designs and some mocks with you all over the course of the coming week over in Gitter. I think, I don't know, is there anything more you'd like to say about that Felix other than that's coming up next and some of the things we were thinking about there? We are, we have identified that we'll probably tackle the sidebar in stages. The hyperlinks, sorry, the task hyperlinks on the top and then the panels on the bottom there for the build queue executors, build history, all the stuff. So, and I'm a bit concerned especially about no, no, we will not touch touch icons on the sidebar. I'm a bit concerned about those panels for the executors because I have identified that we have executors build queue, build history. So, but I don't know which open source plugins use and contribute with custom panels. So if anybody knows by heart any plugin that creates a sidebar panel, please come or does anything weird in the sidebar. Please send me and give me a message on the heads up and they will look into it to make sure we don't break anything. For sure. Awesome. I think, I think that's it for that topic for now. And we had some community contribution chats here. So some questions and ideas about the color palette. Does someone want to speak to that whoever edited I suppose. Yes, I forgot my name to edit here. Yeah, the point is for me. I'm just headed over to the new Jenkins UI and now I'm trying to convert my plug ins to use the new color schema. And so I started with your document you about the colors and the first thing I noted the colors are just, yeah, there's no color numbers given there. So it would help me as a plug in developer if I can get the actual numbers for cars, which I should use. Absolutely. And maybe it would make sense if we have the palette as a standalone document, because I think currently it is somehow integrated in another document. So, maybe it would be good to have it as a standalone document. Yeah, absolutely. On the Jenkins homepage. So this is our new palette and please use the palette for everything. That sounds good to me and I totally agree. It's one of those. I think this is one of the first times that someone is is looking at this project and then trying to reference the things we're trying to establish to implement something or build something new. Awesome. And I will definitely put that together for you in short order and share that with you. And while I looked at the palette, I noticed I think two things I'm not sure about it. So the first thing is a lot of plug ins are using charts to show some information. You need a unit tests plug in. So we need some more colors, I think, than the colors you have already shown. So I have no idea how to present colors. So this is just an idea for you as a designer. How do we or how can we get some more colors for our charts? What are good colors or I think the colors must match somehow your palette. And I am not a designer. So I'm just a programmer. So it would be very helpful for me if we also have some more colors, which plug in authors can use in charts. I think that's fantastic feedback. I totally agree. And especially with a palette, it's the kind of thing we're going to encounter continuously, right? So this is a great example and it does need to be expanded for that. Let me follow up with you in Gitter about this, but yeah, we'll make it happen. One thing that maybe I can elaborate. I've been entertaining the possibility to, in the near future, have the possibility of setting, allowing customization and setting the colors for hyperlinks, buttons and everything, just at least some basic customization using CSS variables. So that would make it easier for, yeah, I would like, sorry, that will make it easier for, especially for people to expand the UI, basically changing the primary color or changing, for example, the background color for the secondary button, whatever. So that's something I still, it's a bit of a project for me, but these variables could be used. And it's something that customization that works on basically everybody else except Internet Explorer. So that's a possibility I'm entertaining at the moment, Uli. That's good. Because this is something we already have that someone is installing a new theme and then the colors are changing for all plug-ins. So I think it would be helpful if this is going in the new releases as well. Yeah, someone installs a new theme and then every plug-in behaves correctly and not only Jenkins core. Yeah, and it's also, using CSS variables basically needs lots of work. Okay, lots of work. So it's not immediate. It's the first step towards, it's the best way to achieve a dark mode. Basically because you just swap the variables and then if you set the background of the pages of variable, if you set the text color of the variable, everything you can just turn up and create dark mode configurations. Okay. And I mentioned in this because there's a community PR for open. That is a task issue for that. Okay, team I'm looking at. Sorry, Adrian has a question for the PR about, sorry if I did, sorry, did we finish talking about this, Uli? Yeah, for me it's good, thank you. Okay, it's laughing. If you would give me a minute, let me answer something. Team just raised a question that from Adrian on the PR that says, I know this may be out of scope, but we are still using UI prefix when those classes, if I recall correctly, came from the UI library. As we are not using anymore, maybe we'll rename the classes. What do you think? So, something I thought that was some of the first decisions I needed to take when dealing with the buttons. And the problem is that basically the current button structure, which is a spam tag with a UI button class, and then a button within it, it's used across all plugins basically across the whole ecosystem. You cannot just not support that. Basically, it's legacy, but it's what's here. Also, we cannot stop using the UI button naming because dropdowns, menus, all those sorts of buttons that are dealing with JavaScript use the UI classes. Yeah, I've had that before. Yeah, I needed to embrace them basically. I have the option to create another API, but I had no real API. You still need it for the dropdowns unless you migrate the dropdown card to the new cards, but then some plug in your line on that. Yeah, I didn't want to, I wanted to have effective new changes and I honestly didn't want to deal with coming on with coming up with a new API. So that would need to coexist with existing one and would need, could not be used for menus for dropdowns for anything. So it would never replace the other one. Something that I'm not satisfied with is that I don't style the buttons directly. I expect the buttons to be within a spam tag. So I could add an option to not wrap the buttons in the future in a future PR, but maybe I'm waiting for community feedback on that one. I will answer, I'm giving this explanation here, but I will also answer it in the PR. So, are there any thoughts on this? Yeah, it would be nice if we could do it without having an option to do it without the spam. Because you don't have to handle the complicated dropdown with all that JavaScript in most cases. Yeah, if we could have a nicer API or simpler API for new codes, keeping in mind that dropdowns are going to have to use the legacy code. It would be nice to have it available, but if it's a lot of work, I would. I don't know. To be honest, I don't know. I will probably be able to, instead of, for example, to style the buttons as the hyperlinks with button class, with a class of UI button and everything. But they really, really want to avoid coming up with a new API interface. I don't know. It will just never coexist. We will never, maybe we can have a bootstrap-like interface, but it would complicate the CIS code too much for me, in my opinion. But maybe I can work on removing the spam tag, indeed. Okay. Anything more to say about that for now? And if not, I think we could probably move on to our next item on the list here, Slaydon. You want to speak to that one? Yeah. Yeah, so I just opened the breadcrumb PR. I mean, we're trying to rewrite it in Java rather than let your jelly code handle it. So Felix told me to get it up. I don't know exactly how to test it because I don't know where exactly would the, I mean, breadcrumbs generated in the jelly. So I've added some of the interface methods, but I'm not really sure how to add tests or something to it. I could get any feedback or any, I mean, that would be really helpful. So, um, could you, sorry, I think maybe you're, can you maybe speak up a little bit out to my volume? Could you reiterate sort of what are you looking for feedback on this one? Yeah, yeah, I was looking on how to exactly test the changes that I made because I just refactored it into making our code generate the breadcrumbs rather than, rather than they just getting pulled up the jelly code. Initially the jelly code just, I mean, they just generated the breadcrumbs using the ancestor. I mean, sort of some loop where it just iterated through the ancestors and then all of the breadcrumbs are updated. So I was, so I refactored that into Java, but I'm not exactly sure how that fits in, or how do I, I mean, test it out on the UI or how do I add tests to it. So any feedback or something that would be really appreciated. Good stuff. Um, if, if anyone has anything to say on that right now, that's awesome. And if you haven't already, I'm a little behind on catching up there, so I would, I would post this over and get her to for, for a bit more exposure as well. Yeah, no issues. I'm not asking for immediate feedback. Feedback would be delayed. I just brought it up because I'm feeling suggest that would be a good thing to bring up in the UX. Yeah. Yeah. Thank you so much. Thank you. I cannot speak of, because I basically I have no idea how, how to have a global global modules to a, how to access global modules to a jail and through a jelly template, but they will I'm basing, I'm basing through the UX six channel where I think it's a nice start where the basically where the cold to the And this is I'm sending you the link to where the interface iterates over the loop with the breadcrumbs basically Just on getting access to things globally and jelly. Normally it's anything in the functions class is available to jelly, I think And then you access like H dot method name. It's the normal, the normal way to make something easily accessible. There's other ways, but Yeah, okay. Awesome. Anyone have anything else for, for today's meeting. Whoa, whoa, not everybody at once. Calm down. Yeah. All right, straightforward call. Thank you everyone. For your time today. And we'll see you in gooder. Yep. Awesome. Bye. Thank you. Bye bye.