 Welcome, everyone. This is the Jenkins User Experience Special Interest Group meeting. It's the first day of February 2023. Thanks for attending. So topics for today. We had included security reviews for UX pull requests. Tim's probably not here. Vada, is it okay if I put you on the on as that topic? Yeah, for sure. Okay. Collecting general feedback on UI and UX regressions was a topic we had before. What's happened recently in UI improvements, what's coming in additional ones, and improving keyboard usability. Christina, I'm prone to move this one higher on the list to be sure we get to it if that's okay. Yeah, I have a short update, not a huge one. Oh, good. Okay, great. Well, so then I'm going to move it upwards. And Vada, we had a topic on feet user feature flags from the past. Is that something you would like to do further in this meeting or no. I don't think there is a lot of discussion to have there the pull request is still waiting to be merged. It was mainly reviewed and partially approved. I had a topic to add. Close to the bottom of the list, which is deprecation of Jenkins JS libs. It's, it's has something to do with the work I've been doing on the pipeline groovy plugin. Great. All right, so deprecation of Jenkins JavaScript libraries and pipeline Ruby plug in. I improvement work. Okay, great. Thank you. All right. And specifically here it's ace editor moment JS and others right. Yeah. Okay, great. And, okay, and Uli is the app are ready for build actions. Thanks for proposing it that's good. I'm not sure if that makes sense if never young or, you know, Tim is there, but we will see. And I think let's, if you're okay with it, let's put it to keep it on the agenda. And, and we may decide to defer to next meeting, that's okay as well. Great. Great. All right. Let's do that then and see Kayla. Okay, good. All right, any other topics that need to be on the agenda. Okay, then security reviews for UX pull requests vatic which you're okay if I open this one. Thank you. Thank you. All right. So as you can see there, there are only two pull requests that are waiting for security review both of them are mainly stalled in terms of the development so we are not reviewing them if they are not ready to be reviewed in a sense. If you open the first one, it will be especially interesting to see there, something that I would like to avoid for the future is mainly. It's mainly it was approved. But there were some change that were added to the pull request, we need to have the need security review level to be going back at that point otherwise we could have some vulnerability introduced as well. At the bottom of the page, you will see, as a potential future that there was a vulnerability introduced after the security review. So it's a bit lucky that we were able to review, to review that and to catch the vulnerability. But it just to highlight the fact that if we introduce a vulnerability in a pull request, it could be very expensive for the security team to do a security release for Jenkins core control to just waiting a bit to review pull request and doing that during the pull request like I was. And I apologize that my page is not I see this, the bar moving across the screen still vatic and I'm not sure what's going on with GitHub today. You know, the don't know about the top is just an indicator, there is no real information behind. Oh, okay, so agenda and do not care about the data. I want it so that's the main point. Okay, great. Thank you. Any concerns from any others on how security reviews are progressing I like the suggested the recommendation, please ask again for security review. I assume that's what you're envisioning there is that the plug in, or that the author of the pull request should put the need security review label on again, after they've made significant changes. Yep. And I would say not necessarily substantial change, but just something that could be interesting for us, meaning if you corrected a typo, we do not care. But if that typo is a HTML part that is using a variable, please ask for a review. Good, that makes sense so apply your judgment as the author of the call the pull request to decide yes I'd like another review. And in case of doubt, just ask. Great. All right. When in doubt. Ask, or when in doubt set the label and you'll clear the label if you think it doesn't justify it. Okay, or set the label and rely on security to on the security team to clear it. Good. Thank you. Anything else on security reviews. And next topic then was collecting general feedback on UI and UX regressions and I believe the last time we discussed it was continuing to use JIRA as the collection point. Were there other things that we need to discuss here on this topic, or should I drop it from future agendas. I think we can drop it. Okay, great. The feedback there is also related to the user feature flag. If you're able to provide a feature that is broken just disable the flag, and that information could be collected in the future automatically with the telemetry, so that we know if a feature is broken for some people or not. Looking forward to have the true request being merged to apply some telemetry. Okay, it makes sense. So that's on general feedback. Next topic then improving keyboard usability Christina. Now Christina do you want to share your screen what what would you like. Not this meeting so bit of a background on this so we know that we have a few accessibility issues to resolve on CI in general, some of them originate from the open source. Jake, we have to work out a few details just around how we want to handle pull requests from the community and work out our process there before I start. I want to get that sorted before I start to create tickets and bug people. None of the changes that are needed are heavy lifts, it's all front end facing around keyboard accessibility, mostly for this round anyways. And I can certainly provide guidance around what's needed. So there will be tickets coming. We're working out our own process around that right now just because it needs to kind of align with some work that we're going to do internally as well. So they're coming plans getting in place and then I'll create tickets for the open source. Great. And of course, like I'm very open to feedback on how that works down as we go to to to flesh out a process that works for all of us. Right, so, so I think what I'm hearing is we can look forward to some initial reports of hey here are some accessibility issues detected, and later we'll look forward to some pull requests and here are the pull requests that resolve some of those accessibility issues. Yeah, we have a laundry list of requests from clients. And some of them are issues that are more pressing than others. So for this initial round we're really looking to just deal with the kind of the show stopping issues where say a user who's relying on accessible technologies. We cannot navigate. We're looking to fix those first and then we can work through the kind of then don't a couple of nice to haves they're all, you know, we're supposed to accommodate them but the ones that aren't quite as our roadblocks in the same way. Great. Super thank you. Anything else or any questions from others. Okay, thank you. Next topic then was what's happened recently in UI improvements and I don't have a story to tell here are there others who would like to highlight recent changes or things that need to be discussed. There was a single recent fix, and it was related if I remember correctly Uli in app bar right in some portion that involved in that bar, but I don't remember the details. Actually, I don't remember the details. I've seen that a fix was in the last release but actually I don't know what's exactly broken there. Okay. Great. And the what's coming in UI improvements. I know that young and Tim had been working on further removal steps for Yahoo UI and that there are some things in flight there. I think it's a good lead into our next topic the deprecation of the JavaScript libraries unless there are others who have topics they want to discuss on what's coming in UI. So Basel let's take the next one deprecation of Jenkins JavaScript libraries you want to share with us what what you've learned and what you've proposed etc. Yeah, and it's not just me working on this. It started back a couple months ago when the pipeline stage view plugin was updated to remove its dependency on handlebars. And since then, it's also been updated to remove its dependency on moment JS. And then I've also yesterday proposed a change to remove the AC editor from pipeline groovy. These are the last three big dependencies on the Jenkins JS Libs plugin, which is dates back to 2015 and has not really been maintained since then. So we've been deprecating these older library plugins like moment JS handlebars, hopefully AC editor will be deprecated soon as well. Once we stop using it from pipeline groovy. So the only thing I wanted to highlight here in this meeting was there's still some bits and pieces left in Jenkins core that have something to do with this subsystem. And I, I haven't figured out what they are, or if they're still needed. But the less and less we depend on this less likely I think that they are needed. So, maybe it very well might be the case that once we rep out AC editor from pipeline groovy think that's the last or close to the last plugin that's using the subsystem. We might also be able to remove the bits and pieces that are in Jenkins core that only exist to support this framework. I'm not really sure one way or another. So that's why I wanted to bring this to more people's attention. Since I don't know much about this, but I think there I think there's more cleanup that can be done. And this has some security impact because these libraries are all pretty old and even if none of them are vulnerable right now. They put us at risk for future vulnerabilities just because of their age. So it would be good to get rid of these little bits and pieces, if we can. I think there's also still a plugin that's using this that nobody has fixed yet, which is the GitHub. One of the GitHub plugins forget which one. I want to think one of the GitHub plugins is still using one of these Jenkins JS Libs plugin from 2015. So you know we could decide if we, if we think that it's important enough to patch or if we could leave it behind but I think so there's there's still more cleanup we're not done with the cleanup work is what I'm saying. There's still plugins left, even though they're obscure that are that are using the stuff and then there's still bits and pieces in core. So, definitely something that we'd like to to get fully deleted, so that we don't have to worry about it. Great. Does that mean that we don't use moment chairs anymore or just the chairs lips wrapper. So you're doing your own most, most of actually, you know what I did with pipeline groovy was it already had its own webpack build. So I just integrated a CE editor into that. And in general that's essentially an equivalent to Jenkins JS Libs is stuff like these modern technologies like webpack they're doing the same thing as what Jenkins JS Libs was doing, or similar. But it's just that these are now standardized industry wide rather than something that our project developed seven years ago that's not maintained anymore. And one thing would be good if you can have a look at the developer documentation, if we still have some references to use JS Libs. I think. Yeah, there's always docs. Yeah, this this more cleanup that needs to be done here. So definitely looking for people to help with cleaning up some of the long tail of this. You know, I think I definitely definitely put a dent in the problem with pipeline groovy plugin yesterday but yeah there's still more left. Because if I remember correctly when I started to use some modern child scripting libraries in my plug ins. I found these that I should bundle them with JS Libs and there is a really a good water tutorial and I think we should remove these from our web page. So nobody will find them anymore. Yeah. Yeah, thank you. Thanks Willie. All right. Any other points on the, the deprecation of Jenkins of those outdated jump Jenkins JavaScript libraries. Thanks Basel. So next topic we had body. You want to take just a brief moment on the user feature flag status report. I don't think it's really necessary at this point and there was no status report at this point it just user feature flag. It's a pull request element just to provide the feature. So if it's not adopted there was no interest to have any report of this kind of thing again. Got it. Okay, thank you. All right, then last topic on the agenda was is the app bar ready for build actions only. Could you give us some some overview for those of us who may not know what that bar is like me, and, and let's talk for that. So maybe I can share my screen. You bet. Stop sharing. Okay. I think you see my browser now. Yes. Okay, good. Okay, I think what I want to show is that recently we, let's go to the minute this a little bit bigger. So I think Tim and young and proposed some kind of new scheme to, yeah, to have some new fuse that use the sidebar on the left here. So, the plugin manager now has separate sidebar with updates available plugins installed plugins and so on, and a lot of let's say managed Jenkins fuse are using this new scheme. This scheme is having a new sidebar and having an application bar where you have some buttons to, you know, to change the few or they look and look and feel. And I'm wondering if this concept should be used for build actions as well. So, let's have a look at this is one of my bills from, you know, from one of my plugins. And we have a lot of summaries here in this screen. And what I would like to know is if, if I am, for instance, going to the code coverage results. Typically you have a few which shows the code coverage results. And this is just an experiment. So it's not really ready. What I've a normal sorry, let's start from beginning. Normally if you click. Into the summary of a build, for instance, we are looking at the test results. Normally you have the same on the left, you have still the old application or the side panel is the same on the left. So I'm wondering if I should change that in the same way as we have done that on the plugin manager so when I click mutation coverage, I have a new side panel, which shows only the details of my few. So, and this is a question if we should go this way or not so I'm just experimented a little bit with it. Before that change I have a tabs here where you can see the overview you can have the line coverage and so on I'm using tabs to show different elements of my few. And now I'm wondering if I should rather use this sidebar to show these results for instance if I click here on fires. Then I have only the fires and I should click on overview I see only the overview and vote that's not really clear for me if I should go this way or not. And that is more a little bit of question for young and Tim, if we should use that in bills as well. And if we use that in bills I think we need some guidelines on how to use it for instance, should I have buttons there for the previous build and the next build. Yeah what else buttons should I have that are common to all plugins because when I use this concept in the code coverage plugin I should use it in the warnings plugin. You should use it in the test plugins or all plugins which show information should use the same way. And, you know, I'm not sure which way is the correct way. So the action buttons that you've listed there's primary control hello and secondary. Those are those buttons that perform some change on things. These. Yeah, okay. These are just some from the Hello World. I've just integrated but actually I would like, for instance, I'm here you normally see the code coverage of the whole project. And I would like to use a button to show the coverage of the changed files only. Okay, so you will click here. It's not read implemented but this is my idea to have a, for instance, a list box to a button and toggle button where you can select show only the coverage of the changed files or show the coverage of the whole project. Or another thing is when you, let's say, you can see here the line coverage. And maybe it's simpler if I have a toggle button where you can switch to the branch coverage or the mutation coverage or something like that so you don't have so many tabs. You just have one tap and you have some other element to select what you actually would like to see. So this is something I'm experimenting so it's, you know, it's not really finished so it's I thought it makes sense to discuss it before I'm start working on it. Otherwise. So, so for me, I've recently been using exactly these pages and have been very deeply happy with the data I get from them so I'm interested would then this would mean line coverage branch coverage and file coverage in one model would move to the or in one idea would move to the left and be along the sidebar and I would click through them to get to those so that, so that instead of a top level list of tabs, it would be immediately the coverage page with coverage data. Yeah, yeah that was the idea, especially now I've integrated for instance we have a code coverage from Chacoco. So this is line and branch coverage and I've also integrated mutation coverage using the same model now. And this is a concept I'm using in my warnings plug in as well I've had results for check style for find bugs for PMD, etc. It would be simpler if I have them in control in one side panel and show only the results I'm interested so when I'm looking at code coverage I want to see only code coverage and now warnings, and if I'm looking into my warnings plugin. I don't want to see the test results so maybe we can focus more on the details I'm interested for now when we are using the sidebar. Currently, you see the sidebar is very long. It's even longer when I let's say let's see if I have a project which is a little bit longer. So, when I'm opening now it's not longer I think my plugin is not loaded my final warnings plugin so typically the sidebar can get very long so you need even scrolling and you know this is something I would like to avoid. And it would help if I replace the sidebar with thumbs and this was a special sidebar for my plugins. So I'm not sure if that makes sense or not so. I need a little bit feedback for that. So maybe this is something we can, you know, have a look at the next session as well. I think we should let's bring it to the next session I think we could also benefit by by pointing young and Tim to the recording of this session, so that they could see the the concept that you were envisioning and your question so that they may be able to to prepare and have their thoughts gathered in ready for our next session. And one thing maybe that's interesting is what's also important for me which does not work currently, I would like to have the screen of 100% for my plug in. And currently if I set the size of my frame to 100%. It's an overlay with the bottom bar. So, I think it would be really helpful for plug ins if I can say, please let my few fill the whole few. And young, but not the bottom here so I'm not sure if this is an overlay, why this is not calculated correctly here. So these are, I think as a plug in outer I need some advice on how to do special things and we don't have these advices yet. So, maybe this is something we should work on. Currently the app bar and these changes all are only applied to the system settings part, which is, you know, for some people it's an important part for but not for me for me I'm interested in the build results, and we should spend some time on improving these results as well. I like that I think that's a great idea let's, let's plan it for a conversation for our next meeting. Thanks very much. Okay. Any other questions here. Okay, thanks. Thanks, any other topics that need to be discussed today. Alright, thanks everybody.