 All right, so welcome everybody. We've got a small group today. It looks like we don't have anyone who hasn't been here before, but welcome to the 14th Jenkins UX SIG or Special Interest Group online meetup. Let me move this bar out of the way. For myself, the zoom bar. All right, so before we jump into it, does anyone have anything they want to add to the agenda or bring up casually or anything like that? All right, then let's jump into it. First thing here is we're... I'm sorry, go ahead. That's like I said, I might add an update for tables to divs in there. Oh, perfect. Awesome. So wait, sorry, did you say you're gonna add it onto the list there? No, I'll add that just opening it. Perfect. All right, well, let's kick off with this design deck. And then we do have a few other topics as we see, so we should be able to move fairly good pace throughout the call here. Let me know if items are not big enough on screen and I can adjust. So this I posted about back over at Gitter earlier, I guess around the middle of last week. I had experimented previously with providing sort of some contrast ratios and more detailed accessibility information about different swatches on these color palettes. And it ended up being a little bit, I think perhaps counterintuitive, the information was so specific that I think the better that it could become confusing and how does this particular contrast ratio, for example, apply to my unique use case. So I think a better approach here would probably be to provide a resource, provide a link to the resource that people can go ahead and test out those very basic foreground and background combos using a commonly accepted tool. And instead, having some very general guidelines with each swatch here. Now these can be a bit vague and we'll talk about that in a second too, but if you didn't happen to see them over in Gitter, essentially these are updated color palette resources. We've talked about sort of the methodology in the past, there's five categories. Each category has these different swatches and something that came up in discussion in Gitter, which I wanted to address here was this idea of as these base styles are becoming more solidified, we don't expect, for example, these colors to change immediately, right? Whereas a few months ago, it didn't make sense to document them very thoroughly because we knew they'd evolve quite dramatically and they did. But as they're becoming more solidified now, how do we want to go about documenting these publicly so that there are less of a thing we look at in this call and more of a guide and a resource for contributors around the world? So I thought I'd just kick off that little discussion and does anyone have any thoughts on there and let's dig into it. I think it would be helpful if we have these resources on our Jenkins homepage where we have the developer documentation. I think it would be really helpful if we have a kind of documentation of colors to use and maybe also which fonts we should use and things like that, it would be really helpful if we have that on the homepage. And you're talking about Jenkins.io, right? Just to make sure. Okay. Yeah, I agree. This isn't something I expect to have a lot of resistance to as an idea, right? So we've got these, we've also got, as you mentioned, like a type scale formalized, we've got different interactive treatments for interactive states. There's a lot that we have gotten to a stage where we can now share these out and people can start referencing them. So as far as where to do that, that makes sense to me. I need to kind of look at how that would work and maybe try and establish a way that we can update it pretty easily. And basically I need to look into how efficient it would be to put it on Jenkins.io and continuously keep it updated. So let me look into that, but that sounds like the right choice, certainly. Cool, does anyone else have thoughts on that? And I'd love to get that going as well. All right, awesome. So we'll start with something like this probably because color is such a big question mark for so many people who are trying to contribute to a project, right? So I think these are in a pretty good shape. We'll start with these. And I think I should be able to follow up on the format and the execution well before the next meeting. Just let me run it by a couple of teams who are involved with that Jenkins.io website and we'll get it, we'll get it going. Next steps for the palettes. Really, this is something you asked for a long time ago. I haven't been able to give it to you yet, but I have not forgotten, which is a data visualization palette. I didn't wanna just be arbitrary in those choices, but I agree it's something that would be useful as a resource. So that is next now that I've got this format going for these colors. And then I think it was you Tim who over in Gitter asked saying, some of these guidelines are a bit general, right? So like when we look at alerts and warnings, I forget the one that you called out but basically saying, I don't know how this instruction would apply to an actual UI element. So something else I'd like to do, which won't be quite as soon as getting these publicly documented, but we can iterate, would be to provide some visual examples, some very simple visual examples of different elements on screen as we create them to accompany these palettes and say, here's what this guideline actually means. So when I say avoid using behind text, maybe say, maybe have a little example of what that looks like behind text and say, here's why, it produces this core contrast ratio. You can see it doesn't look good or something more along those lines, but the format still need to work on. All right, so the next item here, still doing a lot of investigation here on my end with tabs and table styles. So what we're looking at is by no means final. In fact, there are a couple of ways I was talking about with Felix very recently, just yesterday, that these are going to evolve a bit. But we looked, or we talked a couple of weeks back about how we could improve these through just these surface level styles, right? So improving legibility with better spacing, applying all of the treatments and the base styles that we've determined over the past few weeks to tables. So very much a work in progress, but if you wanna go in and look at some of what we're thinking at the moment, this is all here. This is a mock-up of what the tables, with some of this thinking applied, could potentially look like. Again, this is just a static mock-up, right? So certainly not final by any means. And again, a couple of these things I've already realized with Felix's help, need to change to be a little more legible, a little bit easier to understand. So we're getting there and I hope to have a really solid update for you on this element type soon. Before I move to the next topic, any thoughts or questions or feedback on that one? Cool, and you can interrupt me anytime. Yeah, I'm not sure, which kind of tables is this layout for? So we have a lot of tables in Jenkins, so should every table look like this or is it just a few here? Right now it's going to be for big tables. Because right now it's only feasible to style big tables. It's just the only one we can style and control, basically. That's a specific class called big table, right? Sorry, Tim? It's a specific class that's called big table, right? Yeah, it's a specific class used to call big table. That's widely used. Many plugins use it directly. Many widgets use it. So it's basically the standard right now. Mm-hmm. So it would be helpful if the data tables plug in that I created that uses the same styling. So is this feasible or is it not feasible? It is, I think. I mean, if you can try to, if you wrap it in a pain frame class and add another big table, that big table class, you should be good to go or pain big table, but something worth trying. I mean, if it works now, it will work then. It's my goal, so, yeah. Okay. All right. And then I use the screenshot for the next topic just because we're looking at something on the same image here. So this is a pretty straightforward proposal. We have these RSS links for following progress down underneath and currently there are text links with a RSS icon next to them. So, oops, whoa, whoa, whoa. Sorry, my mouse does that. So this is just saying we've established button styles. So we have easier to understand interactive states on those buttons as well. So this is saying, hey, let's take this opportunity to do one of those small improvements and maybe change these text links down here to buttons. And so what we see on screen is the default state for the transparent button style where when you hover over it, then it has a background treatment and it's, again, kind of hard to convey in this static format, but we also have that kind of documented in our previous slides if you wanna check those out or ping me on Gitter and you can look at them in a little more detail. But that's all, really. As we know, this is a gradual thing where when we identify little opportunities like this, over time they add up and become a more cohesive experience and a better experience for everyone. Is this more than material icon? I'm sorry. Is this more than the material icon change? Yeah, I actually, when planning this, the PR, your PR wasn't even created. So because the icon PR is, was rather recent and rather fast and went rather quickly fast to the review process. So this is just wrapping it with adding, for context, the icon change has already happened. Team changed it. So this is just adding it as a button link style, basically. And having the chance to put the, to consolidate the links and put the icons within the hyperlinks and not creating several hyperlinks. So yeah, separate from that and effectively just changing these two buttons. That's that. We can talk more about it or we can move on to the next item. The next item proposed here is this updates to the header bar and breadcrumbs. And this was the first component, of course, that we really dug into as a group. And it really came out a lot better than those initial explorations on my end because of the group collaboration here. So that's awesome. As we've refined the base styles a bit more in the recent months, there's an opportunity for some improvements here, potentially. So something I'm proposing is keeping sort of what's become really well-known as, or really well-recognized as the black bar here at the top of Jenkins. And then also adjusting type size and also the height of the breadcrumbs area. So it would look something more like that. And this is sort of an update in keeping with these styles as we refined them. So current and new. Nothing life-changing, no changes to functionality or anything like that. But a bit smaller and less obtrusive at the top would be the goal here. And a bit more classic Jenkins on brands. Are we gonna get rid of that feature toggle as well? Are you talking about auto refresh? No, the UI refresh feature toggles because it's not currently on my desktop. It depends if people just are really married to the current logo. Right. I don't think we've decided yet, but potentially. It'd be good to get rid of it. Just move it on. If people are really keen, we could add an opt-out. But try and, if the default is new. Yeah, I'm inclined to agree. Okay. Pretty small stuff there for that one. And that's the last item I had. Any need to jump back to any of these other things for today? All right. And that is that. Felix, do you want to speak to color variables? Yeah, so basically update color hierarchy that you, well, what Joe did was also not not just formalizing the color hierarchy, but also updated. For example, right now he switched the primary colors and the hover color because our, the fact of primary color was not the one we were having. So yeah, so these changing color will include several changing diseases variable API. For that, because, and I also want to take the chance to formalize all the colors into the easiest variables with the same, maybe the same naming that they already have on the design deck. So yeah, that's something that I'm going to probably do that API next week, because it should support all further work. So it will also mean for dark mode, maybe a bit breaking news for me for the pan. But yeah. There shouldn't be much. Yeah, no. Because you don't really use any of the, we don't change the colors or anything. No, yeah, but I think it's going to be a much healthier way. We just can specify a name there, for example, four or five shades of gray primary color. Because I think maybe plugins shouldn't use a side panel header color. But I mean, you should be able to use the primary, primary hover, a light gray or something like that, diseases variables. And that also will empower maybe Uli to, to try to use the diseases variables when configuring bootstrap in the bootstrap for API theme. So yeah, that's something that may work well. And these colors are only in for CSS or are you also defining the colors in the Java code somehow? No CSS, just CSS. But what if I will, I have an idea of what you can do in plugin side. I need to, I need to see if it's actually possible, but I will get back to you once I have the, once I'm able to have a proposal. Okay. Because in Jenkins core, we have several colors hard-coded in Java. Yeah, that, I mean, with that's something we're running away from. Okay. So I think you can use the CSS variables in the plugin from bootstrap. I'm positive, but I cannot promise right now. Okay. Because for instance, for charts, you are programming a model in Java. And in this model, you are referring color codes and not CSS variables. So this is something we need to be aware of. You can just replace those codes with CSS variables or duplicate as well, if you need to supply 11 as well. Yeah, I mean, things that colors that are hard-coded in Java side, that's nothing we can do about it in the same regard that we cannot make them work with dark mode. It's just, we're just not able to, and that will require duplication of the color codes, Uli. So maybe you can point them to me where the actual Java code is, maybe can you link the, if you can send me a link for that Java code, because I think it's nice for me to keep it in mind. Just to be aware of where it is. Okay, I send you a link here. Okay, thank you. Awesome. Tim, do you want to speak about theme manager? Yeah, yeah. So I just wanted to show the theme manager that I've made to try and make it easier for users to find and install themes in their Jenkins instances and update them as well so that they don't get stuck. They don't get stuck on one version forever, and they just manage the updates the same as any plugins. And also decouple the theme for the system theme and the user theme, so that users don't get forced to use a certain theme. They get the choice. So two sides, they can just, so it'll default to the system theme, but then they can override it and they can even turn it off and just go back to the default theme. It was all to kind of make it easier for people to use dark mode in their instances so that if I install dark theme on my instance, everyone who's using it doesn't get forced to use it. So I can probably give a quick little demo of it. Awesome, I'll stop sharing my screen. So this is a Jenkins instance just started from the dark theme plugin. And so down here, oh, sorry, I'm looking at the wrong Jenkins instance. That's the problem. This is the one from the theme plugin. I think that one was probably tables to divs. So here we go, we've got built-in themes. Possibly rename it, but so we've got a selection of themes. It's an extension point in Jenkins so any plugin can come along and add its own theme and it will just get automatically picked up. And the dark mode is contributing two themes. One is dark, which is just dark, which is just fully dark. And the other is dark with the OS settings. So if I go to my system settings here and if I go to light mode, it just straight away changes to light mode because it's using the CSS to detect that. And if I go back to dark, dark mode again. And then there's a user level theme. So if I configure it here, and if I go none, so now the user level, I don't have a dark theme, but if I log out, if I create a new accounts, user, user, user, user doesn't have read. So I can't read anything. And this user should be still be able to access to the profile if needed. Okay. Not that one. And he's getting the default system thing. So I've got, this is currently one issue that I have is that the login theme is not working. So it is, there is a paste operator which is modifying the login theme. But Jenkins's login system is stopping access to that. I'm not sure if there's a way that I can get around that. Yeah, I can have a poke around if there's some way to make it an unprotected resource. Or maybe it needs to load in a different way. Drop that. It all works with configuration as code as well, of course. And you can just pick which theme implementation you want. And so there's two repos, theme manager plugin, and so theme manager plugin, it's got, it's quite easier just to look at the implementation. So each theme is just one class. The theme manager will find out the URL for you. And if you don't need to do anything fancy, you just kid it. So it looks it up based on the descriptor name. And then you just need to serve your CSS file. And then this display name is just what shows up in the Jenkins UI. And then here's the dark theme system manager. It was very similar except it has to serve up two CSS files. It needs to serve this file and this file. But it just loads them in the same way. So it's a very, very small plugin. But now you don't have symbols configured on these classes, right? I need to add a symbol. I noticed that this morning. Dark, currently it currently works, but it's adding factory to the end. So I just need that. And even probably just that. And I like that. Yeah, that's basically it. Does anyone got any thoughts? So I'm still not fully convinced that we need theme manager as a separate plugin. Because for me, we still have an option to include it into the simple theme plugin. Yeah, neither. So if I go there, Daniel and Daniel and Tobias didn't seem too keen on that. We seem to want it, just want to keep it separate. So the users didn't have to have the simple theme plugin and just to keep it separate. So does theme manager create decorators on its own? So theme manager has the decorators in it. So it has a login. It's got a simple page decorator, which does the login page, line-up page and restart. And it has the just regular Jenkins page decorator. But that one won't conflict with simple theme. You've got to have both of them running at the same time. Because it's a list, I think, whereas the login theme is just the first one. Yeah, whatever works. So the main benefit of providing, because it is a part of simple theme as a user base, because simple theme is already used by 20,000 users. Yeah. But yeah, whatever. Yeah, I was just going to show you just a quick update on how the dark theme is going. Seems it's getting a lot of views. Traffic. So it's had nearly 600 unique visitors, mostly coming in from Jenkins.io, but a few coming in from Google as well. And it's mostly just looking at the read me. And a few of them looking at the issues as well. Yeah, and we haven't even started promoting it really. This is just from the Jenkins.io change log pretty much. Yeah. So yeah, we wanted to promote it as preview last week, but we are taking all the other events, et cetera, just to be a bit cautious there, maybe postpone it for a while. Yeah, I think that we should announce it. I have the impression that in the end, it will become official part of Jenkins core. I don't know why. Yeah, there was one question. Sorry, did I have one? I should get open a couple of days ago from someone asking if it was going to become part of the core and also asking if it could use the system settings. So I added the system setting support and possibly it could become part of Jenkins core once it's more stable. Yeah. Yeah, that's something. I mean, maybe by, maybe in a few months, we have a more stable idea of what we want to achieve with the, what are stable IPA variables would look like and then we can think about that. Yeah. Yeah, because currently we're only, there's only one. So it's all variables except for, there's a theme for the script console. That's the only thing that's not CSS variables that's changing. Yeah. It's just forcing itself to modify that theme. But there's probably better ways of doing that if we do it in core. So I guess the only thing that we shouldn't release it as a J plug-in until we make a decision whether it goes to the core or not. So what we introduced recently is a concept of incubated projects. So the projects which are actually available in the main update center, but with some disclaimers. So probably it's a way to go here. Yeah, I don't think it would make a difference though. If we did move it to the core, we would just keep the plug-in for a version and just remove the code and just tell people that they can uninstall it. Yeah. Also, will we? Yeah, just because the deprecating plug-in stuff is pretty much there and then there'll just be a thing telling people to uninstall it or even automatically uninstall it. Well, thank you for the demo, Tim. I can't speak as well about the implications here as the rest of you, quite frankly, but just looking at it sort of objectively as a user, I like that idea of not necessarily having to have my theme mandated by the selection made by my admin. So I think this is worth exploring and I appreciate the share. So, good stuff. Tables to div status, Tim and Felix. Yep. So there was the hack fest a couple of weeks ago. I'll just share my screen again and there was about three or four issues reported, I think. Too many issues recently. So we got two, so all four of these were reported out of the, so three of them were reported from the hack fest in March, reported this one a couple of days ago or in the weekend, I think. So we fixed the help button and the subsection titles issue over the last few days. I think Docker Hub notification plug-in has a PR. And so does this one, which is the ownership plug-in. Felix was going to try and see if we could handle some of those issues on the Jenkins core side. The problem, so one of the problems that we've had is with table tags that are declared in plugins, whereas the lower level elements defined in Jenkins core, so the TRs and the TDs, their control, that's all generated in core. But in some cases, the table is actually just put into the HTML. And so we can't automatically change that to a div by just changing a tag and jelly. And that's where the issue has happened. And it's about four or five plugins. It's been matrix auth, ownership, artifactory, Docker Hub notification. I don't think Docker Hub, the Docker Hub was something different. Maybe one or two others. I don't know exactly what the issue is, but I'm guessing it's in the JavaScript. Yeah, it's something JavaScript related. And the problem I think is that this is really something, somewhere that the change should be half a fallback and the code should be, the JavaScript code should be robust because the layout of the, basically with this problem also, it's not just the forum fields on work, is that the whole layout of the, of the, for example, of the managed Jenkins page of the configure system page is breaks. Yeah, and I think it also breaks saving as well. I would call this a blocker. It is something that I will, I am looking into. I haven't had luck, but yeah, help wanted. If somebody wants to deal with shitty JavaScript, pardon my language, but yeah. So this is one of the blockers I think of the moment. Yeah, I think it's probably only no one issue. I think all the other known issues have been fixed. Yeah, I did find a lot of doing a bit of code search, a lot of misused code that will break basically many plugins, but yeah, I don't think there's nothing we can do about it. Yeah, I mean, it's out of core plugins, even core, even the majority of well-used plugins, I haven't seen any more issues. I think there is a, one of the ESCM plugins still needs to merge and release. Need to chase the pipeline guys on that. But apart from that, yeah, this is... For example, I noticed that one of the plugins that break a lot, breaks a lot is one from OpenShift. I think it has a really low install count, for example. That's very niche. Yeah, OpenSack hit, I think it's cool. And like that, I mean, that's the first that comes to mind that there are many of them that breaks in sort of a similar way. So I think we may be on to something with that data, with that breaking, with that exact work. Yeah, cool. Okay, so let's try and fix that issue and then see if we can move it along. And there's also a risk of some of these conflict resolutions have not been the easiest. So I've done my best to resolve conflicts, but sometimes, in some cases, the code's changed. It's not just, so it's not the easiest to resolve, especially in CSS, when you can't visually view the code. So I've tried to do my best, but I've had like three or four conflict resolutions in the last few weeks and there's a risk that we're gonna introduce bugs back in. So I think we have a chance to explore whether we could merge an experimental UI. Yeah, that was the other talk is whether we could merge it with a opt-out or a rollback. So that's the limit you said that you're gonna take a look at, Felix. It takes time. I need to see if, for me, it will take at least two weeks to get the proper fallback out. So maybe that's something that we should do if we see things breaking a lot. Yeah, so we have a number of plugins which are known to be breaking. So definitely it's not the best time to release it to be opt-out, especially since right now we cannot even release fixes for these plugins. So yeah, maybe if we get everything fixed in a couple of weeks, we could revisit that. So how difficult would it be to maintain this branch for another couple of weeks? Maintaining the branch is fine. It's mostly just CSS changes that hit it. For me, the problem of keeping the branch for another week is done then. I mean, it's something that I think we either merge it this month or then I think it's too late. I don't know if you feel the same way, but that's what I feel. It's very tedious and draining to keep merging these conflicts. Yeah. But yeah, the most of conflicts come basically from dark theme purchase, right? No, no, there's very few from dark theme. It's like the side panel rework mostly. They've been the recent ones and there was something else as well, but I've done this, I think at least two side panel resolutions. Yeah, now I will try to look into the tables, into the table breaking stuff next week. It's possible over the weekend. Yeah, I'll see if I can have a look at the tables as well, because it's probably, it may not be too hard. You just need to find the magic line. Yeah. Just the problem is the JavaScript is very horrible to read and horrible to understand and very dated. Well, thank you all for the, you know, really tremendous work with potentially a lot of impact. So, and thank you for the update today. Awesome. Does anyone else, that was the last item on our list. Does anyone else have anything they want to raise in today's call? All right, I guess that's it for today. Thanks, everyone. Have a good week and in a couple of days, have a good weekend. Thanks. Stay tuned. Have a good week. Bye-bye. Thanks.