 Give me a second, please. I need to close all my apps. Okay. Yeah, let's start. Hi, everybody. Welcome to the 6th edition of the UX6 meeting. Let me share my screen so that we can start going over the agenda. So agenda for today. So first of all, introduction, agenda review, and agenda topics. So first of all, I'm going to give everyone a bit of some updates on what the status of the city is, what we did these last, these past two weeks. And then we are going to talk about some design feedback we collected on when working on the header PR. Everybody wants to place a point about how to improve the group for non-seek members. Okay. Introduce new participants. I think everybody already know which are for the record I'm very happy to work in front of the developers from cloud is who is working on this project. Okay, so updates. So these past two weeks, we moved to Gitter. Thanks to whoever created the channel. I think it was Ulrich. So basically all discussions are we, we are going to start discussing all the matters for the seeking Gitter. And we have, we have updated the also the documentation page on the engines that IO, and we try to notify to as many people as possible in as many channels as possible that we change the discussion forums. And we also recently, well, the header and backgrounds that merge will not merge approved. So basically, oh, and they are, and the header and backgrounds pull request is slated for merging tomorrow. I don't know if it's going to make it to the LTS, but it's going to make it to the Jenkins 2.222 version. Probably. And what's next. I want to refresh what we talked in previous meetings. The main changing right now as our next steps will be focused on changing mainly typography, the typography hierarchy. And fonts, sorry, the typography hierarchy and the typography fonts. Basically, so this is something that we talked in a past meeting. This, this design deck is what is linked in the here is linked in the meeting from the 5th of February. If anybody wants to take a look at it. Also about regarding typography, I have sent an email to the to the lead of the Chinese localization sick to see sick input for for funded choices that don't be great user experience for people who use non non Latin alphabets. As their main, yeah, as their main make language, basically. So this was it for this past two weeks, basically, no active development, it will not active development on the typography just research. And is there, does anyone want to ask about this, this or bring something up. Okay, I guess we're good then. So I think there's maybe something one thing I just thought that I was, I missed that. I think we are seeing the exact use case for the mailing list here. That's great. You reached out to these people. For now, it's, it's only somewhat in private because it's not in targeting the various the people from the Chinese community. And I think we could, we should actually CC the Jenkins to explain this that everything is related to. Yeah, so CC the mailing list because obviously that's just one guy and you know, he might not be available for it. He may be on leave or, you know, God knows what's happening in China to coronavirus. So I mean, it'd be good to hit as many people as possible on the mailing list. Yeah. And I think it's in general way working on something that's open. You should try to make everything, every single bit of work public. Yeah. Anyway, that's just kind of an aside at that. So you can kind of resend the mail, I guess, and I'll just add to the CC of the mailing list. That would be good suggestion. Just a question about the typography or working on Felix. Do you have already some plan about how you can cover every case in the ecosystem? I mean, the two typography, the current one and the new one are not very distant one from each other. And so if there is some specific rules in some plugin or in core things like that, potentially it could be easy to miss them. Do you already think about that part? Oh, it seems to me today. Yeah. Okay. Yeah. Now, and one of the few, one of the things we aim to do is based on our discussions from previous meetings was we realized, basically, one of the things is update typography. Basically, update the font, probably going with a more modern form font. Another thing is establishing a hierarchy using CSS classes and default styling for the tags, a hierarchy that makes sense. We will also provide utilities, for example, if somebody wants to put an edge to heading, but with the roots really huge like already spread we also will have CSS classes as fallback. And that basically just that base typography rules. That's everything. Plugins can also deviate from current typography rules right now. So there's only so much we can do, but we want to provide a good baseline so that they don't need to, basically. One other thing that we are probably going to look at next is this site bar. Especially for example when looking at typography, one of the main, one of the common complaints was that this site bar, the links were so small and it was difficult to work with Jenkins for example doing presentations and everything. So we will probably be looking into tackling onto the typography of this site bar and working on this, basically. So that's our plan. It's in the early stages of research. We will share mockups, we will share everything as soon as we have them to iterate on the feedback basically. Does this answer your question? Would you like further clarification? My concern is more about if I'm a plugin developer, if I'm using a specific font that is exactly the same one as the core, but it was more by a mistake that I use the same because I don't know exactly how CSS is working. In that case, you are providing the new style for the core, but potentially it will not be able to see the difference between my font, the previous one and the font you are proposing. If we are looking into using Roboto, which is already bundled into Jenkins Core, which is already used in the setup wizard. So if plugin authors choose a different font, I mean, they will see if we change Jenkins-based rules in Jenkins Core, plugin developers can still change it. I don't even understand why it would be actually a problem. It would almost be a good thing. Why are you saying that if people would be already using the font we are going to set over the standard font? In your mind, this is a problem? No, it's more about if as a plugin maintainer, I was just overriding some CSS rules by mistake or by lack of knowledge. And we know all the plugins are not equal in terms of quality. So the font you are overriding currently is the same as the one in the core, so there is no problem. But with the new approach, the new style, the new font we are providing, that previously overriding rules is just a new rules. And so it takes precedence potentially. So it's more about how you can have that warning in a sense for the plugin maintainer point of view in a sense. Yeah, basically what we are going to do is, first of all, I'm going to look for cases of custom font family declarations, which is the way for places where in the Jenkins Core organization, places where actually new fonts are being loaded. That's part of the research. We already took some steps towards it. For example, in the Jenkins right now, whenever you go to the... If you want to do work with responsive fonts, would you release a CSS unit that you couldn't use before? And I added a patch on the set of breadcrumbs pull request that makes it work in all Jenkins pages. So there are steps we are taking towards it to, as artists say, correct stuff, basically, and make it easier not to mess it. But it's part of the research. Okay, fine. That's why it takes a while. Okay. If there's anything else, I will move on to the next section for the same feedback. There are a few pieces of feedback we collected when creating on the Jenkins header and breadcrumbs PR. So I'm going to scroll past all of these. It's mostly for the benefit of new people. So, okay. So admin monitor warnings. There was, we received some feedback that maybe Vatican about it, that mainly that this new design for the warning monitor does not pop. It's not as in your face as it should be. Also, we also, there's a proposal. This is, by the way, this is just a mockup. This is not a final design. Okay. So, for example, of having this shopping, the red background. So, for example, some, some internet proposals also. And then it raises a good point that realization feels weird. But for example, if you have to, you would read monitors to instead of two monitors. So that's that's a point. That's a nice point. So just just one question that the top design is the way it is now, at least with the once your PR gets merged. Yeah. Yeah. Lower as a proposal. Yeah. It's an experiment. Sorry. I assembled this deck in. No worries. I just want to make sure that this is the, I mean, if the PR gets merged, the top is how it will look. And the bottom is a potential thing. Yeah. The bottom is basically a game edited thing I did in two minutes. I included shamelessly. I just think, so I think right now, I'm going to let you talk about that. Okay. Well, what we, so before commenting, I'll open this for comments. What we are going to do is definitely collect all the feedback people have. We are 100% open to for several iterations on the same UI element. No design is closed. We'll collect all the feedback. And if needed, we will revisit it on once we work on the warnings pop up probably or on a separate PR. But we, first, we will want to collect the feedback in form ourselves, do actual access, do more comprehensive accessibility testing to see if the contrast is good in any option. So basically we heard this, we heard this feedback and we will look into it. Any product to elaborate on this? Just one point, because it was even in the title in this slide deck. The most important thing from my point of view is that this information about the admin monitor is not a notification. Because the notification is really, yeah, you receive a new message or you receive something that is not really important. It's interesting, but not important. In this case, the admin monitor, we listed the things with Daniel Beck about what is important and what is less on the setup that we had for the test. It was about 40 admin monitor and only two are not really important. All the other are about lack of performance, lack of security, lack of something that is important. And so for me, this UI means it's just a notification. If you don't read it, it's not important. But actually it is. So that's my main concern for the admin monitor in general. Okay. One of the things we can look into is to determine if there are actual security wardens using a warning icon instead of a bell, using a bell on it, information, stuff. Probably upstream or separately from the PR of the header right now, there could be ongoing work. We need some kind of level of criticality of the messages that are being sent through the admin monitor feature so that we can differentiate and maybe make it red only if the criticality is a little high or something. Because we have things like when the reverse proxy is badly set up, it's a bad thing, but it's not maybe worth the red. The one on the top is maybe enough. For that reason, we have something in our backlog in the security team to split the warning into what is just non-security warnings and security warnings. Because for some companies, if you have at least one security issue, you cannot use it in production. And so we need to be careful about this kind of information. That's kind of my concern or my request is that I think maybe making things pretty related is a bit unnecessarily to constrain restricted. I think maybe we're going to introduce something like the log levels, like some level of criticality. And then people who are using admin monitors would define the criticality of the messages that are being sent. And maybe there would be a top level that would be high vulnerability or something or security related and then the rest would be critical, high, medium, whatever. I just think that maybe a Boolean thing like is this security, is this not, maybe it's a bit, while we are at it, it's a bit unnecessarily limited. I guess we're kind of going a little bit beyond what we're trying to do here, which is just doing a CSS-based baselift at the moment. Whereas this is obviously something that new functionality, that's important and worth noting. Indeed. Yeah. Yeah, I agree with the enemy. Any other idea, if you talk on this, Tim may ask what do you think of this? Do you have any thoughts on this? I think, I'm not too worried on the admin monitors, I think you've covered it quite well. Okay. Yeah. Okay, thank you. So, yeah, so basically what I said, we are going to look into it, we are going to inform our situations based on what Vadek said, but of course, as Jeremy said, this is a CSS-based refresh and revamp. So we are going to not expand the new functionality, especially if it's security related. Okay. Next, the next feedback piece we did receive was the contextual menu drop-down. It has been mentioned that there are several problems going on with it, I'm sure everybody knows. It's used across the whole application from the breadcrumbs to the links in the header to the jobs, to the tables. It has several problems. The discoverability is really low. You need to hover over the element. It's a power user feature basically. It's difficult to click, it's only 16 pixels wide. It does not interact with the element it's on. When you hover over it, chances are it will not have hover effects or focus effects on the element it's positioned above. And it's implementation is a bit difficult to evolve. It uses some rather old JavaScript. Not saying it's rather than saying it's old and it's slathered and it's used across the whole application. So there's a potential to break lots of stuff. So from our point of view is we acknowledge this is a problem. This is an area of the interface that definitely there's room for improvement. But we even think we think our efforts for this CSS refresh are better located elsewhere. There are far more important things from layout, typography, the sidebar, tables that demand our attention. So we know this is an issue. It has a lower priority than all the other bigger ones for your back improvements. Can we document? I think this is absolutely acceptable. I'm just thinking maybe it would be great in our central page. Maybe not on the website or somewhere else, main resources that we actually put. What we are actually feeling like knowing about what we don't touch is for now. But anyone maybe is free. If someone wants to give it a try. It's an open thing. We kind of make it clear so that people don't come over and over and over about some recurring problem and say, oh, I think it's shit and we're like, well, we actually look at it, we know it's a problem, but we think there are higher, more important things that probably mean to the cat first. So that's kind of avoid having people watching hours of signetings to actually find what we know about already. But you have maybe one thing that comes to mind is maybe we can create a user story for that on the Gira tracker. Yeah, we can add a backlog item. Something we'd like to pick up one day. So I have a question. Is this only about the drop down menu or also to the photo contextual menu? With drop down menu, I mean the contextual drop down menu. I mean this sort of menu. Whenever you position something, you see this arrow and then it's also on the sidebar, on the jobs descriptions, I think. The thing is, you see the arrow pointing to the right, just to the right of the arrow pointing to the bottom. That is also a pop up menu. Yeah, I know. With that I meant the arrow pointing down. The menu pointing right here. Do you mean this? No, between the words Jenkins and the word all, there's an arrow pointing to the right and that is also a menu. Yeah, that's sort of a similar case. It's not the same way. I was talking about the other. We were talking about the other. The other one is also breadcrumbs behavior that we did not feel comfortable changing when updating the styles for the breadcrumbs. Well, I think the point is that the discoverability of them is fairly low. I mean they're hard to click and I think that applies just as well. Yeah, yeah, I think it's fair enough that we're sort of benching it for parking it for the moment because the United is probably hundreds of other things there, but it's a real issue. Yeah, and also 25 clones of you, then we would put one of them onto it. Also, Daniel, quick mention about this separator menu between breadcrumbs. I don't think it's maybe we can take this discussion offline but I don't think it's possible to change it without pre bumping the breadcrumbs called on Jenkins. So it's definitely a big task. I just wanted to get clarity on whether this general topic applies to both variants or only to the drop down menu variant. Both of them. Probably both of them. If there's nothing else I'm going to I don't have much to share regarding these pieces. So, if you please go ahead and talk about what you wanted to mention about this topic. So yeah, essentially it was a discussion we initially have in the cloud based channel directly but for the openness just to discuss that more broadly. So mainly during the feedback we can provide in the PR it's a bit difficult for a community member to come and to provide feedback on the UI directly the new design that is proposed because it's already a PR. And you expect the people to be present in the sig meeting to discuss to provide feedback to improve the feedback look in general. But it seems to be a bit difficult for every community member to be involved in the sig meeting in addition to the other things they have to do. So providing the feedback in the PR seems to be the most straightforward approach for the people outside of the sig. But it seems it was not initially expected, especially after my initial feedback it was more about yeah, we need to discuss in the sig topic instead of the PR. But in that case, do we need to have a preview step before the PR we discuss initially perhaps similar to a JEP or things like that to propose the design in the community so outside of the sig. So mainly the discussion is just an open discussion what could be improved there because from my point of view as an external member because I was not following the initial meetings. It's a bit difficult to have the context, because it was not really explained all the things that are already discussed or not, and to provide feedback to have something useful as we said. Yeah, I guess I'm going to have a few points here I mean one of the original guiding things when we started this whole process was that we wanted to avoid the signing by committee so we didn't want to have the whole Jenkins community, saying I don't like this color I don't like that. But at the same time we did want to have some level of consultation as well, which is why we set up the Jenkins UX sig. So, so I mean, I think I agree with the approach that we should push back on giving the science feedback in the PR the PR should be concerned with the code quality, you know, security issues, you know, regressions it could introduce. So I think that the signature is the place to review the designs, however, maybe we could also post the design somewhere but at the end of the day. We do want to avoid the sign by committee where everybody's like well I think this thinks a little bit too pink and that purple is a little bit too purple you know it's. It's a difficult balance between getting some reasonable feedback and you know not having 1000 people pulling a pixel. Yeah, I agree. Also, also we want to optimize for time I don't think it's good for anybody. If we need to create a gap for the every design change that the feedback loop will be too big. I mean, it will take us too long to deliver even small pieces. Something we can do is maybe whenever we we are about to we are about to present the science and the sig meeting. Maybe we could look and we will we will explore. What I would suggest is maybe we can look into venues for making people aware that new designs have been posted and they are up for discussion maybe an invitation to discuss them on the guitar room. But we, for example, maybe using putting an announcement on the Google group or what they will mainly suggest new designs come discuss them to the guitar. Yeah, I think we should have something like a place. So not the wiki but either using more Google dogs or some central place for people to be able to follow from far away or something. But then we can indeed and not expect everybody to be up to date and then be able to. Well, we don't want people to go to risk concerns, but if it's very related to the process for a year too late and then we'll be fixing it if the outstanding but just matter of opinion or feeling. Yeah, yeah. No, I just like I think like I was saying in the beginning, I think we should probably there's probably at least a balance to find to write down a few more things from some central place to link to the various ongoing design because the full mock up design has been done. I think provided by Joe on the last meeting. So, you know, just writing a link or something. Some kind of notes, because we already have the transcript of the meeting so something like a summary of what I just like to do on your IRC open source meeting. There's kind of a boat to surface, you know, amongst 900 messages that was sent under 10 or 20 things that people need to know about what was discussed. Maybe it would be good for people like that or anyone else to be able to, you know, like very quickly know what was discussed, if they want to chime in and dig into it. You know, instead of having to watch in the 30 minutes of video, which not everybody can afford. And when I try to review the corporal request and I asked for the design direction to understand the change in the first place because I did not explicitly did not want to provide feedback of the kind that Jeremy describes. I basically got told a sign up to this slack that nobody else is using. Maybe the messages aren't deleted yet. And that's not a good basis for to enable people to even understand the change in the first place. And I want to also want to make it very clear that Vadek and I don't really care about the, I mean, design is everything, right? I understand that. But I think what Jeremy described is more like, you know, which shade of blue or red or what pixel distance and I don't think Vadek or I really care about that. The feedback we've provided has been very specific and limited to a very small subset of the overall changes that specifically are about the emphasizing of the warnings. And we got the impression through the conversations, at least I got the impression through the conversations we had about it, that it was, it's not like, for example, on GitHub, where there's a bell with the unread marker. It's also not an email client. I reviewed the admin monitors in core and like 35 of the 37 indicate that something seriously wrong with your Jenkins instance. And I don't get the impression that this fact was accounted for in the redesign. And at least for me, that was the extent of the design feedback, as I understood it. And I was saying, well, designed by a committee. Honestly, that sounds a bit like a strawman argument, to be honest. How can we did this more effectively than because I mean, I mean, obviously, when we talk about shifting left, I mean, code is too far to the right in this case and then we should be doing this at an early phase, this feedback. There were probably design mock-ups or something before it was implemented. Perhaps share those on, is the mailing list selective or are we entirely on GitHub? Share that in some of these channels that are accessible, but let's just say, not something that people just stumble over if they are on the dev list, perhaps. Or, and I admit, in this case, it would be, might have been difficult to try to identify specific stakeholders for changes. Like, for example, if you redesign how security warnings specifically appear in Jenkins, I would expect that you contact Wadeg or me as stakeholders in this area. Now, obviously, the notification area or the admin monitors are more generic than that. So perhaps that would not have worked in this case, but that would be an idea in the future when it concerns something that's security related that you invite specific additional stakeholders to provide feedback. That's not excluding people who are really interested. That's not sending an open-ended email to the entire world, but rather making sure that you get relevant feedback beforehand. That's a great point. I think that's a great idea. We will definitely look into doing that. I think you're absolutely right regarding the stakeholders. We will look into that and into practically engaging stakeholders, like in this case you mentioned. And yeah, let me say that maybe my answer to you to, you can look at the documentation on the Slack and then the Slack was a bit abundant. Maybe that was not the best answer and I apologize for that. We will look into ways to better make the design preferences more available and to better broadcast them. We will look into what we can do until at least have them accessible by everybody. If you can provide the explanation about some of the parts or things like that could be also very useful for the different feedbacks. Yeah, that would be nice. I mean, I guess what's frustrating for everybody is that you don't want to get the feedback by the time the PR is being merged, you want to get it earlier. And of course, it's not always possible to get all the feedback because you can probably get quite a lot. Yeah, I mean, we need to find a better balance, I think. I don't really think we can really expect everybody to be able to catch every single backing decisions or again behind everything. Just from a 10 second glimpse, you know, to be able to act on the project, you have to be involved more. I just think indeed that we need to have a central page again, just start that right away and where we can iterate like a wiki, even if we cannot don't have it anymore. But, you know, some places where it's easy to edit afterwards and make minutes, the design, the full screen mock-ups that were, you know, again, shared last seed meeting. But I fully understand again that not everybody could afford watching the full one to just track what's interesting. So, yeah, I think we should try the next immediate and easy step is that. And then we can iterate on the texture entry points for outside watchers. I guess we can, I think we should move on on the next discussion or subject. Are we going to run out of time actually? No, we still have a few more minutes, but there is no other discussion or topic. Oh, yeah. I was looking into that. Just one point about the PR. We said before the PR should not be there for the discussion about the design or things like that. But just one point. We have multiple PR that are just for iteration in the community. And the team can explain that also very well with the system read. We are on the third or fourth iteration because the initial one was just a proof of concept. And then we iterate to have better quality, better quality, better integration with the rest and things like that. Also for new approach and to have just a proof of concept of the design could be also useful for the usability and not just the design. Potentially the arrow of the menu for the over effect and things like that cannot be discovered with just the slide because you don't have the feeling the interaction with the components. So it could be potentially a good approach to have just a PR that is draft that will not be merged as is, but just provide feedback and iterate on the next thing. Yeah, it really depends on the effort it takes, you know, because for example, for one of those things, it can be okay. But for the typography, it can be a whole week of development effort just to have an experimental PR, you know. It really depends on the component on how much effort it can take. But yeah. Also, I'm sure other UI elements don't have full secret venues and specific venues for discussion, as we do. So we do have this resource. So we, I think we need to use it. I agree we can do better communicating the design decisions, especially communicating them and making them accessible. So that's something we can all agree on and that's something we can all agree we should look into. Okay, anything else? Okay. Then if there is nothing else, let's close this meeting. Thank you everybody. Thank you for raising these concerns. Very valid points. Yeah, hope to see you again here and we will convene again in two weeks. Same Wednesday and same time. Okay. Bye everybody. Thanks everybody. Bye. Cheers.