 Cool. Okay. So welcome to the Jenkins UX SIG meeting for August 17th here. I'll just clean this up a little bit. I'll just put the link into the chat case anyone doesn't have it. So you feel free to add any topics that you want to go through to the chat. We'll start with the first topic on here, security reviews for UX, pull requests, WEDIC. Yep. So the current status is pretty simple. I think we have three open pull requests at the moment or something like this. The other were reviewed before some bugs were found but nothing really related to security issue this time as far as I know. The two big ones are still waiting so for more final version of the pull request before the real security audit done there. So from my point of view at least it seems to be a pretty good. Okay. So especially, Tim, Daniel, if you have some insight forward about the process, if we don't have to say. Right. So, for example, in a fairly new PR around tool tips. Sorry, not tool tips. The annotations on links on the Manage Jenkins page. What are they called? Badges. Yeah, those badges. So as implemented, there would be an HTML injection vulnerability. If implementers are unaware of that. So, but they're still ongoing discussion whether this should be string valued at all or whether we should only allow numbers. And if it's string valued, it can escape the value right there in current say it's plain text valued. So either way works but yeah this is something that I brought up in review here. As far as I'm concerned this pull request isn't far enough along to make a final determination. But this is one where reviewing it with an eye towards potential security issues wasn't a bad idea. I haven't been put in a security review things on the really trivial ones which I'm assuming is okay with things like removing a line of CSS removing some links. Just to skip some of that as an example is. It's usually not a label. Yes. Yeah, I remove the uplink haven't bothered. I'm just going to go through a couple of similar ones where people just done minus CSS tweaks. In terms of UX improvements, Jan, you've just joined welcome. Did you want to take over for that we could go through any of the open pull requests or anything new that you've got. Yeah, I'm not anything major to show. At least running locally but we're good to for the active PRs. I might have a quick prototype to demonstrate later I just need to see kind of what state it's in right now. I'll just do that in the background. So, of the open PRs we've got what would you want to go through. So there's the up or first was the up pages to quite trivial one. Sure. So, yeah, it's very minor. Well, it's about replacing the up arrow on the people page on the user configuration page here. So replacing the up arrow with the people icon. This one seems quite odd in general because I feel like in general there's not really an it's not really descended from the people page. For most people accessing out. I don't know whether that I don't think people would actually we generally don't often don't want people accessing that page. Because it loads all the users. And there's not really any need for general users to actually view that page ever I would say. I'm not sure if you've got any thoughts on that or whether you just want to change the icon to be the people icon. I'm going to be ready. I hope the top of my head, probably just replacing the icon makes makes the most sense. Just comments at the bottom. That seems, seems sensible to me. Okay. breadcrumb. Oops. I think there's some. So just for context. What are we currently doing. We're kind of just just having a look through just see if we can unblock or move along some of the open pull requests, unless anyone's got any other. Well, so I guess that's more this topic down here stole UX pull requests if we can just review some of those quickly. And then I mean, there are certainly still pull requests but I'm not sure how much sense it makes to look at once that got updated 18 minutes ago. Sure. Yo, I had, I mean, I hadn't seen that one till then. I think this one we had quite a lot of discussion on the last time but yarn wasn't here. There's been a bit of chat in getter but be good if we can find a way forward on this one. So this is the one about moving the icons to the sidebar and the search bar to the top and center with the title in the sidebar. The last context and getter was about judging success for an experiment. And then young editor reply here about that. I'm not sure how. I mean, done responded but I'm not sure whether it's an answer. Because if we're looking for user feedback as an as an unrelated example we have seen extremely negative user feedback on the monochrome icons. So far we don't give a shit. So what's the, what's the meaning of user feedback for UI changes. I guess if we could kind of gather that feedback and kind of. I'm not sure that we might be on like issues to Jenkins, but if we kind of categorize that and keep it in one place and kind of draw attention to it in some way that'd be. Daniel specific to the OSS update or does that include the CI. I don't know whether what what feedback cloud business getting from customers. Where did that, where did that come from. Like random poor request comment. There is feedback also not the source issues and the thing that makes it complicated Christina is that obviously customers are aware that cloud BCI is Jenkins plus some stuff. So it may as well be customers who are complaining through the open source channels, or it's just Jenkins open source users we don't know but it is coming. I am seeing it through open source channels. I don't know what a copy support and field or say it be worth like do you ever do. This story on it's nice to meet you this is the first time I'm just the senior designer over here that works with CI. So I just attend to kind of be able to kind of get an ear on what's happening in the open source and how I can support it. I don't have a copy site. Anyway, do we have a process in place for generating issues or generating generating tasks that aren't necessarily development nature but that I'm more like, because I would kind of want to do a bit of a dig into maybe doing customer research sessions and gather some info there to see where that type of feedback is coming from before we evaluate whether that's actually something that's worth acting on. Does that make any sense. Would that be useful. I think so yeah. Oftentimes like what people will say online. It's very easy to complain because in customer sessions. I mean of course then this is a different user group right so it could be vastly different experiences and perceptions but so far the feedback has been quite positive. So I would just want to make sure that we're any any action that came from those like complaints. So, I'm just just in case I don't think we should be discussing the monochrome icons here it's just coming from young saying well, if we get feedback in Jira, for example, then we can adjust if the feedback is negative. And, and I'm saying, well, there was this other change not too long ago, where we got negative feedback and we're not acting on it so are we only selectively looking at the feedback. If there is no way that we provide where users can say I like this in addition to I don't like this because obviously people will complain if they don't like something and if they like something they will just accept it and move on. Whatever you on page kind of, you know, you've seen them when they're on a page with a new feature, they'll kind of get a little poll or. And that's something that I brought up in Gitter. We have probably a feedback mechanism inside Jenkins, that highlights new changes, especially the experimental ones and says, Hey, how do you like this is this good is this bad. This is something I'm prototyping and pushing through in CI. So it's maybe something that we could, you know, make available to at least the process make available to the open source. If they'd find it helpful. It would be useful then to at least even be able to draw correlations between the type of, you know, the scale of user just that the type of users and who tend to have that feedback. I think we'd want for just to vet any feedback, whether it's icons or future work so if that would work, I can pass that kind of research along so that maybe it could be used in the open source. Right, that would be useful. I don't think we have a do we have an internal channel for the for the UX work at Lopez just to make then I could join. Otherwise just it's kind of formalize interval krs for for me for tracking. So here to remind me but otherwise I'll make a note of it and maybe follow up with Mark, maybe on how best to cross pollinate. Makes sense. So we have mechanisms in Jenkins that can be used to for people to provide feedback or to send data to the Jenkins project on a very high level that we could hook into although the problem there is that it is tied currently to the usage statistics feature so that could be a bit of a mess so we may need something completely new that we don't have yet in Jenkins. And obviously if it is in Jenkins. We will also need to report to the Jenkins project so the folks we should look in there are like Damian was working on Jenkins project infrastructure. And that can then be reused simply in cloud based products by simply being a part of and then also being part of the products. Yeah, I think that would be very valuable so even for something like the icons right if if if what you're hearing is that people like it. And I'm seeing the very vocal few who absolutely hate it. Like, you could see how you could start to and this is why like before I action anything I would want to make sure that we're not kind of getting things in a vacuum because I may be in a vacuum of a certain type of user. And it doesn't mean that only they should be informing our decisions. So we have to like, make sure we're hearing everybody and find something in between. So this is a touch base of a Damian and Mark. Awesome. It's all for me. So that would be useful for acting on feedback that we're all just getting more feedback mostly. I guess, so specifically in this poor quest. I don't think, I mean, just because it's good to get feedback on these sort of changes but I think the main was the main thing that was holding this up was it just the title or was there anything else holding this progress stop. When you say title what do you mean the title in the sidebar in the side panel. I mean the side panel is. Oh right the title in the side panel was the one thing and the other thing was the separator, which is for example currently not usable in anything that is extensible. Right, so if we want to have the separator as part of what side panels can contain we need a way to have that be part of the actionable interface for example. In the side panels just showing a link to update center at the moment right. I scrolled on a bit I think there's a separate one that has everything. Maybe the video maybe. Probably not. Maybe it's further down to a picture, but I'm pretty sure it's just a line that has a link to update center. And yarns planning to mostly get rid of that link later by inlining it into the inlining the information into the table. The problem with I guess not having a separator is that these are. Well, I guess you could just put it in there. There's a almost kind of like their tabs whereas it's a different page which is why it's separated. I mean the explanation makes sense it's just, it's this one place in Jenkins that nowhere else, and it's not working with actionable and the existing extension mechanism, and so on. So this isn't about the benefits of the specific thing but how it integrates into Jenkins more generally. And have you got any thoughts on it. Yeah, like like Tim said this is going to stop that solution, and just so we can separate the kind of permanent items, I guess we can call them at the top so you've got the active, the updates available in still advanced. So you can separate those visually from the update center. In terms of that, thank you to a separate page altogether. In terms of extending the API to support separators. I'm happy to do that. It's just whether other pages on Jenkins would benefit from having that separate. Because the goal is generally to shorten that sidebar rather than lengthen it. That's not on really so probably wouldn't want to encourage other developers to start separating items whereas we should be kind of trying to find better ways of exploring or showing that kind of information. So another option how we could get this effect without needing a separator could be to have nested site panel items like we have for whiteboard workspace. We also have for the plain text log, which are basically, there's basically a tree of site panel items that exists in some places in Jenkins. So that way, install plugins advanced settings could be shown as part of the are available plugins can be short as part of plug in manager, while the other top level item would be the update center. And that's not a separator required because the tree structure makes it clear what's related. I'm not sure it needs to be discussed in this meeting though. Just just the thought if you want to move this forward without the separator. It probably makes sense for us to look into the feedback mechanism rather early because the more changes and the more experiments we publish without having a feedback mechanism. The worst the situation will be because why would anyone provide feedback on something they've been using for months. Yeah. Any thoughts on what to do about the title, Jan. I think for this page there isn't really a place to have the title really of them on the left side. We have that kind of giant search bar in the center. Just so it kind of gets the users kind of focus straight away. See, I don't know I can't think of a better spot for the title. I'm not really going to be on the, on the left, you know, but what do you guys think. My only concern is that it would open up a can of worms for other pages. I think young you weren't here I think it was in the last meeting right where we already discussed in quite some detail potential issues with having the title in the site panel. For example the resulting length limitations, especially in more both languages, stuff like that. So for example, if we move the title into the site panel on all pages what does it look like. On job pages where the job name is the page title and job names can be extremely long and very difficult to break because people like their word separation using underscores which are not really easily breakable with normal rules, and so on. So I don't want to reopen this particular can of worms I just want to mention this was something that we discussed in some detail last time where quite a few concerns exist with having the title in the site panel. Obviously on this page. But if, if this is something that should be done more on more and more perhaps, ultimately all pages of Jenkins, then these are problems we need to figure out an answer for. I managed to watch the last meeting. And so I managed to capture all your points really. And I responded on on the ghetto as well I'm not sure if you had all seen. Like you said this this page, it works with the head because plugins as a title isn't particularly long. And be effort for the job page and whatnot if you have a kind of crazy job name. It wouldn't handle it. At least in this kind of current implementation so it would be worth looking at how we could kind of work around that or there's a better way of doing it. I think some pages have descriptions to associate the option the ability to add a description as well. Right. So suddenly all the links start pushing down the tension below the fold. It could be that the plug and manager pages unique enough to stand alone with it in the sidebar with no problem. But I would agree that like future pages like couldn't hurt to have further discussion. That was my two cents my opinion is only worth it. I wouldn't mind actually if we had the time to stay potentially just to go over a small prototype for the kind of project page. It's pretty much like a wiring at this point but it's just an idea of kind of cards that we spoke about a few months back on the next meetings. Sorry for this time. Yeah, we've got time for that. I think I guess the main thing here is just trying to work out a way forward on the support request is the main one that probably not too much hopefully not too much work to unblock this one. Listen, have you got enough to go away with young to figure out something or do we need to figure out page titles or so for the title. If if we kind of class this page as being me like Christina said, then that I could stand like it's compared to the rest of Jenkins the plug in managers is quite a unique page. It's more like a storefront then kind of managing builds or whatever. From that viewpoint it could be seen as it kind of requiring a more unique layout. And then for the separator. I have no issues with being being part of the API. And I wouldn't want to encourage developers to actually use it unless there's a situation that kind of needs it like where we have the update center being separated from the top four items. Yeah, I think I only make sense on custom pages and do we need to bring that in. Okay, so how about this. We change all the labels of update center to plug in manager and call it the download progress page of the plug in manager and otherwise pretend it's the exact same thing. Yeah, that could work. It does come up in breadcrumbs as updates into we could either. That's that's the point you can rename the label. You just make the label also plug in manager and call it the download progress page because that's basically what it is. Yeah, yeah. I think that's probably a nice solution. Review what the API offers, however, both of these have API is and so that could be awkward having the download progress page having an API that has little to do with downloads but I think it's the jobs. So, it might actually work. So perhaps that would be a way forward and then we you don't need a separator, because the plug in manager suddenly has a download progress page. Yeah, I think that works. Yeah, sounds good to me. And are you happy Daniel is the title of the title of this page is quite special. I don't think happy as the word. Are you okay with that. Are you okay with that. I mean, at this point it's just another page like all of them, or another side panel like all of them right there's nothing special about this side panel compared to the job configuration. As I explained job configuration has a special side panel that is the like the what used to be the scroll spy on top. And so it kind of made sense there but now it's just a regular side panel why does this have. And if you scroll down you will see how the site panel actually progresses through the different options right, which is very different from the usual go to a different page side panel that other pages and Jenkins have. And so this kind of, I thought this signified this special kind of side panel as well and now you apply this to plug in manager why, why does plug in manager have it but not system log. For example, system log is also a sort of unique page on manage Jenkins. Why does this not have the title in the side panel. And I think for that page it could potentially have the title in the side panel about too much issue. Then what would you do with the buttons then I guess. I guess I'll just keep that kind of top pro kind of blank I guess. So, if I show that prototype late you'll kind of have a similar kind of theme to that you have the controls on the right but the kind of title on the left. Yeah, yeah. And now do you think. If there's time. Just bear in mind it's not like kind of anywhere near feature complete or developed it's just like a refiger at this point. Just wanted to get some feedback on it if it's demo it kind of next month. Yeah, I'll share my screen. I'm going to. So you will see my screen. Yes. So it looks quite a bit different what we've got currently. The idea behind it is to kind of cut down on white space that we have on the build page or the project page as we currently have kind of controls currently everywhere. So you can visualize kind of the controls aspects you've got to kind of build a parameter option configure and kind of generic options are not really thought of there. And kind of put the most kind of important information kind of center stage. So for this kind of project, we have the stage for you plug in. It's kind of massive canvas so it can display all of its information. And then instead of rather having kind of sidebar links traditionally have the contents of those pages is instead visible on the project page itself. So kind of rather than clicking through different pages. You can go down to see different information, such as the test result trend, all the stages for example. Kind of nice things that you scale to say if you have a really large monitor, you get more information. If you're on a phone, you kind of get a view suited towards your kind of form factor. But that doesn't work. It's just a really hastily front end approach type. I love the concept behind it. It looks pretty. I think the main problems are worse going to be how do you get the plugins to fit in and behave and go and like, do you provide areas for these sort of things? Do you make it configurable so people can choose what they want? Or is there like specific areas and sizes that they're allowed and they hook into because currently it's just a hot mess on a table. It's literally a table where plugins dump themselves in certain areas and break layouts like a certain plugin going somewhere can break the layout and through silly things. And how do you, I guess you have those, or are these like key actions or something that appear there and if a plugin has a super key action, they can put themselves there or just all actions appear in the little Hamburg menu. I think it was right because it suggested back in the day that we kind of have it kind of customizable. I think that was early. And then that obviously had lots of complexity, but I also kind of agree. I think Jenkins as a service is quite complex. So you kind of need that fine green control over what's visible. Yeah, I guess it's kind of a, yes, it's kind of letting you build your own dashboard sort of thing. I think, I mean, for me, I think it should be sensible default and be nice if you can customize it in some way and plugins shouldn't just dump themselves on there just because they can. I think, I mean, this page is well due a overhaul. It's a mess and the, yeah, the page structure doesn't lend it well to that without current years. Like things like the few, if you're showing like a before view on like some plugin on CI. So some build on CI. You'll probably see maybe 15 side panel icons or something on that. I guess this is the run page and then there's the project page. But yeah, if you click the master branch, so you've got 10, you've got 10 side panel icons. So if you click, I think I was probably thinking of the next page down. If you click the run page, you'll get a ridiculous amount. I would say maybe one that's already run. That's, yeah, there's a, there you go. Probably one that's already run will have even more, I would say when they actually finished. I mean, next and previous are the easiest ones to kill off. Yeah. Three, six, nine, 12, 15, 18, 21, 23, 24. That's it a quick 25. This is a quick count and I could have missed some about 25. I mean, this is easy to clean up just fix warnings and G to have one side panel item instead of 10. Yeah, and get build data to not repeat itself for every build and So yeah, so anyway, the experiment or the demo that you showed looks great. It's actually fairly similar to what I suggested or meant to suggest recently when I asked about the build overview and or job overview page. The details in the details as usual, but this looks looks pretty good and this is also the kind of magnitude of change that makes it where we can basically defend us breaking stuff. So for example, the build history on the site there looks different than what the site panel widget would be right with the accompanying breaking changes around which is an alignment and are we showing the description and on and on the problems that create problems basically every time we touch it. So we have a we have an opportunity here with this to completely rethink how that which it would work and throw out some of the accumulated garbage over the last decade or so. Every time you try and debug that stupid widget, the HTML just changes constantly. It's ridiculously hard to debug. I'm this kind of design carries through to the build page as well. But I think the page is horrifically broken right now so that's why I'm not really showed it. But has a similar concept where we kind of bring the side panel actions out. I don't care how broken it is but showing an excerpt of the console output on the main page. Thank you. Thank you. This is long overdue. Yeah, so yeah, just just kind of reduce the amount of clicks it takes essentially. It's just, I've just broken this UI completely. But yeah, that's it really I can kind of develop it more if there's an appetite for it and I'll hopefully have something. It's a huge appetite for it. I'm putting posts on Gitter about in that case now trying to get some kind of more realistic data on there and more realistic view of how kind of plugins can integrate and what not. Yeah. Yeah. Yeah, that's that's really. Yeah, certainly help with this as well. So I'll stop showing you my text. Cheers. Cool. Okay. So thanks for that demo yarn that was great. Just in terms of the plugin manager page just to loop background foot was worth just seeing that demo. So I think the last bit we're at was it's not completely special because pages like the job page have it the log recorder page. Could have it and so yarns, I guess you showed how that different action bar, I think was there still a title title on that page was it was at the build. Was it the project name and then there was you had a kind of different type of icons with a. So I think it's a good work for like extra things that didn't necessarily need to take up 1010 sidebar spaces pretty pretty much yeah. Yeah, I can send a screenshot if zoom supports that. It does. I don't know. So this might be a really stupid question, but why is the plugin title not above the search bar would that be so terrible. I think it should be down just like the vertical space. If we have the space on the left you could always take advantage of that I guess rather than trying to put more stuff on top. As far as I understand it this is still an experiment right. So we would probably want a feedback mechanism to exist before we publish it. Yeah. It could be a good prototype for whatever we propose for the on page feedback. My suggestion would be perhaps we could do the following. Change it to move the title back to the main area where it unnecessarily takes up vertical space. Change the update center to be called plugin manager so it's just yet another page of the plugin manager that shows up as needed. And remove the separator. That way this kind of looks more like a classic page of Jenkins, we can basically postpone the discussion with the title in the site panel for now. And basically, we submit that for review. And postpone the title in the site panel until we have a feedback mechanism because that intro kind of introduces a new way for the pages and Jenkins to look. Yeah, only kind of concern was safety advanced page would end up having two titles for that page. You can have like plugins and below you have like advanced settings, at least on the on the redesigned. Yes, big old title there. Yeah, because that one's like an actual regular page whereas these ones are different. Or you could just change it on that page to just advanced or plug in manager advanced plugins advanced. Yeah, that works. Would it make sense to split that page up into three separate pages one is the proxy configuration one is the plugin deployment one is the update site source. It's basically just a random grab bag of other options that are vaguely related to plugins. And I'm saying vaguely because the proxy configuration isn't just for the plugin manager but also affect the rest of Jenkins so this might as well be in the global configuration for system options. So, if this page is painful because of the title that's because this page is stupid already and has always been stupid. It makes sense to me here. You could just call it configuration. Maybe it's not even configuration because you can deploy stuff. So basically this could be two separate pages for the plugin manager one is the deploy plugin one is the update site sources. And the proxy configuration could be moved elsewhere. So, I might need to look into whether that makes sense structurally but I can see this happening we've moved options around in the past, for example the cloud configurations used to be part of the system configuration. We had this label that they were moved the tool configuration used to be part of the global configuration. They moved something back, and since the proxy configuration confusing the applies to more, or applies to more than just the plugin manager, having it here is actually confusing. I think that your pull request as suggested would be slightly awkward on this page is acceptable. If we intend to split this up a page up afterwards anyway. Yeah, I mean there's been talk of fixing this for years. It's just getting it done at some point. I mean the main thing is I think it's moved to be proxy at some point, but it's just figuring that out. I'm getting rid of all the action. For this PR I think it would be fine just to change the title on this on this page. Right splitting this up, I think would be a separate follow up change. Yeah. Is that enough to go on yarn if something is an interim measure to get this over the line. Yeah, it sounds good. So just to kind of clarify, move the title of the search bar. Right, and then kind of rename the update center accordingly. Right, so the breadcrumb would also be plugin manager to basically make it appear as is it as if it is part of the plugin manager. Have the sidebars look identical between plugin manager and update center. And the side panel item for it could be download progress or something along those lines because really that's what it's used for right now it does nothing else. And then the only thing that's kind of separate is it has a separate API, which I expect to be fairly little used so that's not a huge deal probably hopefully. The other is separate URL and who cares. So what about the URL did you mean, do we, was it do we care that it's still under update center or is it that you want this page to be served up under the plugin manager. It doesn't have a top leveling. Yeah. So you always got there from the plugin manager. It only exists. If you actually downloaded something. And so that's why I think it makes sense to consider it part of the plugin manager you take an action plugin manager and the update center becomes available which is kind of dumb. You go back to plugin manager and just you know just install any of these updates nobody cares right just take any of the updates say download now. Suddenly exists go back to plugin manager. And now you have the link to update center right and if you call this link, download progress. And here now go back to update center. The only thing that you need to be careful of is in the background bar we would also want to call this plugin manager because we wanted to appear as part of the plugin manager. And then I think the entire rename this page the title on this page as well to be download progress or whatever the site panel title would be for a bit of redundancy and we're through. I think that would make sense. Yeah. How straightforward is kind of changing that breadcrum to be plugin manager. It's the display name. It's not changing the link it's just changing the text. The link will still take you to that same page but you've got the side panel which you can use to get back. Awesome. That sounds good to me. Oh, right. Good point. Well this is stupid. Or do you want that link to change go to plugin center plugin manager. Yeah, that would be nice right because the label would be plugin manager but it takes you to the download progress page. It's only going to be a problem when you're on that page. Right. Still kind of weird. But I mean if you if you treat it as. It's an actual page of plugin manager it's. And so if when you're on when you're on plugin manager and you click it doesn't do anything. It just takes you to the same page. Well, technically it takes you to this because these are actually pages, but if you click this it does nothing. It'd be the same thing over here. It's more like this should be a non active bread crumb which you can't actually click because it's a useless bread crumb would for it to do anything would actually have to have sub pages here. We might be able to hack the get URL to say plugin manager. And if nothing else breaks we're good. So yeah so there might be some pain here that we'll need to. We'll need to see in implementation and if you want I can take a stab at this. To see whether it even works. Sounds good to me. Okay, so later this week maybe before the next meeting let's say before the next meeting. Yeah, I mean I can probably do most of the small stuff at least push something like tonight tomorrow or something. If you've got unless unless you've got time young. Yeah, I can definitely take a look at some of them I just might need help with the kind of jovery side of things because Jenkins Java confuses me. Well we'll see who gets to it first. Cool. Has anyone got anything else. There's mention of an accessibility assessment here but as far as I know that was it was a done by a company and it was in German and I'm not sure if anything was done about that. No, is there anything else or should we close it. Cool. Alright thanks everyone for your time.