 Welcome, everyone. It's the 14th of September 2022. This is the Jenkins User Experience Special Interest Group. Thanks for being here. Topics that I have on the agenda, security reviews, UX improvements, October Fest, Open UX Regressions, Stalled poll requests. Any other topics you'd like to be sure we put on the agenda? I guess you've already got UX improvements. I've got some stuff to show, and I think Jan might have some as well. Yeah, great. What if I'm showing off some of the prototype stuff? Yeah, and I've got some pipeline graph view enhancements to show. All right. Pipeline graph view. Excellent. Thank you. Any other items that need to be on the agenda? OK, is the ordering OK? I thought security reviews, relatively quick progress check, and then focus on UX improvements. And we'll try to give ourselves enough time at the end to talk to the other topics. Daniel, is that OK in terms of the ordering? Open UX Regressions will be later in the session. Sure. Oh, I expected it to be quick, but yeah, sure. OK, great. All right. OK, then. So this section, security reviews for UX poll requests, is mostly about asking the group as a whole, how is it going with the security review process? Is it progressing OK? Are there any concerns, things that need to be raised? Or from Vodek and or Daniel, are there things you need to flag to the rest of us about it? And we'll especially let Daniel talk about that as I was not participating in this point. OK. I don't think anything interesting happened here. Great. OK. Any others who have concerns or topics that we want to discuss in the context of security reviews? OK, next then. Update the design of notifications seems pending for a couple of weeks for two weeks. The only debates in the poll request currently is about the area to put it. So it's not related to security. So it's been open for two weeks and hasn't been reviewed. God, OK, so I got it. Sorry. So what that really is, is that's that may be an example of a stalled poll request. Good. Thanks, Tim. OK. Any others, Tim? No, I think there was one I chased this morning. They've been waiting for a week, but it looks like it's been reviewed. OK, so the notification one also doesn't currently have any approvals. So it's not like we're currently delaying that. So it's truly stalled in that sense that their general review is needed. It's one part of one part of what needs to go in. So it's not right. OK. Any other topics? On security reviews. OK, and Vada, I assume the one that you linked in is for the discussion. Yes, designer notifications. OK, got it. Thank you. All right. Then let's go to UX improvements. So, Jan, did you want to take on first? I'll stop sharing my screen and let you share. Sure. That's a bit. Awesome. So what we're sharing is the prototype of a kind of future version of Jenkins that we're potentially working towards. So hopefully you can see my screen. I'm not really sure what screen you can see. Yes, we can see it just great. Awesome. So, yeah, this is this is a little prototype of where we potentially want to take Jenkins. So, Tim and I have been working on this and this is what will be demoing in a couple of weeks time at DevOps World. So I gave a little demo of this last week, well, the last last meeting and kind of made several refinements to it since then. So I just thought I'd kind of walk everyone through them and try to get some feedback before we demo to a larger audience and the couple of weeks time. So hopefully you can see the dashboard. So it looks like some of what we have at the moment. Kind of key difference here is that the navigation bar at the top is moved to the left. Just so we have more vertical space. And this persists as you scroll down. So it's always present. If we go to a project, it's a bit broken at the moment. But the layout is quite different what we have at the moment for projects. So instead of lots of links on the left, those pages have been kind of pulled out into these individual card components. So say, for example, the stage view appears at the very top, built history next to it. And as you scroll down, you'll have more information about the project that you've been for example. So we've got the test result trend and stages and kind of empty blocks at the moment. Just to fill the space, but we'll fill them before DevOps world. These cards are interactable. So you can full screen them, for example, and that will show you more information about that block. Popping up a build kind of follows a very similar pattern where we instead of having a large kind of sidebar we instead display that information on it one time. So it's kind of less clicking ideally. So the very first thing you'll see is this kind of large console pane or card. So one less click to interact with it. You also have kind of quick actions such as the copy button to copy the lock or download, download it. Again, you can full screen it to get more information and to fill the space. So we've got a little bit of an example of a little bit of a small space. That's the kind of pattern that we're kind of developing here really for these pages is this kind of card layout that can kind of flow to different screen sizes. So if you're in a mobile, it'll fit nicely there. If you want an ultra-wide, it'll scale to that too. So you'll have lots of information. So that's the kind of project and build page at the moment. Again, we'll develop that in the next couple of weeks. We've got a kind of really basic new project page at the moment. And the idea behind this is that plugins can integrate with it. So it's kind of taking version from Blue Ocean in a way. So you might have kind of kind of what do you call them? Get instances and they can provide little pieces of UI that can plug into this page. So if I want to connect to a Git repo, I just hit GitHub and I can fill in the information and we can go straight from there rather than building a project and doing it that way. Hopefully it makes the kind of process a bit smoother, but again, it's a bit work in progress. And then the last thing that we've been kind of looking at so far is updating the settings page. So in this instance, rather than having the kind of little by the card layout that we have at the moment, we instead of adopting a little sidebar. Looks like so, really. And you can kind of just quickly click through them to jump from section to section. And I'll hopefully be a bit easy to navigate what we have now. But yeah, that's the kind of current prototype we've got at the moment, still a work in progress. But if anyone has any thoughts or ideas, we're all for all these really. So on the settings here, the switch from card layout to the wire layout, is that to give more space for interactions? Is that, tell me about that one. I've enjoyed the card layout before, so I was a little surprised this one's switching. Tell me more about it. Sure. So for me, currently the pages of the managed Jenkins, that they kind of, a lot of the stuff in the pages aren't necessarily related to one another. So if we could break that out into kind of more sections if possible. And that's where I think the kind of sidebar approach would be better. It's easy to kind of flick through various pages rather than having to kind of go back to this main settings hub, I wouldn't call it that, just to drill into another section. But yeah, it's just an idea for now. It's not something that I'm necessarily pulling for, but it's just an exploration really. Well, and I love the exploration. So the concept, conceptually then on the left hand on the sidebar, there would be at least one row for each of the items that's currently in managed settings. And some of them would get more than one row. Yes. Yeah, yeah. Yeah. So typically related to the last comment there. So you expect to split the configure setting as configure system page into multiple section. Well, that would make sense. Yes. Because right now kind of plugins can put stuff in there as well. And it can kind of get a bit all over the place. So if we could kind of better organize that, that would be ideal, I think. Perhaps a concern that could be raised there is more about the discogrability of the stuff. When you install a new plugin, it's not always very easy to find where the plugin is putting its configuration. If it's in the security settings, the system settings, the job settings or anywhere and looking at the different page, doing a control F kind of like just searching the page is sometimes pretty useful, especially in very large instance. So just wondering about the kind of people. So search here as well, which kind of helps solve that security issue as well. Cause I think an example is Git plugin recently chain added some feature. I can't remember quite about, but it went on the security page, which was a bit different to other things. And so it's another place to look for, but you could find all Git configuration by searching or something like that. And Yann's been trying to enhance some of the search as well. Certainly on, okay, on my Android device, I've learned now by heart experience that when I want to do settings, I always have to search for it anyway, like was on my Chromebook. So the concept here might be add a search facility here that lets me search for all of the settings and then find the things that matched him. Is that what you were saying? Yeah. Yeah. Yeah, because I agree the example you gave from the Git plugin is a very recent one. It intentionally put something in security because it was security related, but all the other configuration things for the Git plugin system-wide are in the system configuration page. So now it's in two places. Good. Concerning the search ability of the plugin, it's something that the plugin has to change themselves or something that is done automatically at some point. What do you expect? Yeah, for search. Yeah. I'm not sure at this point. So Yann's existing search stuff kind of integrates with more components like users, builds, other jobs and everything. So I'm sure if you've seen it, the pop-out one which kind of splits the search results out into different sections so you can see what sort of thing it is. So that's something that needs prototyped at some point and did start exploring the search for the design library as well. Look kind of a similar sort of idea through this, but like searching all the design library components so you don't have to try and find what you're looking for, but you need to explore that a bit further. Typically, if you have a search that is specific to the configuration page, that could be pretty nice because if you are using just the generic one, you will get confusion, conflict with all the build and all the job and these kind of things. So that could be useful. This looks so promising. Yann, could you take us back to the homepage? I wanted to ask some questions about the cards there, if that's... So I've been using descriptions at the top to hide additional information. I think that in this envisioned layout, the descriptions are gone to focus instead on the jobs themselves and their results. Have I understood correctly? Pretty much, yeah. Forgive us the dashboard. We have a little card for the description there. And so I imagine that would kind of have a similar pattern on the projects that build to just not that part up yet. And I had a question, Uli, I believe. I think Uli Hoffner was with us. No, maybe he's not here. I was wondering if there was experience... Oh, you are. Okay, with warnings in G, are there experiences you've had on this card style layout that might inform us in terms of, hey, what's worked well and what hasn't worked well in terms of concepts and ideas? Yeah, the things I'm doing in the warnings plugin is a static page only for the warnings plugin. But this page looks like a dynamic one which uses, let's say, some kind of widgets from each plugin. Like you have on your iOS screen where you can say, okay, I have a widget for two rows and three columns. This looks like, is this the idea, Jan, that plugins can provide widgets for these screens which have a given width and a given height? Or what is the intention? Yeah, that's pretty much it really. The idea is that plugins are able to provide a widget and they'll sit inside this little card surface and they can provide optional controls on the top right as well. So it's always consistent between plugins. Out of curiosity, are you guys using a framework here for the UX elements? No, no framework for this. And so back to Uli's question on the sizes, there are some conceptual sizes here then, like build history is it two by two and stage view is four by two or is that not a concept for you? ATs, I've just not really kind of had the chance to think that for a year. But as you can see on this kind of larger size, it doesn't really scale too well because two kind of column widget can't fit kind of the one space. So it's a bit where the moment it kind of fits back like that. It's currently just it's large card and regular card, I think at the moment. I think we tried something similar with a pull request dashboard where we propose a lot of widgets, which show the results of a pull request, how many changes, how it's the code coverage of a pull request, et cetera. And we started with pixels as width and height and this was not really good. So I think it would be much better if we have a layout like a grid of 12 by 12 or what else? And then we can have some widgets which are only small widgets or large widgets. This would really awesome for plugins to contribute to. This requires a lot of work for the plugins, but I think it's worth, it's very helpful for plugins if we can. Currently, we have just a list of blocks which is not really helpful to this. There are so many plugins in one job. So I think it's a really good idea to go this way. And one thing I think would be really helpful if I'm not sure this configure button is maybe it's not yet programmed, but it would be helpful if we can select widgets somehow. So because some people would like to see the test results, some other people's would like to be the stage view and some would like to see the build history, but nobody is interested in everything, I think. So because typically in a team you have project manager who is more interested in some overviews and the developers would like to see something totally different. So it would be helpful if we can configure this per user. So are you envisioning it as a per user thing? I was assuming this was a static page, static definition page like the current Jenkins pages, Jan. I'm thinking it could go either way, really. I do like that you're being customizable. Obviously everyone has different needs. It'll just run on how much complexity that adds to everything really. I have to kind of see how it develops really. Cool, thank you. This is beautiful. There's really marvelous work. And the bar on the left is just the dark bar on the left is just part of the web page. Yeah, that's the kind of... So on kind of current Jenkins, you've got the build history and the users, they kind of sit there at the moment. Not too sure how useful that is. And kind of seeing this bar as a good place to have kind of permanent links that you kind of frequently want to access or links that kind of span across pages, for example. So it depends kind of what's useful. Home or dashboard is useful. Search kind of pops over the kind of current interface and settings I guess is valuable, but the rest I'm not too sure yet. Impressive. Any other questions for Jan? Anything else you want to show Jan before we switch to Tim? That's everything. Oh, sorry. We have a question about this UI. What parts do you envision to be extensible? Because, I mean, this looks great, but as we know, for example, from side panels of jobs and builds, the challenge is to make it work once every plug-in dumps additional links everywhere, because obviously every when there are things their own plug-in deserves a spot in the top level navigation that's shown on every page. And so this won't be just seven links, but more like 50. And how well does it work then? So for the dashboard, I was kind of envisioning this, this kind of sidebar was being extensible kind of much the same way it is now. Plug-ins can provide their own cards here, for example. Currently, kind of secondary sidebar links would appear underneath this kind of overflow button, kind of links that aren't important or very rarely used, for example. So yeah, we'll definitely be areas for plug-ins to integrate, but I guess it's still an issue if we kind of go overboard with it, you know. So I interpret that to mean that the left-hand side will be less extensible. It's less likely that somebody is going to add their own there because likely we'll be blocked from doing so. They would be rather added to the three dots on the right. Did I understand that correctly, Jan? Yeah, yeah, yeah. Any kind of Jenkins-wide spanning links, such as settings, which is accessible from every page, we'll sit on the left, page-specific actions will sit in the kind of page frame, whatever you want to call it, and kind of release some cards. But yeah. To evaluate this, it would be interesting to know kind of how the existing extension points map to locations on the new UI. So for example, root action, if the bar on the left is not extensible at all, where do root actions go, stuff like that, I think that would be interesting. Similarly, on this page, how would you present existing prominent project actions, which is what graphs and such are currently implemented with, if they show up on the build's main page? So I think that would be our job's main page. So I think that would be interesting, you know, existing extension points and where they appear, even if with reduced fidelity, because there's some backwards compatibility requirement there. And for it to look really great or integrate really nicely, for example, to have this full screen button on the top right of each block, they need to use a new API. So I think that would be very interesting, very important because obviously we're not starting from scratch, right? We have 2,000 plugins we need to take along on this. And if Jenkins looks great, if you have zero plugins installed and there's an unusable mess as soon as you have a realistic setup, I don't think that would benefit anyone. I agree. I'll have to kind of start running up some kind of docs on this really. Oh yeah. That's the kind of prototype, right? If anyone has any kind of feedback, sorry. But don't get me wrong. It looks great. So I like the bar on the left, for example, design-wise. And last time when you presented this build view already, I think it looks nice, but I worry about how all of the plugins that people are already using will integrate with this. In Blue Ocean, we basically didn't even attempt it and that didn't go well. And so I think with a UI redesign like this, we need to have a plan to make existing functionalities still be reasonably accessible. For the existing kind of press bring up like CI Jenkins. For existing kind of project page kind of plug-in integrations. I was imagining we could just kind of wrap them in a kind of basic card in a moment. So for example, the test results could be a card. And then the current stage, you could be a card. And that can just, say, be placed at the bottom, for example. So it's not about backwards compatibility, but say when a plug-in developer kind of enhances it for the new design, it might get a more prominent position. For example, it might get access to the new kind of controls and so on. So it can integrate better. One thing I do want to kind of get rid of is kind of this idea that plug-ins can just truck stuff wherever because it kind of gets a bit unbiased. Like right. Literally what's on those, I think. Right. And you missed the most important one. Could you go back to CI Jenkins. I owe it to the main page. That was the dashboard. Yeah. So where does the we need beer link go? That's good to say in the fall, absolutely. Okay. So it's extensive after all. Okay. Yeah. We need to put that one plug-in. Those of us who do not, do not drink beer object to this, but okay. You can have your grape juice, Mark or orange juice. So whatever you want. A couple of questions. I don't know if I missed, do you guys have a date in mind when you're hoping to have this kind of in-users hands or is it kind of TBD? Yeah, no, no date, really. This isn't Jenkins at all. This is just a prototype. It's not built on top of Jenkins itself. So is that like six months here next week? No. I think that was the first time that I saw this. At like. No, I, I, I, I, I, I, the answer I interpreted was. This is, this is a sketch. That's realized as code. Right. So, and, and Tim and, and yeah, I, I heard no, no mention of any date. And I wouldn't expect anything, right. I mean, it's whenever, whenever the prototyping looks good and it evolves and continues Okay, Christina, sorry, back to you. No. No, that was that was it. I imagine kind of a decision to kind of remove some of the Jenkins branding or is that something still being worked through. Yeah, no decisions around that really. I had a little Jenkins logo there initially, but it just kind of got a bit corrupted so I changed it to a home symbol. But yeah, no false and branding really would be nice to make it more Jenkins D. That's a word. And as well as the accessibility piece because I noticed that there's some like keyboard traps and stuff so I if this is a perfect concept I'll stop looking. But it's just something to have top of mind as you're building. Awesome. I'll stop sharing. If anyone has any kind of further thoughts or anything do do give us a ping. Especially next two weeks as we've been demoing it to like an audience in DevOps world and I don't want to get screened out. Would be would be nice. Yes. Yeah, so we'll be at the contributor sub summit on the Tuesday and then on the Thursday will be presenting this at DevOps world. Yeah, looking forward to it. Thanks very much to both of you. Great traveling to Orlando. See you there. Sorry, go ahead Christina. No, I'm just curious what the next steps would look like after the demo. We'll do some hacking on the plane. We'll see how we get on TBD, big TBD. Hey, Tim, you I think you had the next topic. Yep. So I'll share some of the enhancements to the pipeline graphic plugin that's came in. So quite a few people would have seen this before. The graphic plugin was a kind of prototype that I did during the UI UX hackathon last year. Haven't really had much time to work on it over the last year since the hackathon itself. The last, there's been a few features introduced since by other contributors, but basically it's a idea about moving blue ocean into classic view into the regular Jenkins and kind of some of the features, hopefully with more of a extensible approach and without needing to basically the custom app that blue ocean is and making it a lot easier to develop on and maintain. So since the initial release, I probably haven't really presented it much since then, but it's had two new features since then one was the job view and one was a pipeline logs view as well. Those are all in kind of semi broken state. There were some issues and the blue ocean graph wasn't accurately represented as it was in the pipeline graph view. Some things just didn't work right for my prototype. But over the last week, we've had a contributor come along and fix all of those issues basically all the graph related issues. We currently have currently have no open issues with any reproduction issues from blue ocean to the graph. And there's also some pipelines that can be represented in the graph that couldn't that blue ocean wasn't able to handle the only open issue related to the graph is now the pipeline visualization support, which was the most upvoted issue on blue ocean and was never solved. So then that's the only visualization issue still open. So just show you some of the enhancements. So there's a recent one. So it was fixed yesterday was just go here, show a simple one. It's taken a deviation from blue ocean where declarative is now showing its synthetic stages. Previously in declarative they, it was shoehorned into the previous stage. So there's a synthetic stage and to curve. SEM when a when it does the global check out for the for the whole agent. That was just randomly put in the first stage and same with post action. So if you did a post actions across the whole pipeline that was put into the last stage randomly, but that was found as a bit confusing. And so we've just put that in here just to see how it works. Benefit is you get a actual stage up here at the top and you can see the check out in case that's ever useful. So one thing that I'm working on that's not released at the moment is I'm adding node status to stages and steps. So you see here these have got the tick to say that that step was successful. So that's all working. I just haven't created a PR for it yet. Just to show you one where it's failing. I think this one here. So this is a. This is a build from the slack plug plugins master build, which running on my local machine. So some things aren't quite there. So this is the visualization as in blue ocean. It's all accurate. If I go here, you get set up the parallel branch failed. That was Linux 8 branch failed in the build stage. Nested stages don't work properly. So this in theory should be nested under another level, but that doesn't quite work in the log. And if you go down here, you'll see that it was the step here that failed. And you click on it and see the logs. And this is one of those Jenkins isms where it failed for a agent connection issue, which never appeared in the blue ocean log either. So if I were to go to the plain console log, you'd see that it's got stack trace with no such method error is what it failed with. And the same with blue ocean. So blue ocean wouldn't display that either. It's the same sort of error because be using similar APIs, I guess. But yeah, so that's the stuff that's kind of most of this is real. And so the other thing is that it used to be for those who've seen this before say on ci.jncon.io. There was a few. I'll just show you the released version. Depend on whether they've updated or not. High-plane graph. Sorry. So yeah, this should all be fixed visualizing. So yeah, so they haven't updated it here, but you see that there used to be a couple of UX issues here. One, the step would overflow into the pipeline log area. And the other issue is that you can't really tell the difference between steps is they're pretty much the same. There's no real clear separation. So I've added kind of this is probably a bit more obvious and not dark theme, but there's little separators between each step. If I go to here, it's all rounded and highlighted more clear and the text doesn't overflow anymore. So Daniel, were you saying something before? No. Probably also helps that it's a one column view now. So you have more space. Right. Yeah. So that's the other thing is that I've got rid of the side panel. As before, I only had this back to build thing which took up all the space over here, taking up a lot of room for nothing basically. And same here with the graph. It was moved all this far away over to the right. And so now it's moved to a much better location. Which, yeah, makes it all work quite a lot better. So something I'm working on, which isn't released yet, is kind of pulling in some of the concepts from the prototype that we showed earlier. So if you see here, this is using the card design. So it's pulled in a the build display name. Hopefully pull in the for poor Chris hopefully pulling a poor Chris title here probably. And it's pulled in the card details and the stage. And you can rebuild it and go to like a configure page. Showing that links. Yeah, so it's going to the right place. This will trigger a new build but it's not actually hooked up fully. So it's Is there a way for me to suppress that card on the right hand side sometimes my graphs are are are embarrassingly large. So or is the is the card that you're showing with details expected to be yeah that's going to be there no matter what. I'm sure I think if I've got a big one here. I got the packer. I've got the packer images matrix to see what it looks like. That's a fairly large one. Not sure how big you're thinking. Yeah, so my worry was more about the horizontal rather than the vertical the vertical. I think that handles it very, very well. There are times when I've got long, long chains that are running. Oh yeah so sure. Thank you for having me. Big ones. And Tim you don't particularly need to even show it. It looks like this is ready for me to do some experimenting and testing and you'll happily take bug reports. Yeah, yeah, yeah. So let me just do my stage post parallel. Live stress testing I'm very impressed him. Just try it. I mean labels are unique so it doesn't even matter. I just run that that should cool. So scroll. Okay, so just horizontal scroll bar. Okay. Yeah, I didn't try it on any long ones but yeah so that and it would have like yarns this if you remember the full screen sort of click so you could add that and then expand it out fully. But yeah so this is something that I'm just working on at the moment. I'm not sure. And it's, yes, so this isn't a react app. So I'm not sure how extensible or what not but it's kind of just a prototype I'm working on. Probably just to sit in this plugin for now and then look at how we can pull things in better. In a more extensible way, and kind of just as a really look before before breaking this into the main Jenkins it's kind of a good place that we can experiment with some of this in a plugin. Now you had mentioned something earlier that's you got me all wound up and happy about build 374 that was on the page there. You mentioned that might someday be the description of the pull request so that instead of trying to remember what PR nine means it would tell me hey this is this was what pull request nine's description was. We got that in the prototype at the moment. So this at the top is the Jenkins build display name, and then this is the pull request title. Okay. So we should kind of assume that you'd want both the Jenkins build display name and the pull request title, probably. Ideally some. If you're pulling some like. We basically is bringing some other get information a bit more into Jenkins so that you know what it's not PR 370 it's marketed something. Exactly yeah thank you yeah I agree I think the build number is good the build identifier is good but but I would love to have that pull request there because I inevitably click through that thing to find out which pull request is this. Thank you. Yeah, so that's kind of trying to pull some of this information a bit cleaner and as well if I just go simple one. Yeah so it's got like the PR link and that and a nice easy to find place because the existing CI is not it's in a giant side panel down here, if it's even here. Yeah you have to go up one more level to get it to get the GitHub link right and now the GitHub link is there but it's in the middle. Yeah, it's really hard to find amongst a bunch of stuff unrelated. And is it not really not a poor question at all on here. I'm sure there is yeah. I've got a poor request. So, I could have sworn there was a poor question but I can't even find it so yeah exactly. Thank you. Any questions, any suggestions anything you'd like to see. So the, the graph improvements are already released. So, I find graph view I should be able to compare it to blue oceans graph rendering and any surprises I find you'll have to take us by group. Yeah file an issue with just with a simple pipeline. If you see recent one basically just don't don't use an agent just basically just put your stages and and put echoes to identify what stage there or whatever. So if you see my ones here they're all. So it'll be something like agent, any agent none, mostly agent none. And then using echo not shall because you don't need an agent just so they run super quick because just about visualization. And a lot of these go into the unit tests as well. So they unit tests will show the visualization make sure visualization doesn't regress when changes are made. So yeah, anything we're interested in. Yeah, anything that doesn't match the ocean currently unless there's been decided to deviate so what these synthetic stages have been pulled up and they've been marked as italics just to kind of highlight that they're a little bit different they're not, you don't have any control over what they named or anything. They are actually prefixed with declarative colon space which is not really very useful, and just takes up a ton of space. So if you look at, I don't know. This is any declarative on CIG's I. Yeah, acceptance tests so under infra acceptance tests. I think the, yeah check agent availability I think is declarative. Nope, nope sorry it's not helping. Okay so anyway there are declaratives that do to a global check out you'll get a stage here which says declarative check out ECM. And basically it strips that in this implementation, same a post actions it strips that and the reason for one was it's not helpful and two was it the label just cut off because you're only allowed like 10 characters or whatever before you're outside here and you get the dot dots the same as blue ocean. That's probably an example with long labels somewhere, not sure. Welcome to the, it's all the matrix builds. So it's these sort of things just not very great and we'll be good to improve but just needs to figure out how to make that readable without spamming it. I mean, just doing the values might be a start. Yeah, so there was this suggestion. Yeah. So there was one suggestion to do matrix brackets and just making it a lot shorter basically, but yeah just dropping matrix and simplifying it. Yeah. Not sure. Joe anything else. Looks brilliant Tim thank you. And thanks to whoever that contributor is that contributed those fixes that's that's really great. Yeah, that was my girlfriend. So the back graphics is basically just been really good. And then I've just been working on some of the console view and the cards. And I hope to do some more work on it before DevOps world and probably show this as well. Yeah. Thank you. That's great. So next topic on our agenda was. Let's see and you should see my screen again. Do you see the agenda. Yeah, okay, good. Next topic I had was October Fest and you exit and Patty you wanted to bring this topic. Yeah, hi, I haven't seen you all in quite a while. So, I'm just trying to get more people involved in contributing and seeing the Jenkins workspace. And so I have a UI background so I'm helping with some of the organization stuff that is happening with October Fest for us and I was hoping that maybe there would be some good issues that we could maybe get from the group. Just to say, I, I've heard that maybe it's not the best place to be a first time contributor to Jenkins so of course I will take your feedback with me. But I was just curious, you know, to kind of get the feel of the group to see if it's something that you all had typically participated in as maintainers before. I was just trying to get a temperature feel. So, so part of me wondered that most of the UI things for me are beyond a first time contributor. But with Uli here I wonder maybe there are things from his experience with coursework at the university and his environment for warnings and G and data tables that maybe that is more of a October Fest kind of topic. Could you absorb October Fest contributions or did you find them a distraction in years past. Yes, I tried to use hackathon last year or October Fest last year to get some contributors on the UX side. But this was a real disappointment. I think I created about 30 issues in the code coverage plugin and the warnings plugin, which are only UI related somewhere really easy and somewhere a little bit more difficult. But actually, two issues have been picked, but nobody completed actually any work. I spend a lot of work to create these issues but yeah, I had no output at all. So, I thought maybe it's too difficult. The problem is you, you need your UX experience and you need Jenkins experience to understand what's going on. And I think this was the main problem that if you have a UX expert, then you don't have someone who knows what is code coverage and what to show in code coverage. So, I'm not sure if it's so helpful. Do those issues. Sorry. Sorry. I just do those issues still exist in that plugin. I think a lot of them I fix on my own. And but there are still some here. Yeah. There are some remaining, they are still open and I removed the October Fest label but I can add it again so I'm fine with it to add it again but I'm not sure if it's really so helpful. Yeah, I know a part of what I'm trying to do is get a list so that we have them so that when we're in a group because we actually have some dedicated time for our community team this year. As well as with our like design system team, and we have four front end engineers on that team. And so having a list of what we, you know, is available in the Jenkins space for us to go try to tackle might help get better eyes on those tagged issues. But also I realized that it's, you know, it's, it's a, it's an ask for a little bit of work for our maintainers who are active in this workspace and so definitely want to make sure that we're respectful of that and being helpful and not adding more, you know, useless work for you. Yeah, but I think it's not so really useless because I use these issues in it for different audience and for instance I use them these issues for my students that's okay too. So, I just noticed that it was not really helpful for October Fest. Yeah, so what I can do is to review these issues that I have. And I also can add a lot of new ones. A lot of them I can add. So, maybe it's helpful and if it's not helpful it's not. The effort is okay to spend because I can reuse these issues for other projects as well so Yeah, I mean that would be great I know I'm, I'm really interested in getting my hands dirty with Jenkins and I would be a first time contributor to Jenkins so I would be super curious to see what those issues are. But also I can help kind of mobilize them within our team. You know, there are some simple issues just to support our black theme, for instance, there are a lot of things which are not really working yet so this shouldn't be hard to implement. Even for someone who does not know Jenkins really good. Okay, okay. I think I can prepare one in to the next week and make a list of these issues and send them to the UX list or to you directly how you prefer. It's okay, yeah. Yeah, that would be great. Thank you so much. Okay, yeah, fine. There are a number of open issues on Jira, which some of them are probably fine for new contributors, some of them not so. It's quite a lot of open UX regressions which probably be looked at. And if there's more experience for engineers, there's pieces of work that are getting a bit stalled that could certainly be helped with in certain areas. I'm not sure there's things like TEPI and then there was the Jenkins button rework that was tried a while ago, which would be nice to revive. Okay, would it be, would it be helpful for me to go through the Jira and pull things that I have I think are what you're talking about and post them in the getter to get feedback on if these are ones that would be good first time issues. Yeah, you could also do it on the UX CIG repo with an issue or discussion. Getter doesn't really read so well for ongoing discussion. Okay. So Tim, the UX CIG repo that's can you could you hook the URL to that I don't have that immediately available. I've put it in the chat I can. Thank you. Good. I can put it into the page and if you've got it in the chat. Thanks. This is awesome. Thank you so much. Great. So to what degree would adapting plugins to recent UI work in core be a viable beginner task for Octoberfest in general, like, like I'm thinking of all of these CSS classes like Jenkins table and Jenkins button and stuff like that. I imagine there's probably a thousand plugins that might need updating or to what degree do they need to be adapted to those changes. Yep, that'd be good piece of work. That would be fairly straightforward. Plugins like lockable resources. Others. It's the most prominent one I know that's not adapted. It's been a lot. The more common ones have been adapted. But I'm sure there's plenty of other useful ones to look at. So and Daniel when you say adapting them to the Jenkins design library you specifically mentioned CSS CSS changes, I guess tables to divs if they've not already removed if they depend on a version after 277 they could remove the work around. I know I'm just I was just working on one yesterday that hasn't yet been adapted. It's much low volume. So tables to divs kind of things. Okay. The general tables like on about Jenkins with the dependencies and the versions and the licenses, or plug in manager table I think there's a change there to make them look a lot different than before. I haven't thought about this beforehand so there's probably a bunch of potential changes where do you I guess big table is the old one I think and that now needs to be a Jenkins table or something right. Yeah. Another thing would be icons and colors to use the new defaults that we have. Yes, yeah. And another project is things like ripping out back to build links and that sort of thing and removing side panels that don't need to be done like so I didn't actually show it today but there's a, I did a progress on the credentials plugin to rework its layout but so it basically removes the side panels mostly and moves any actions from there into the app bar along with a couple other fixes I think. Okay, so and those some some or all of those Tim sounded like they might be good first issues or are those. Yeah, I mean that credentials plugin layout rework I think was way beyond a new first time contributor but icons and colors seems sounds like it could be within reach. Yep. Yeah, to a degree, the challenge here is basically identifying plugins that misbehave in some way, not everything is as simple as Tim's query for big table the keyword. But one of the things is for example if you would not have a site panel with links other than you know back to dashboard, then we would change the layout to not have a site panel at all I think is the current rule. And if you know of plugins that do have such pages, then very low hanging fruit kind of improvement is changed the layout of the page, which is basically just one keyword in the layout tag, and it'll look consistent with the current design library rules. And there are handful of these changes that we can define very generically. And then, you know, if you have your favorite plugin that few other people are using, and you want to look into whether you probably as a Jenkins user you probably already know whether that plugin behaves according to these rules or not and if it doesn't can file pull requests for it. Good. Thank you. Alright, so Patty, I think that addressed your question. Thanks very much for bringing it. Any other items on Hacktoberfest so we're now at 14 September. So we're in what the Hacktoberfest team calls preptember. Welcome to preptember. We're very glad that you're here and Hacktoberfest starts October one. And ready for next topic now we're just past the hour. Daniel you had said you open UX regressions might be brief would we like to take two more minutes for open UX regressions. And then in the meeting or do you think it's going to take longer than that. What's your preference Daniel. I think it's pretty quick. It's just me sounding like a broken record. Okay, go ahead. We have a bunch of UX related regressions and they're not all trivial to resolve as we've seen in some core pull requests, usually the change that causes a problem has been done for a reason. And just removing the line of CSS will not. While it makes the problem go away it introduces a different problem. So, I wanted to raise this to this group that roughly a third of all UX regressions filed over the last nine months or so are still open. And I don't think that's a great state because while the improvements are nice. If at the same and they look great and everything and for the same time, they break people's use cases. Then, you know, acceptance of those changes goes down. Right. And so I think it's important for us. For us being able to deliver these changes especially larger scale changes to also address reported regressions in a timely manner. Thanks. Thanks for the highlight well and and this UX regressions over time dashboard I'll put a link to that into the, or you've already put it into the page haven't you. Yes, good. Thank you. And as you can see the graph for the same query as Tim's dashboard. It just highlights, not just what's currently open, but how much has been filed and how much of that has been addressed. And as you can see, there's quite the gap, both in absolute terms, as well as in relative terms, a third of all file regression still being open is is a lot. And it seems to keep growing. Thanks for highlighting any anything else on open UX regressions. I would say that in some area Daniel's overstating the impact. Breaking users credit you breaking users functionality. I don't think there's any example of things actually broken. Other than a password manager field or something that's been broken for years. There's a few oddities, but there's nothing that I'm aware of it's actually broken other than the only one that users care about is the weather icons one, which we really just need. To replace it with that looks nice. And that was done by the cloud bees UX team before they well, the cloud bees team that was working on us before they rolled off the last thing that was done was these weather icons and I think we just don't have a good weather icon set but that's the only one that users. There's more that the users are up and arms about. Obviously these need fixing but I think it's kind of overstated events of the regressions. I do have a branch for the weather icons. Would it be worth kind of getting that open getting it reviewed, even if the icons aren't perfect. I guess you can iterate later. Yeah, they solve the kind of issues the user having. That's the only one there where there's any users complaining as far as I know. There's no risk to oddities that have been picked up and filed. Like the sign in buttons gone a little bit extra focus recently for some unrelated change. But it's not affecting anyone. Thanks Tim, any any other comments or any other items on UX regressions. I propose we go ahead and end all after the recording is archived. I'll upload a copy of the recording. I'm going to actually put index points into this one so that people can see jump to various points in the demos. Thanks John thanks Tim, looking forward to seeing everybody at DevOps world. Thank you very very much. Thank you. Thank you.