 I'm recording now. So hello everybody today we have March the 16th and we have our user experience group meeting and Yeah, on the agenda. I have actually only three points. So First thing is the weekly status the three three nine I don't know if someone can say something about it. Can you say about it something Tim? It's the weekly so because I am not involved Nothing too exciting. Okay, then I would like to skip this point and then we have only two remaining things actually Only one thing is the UI improvements from Jan and Tim if you have something to share and If there is still time Sorry, if there is still time, I think I can share some details about the Refactorings I'm making with a student of mine in the code coverage plugin Okay, then, yeah, let's start with the UI improvements, right? Jan, would you like to share your screen? sure Take everyone can see my screen Yes Yeah, and what's what's recently happened? So right now we've got three merge requests up and one for the buttons Which is a little work in progress one for the updated breadcrumbs and then one more for the Icons and So the breadcrumbs PR should be merged soon. Now. I'll just update the kind of A drop-down links that we have across Jenkins and Then hopefully the icons should be Relatively soon for the next week or two That's that's pretty much a bit on the PR right now is the model inside Ishting an issue that Daniel was asking about or I've not seen if he's responded I think I'll just have to see how it works with plugins. I've not personally checked plugins for it. So I'll have to Have to see if that's a bit dodgy or anything I would have thought I would have noticed if it was dodgy But you know it used to be in the Jane a plugin, but I removed it recently. Well, here's Daniel Yeah, maybe it makes sense to document this behavior somewhere in our developer We we spoke your name when you came Yeah, I wanted to get that documented on the Jenkins dev docs And then also add it to the UI samples and plug-in Which I'll all get done. Hopefully soon Yeah, it's the only reason I hadn't clicked merge yet I am as they're talking about the breadcrumbs one Daniel On whether we want to hold off any time or just Yeah, and we'll in the background do some documentation and have a look at those plugins Because of modeling inside copy and paste or yeah, okay Yeah, I think it's in a whole bunch of random plugins I think generally copied and pasted all over the place, but I haven't seen anything that looks weird. I mean This seems to be just one part of a larger It seems we're fairly light on documentation a kind of situation and Something else that I thought about is it probably makes sense for us to think about Sort of the the API or contract for plugins like for example CSS classes, perhaps we could introduce a naming convention there That indicates whether something is internally used only or Intended to be used in plugins. So it's really obvious for someone who knows a very straightforward rule to tell well, this should not be used in plugins and it's kind of akin to using restricted API in Java Something along those lines now. Maybe maybe this already exists and I'm just unaware it does I don't know when there's two underscores or an exclamation point or something in the CSS class But perhaps something like that is is also what we what we could do there I just fear that we introduce a bunch of changes here And plugin maintainers for one thing they do not know what they need to fix in their plugin What version of Jenkins Introduce the change like for example, I mentioned something, you know in which version of Jenkins did we add an icon that you want to use Well, you need to look at the git history for that And then they might end up Copy and pasting a bunch of stuff where we say well This was kind of internal use and now your plugins screwed in the next release because we are changing Changing it again to make it cleaner in core So a few for me related Topics here. So I'm looking forward to having that documentation. I don't I don't think it's an immediate prerequisite, but Perhaps for the nearer term future Yeah, um for the CSS one, um, I've been trying to prefix kind of global kind of styles with just the Jenkins kind of word um And then for kind of internal classes just prefixing of like app or something just so Plug-in developers don't use it as it might change um might not be the best prefix, but kind of That's what I've been doing at the moment It's probably just worth writing that down on jingles.io a little bit I don't really know how you go and how you document CSS classes when they're available so much unless you have a whole public api documentation Yeah, that's the CSS I simply um, yeah, I need to hold onto documentation Just perhaps do not care too much about that We have seen a lot of copy paste of code that should not be copy pasted in the past that are private to Jenkins core But people are still copy pasting that for for their own plugin When we are correcting a vulnerability in core that plugin is still using the forked version that is not corrected with the vulnerability So for CSS, it's even easier for them to copy the stuff So I will propose you that if you want to have something reusable Create a jelly component Otherwise do not expect people to not use your stuff. They will do it at some point. So It's not your fault Right, but if if a CSS class is core internal, whatever We can tell the plugin maintainer. Well, maybe this wasn't the best idea you've ever had look at what this says, right? It's right there Sure, it will not prohibit it Um, but at least we give people who want to do it Uh, the right way a chance to get it right On the opposite direction there. Is there any CSS class from core that we expect plugin to use? modeling inside What do you mean with expecting so there are a lot of classes that I would like to use in my plugins for instance a table visualization I simply would like to have my tables implement a check its table I hope in that case you have a component no No, it's just a table that has the CSS class big table pain. Oh, yeah Sortable and a few others at least it used to be until fairly recently Um modeling inside if you want the drop down next to a link to a build or whatever or the classes to put there um, and there's just ton of that and Some plugins do their manual task implementations where it can be just Debated whether that's a good thing or not probably not because there's uh the task tag um, but there are several What is just is part of the definition. I think with the widgets in the site panel you also need to Assume that you're in a table environment and need to add Need to start a row or something. So there are quite a few of those Yeah, good example. Thank you Um, I've got a couple of kind of things to to demo Today if that's all right Should we look at the symbols just briefly and see what people are thinking? Um, did you want to open the PR correctly? Yeah, sure Um I found something that you can do now if you go to um pause you can just put your name at the end So if you go to the URL bar and just do slash and then just put your name there Very nice So I've got the uh PR Um, what was your update? I updated the change a lot this morning because it's not doesn't just I think originally it was just about the side panel But as soon as you touch the side panel you touch all over the place So I just changed it to update icons. I'm not sure if we want to be a bit more descriptive, but um Previously said side panel, which is touching a lot more Um, I think so at least you at least done a whole bunch of feedback recently Which I think has been mostly addressed if you want to go down um Yep I'm not sure if there's anything else that we want to do in this PR If anyone else is planning to test I've quite a bit of a go around it last night, um And expect like experimented with the gray color. I'm not sure if it's just too light or not Because it looks really good on dark theme on regular theme. It looks okay But I see it's it's more for me. It looks more weird when it's mixed in amongst other icons Um, which is something that we can improve as we go but Yeah, I'm sure what do other people think if I people tried this looked at it recently So so it's no longer blue or what do you mean? Uh, it is black in the side column and it's blue if it's inside of a link Which we've tried to avoid Um, the context mean you're still blue and that would be fixed in a follow-up um But no in general they're um black or like a gray on dark theme. I think Uh, so that's like that's an example if you go to yarn if you go yarn goes to the top you'll see what they look like It's not a full black. It's like three three three. I think Yeah, I think uh on the side panel side, it looks okay with the black what Didn't look so good. I think was the summary punk cellis which are rendered in the middle This was a little bit too black for my opinion, but yeah This is something which is quite different for people some like it some like it not so Maybe I can change it via a theme I think part of that is just about it fitting in with it. There's not very many of them fitting in it looks quite different And and the font awesome ones are quite a lot lighter. I'm not sure if that's Something set by you if that's just a font awesome icon to lighter. Um, I'm like yeah Yeah, I mean if we all agreed that we want to have these monochrome icons Everywhere then the exact shade of gray doesn't really matter. We can iterate on that It's just if the if the feedback ends up being Well, it was more colorful and nicer before than we're kind of you know stuck with it And and can't go back and otherwise, uh, you know the exact shade of gray We will iterate forever Yeah, it's fine. I think it's good just to hear that it was more just about the summary panel rather than the side panel Which I didn't pick out from the before um But yeah, I guess so we've got four approvals Um, three of them from people testing it recently So I'm not sure if is it anyone else that plans to look at it and provide any feedback or whether we should look at Shipping this um during this weekly I mean, um, I would like to take another look at this one I mean, I've I've now approved the other poll request with the drop downs So we can definitely include that didn't go out yesterday, right? That was Okay, so so we can definitely have that in the next weekly Um, and then the question is whether this needs to be in the same weekly um Could could go either way. So I would like to take another look at this one or sure. Yeah, we can wait for that I think there's probably quite a lot of stuff that's related to this that will come out once this is there. So um improvements and iterations Um, this will be a base on quite a lot of other stuff Cool. I guess that was all I had on that one. Yarn, if you wanted to show your demos Oh, um, but just to reiterate that what Tim said, there will be like a million Kind of poor of us after this just to just iterate and Change the odd icon here and there and and fix things because no doubt there'll be Kind of issues somewhere, but they'll get better. Yeah I've got a decent sized PR to the credentials plugin to Utilize it there because that was one of the main ones that looked quite out of place Um, I've also been working on a branch just to add the custom symbols. So Kind of plug-in developers can add their own Um, so it should fit in a lot better at that point. Um, but I'll open that up for discussion once this one's kind of margin Um, so a couple of things, um, I've been working on that kind of since the last Meeting, um Putting a bit of work on the UI samples library Um, it's still it looks like a mess just because the custom icons aren't being loaded on this branch Um, but it's got a bit more content now That's a bit more categorized. So trying to keep things kind of Really simple Kind of addressing it towards a first time kind of plug-in developer Um, so kind of for calling things like just checkboxes rather than the Jenkins name for that because Jenkins has some kind of odd choices for component names, but trying to keep it kind of straightforward Um, this is like the the buttons page Um, so ideally it shows you different types of buttons you can use Um, and I also show you eventually the code to actually use these buttons on your plug-in Um So I've got a page for comments as well. Um, I assume we if you just go right to button. I assume we don't still use a hidden flash SWF or whatever Says something like I'm sure I was I'm sure I mentioned flash on that page somewhere Yeah positioning a hidden flash movie. I'm sure we don't do that anymore Oh One questions one question to these widgets are these useful in every context of change are only in the configuration page Because I'm using for instance a lot of widgets in my static analysis plugins and in the configuration of trend charts For instance So I'm not sure if I can use these things as well or if these are just bound to the configuration section Of a freestyle. No, these are beautiful anywhere. Oh, okay. Yeah, so you have to be free to use them anyway really um Yeah, I mean this this ui samples package is still very much a work in progress. There's still a ton to add And code samples and stuff like that So if we click the colors Um, we'll show you all the colors that jinkins currently supports so you can use them in your say charts for example or whatever else This branch is missing quite a few colors. So it's it's a bit broken, but That's what it looks like right now. Um If you hit say text box, you'll get different text boxes. Um, you'll have different scenarios. So This one supports autocomplete So if we start typing a state You'll you'll get examples Um, we've got the code for this other right now. It's Just broken. Um We've still got the the code mirror text box. So you've got the syntax highlighting and stuff like that Got a page for tooltips. So When the tooltips branches is updated, you'll be able to use this for your plugins and stuff Just again things are quite broken just due to the branch of jinkins. I'm running. Um But yeah, um, so that's the UI samples. It's just going to be a kind of hopefully better organized version of the the one we had before Any questions or ideas or anything Do you need help with that? Yeah, I'm I'm open to anything really I think this is really helpful because typically I want to know how to how can I do something and I look into other plugins And the other plugin makes it wrong and here I can look how to make it right. This is a really good idea Um, one thing I'm struggling with right now actually is is how do we Kind of print that the jelly kind of Code on the page without jelly actually like rendering it Is it like a tag to Sure, there's a raw tag or something right where it might know With the g uh g colon row out directly that should be able to display directly the thing you want Now if you are finding a way to automatically display that instead of having to code it yourself that could be even better I'm thinking especially about some of the popular framework where you have all the things in the code directly Perhaps it's not the level of detail we want to have for jinkins especially for that small plugin in your sense, but That could be good, but normally gout should be the The good thing if you want to include anything inside just be careful to not include xss That would be nice But yeah Try that after this, um Yeah, that's the uh ui samples I'm hoping this will look a bit sharper Um So I'll say we've talked about this before I think so this is probably more important than documenting stuff online jinkins.io Is improving this but how like raising the I guess it's kind of pretty more important to focus on improving it right now But raising the awareness of it something like Should this be automatically installed? In jinkins core should this be moved back? It wasn't jinkins core originally. I think should it be moved back to jinkins core and an extension point added um So that plugins can contribute to it because no one's going to update it If it's if they're not forced to as part of their change if they add a new component Are they going to add a demo to it if it's in a separate repo? Um, are they going to maintain the docs if it's separated like does this belong as a separate repo? Shouldn't it be a demonstration of how to build? Like we can hide this from users unless they're running a development roads or with a flag or whatever that sort of thing's quite easy um I don't know if anyone's got any thoughts on that What could be the advantage of having that in core directly? So that when someone makes a change to that component is They document they make the documentation change with their feature change They introduce a new component They document the component as part of their change and they can and they can demonstrate their change there Even if it's something that's for another plugin they can show in the UI samples that this is how it would be used and this is how it's worked This is how it works Yeah, also easy auto do and your pull request preview and this kind of thing. Yeah It was just a bit concerned with the core size because we have a lot of things inside call that are Related but not directly related to the code that make the full project a bit slow to compile these kind of things Do you think about a module? Or what in particular? Yeah, could be a module for it Um, I'm not I think it's more important to improve it. So if we get it improved and we see what it looks like and then um Say early wants to have his plug-in data. I mean he could I guess he could add dependency to UI samples um API or something um, but it would be easier if it was in core um And I feel I feel like I mean obviously this has drifted a lot of things like um flash Was not updated when whoever moved removed the flash dependency didn't update UI samples um, but they're probably more likely to find it or If it was more used As I commit from UI samples plug-in. I think it was split from core originally Yeah, it was part of core in until 1535 or so Yeah So, I mean we can go back but perhaps it might be useful to understand the motivation uh Seven years ago Nice commit me such a jc Oh reference Yeah, um, but there's something as a consequence to that as you can say It's had very little maintenance since it was split from core So there's been Base it's been basically no change since it got split out of core. It wasn't maintained um I mean we as core maintainers can say You've added a new Atch attribute you need to go update this but um Then you've got to manage Hopes with core versions and update the core version over there and Um lining up the prs and then get someone to merge and release it um We're like tying your documentation to your code is more likely to get you a better result So perhaps a bit naive thoughts just thinking slowly what about Instead of moving that inside core moving the thing from core outside The ui library that are used in core with strong binding with core for sure But I think it's mainly that part of the code that should be close to that one Not really the full core So just thinking loudly. What do you think about moving out the library for the jelly component? I think it can get harder to update um People least likely to updates um Then they're less likely to create a component um I think it's an interesting idea And what happens when it fails to integrate someone does this change someone merges it and Then it doesn't get merged in um Changes like someone can't roll out a change to the ui samples. I've I've worked with common lib sort of things before um And it's Makes things more aligned, but it makes the changes more difficult and longer Like I don't think that's something we need And I would bet that your common lib has not that strong binding with the rest of the code Uh, well, it was a lot of ui stuff and then Yeah, but then get some data one place and not the other place Yeah, not a lot of fun Um, I think the focus should for now should just be on improving this. Let's make it nice make an exemplar and then We can see um Even if we don't move into core, we could possibly find a way to automatically install it through plug-and-pom something or or through test harness In some way that could be very nice to have that for the development or tooling engineer So I think a lot of people aren't aware it exists Okay, we've got anything else jan Yeah, um So I've been playing with as a kind of redesigned the new project screen um Oh, nice Just because it was it was quite old before um So idea behind this one is Maybe I was I was being done, but never I first started using Jenkins. I'd often get confused Between the hands the ordering of of things. Um, it wasn't particularly clear. You had to click a project type They didn't look particularly clickable Um, if you wanted to copy an existing project type, you'd have to scroll all the way to the bottom It wasn't kind of immediately obvious that You could do that um, so I've tried to address that with Move this kind of redesign um And also add a new kind of drop-down component Which is a bit more Visible. Um, so I'll just give a demo really. Um Just have a wild Um, so you hit the the new kind of drop down And it shows you this kind of Pop-up list. Um, so the categories are kind of That the project types are categorized um as before Um, the default Jenkins one has a new icon to fit Um And it kind of looks just like that really. Um, you select one. It's just a freestyle and it pops up um So it's immediately obvious that you've Selected a project you entered a name You can now hit create. So Things are simpler really. Um If you want to copy an existing project type You've got this toggle here to click that and it'll pop open the Copy screen really. Um, so you hit this And now you're getting kind of more visual view of your kind of current project Um, so I'll now tell you the type which I thought was handy Um, I also have a little icon saying if it's Past or failed or whatever Um, I'm not terribly sure if that's helpful But it's just to make make it more obvious as to what you're actually picking essentially um So if we can hit freestyle project and that'll just pop in like that Um That's it really. Um, I think right now it's a little bit broken. So click and create probably won't work but Yeah, that that's that's the idea really um Any Comments or feedback or anything? or So one thing is you copy an existing project Not a type right? Okay. So this is a bit of a label issue, right? Um, then this needs to scale to at least a thousand projects So right now it's a text box where you enter a project name That you can probably copy and paste from a different tab or something Um As shown This does not seem particularly scalable Um as a comment for the other viewers if you go back to the project type Um, this grouping existed before so if you open it Um the standalone projects and the nested projects this existed We just disabled it in Jenkins 2o and completely forgot to enable it again So this has existed for five for six years now. Um, so it's great to see this Actually make its debut. Um, so this looks actually fairly reasonable um I wonder How this scales now this doesn't have the same kind of scaling issue, but we should Support at least I think 1015 project types is probably reasonable um, I know that cloud piece products have a feature where you can add more project types fairly easily and so If this has kind of a hard cut off at 10 and afterwards it becomes unwieldy that would be a bit of a problem Both for obviously the clubby stuff. Um, as well as if you have a particularly Uh complex instance with a bunch of plugins installed Several of which contribute new project types But um design wise this looks reasonable. Um, how is the I see the freestyle project icon is uh in the new style And the others are probably just compatible with what already exists in the Uh plugins, right cool. Yeah Yeah I mean this looks good assuming the scaling, uh, can can is quite a problem So in term of ui, I will say it's very nice I will not say even reasonable, but very beautiful in terms of style Very accurate to consistent with the rest of the application that you are revamping You are improving the user experience in case of copy My concern is just For the regular usage like I want to create a freestyle job at the moment It's one click in your case. You have to open the select then you will see the proposal and then you have to click That's more about the ux at this point. You are slowing down the process for people who know What they want to do and this kind of thing For the beautifulness of the design is it really good? Not sure What you want to do with the the copy that you mentioned that it was not really a good experience because you were at the bottom With you moving that to the top It's a very good initiative that part. I will say 100 percent agree agree with It's more about the select that you have one click more than the rest of the iteration And potentially even more because if it's not displayed in your first page For example, if you look for something in the nested project, you will have to scroll Before it was already displayed in the page. Yes, you have to scroll but it was displayed It's more about that level. I will say that could be a bit Potentially annoying for some people I mean, it's consistent with the rest of all web applications that are dumped down So the same UI can be used for a phone as well as your 27 inch monitor Yeah, I'm wondering if there's a way that you can kind of handle both where you can have an expanded view in some way and It's nice simple clean view. It's kind of a lot of products. They say they have like wizards and even Even may recommend to your project type. So you instead of starting with this you put in your get repo at the start and then And you just like you start with your get repo and that's it Or even even starting with your scm type and then your get repo rather than just Jumping you in here and taking you through all these other forms But also how like power users who are creating a lot of pipelines it can be quick But for new users, it's really nice simple experience because I think this looks really nice And I don't know how often a lot of people create jobs I use multi branch pipelines for a long time. So for me, it's a very one-off thing And the other thing is on the copy even what you've got might be okay if you've got 10 jobs or 20 jobs to start with and then maybe changes to a more scalable component or There's gonna have to be some typing involved and even Yeah, so if you if you can select the 10 projects or whatever and then you type to filter it in some manner a bit like Plug-in manager available kind of like we're doing it there, right? You show the top hits And then you need to type to find something else That would be I think a viable approach there that would also mean it's Less easy to get it wrong because there's some weirdness if you start out inside of a folder And you provide a project name and the project exists on the top level and the project name exists in the same folder How do you reference which? and with a more complete With the suggestions you show that can probably be disambiguated because It might actually depend on where you currently are there's a What's it called? Inconsistency between various form elements that allow referencing projects So that's actually something where it would be valuable if that would be a reusable component Like you can say That we can plug into plugins like copy artifact you specify a project name there The the post build step that triggers another project Right, you want to specify something there and if that would be a reusable component We can just copy into these plugins that would be useful But this this does look promising Very awesome So I'll um, I'll write that down and try and kind of iterate one of this for next time um I'm trying to have something that's a little bit more scalable for Larger organizations Um That's basically everything I've got. Um, so Awesome. Cheers everyone Um, I'll stop sharing Okay. Thank you John. Yeah, um, let's see. I'll share again again so Yeah, basically We are finished with all parts of yarn So if you still have some minutes, I can show you what we are doing in the code coverage plugin It's more or less a little feature. We are new Extending so it's not so you I Yeah, it's not only you I so maybe I'm not sure if everything is interesting But I will show you and you can choose on your own So, um, let's see. I think I share the screen and I show you what we are doing here And I share my whole screen and here we have it So you should see now. Um I hope you see now my Jenkins instance in the background and I think I Introduced our ideas for the code coverage plugin in the last meeting. So what we are Adding now in the code coverage plugin is the first thing is a new Coverage column which shows you all the code coverage. This is something I presented already in the last meeting So I'm still we did not finish the coloring thing. So this is still a work in progress But what we now introduce or changed we we started to Introduce the kind of change coverage Currently the code coverage plugin reports the total coverage of a plug-in or a project That means you see how is your line or branch coverage in your whole project What is for me? It's more interesting if I am on a pull request. I want to see how good the pull request is so what we are actually Computing now is Not only the project coverage, which is here where you see how it's your project project standing We are also computing the coverage of a pull request That means you we are selecting only those files and Only those lines in those files that actually have been changed in a pull request That means here for instance, we have code coverage of 100 for the pull request And the remaining is yeah less than 100 percent. This is yeah I think something which a lot of development teams would like to see just to focus on the differences and not on the whole thing So this is now new in the visualization that you see these two changes And what we are currently trying to redesign is the user interface. This is still not finished It's just the work in progress now. So we have The overview which is the project overview. What we would like to add is a similar Overview for the change coverage. That means you see only the delta of the coverage And what we also would like to show is We have this kind of a tree map where you see your Your code coverage of the whole project But I think what's more important is to have only the code coverage of the changes So you see these are the two classes I changed and the code coverage is good or is not so good So this is one thing we are currently changing And what we are also changing is Yeah, this is still not finished. So we are also having a second view where we see the individual Files of your project and you see the source code now in a side-by-side manner. That means maybe let's see here Um, that means if these are my classes that have a code coverage And now we have a selection here and you see on the right side We have a let's say a master detail view Where you select the source code you would like to see and on the right side you see the code coverage of this source code This is currently your work in progress has already mentioned. So it's not yet finished But I think the student is making a really good progress and it's here A feature which I'm really looking forward to having it in the mainstream I think it will take a couple of weeks until it is finished Um, so yeah, I just want to say yeah Have a look at it and the pull request and if you have any comments feel free to comment Are there any questions here for this part? Okay Okay Thank you Then yeah, I think I have no other items on the agenda Is something else someone would like to add today? Okay, then I think we are finished with the meeting today. Thank you everybody And let's see us on the next four weeks. Okay Bye. Bye