 Welcome. This is the Jenkins User Experience Special Interest Group. It's the 27th of March, 2024. Topics for today include LTS baseline selection, what's happened recently in UI improvements, including recently merged and in progress, any other items we need to add to the agenda. Then let's go through those. First topic is LTS baseline selection. So we're one week away from the LTS baseline being selected. As far as I can tell from the ratings, so looking at the Jenkins change logs, the ratings are generally positive on weekly releases. I've looked at each of the bug reports in the last five or six and found that they are five or six weekly releases and they are in general plug-in issues, not issues with Jenkins Core. So I think we're nice and stable, 2.451 if it needed to be chosen is a good choice. 2.452 is also possible. It will release next Tuesday. Any questions on upcoming baseline selection? Or maybe I should ask differently. Any major UI changes that any of you are aware of that are coming to Jenkins Core in the next weekly. Okay, great. So next, let's talk about what's happened recently in UI improvements. The Pipeline Graph View has had several recent releases, and in those recent releases, some nice capabilities like, for instance, a run details card is now available. It includes the upstream cause, and Tim Jacome reported in chat that as far as he can tell, all the known bugs with graph presentation or portions of graph are resolved. Parallel, this was one of those handling skip stages in parallel branches. Tim Brown's addition of the tree scanner. So the Pipeline Graph View is looking especially good as far as I can tell. Thanks very, very much to Tim for the work on the console view, or Stuart Rowe, Tim Brown, and Tim Jacome. Any questions or comments there on Pipeline Graph View? Okay, then on Jenkins Core, I hadn't extracted any specific topics. Are there any UI improvements that you'd like to highlight that you've seen in recent Jenkins releases? Okay, then let's take on the next topic. In progress, Pipeline Graph View is we've got a proposal in to add a change details card like here with the changes, and that changes detail. It's currently being prototyped. You can see that the pull request is in draft mode open three days ago, but I look at that and it looks promising. It's similar to what we see for the changes that are presented from the more typical job page. Then on Jenkins Core, Daniel, Daniel has proposed moving the people view from core to a plugin. Would you like to give us an overview, Daniel, of the situation there with the people view? There's a really old Jenkins issue that I linked in my PR comment where people complain about the existence of the people view and that due to data protection laws makes it impossible for them to use Jenkins, since people need their needs overall permission to use it at all, but that also grants permission to access the list of all people known to Jenkins that got a recent ping and an old pull request from 2014 was resurrected by this one which doesn't actually do what the old title said, separate permission for people view. Previously in 2014, there was feedback for the old pull request that it would be better off in a plugin. So I thought I would look into that to see feasibility and it seemed pretty straightforward. The idea here is that unlike the vast majority of feature extractions from core, but like the CC tray XML plugin that I linked in my comment, this would not come with a plugin split because there are no plugins with a single exception that use this API in Jenkins core. So doing it that way would not break a significant number of plugins while allowing administrators who do not want to have this feature to just not install the plugin. That's the way I did it for CC tray XML and this is the way I'm proposing it here. The plugin at this point is essentially just the code from core restructured a bit to make it work, but feature-wise it is identical and the change in core replaces the existing URLs if people access them directly with a placeholder page that tells them to install the people view plugin if they want to have the plugin, if they want to have the functionality there. So anyone who uses codemarks or uses the provided rest API will be able to, will be directed to the new plugin, but it will not be automatically installed an update. I think this is a pragmatic solution in this case given there are next to no consumers of it. I like that so all that we would then need to have Kevin Martins be sure he does is in the LTS change log and upgrade guide he puts a note people view has been removed intentionally. If you would like the functionality you need to install this plugin and if they don't detect through the UI clicks like you've described we hope they read the documentation great. Well the other way around if they don't read the docs which nobody does then they will see it on the UI. Okay you detected my bias right exactly right if they don't read the docs which they don't then we hope that the user experience will guide them oh you need the plugin great right and that also opens up the possibility since it's in a plugin and the plugin or the feature currently has besides being available to everyone with overall read and listing all of the users it also has the performance problem because what happens when you access the view is especially the top level view Jenkins will load all build records of all jobs to identify the SCM users because the people view is not the users view Jenkins kind of conflates who is a user in the security realm and who has committed to something at some point in time and so all build records are loaded which means you may wait minutes for these pages to finish rendering and it's even worse with the REST API basically you have no chance to use the API if you're behind the reverse boxy that sets a reasonable time out for an upstream response and so this being in a plugin I think we can provide a more basic feature that's not quite equivalent but that allows administrators to look into what user records Jenkins has locally just for admins and other plugins can fill the gap here if there are specific information needs here it doesn't have to be the specific people you plug in after all excellent and so your analysis that had found these two outdated plugins so last release over over almost 10 years ago last release nine years ago of one and the other that Gavin Mogan has said hey he's no longer maintaining a conservative failed experiment right that's great right okay super and either of those if someone wanted to bring them back all they do is declare a dependency on this new plugin right that's that's really all they have to do is if they want to bring it forward they declare a dependency on the plugin and release a new version or potentially yes the GraphQL server is a bit weird there it just appears in a list of classes I don't know what's going on there I think it's because it is intended to be a GraphQL representation of the object graph or something like that right so I don't know exactly what's involved there it might be as simple as just deleting a class from the list and you're done I'm not I don't even remember whether it was in production code the other with Jabber server depending on what the exact use case is I mentioned that it takes forever to build this list of users there is a solid chance that this is not actually the kind of information the maintainers wanted to look for but this is what they had found so it might actually be more correct to use a different API like user all or something along those lines to get just the users with records and Jenkins without loading all of the builds but yeah so your your suggestion should definitely work alternatively look for a different approach to to accomplish the same goal right so this feels to me like it's a good candidate to merge for this 2.452 so that we get it in before the LTS what's your sense of the relative risk of it given your investigation do does that seem sensible to you or am I being too aggressive we've had two approvals it's it's met all the all the requirements for usual yeah I don't particularly see a blocker here I did the usage and plugin search I identified one other use at cloud base but I believe the latest state is that that would be deleted anyway so should be safe enough and I mean until the LTS line is out it's another six weeks so that should be safe enough so at the minimum I think you can start the countdown and then we can check whether there are whether we can identify any additional users great all right so I'm gonna I'm actually going to live in person in front of everybody start the countdown see we've got a correct label no we don't have a label attached and this is an RFE do you think should I call it a I don't feel like calling it a bug RFE potentially major depending on how you see the breakage yes a good question all right so yeah I'm I'm gonna go with RFE are you okay with that or would you prefer do you have a do you have a strong preference one way or the other call it call it RFE labeled removed labeled you are you removed right very good and you are okay good all right excellent and now we start the clock thank you Daniel anything else on removing the people view hey then let's go on to the next topic which was removing the side panel widget and this one Daniel I think is more conversation there's not a I've not seen a pull request but rather a question you raised in Gitter Chat and with seven of us here today I think it's a good place for at least a conversation do you want to begin the discussion there sure so I'm currently working on some stuff that integrates with github actions and so what stood out to me there was that I have no clue what the available resources are they just exist or you know they are delayed and in comparison it struck me as weird that Jenkins tells everyone exactly how many agents are connected because realistically low privileged users shouldn't really need to care they care whether their builds can start or not and if there are 50 agents connected that are all sitting idle but their own pipeline says there is no agent with the label whatever then that information was at best misleading so I started questioning the value of telling non-admin users how many nodes are connected that seems like superfluous information for anyone who's not an administrator or at least has agent-related permissions and so why don't we stop using that that seems like it would open up the UI in some views a bit make them less busy get rid of questionable Ajax if you look at how these widgets are implemented we basically replace a part of the HTML if I remember correctly that makes keyboard navigation awkward and it all seems to be for very minor like like very little benefit if at all like you see what's running but you could just as easily see what's running in an appropriate view so that's what I wanted to start the discussion on removing the executor widget at least I'm sure about the QWidget that seems more useful because if you have access in most instances if you have access to a job you have some interest in or involvement with it so but the executors widget seems completely unnecessary and so when you say remove it so I'm an admin and I like the executor widget because I use it to look at how things are going but an admin would they still see it or will I need to go somewhere else as an admin to see executor status could go either way in one of the responses I got in Gator I was pointed to the prototype that Jan did a while ago in which there is no widget by default but like a button on the side panel that opens a pop-up not unlike our security warnings just off to the side and I guess this is where the executors would show up that seems like kind of a compromise it's there if you want to look at it but it's not shown by default so that might also work out but yeah just just the thought I had I have not done development for this so far just wanted to kind of get some some feedback whether this would be worth pursuing okay so we've got Uli and Vadak here and Antoine all who are interacting with Jenkins comments Uli I see that you have unmuted yeah I think these widgets should be moved but all widgets should be moved somewhere else so I think Jenkins still has a problem that we have the sidebar which is some kind of navigation and this sidebar also contains some widgets which makes not much sense for me I think we should clean that up to have a sidebar which or a menu bar or a navigation bar and then we should have a page where all these widgets can be placed and if someone wants to place all these widgets on one view then it's fine for me but I think it would clean up the UI if we remove these widgets to some separate place so this is still a little bit strange for me that we have the sidebar with so many links and if there are more plugins then you get more links and I'm not sure if it's possible to add additional widgets I don't know so I think it would be helpful if we have a place where we can put these widgets so for instance when I'm looking at the dashboard view plugin this is a plugin where you create the page on your own or the view on your own so you select the elements you would like to see and these are the elements you see so if I want to see the queue then I add the build queue for instance but I think it's better to let the users decide which widgets are shown and if possible it would be very helpful for all other pages if these widgets do not show up on the left in the side panel so it's a little bit a problem of the space as well so we have yeah actually just a menu and normally when you see modern web applications the sidebar collapses to some small thing on the right if you're on a smartphone and yeah we can't do that with a widget so it would make sense to split navigation from content it would be one thing for the future so I think what you're saying is you you see a day in the future at long after this this idea but that would you take this even further I think is what you've just described it's not that this idea has to encapsulate all the things you were saying but rather that there is a way that this could go even further now Daniel you had said you reviewed Yann's prototype is is what Uli's describing aligned with what Yann's prototype was doing? What was the question? So you had looked at Yann's prototype in the context of having no widget by default and Uli was saying hey we long term would like to have the sidebar gone completely the widget's gone from the sidebar completely the side panel completely and only have it be navigation is that aligned with Yann's prototype I don't remember how Yann's prototype did navigation. There was there's just like a very narrow line on the far left side of the screen that had a few buttons you could click that I think also was some sort of navigation yes thank you Kevin so link is in chat oh okay open it great so let me so it was not part of the regular UI but was quite separate from it ah okay right so here we see thanks that that's this is the easiest way to so here it's it's not even expand and contract no hamburger menu it's just navigate well um if you uh make the window smaller it actually gracefully scales down or entirely it moves to the bottom I think okay so so when I'm at phone scales it really has moved itself out of the way nice and the one that looks like a pie I think represents the controllers yeah the the executor's widget uh oops when you said built in oh oh right so this is problem well okay you said pie I'm not sure I picked the right one did I pick the right one yeah yeah that was it if you look at the yeah so obviously this page doesn't exist yet but it has a pop-up when you when you hover over it that I think back one um navigation item where the build queue was this one and I think this is the thing where we should go we should have a page where we have these widgets and this is the running builds widget and it does not need to be present on every page if I want to see the builds I navigate to this page right so yeah that would be the future and not the near term but in the long term right what's also interesting about this is um while it superficially looks like the executor's widget the focus is on the running builds like if you go to the oh right right here you mean this one right so if nothing's running then nothing would be shown right now in Jenkins if you look at some Jenkins instances like I think the Apache projects they have these super special agents with 20 executors so you have this giant widget and you need to scroll down to see everything and everything's just idle while in this case it just shows you the builds right that would be kind of between having it hidden and uh retaining what we currently have to just change the focus from uh it is on the executors and what they're doing if anything uh to what are the builds that are currently running and just mentioned the the nodes the builds are running on um as just additional metadata there so yeah I think those are two there were a bunch of options here uh and I just wanted to kick off the the discussion on the on the topic thank you any comments from others insights or things you'd like to share so for me it seems like the were there things in the chat Daniel that you'd like to highlight in addition to what you've already mentioned anything others any other items I don't think so no okay great so the prototype um prototype idea seems to support that and what you're proposing feels like a a good first step towards it and well I mean I propose the removal right so so the admins would need to have something where they see the status of things right so whether we need different prototypes to look into make it pluggable think about you know what are the various use cases especially the ones out of the box uh or um that we consider best practices there um yeah I'm I'm I'm not sure what the solution should be uh but I am fairly confident that it should be different from what we have now right I like that that's I think that's a great way of saying it so so what we have right now is not this and but getting rid of somehow moving the executors widget out of the the non-privileged users experience makes sense I think your your observation about github actions not showing resources is a sensible thing anything else on the topic in regards to what uli said um I just wanted to um remind us that the builds history widget is also a widget so unless you see like the various list of views as being without a widget without widgets in the future and having a very different navigation from what job views currently have well we need to think about what to do with the build history widgets of individual jobs right if you select master here uh in the list then and on the left you will have the build history right and this is expand and contract right it works similar to the other widgets right and you click trend and you get a page that looks looks a lot like a half baked separate view for the build history so perhaps we could take all of the information shown in the side panel and kind of move it here right and just have a separate page for the build history make it a prominent project action so it shows up in the middle of the main job view would also in the status page right that would also be uh like like similar to the stage view right this is also a built history of sorts if you will um so there are a few options there but it's not as easy as saying well the side panel is weird and the the widget is unused anyway let's rip it all out because the build history I think is far more important to to let's let's say non-admin users right yeah I certainly depend vitally on the build history this widget and I navigate it all the time right good thank you this widget should be placed on the main screen here so it makes no sense that it is on the side panel it should be here where the stage view is over the test results are the user should decide which of these widgets show up in this screen so yeah so so your concept is this build history widget would drag towards the center of the screen right it would it would appear and then I choose which things I actually want to see yes exactly and the best idea it would be if we on this page all elements which are show which show up here are a draggable and should could be configured by the user which of these they want to see it does not make sense to say hey here we have everything but some people just want to see the test results some want to see the stage view and and and this should be user configurable right but this is uh yeah the major major effort and a and a major a major effort to retain compatibility while making such a change yeah absolutely anything else on this particular topic not for me okay thank you we had one more open one that I had noted uh Jan Farcik had started a poll request on linting that I think is still not settled there are others that this one is just ongoing discussion right I think is what's happening there are there others that we should discuss here as a group others about the linting or about any any user experience topic yes I have one that I did not write on the agenda okay I recently upgraded the data tables plug in which is now a new version it's 2.6 and this new version has some new yeah effects some new user interface elements and it looks a little bit different than before so I'm not sure if it's interesting for others maybe I can show a screenshot a screenshot not I'll share my screen yeah let's let's do that at least let's have you show it I'm gonna stop sharing go ahead please yeah so so are you seeing now my coverage yeah okay we see the coverage report so what I'm talking about is this whole table where my mouse is now hovering and this widget is provided by the data tables uh yeah JavaScript framework and they release the new version which has some new features so for instance I can add new buttons into the view so here I have a button where I can show the coverage of only the changed files so when I click this button yeah there are no changed files but normally you would see only the files that have been changed so you have additional UI elements you can add to this view the user interface slightly changed so before we have this striped model where we have white and black white and black and now it's yeah some highlighting on the current line where you are you see when you're hovering over the topics you see where how you yeah want to sort so this is new in the view and yeah you can have tooltips for all the elements which are here these elements are from yeah the work from Jan so this is the same a framework tippy in the background oh good so no yahoo UI yes yeah so you can basically the sorting can be done on an additional attribute for instance so when I'm clicking here you what you're here seeing is a widget but you can give a sorting uh property where you can say okay the widget contains a number and the number yeah is using sorting so this is kind of simple um what is also new in the in this tables is that it automatically remembers the last settings so if I switch to 24 elements and when I'm reloading the page uh then it's still there and I don't have to do anything it's all in the framework or all provided by the framework and it works now because prototype jas is removed so now it serializes to jason and everything works out of the box and this table also has uh the capabilities to uh sorry to show more columns if you make the screen wider so now you see a lot of more columns and if you switch smaller then it automatically renders the number of it uses space that is available and yeah I think this is a widget which basically I'm just um have a wrapper so the the main work is in javascript so it would be really helpful if we can use such elements more in Jenkins without reinventing the wheel and just say okay this is a good component a lot of projects use them and they work out of the box maybe another example what I'm using sorry I'm using it also for the tables view where you can have some you can open a role a details part of so you can see here okay where is a code application and here you see the code application so this is something you don't need to invent on your own it's already provided by this library so a few other plugins are already using it but yeah most plugins that are using it are mine plugins so I want to make a little bit an advertisement to please use this view it's much simpler to use than the standard html tables or the big table from Jenkins thank you so this looks like a candidate for some work that we brought into the git plugin as a draft poll as a poll request from google summer of code a year or two ago that you haven't merged and released yet where it presents maintenance results in a tabular form with more and less information so thank you for highlighting it uli any questions from others to direct it towards uli all right thank you uli any other topics we need to discuss today okay thanks very much session will is what recording will be available in 24 to 48 hours thanks for joining