 All right. The robots have informed me that this meeting is being recorded. Let me go ahead. The way I want to. Shall we wait one or two minutes more minutes? Well, now that you let's start them because if you have already started recording. Sure. Let's just dig in and, you know, if anyone joins no problem, we can, we can pick up and catch them up. Okay. I will. I will start sharing my screen. Okay. In one second. Joe, I did need to ask for a revision to the agenda. I've got a drop off at 30 minutes into the meeting. I put an item as the very last item on the agenda. If we could sneak it in before I exit, I would much appreciate it, but it doesn't have to be immediate. Just. If we can sneak it in before we've completed 30 minutes. No problem. Yeah. Actually, usually the first thing on our agenda is to. Review the agenda. So yeah, that sounds good. Let's see what we got here. Yeah. Okay. So. Does everybody, does everybody see my screen? Yes. Okay. Great. So nobody else other than seven is joined. Right. So we all know each other. No, I think so. Yeah. Okay. For, for anybody watching online. I'm Max. Okay. So. So I'm glad to be here. I'm glad to be here. Thank you. I'm going to talk about the agenda from Cloud. I'm the front-end developer who's participating of these. And this. And who is developing the changes? So the agenda for today is to. Well, talk. I would like to talk a little bit of how Slack is working for us. and it's not to learn any feedback, basically. After that, I will give a brief update of what we've been working out these past 15 days. Hey Felix, can we move number six up to number four? Real quick, do you mind if I make that switch? No, yeah, yeah. No, I'm moving it myself. Oh, awesome. Okay, after it, we will be talking about adopting or retiring the UI themes plugin. After that, a quick development update. And then we will talk about, Joe will give us another update on the header bar, on the header bar designs. We did iterate based on the community feedback. So yeah, you will see. So, first of all, if it's okay for everybody, I will start. So, first of all, we've been using Slack for almost two months here now, or for month and a half. So, and I think it was a great venue for having those long discussions and those quick, the chat format worked really well, especially when talking about some plugins. But some people did say they feel it's not an agent ideal tool, it does have disadvantages. One of them is that, for example, we will need to archive the technical discussions in order for them to not be lost. So, I would like to maybe talk about five minutes about this to see how everybody feels of Slack. So, I will not say my impressions right now after everybody talks. So, does anybody want to say something on this regard? Yes, for instance, I can say a little bit about my experience. I think it's a little bit complicated. I have so many channels, but actually, I'm just using one channel. So, I'm not sure if it's configurable. Typically, we use IRC or we use Gitter, but now I have yet another tool which I'm just using for user experience group. So, I think it would make sense we either use all groups in Slack or we move to something else. So, I don't like to have one tool for this group, one for this and one for this. I think it would make sense if we have one common tool which we are using in Jenkins. So, you said, if I understand correctly, you said that other six in the Jenkins project already use Gitter or already use other platforms? Yeah, typically, I think I have about 20 channels in Gitter and one in IRC and now I have yet another in Slack. So, I'm not really sure why I should just use Slack for user experience group and everything else is in Gitter. So, it's just another open window and I don't see that there are many different features in Slack which are not in Gitter. So, I'm again, so it's just, I don't know, see any benefit in using a different tool here. Makes sense to me. Out of curiosity, does Gitter, is it paid and does it sort of, I haven't used it much before, so does it keep a long-term archive of the conversation or is that something you have to unlock or? I think the archive is somewhere in Github but actually I never cared about it. Gitter's free. It's kind of like a just behind version of Slack. So, it's got some great benefits for open source that you can just sign in with GitHub and it's all public, but default you don't need an account to see it. But it's quite far behind in usability and mobile is the biggest complaint that it has and also frequent disconnection. There's been more than one thread on the Jenkins developer mailing list about it. The last one was started around New Year's, kind of got to, I really saying it's on his list of things to look at but it's not very high up that everyone knows that Gitter's not great but it's an okay solution and satisfies most people. Yeah, there's definitely not gonna be a perfect fit, right? I get wanting to have it all in one place for sure. Like that makes Gitter very appealing to me even though I've never used it before. But the, like if it is, if we're not able to pop in on the phone and just see what the conversation is, it does seem like a disadvantage. I don't have super strong opinions on this. Does anyone else wanna try them? For me, I already have eight other Slack's open so one more doesn't make any difference to me. I've also got five Gitter ones open so Gitter doesn't really make much difference to me either. Gotcha. Yeah, I echo Tim's observations that the user experience in Gitter is far behind the user experience in Slack but the community is far ahead in Gitter compared to Slack, right? We've got, as Uli noted, one Slack channel for UX and we've got many, many Gitter feeds, many Gitter channels for obscure little things, for large things and so I'm hesitant to say to go with Slack considering what are, how much critical mass we have around Gitter right now. So how would this seem as a next step for everyone? If I just, every still has been capturing all our notes there and the pros and cons of both and then I'll remember what we talked about here too. So maybe I can consolidate these pros and cons into our current solution, which is our Slack channel and everyone who's been part of this thus far can do a quick vote on it in Slack and then we can remove it or not based on that vote. Does that sound like an okay solution to everyone? That's okay. Yeah, cool. Perfect, I agree. Awesome. Thank you, Joe. So after this point, Mark, can I introduce your proposal? Oh, yes, sure. So there is a plug, well, the catalyst event that caused me to put this agenda item on is I received a notice from GitHub saying that the UI themes plugin has a known security vulnerability. And the vulnerability is it's depending on Jackson 2.4. I looked at the history of this particular plugin. It doesn't seem to have been through many releases. It's been inactive for many years. My thought was retire it. So I asked the maintainer, Tom Fennelly, their last committer to it. Tom Fennelly said, yeah, I'm not maintaining it. It could be retired, but there might be concepts in it which would be of interest to the UX special interest group. I have, I apparently was just granted or have been granted merge permission. So I merge the security fix onto this thing. So I will no longer get email from GitHub. Therefore, my actual personal interest in this plugin has ceased to exist. But as a UX SIG, if you're interested in it, you might want to be aware of it. The concept it had was per user theming. And if you're interested in it, the plugin's there and it sits in the community. The question was, should we adopt it or should we archive it, retire it? Do we have any idea how much use it currently has? I looked and I could not find any evidence of a release of the thing. So, Tim. I'm looking at the moment. So I would be astonished if there were significant use of it. There is 32 installations. Right. Therefore, not a relevant number, right? In a, in a community with one that's mostly used in the community. Right. Good. So just so you're aware as a special interest group. So whereas it were aware as a special interest group, this plugin does exist. It can be archived. It cannot be archived. I'm no longer concerned about it because the problem it was causing my interest in it has been resolved. Okay. Okay. So, yeah. I'm new to the project, but I would say that anything that causes increases the complexity on, yeah, it's not for the best if it's not being used. I would say that maybe it's worth considering by, well, the most active contributors to the Junkie spread and maintainers to maybe to do something about it. I think it's worth researching. I will do research how it affects, to see if it affects the seed work. So, and FedEx, I would lobby that keep that research intentionally limited. All I think you're looking for is 10 minutes of, is there something wildly interesting in this conceptually because usage in the community is a good indicator and simple themes as noted by Tim is much more heavily used than this plugin ever was. Yeah. Indeed. Great. So I'm going to leave it as open for now, not archived because I'm satisfied. And if any additional investigation happens, great. I tried to build it. It fails one of its tests. I did not attempt to figure out why those tests were failing. I didn't have the time for that. Okay. Thank you very much for raising this topic, Mark. Thanks, Mark. Yeah, that covers the entire topic. Thanks for your time. Thanks very much. Okay. Thank you. Okay. Does anybody want to say something about this? You mean about this plugin? Yeah. I mean, before we move on. No, I think it's okay to look into it afterwards, but not now. Okay. Perfect. Next point on the agenda, department updates. So these last 15 days, we did not have the chance to do much work on the page header and breadcrumbs. We did some, but nothing that's worth showcasing here. We did talk about how to integrate it. How to, if you recall from last meeting, I would like raised some points about how we could merge some parts, have enabled some parts of the changes, but stuff like the header colors and the logo section should be behind the feature toggle. We've been looking into how to do this. We will probably use a Java property at first, and then we will research a better way to do it from the user interaction, but first we will just do a Java property at the startup time. And what we've been working on these past weeks was work on replacing the JS builder from the tool chain based on JS builder by one based on webpack. I've got to say thank you everybody who took the time to review it, paid attention and to comment. Thank you very much. Appreciate it. I think it's an important change because basically all the new UI work can expand on this one. Even the header. Once it's merged, I can apply, there are some optimizations I can do to the header straight away. So other than that, not much and not many updates basically. Okay. Does anybody want to mention something about this? Okay. Thank you. Then to the last point of the day, Joe, if you can give us some design updates. Yeah, sure thing. Felix, would you mind opening up that link? Yeah, sure. I think there might be someone typing there. Could you maybe go on mute for your typing? All right. Sorry, it's just my preference. I think Adrienne, could you maybe mute for the typing? Sorry. All right, cool. Let's dig into the last bit of our meeting for today. And as you mentioned, Felix, what we have on the docket is some header bar updates. This will probably be the last time we look at that, but we have some updates there from the last one. Sorry, bear with me. I'm just clicking around here. Then we have the opportunity to look at some interactive states and what those are about and how those will help us long-term and the beginning of our UI color palette for Jenkins. So yeah, you're on the first slide there. All right. So basic details here that you've seen before, you can go to the very next one, actually. And these are the changes since the previous meeting. So following feedback that we had going on there in Slack, the placement and visual treatment of the admin warning indicator there has been reconsidered. It also has a text label. The feedback was that previously it looked a lot like, a lot like a field input, just like the search box did. It wasn't something that I personally found super concerning, but you know, if it was going to create a user. Joe, I can't really see on your small slide. Oh, could you maybe go full screen Felix? Yeah, probably because I think is I'm sharing my Chrome screen. Can you just hit present in the top right? Present. Okay. Yeah. Perfect. Thank you. And so yeah, just a pretty small modification there, but that came from some feedback in Slack. So thank you. And then the second thing is we paired back the aesthetic changes to the breadcrumb bar. They were a bit more ambitious before, but something we realized thanks to your feedback was they were sort of making a certain feature less discoverable, which was that ability to use the dividers there to hop to certain pages. So now it should be a little bit more familiar. There's some type adjustments, but it's not quite as changed. And we can go to the next one, Felix. And the last little note there is that of course, whenever we make a change like that, the design is reconsidered for all our viewports. So that's an updated view of what the tablet size and the mobile size would be similar to. And next slide, Felix. All right, so this is just, I wanted to take just a moment to mention sort of the special power of a special interest group. This is the first one of these groups that I've been involved with for Jenkins. And I think this is a really interesting tiny case study of what can be achieved. So obviously we're just getting started and we're just a few meetings in, but even though we're just ramping up in the big picture, this is having a pretty big impact on how this will be designed and how we're creating these changes thanks to your perspectives and your feedback. So this header bar might seem pretty inconsequential, it might depending on where you're coming from, but designing this has actually solved a lot of questions, solved a lot of problems that will inform future design decisions. So this is where the design of it was two SIG meetings ago. And there was some internal deliberation here on my side about improving the design, but for the most part, thanks to your feedback, if you wanna go to the next slide, Felix, this is where it has landed. And for some reasons that are obvious and for some that are less obvious, it's a much stronger design. So thank you all once again for your feedback. I think this is just a cool little example of what the SIG can do. So I really, really appreciate it. All right, next slide. So the next thing we'll look at today is component interactive states. So we're using our first fully designed component, which is that header bar to establish standard interactive states to inform the design of additional components, right? So implementing these states consistently throughout Jenkins should help make the user experience more friendly without doing deep technical changes right away and it will improve visual accessibility. Now, there are currently a lot of different states for a lot of different elements, but some elements in the UI don't carry all of these states. So there's room for improvement there. And as I mentioned, this answers a lot of questions for the design of future components and will help speed things up in that regard. So if you wanna go to the next one, if anyone wants to look at this after the call you're welcome to, of course, these are all the interactive states for that header bar component. So like, I don't have to explain this to you all, but basically how does the design change aesthetically based on how the user is interacting with it, what point in their interaction and that behavior? So this hopefully just gives a little bit of context for two things, which the first one is how we're thinking about these components sort of holistically, how they feed into this long-term vision for a Jenkins design system. And then secondly, how they all connect and inform one another. And this will solve a lot of the problems that we'll face for designing future components and hopefully speed some of that up too. We can hop back, but I wanna be mindful of the time. So let's go to the next slide and we can come back if we need to. The last thing we'll look at for today is the UI color palette. So a lot like those interactive states, right? This is something that needs to be defined in order to have a successful design system long-term. And we gotta start somewhere. This is something that will evolve over time for sure, but designing that first component allows us to establish a lot of this now, which is pretty cool. So a consistent color palette throughout Jenkins will help create more consistent visual affordances, of course, and this will improve feature discoverability. And of course, another big gain here is improvements to visual accessibility. So all these color, the common color combinations that we'll look at on the next slide have been checked for visual accessibility in line with, I always call it WCAG guidelines, but I guess WCAG guidelines. And let's look at the next one real quick. So that's a little bit more in-depth. Those are, that's the palette as it stands today with a little bit of the logic behind all of these color combinations, how they should be used. And as I mentioned, this will evolve. This is not set in stone and how this filters out to people who are creating plugins and contributing UI is something that we will still solve, hopefully in the long-term here with a UI toolkit. But for the moment, just trying to get this established to inform these designs. So that's something I wanted to share. I think that's it for this week that I had to share. Does anyone want to hop back to any of this stuff and talk about it or questions or feedback is more than welcome. It's terrifying for someone who's never done UI design work before. Thank you very much, Joe, for showing it. That scares the daylights out of me to see, oh my sakes, there are so many sophisticated things happening here. Thank you. I'm happy to have somebody who actually knows how to think about these things. The goal of the SIG meeting is to have everyone leave scared, Mark. So I'm glad that it's working. No, I'm kidding. That's thanks for the feedback. There's obviously a lot here just as there's a lot more that goes into implementing these changes. But yeah, we're definitely trying to think about these things holistically. And that means sometimes spending a little more time to solve for this stuff before we can just crank out more designs. But these pieces help us get to that point. These are big steps, even though they're small screens. Do you have any other thoughts or feedback for today's call on this stuff? No, and I am utterly unqualified. I barely resolve colors. So thank you for being sensitive to the mentions there of things that shouldn't be combined with each other. It reminds me that my color resolution isn't that great. No problem, all part of the job. Yeah, cool. Well, as always with anything we've talked about in today's meeting. And yeah, I think that was the last slide. The rest is just about providing feedback and that's in every deck. Yeah, I will close it then. Yeah, for anything we've talked about, we can pick up the conversation in Slack. I will be sure to post that the word is escaping me. The vote, the poll in Slack about getter versus Slack and that sort of thing. Does anyone else have anything else to raise on today's sick call? Okay, then before we move on, next week meeting should be just to confirm. Next week meeting will be on February the 5th, which is two weeks from now, same Wednesday, same time, okay? Good stuff. Okay, perfect. So this is it. We will be uploading the, Jeremy will be uploading the video to the YouTube channel as always. Thank you everybody for attending and for your contributions. See you in the Slack poll, basically. So yeah, thanks everyone. Thank you, Felix. Thanks everyone. Yo, bye. Cheers.