 Hi everybody, welcome to this 4th or 5th UXC meeting. So this is mostly a catch-up meeting, so first of all I will start with the introductions. I believe we all know each other. Maybe I don't think Vadek and Fernandes have participated in previous meetings. So just hello everybody, I'm coming from the Jenkins security team, so mainly concerned about the potential aspect that could be worse for us in the future. Hello everyone, just another cloudless engineer participating in an open-source team within the company and just trying to help in anything that I can. Okay, the rest of us haven't introduced ourselves like three times now. Felix, would it be possible to put the agenda up on the screen? Yeah, sure. Sorry, no problem. Okay, so now, well I start again the second point. First point, general review topic. The agenda for today is first, I will introduce the created tickets on the open-source data tracker. I created an epic as Oleg requested a few meetings ago. I will show the issues created. Then I will give a quick update on the UI progress. After that, Joe will show the design deck featuring the full-page mocks that were requested a while ago and also talking about what's next in regards to the typography. I will follow up on the typography. Then Joe, we will talk about basically the results of the poll of Slack versus Gitter and the follow-up actions needed. And then Uli will raise a point, raise a concern about the Woodstrap 3 grid. How can we do a Woodstrap 4 version? Well, Uli would expand better. Are we missing any agenda item? Does anyone like to add any agenda item for today? Okay, since we can start. Okay, so starting with the... I have created an epic on the open source data tracker which contains all of the tasks and user stories basically related to the project under the scope of the SIG. Right now, I retroactively added the JS Builder one to this epic. Mostly, there's one user story for each UI item and then a few support ones such as this one which is a toolchain enhancement and another minor one which is renamed the root breadcrum. Maybe, yeah, this is just to show these issues to everybody. Maybe somebody would like to discuss whether, for example, this last one, the renaming the root breadcrum could be marked as beginner friendly or in case we want to give it priority or something. Yeah, just to share with everybody that this is here and I welcome everybody to take a look at it and please correct the any description or anything. Does anyone would anyone like to comment on this topic or say something about this? Okay, let's go ahead then. Next item. UI work progress. Okay, so basically this print... Since last meeting, we have created the header and breadcrumbs PR. There were lots of comments, we did some work addressing those. It's a work in progress but little work is left before we can go to a full review status. There's one thing, for example, that we saw that we will do a little increase to the scope of it. For example, we noticed that the footer is the same color as this breadcrumbs. So we are probably going to go ahead and also change the color of the footer because again it doesn't make much sense to have just this footer being of this color. It looks off. Moving the UI tool to them. Okay, does anyone like to comment on this before moving on? Okay, good. After on a separate PR, we are considering to enable right now. Right now, the UI, the new UI is toggled on Java property at Jenkins start time. So we are considering adding a runtime toggle probably in the admin panel to enable or disable the new UI. So we are considering it doing in the manage Jenkins section so that system administrators could enable the flag for the whole system. So this is what our plans are basically to make it a bit more usable than just a Java property. But we welcome any feedback on this topic. Does anyone have any comment on this? Any idea? What is the long goal objective there? Because if you look at JIRA, for example, they are proposing the old UI and the new UI. Currently, I'm still using the old UI because I can. The new UI is a crap for some of the things and I don't want to use it. So I still have the possibility to use the previous UI. Do you expect the same thing for Jenkins? Yeah, just to confirm again. So the new UI, the things that are enabled through the new UI for this deliverable, for the children and breadcrumbs, are just this logo section and header color. The rest of the layout and markup will be, are going to go ahead and be in the baseline, in the product baseline. So that's what's opt-in right now. So what is the boundary between the full rewamp innocence and just the breadcrumbs, the header and the breadcrumbs? Because at the moment you are using the system property to enable or disable only the header. But you expect in the next or next next PR to rewamp the full UI innocence or to force the CSS rewamp to everybody if I understand correctly. Yeah, so right now what we are going to, it's decided on a component per component basis. Right now it was decided in a previous meeting that we are only hiding the theming behind the feature frame because it was requested that Joe presented a full vision through full page mocks before considering changing the default theme of Jenkins. So that's why we keep the old school view. But it's mostly a theme, the old UI folder is just a theme. For example, look at it here. Then after this, it will be decided on a component per component basis. Basically, if we determine that changing a component is risky and it can break something, it will be hidden behind the feature flag. That's going to be the reasoning. Okay, just that I'm not seeing the advantage to have a real switch in the UI if it's just a quick CSS like this. Because the thing is that what you're adding to the UI, it's a bit difficult to remove afterwards due to the compatibility we want to keep and things like that. If you just fit your flag, you add the feature flag, you keep it for six months and then you remove it. There was no impact. Yeah, that's what we, I think everybody, we want to avoid having a two code bases in the long term. So that's why we are a bit proactively trying to make any and all changes final. It's just, I just think we just think it's a bit more usable for users to test the new UI without just going to the admin panel and toggle a checkbox on instead of having to go through all the steps rebuilding the Jenkins instance. And I don't think that toggle will be there. Correct me if I'm wrong Felix, but the intention isn't for that toggle to be there forever. Right, this would be, yeah, this, this, even though it's technically just CSS, but it's obviously a really big shift in the interface for Jenkins. So we want to have, we want to offer that versatility in the short and medium term to be able to switch it off or certain things that might be more questionable might be more breaking adjustments. And it won't be there forever is the intent. Okay, does anyone. Yes, well, because since this is my first meeting probably I'm missing things. It's intended that in the future. Any user, we will be able to choose their own theme or the, or is expected that everybody will see the same styles in the in the, when they, when you access the instance. The intent is not to have a variety of themes. Obviously there are solutions out there for, for applying themes to your Jenkins right now and those are widely loved. But the intent here is to redesign the aesthetics, do a visual refresh of Jenkins for everyone it will look the same essentially between those two options it's that it's that ladder one. It's one one redesign it's not the ability to choose from different themes that's not the goal. Did I answer a question maybe I misunderstood. Yes, no, but no, no, no, it's, no, it's because I, after Patrick's question. I was thinking about the possibility of having the check instead of in the manage Jenkins page in the configuration page for each user so each user can enter and decide if they, if they want one of the styles but if, if not intended. It is just a temporary solution just to make it easier to switch between one, the old styles and the new ones just make more, more sense to add the, the checking the manage Jenkins page as Felix proposed at the beginning. Yeah. And does anyone have any other thoughts on this. Okay. Good. Let's move ahead. So yeah, so basically as front, then we are going to try to add it in the manage Jenkins section. Okay. Full screen mocks. Now I will be sharing my screen to show the full screen mocks with Joe. So we won't run through them right now, but, or the first four slides there but what I can friend if you after this call I always share in the slugs, the SIG Slack channel. This, this deck whatever it looks like and from that call, and those three slides are always there and they give a little bit more context for the project at large, if you want to check those out. So yeah, digging into this one. So this is not from our previous meeting, well from our previous meeting but from also also from the one before that we had conversation around getting a better idea of the goal. Actually, can you go back one step, Felix, or one slide. One more please. Awesome. So we have a better idea of where this is going right so we started off with our first component and naturally the design process was a bit slow there just because this was our first, our first time figuring out how we can do this as a group. Last last meeting we took a look at the impact of these sorts of conversations and of this group, because the design actually changed really dramatically with everyone's input and it was way better off. Great. But we, as a group we've been wanting to see what could it look like you know instead of just looking at a component by component. So there's some pros and some cons to, to designing a full screen muck like this at this stage in the process. Essentially, the only danger for lack of a better word around that is that it can set the wrong, the wrong intention potentially right so we want to make it real clear with these mocks that. These are not set in stone. These designs are going to change and so that's what I'm kind of mentioning on the side there. The goal is to communicate a long term vision for the impact of this visual refresh the CSS phase, but these are going to change right. So just like with the, just like with the header bar, we encountered some technical limitations that impacted the design. I got feedback from all of you that impacted the design which is great. The same thing's going to happen for everything on the screen and the other screen will look at in a second so take it with a grain of salt. But this is what we were, we were wanting to see a couple of weeks back of what we can, we can be working toward. And one of the things that I wanted to do is that I can now use this over in my screen design software as a springboard for designing all these new components just like we had in the last meeting looked at all of the interactive states for the header bar, and all of the different considerations there for designing this one component. Now I have a solid starting place for designing all these other components table styles buttons, what this nav panel could look like. So in this regard, this is a really great exercise to, and this is to give an idea now we can go to the next slide looks. This is the same screen a little larger. And then if we go one more slide. This is what, you know, again, asterisk marks asterisk marks, take it take it all with a grain of salt but this is what we could achieve, you know, potentially with with a bill view for example. So here and obviously we keep our conversation pretty free from here you can interrupt me time, but does anyone have any questions or thoughts on on this stuff. Do you think it wouldn't better if we have some more user interaction in these pages. So, these pages are quite a static. So, what a lot of people ask me is why can't I rearrange these items on the screen for instance so this would be one of the valuable features, if these pages have a concept of dashboard thing where you can put in things and move things off and things like that. That would be really awesome. I'm not sure. But yeah, it does make perfect sense I totally agree. And frankly, taking a step back if if if this were the right phase of this this long term Jenkins project to think through that sort of thing. This this part, these smocks would look very different right in a perfect world and if timelines weren't weren't a factor. I would love to just reconsider a lot about the user experience here because you're right there's so much opportunity for improvement. That said, right now in the scope here is for these mocks is just this visual refresh right just this CSS phase, not changing functionality. That's it I mean that said that's something for the future and and yes I would love to make something like that possible. There's all sorts of great stuff we could dig into we're just not there yet. So for now it is purely aesthetic you're right. Would you be looking at things like refreshing the icons that some of those panels have in the middle. Yes, a little bit different to the rest of the page. Yeah, I think that's a that's a great point. So some that come back packaged within Jenkins would would definitely need to be revisited some that are contributed via plugins would you know I wouldn't have a very much ability to change those and that's okay too. But yes, in short. Yeah. So one example of how this will change. There you go. Cool. Maybe we can toggle back a slide. Obviously, you know we have our sig meetings, one every other week, but conversation is going in slack and soon get her will talk about that in a second. So anytime reach out and let's let's talk about these. And then if we go to the next section of the deck. So in our last meeting we took a look at a new color palette for the Jenkins UI something that is informing the design of individual components and that also inform the design of those full screen mocks. A lot like a lot like a lot of the content we look at this meeting will continue to evolve right it's not perfect yet it will change, but it was created with accessibility in mind for for high contrast UI, and the other item we look that was interactive states. So let's take a quick look at typographic hierarchy. These are the elements of interface design that come together and will inform all of these additional components that we kind of saw early representations of in those full screen mocks like table styles buttons nav, that sort of stuff. So the intended outcome with this is to establish a formal typographic higher hierarchy for the Jenkins UI that improves legibility, and that results in a more consistent experience throughout. So still being defined, and if we go. That's a bit, a bit more context. I know it can be hard to see on the screen but of course you'll have access to this deck after the call. And, you know, still still a work in progress as with these other items. The font selections that you see here are also not final. This is something we'll talk about in just a second, but we know that Jenkins has very important internationalization needs. And therefore, you know, we can't just go about picking picking fonts just based on on legibility alone that they have to have a certain degree of compatibility with other languages besides English for sure. So we'll talk about that in a second and that's actually it for this deck I think does anyone want to comment on this or have any questions. Just one comment about the heading. In general, we have some trouble when we have something like that that is separated into multiple tier, because often the age five is it in the same size or smaller than the regular text. And it seems to be the case here with 16 and I think 18 for the paragraph body. And in this case, the title or the sub sub sub title is smaller than the text inside the paragraph. So it's something that we have, for example, in Google Doc, it's the same kind of stuff. And if you're digging to be too much into the title level, it's a bit weird. So if we can increase a bit, the smaller title, it could be nice, at least from my point of view. I completely agree. Yeah, so that's something that needs to be fixed here right in no in no example should should a heading level be smaller than paragraph text. So in those full screen mocks. There was a case where that became useful. But yeah, that can't stay totally agree. And one thing I want to mention is what is currently done by a lot of plugin developers is they choose h1 h2 or h3. They choose one thing that they like. So I think it would make sense that everybody starts with h1 and then h2 and so on. But currently one does not select the semantics. Someone selects the font size and that's just a little bit strange, I think, so it makes sense that we define that if you have a new page, then you need to start with h1 and so on. Otherwise, it looks a little bit weird. What we can do really is we, what I always like to do in all my projects, one approach that I found works really well is, for example, I will style the h1 tag, but I will also create an h1 CSS class that I can apply everywhere with the same styles. So I think that's approach works really well. So if semantically somebody wants to put an h3 but they want it to look like an h1, they could use the h1 class. No, that's good. Other than that, my recommendation is to always use the headers, sorry, the heading elements, plain, no classes, just the proper margins, the proper default styles, because it's more homogeneous. But for that, you're right. We need to plug in all those needs and need to have available actual typographic classes. I want to be mindful of the time because I know we have other agenda items. Does anyone else have any thoughts or questions for now? Cool. I think we can probably move on if it looks. Sure. Back to the agenda. For recent typography, just a quick mention of something. Choosing phones. Joe mentioned that we are looking into choosing new phones. Right now we are going with Roboto. Why? Because it's well, basically it was being used also before in the project. It was. Felix, I think you cut out there. I'm not sure if it was just for me. Can you repeat that after Roboto? Sorry. So right now, we chose Roboto. It fits the material design theme. It also was the font already used in the Jenkins project. We are also aware that a huge part of the Jenkins use base, for example, is located in China. So what we are probably going to try is to get in touch with the Chinese localization to get collector feedback or whether there are good font fallbacks for Chinese characters or non-Latin alphabets. And if not, maybe they can recommend a font such as Noto, for example, which is pretty big or something. This is, yeah, this is just to mention that we are aware of this. Anyone want to put anyone like to comment on this? Just a quick question, perhaps a bit stupid. The right or left, left or right approach is not in the scope of this change for Arabic character and things like that. Are they currently supported in Jenkins? Yeah, concerning the global approach that we want to use here for the refresh of the UI, we are not considering changing the localization strategy in a sense. It's just for the font for the Chinese people that we are carrying a bit more than the other thing. Yeah, it is mostly to see that we don't choose a font that will break existing functionality. That's a good point, Farrak, maybe we can talk about that in future. Awesome. I think we have reached item number seven and I want to make sure we leave time for item number eight, so I'll be quick. In the last meeting, we talked about whether or not we should be having our discussions in Slack or some place that for some people is more central, which is get our lots of pros and cons, which I don't have to go through here, but one of the most important ones being that Slack is in the CDF organization, so it's unpaid and therefore we have to manually archive our valuable technical conversations. Another thing is that all the other SIGs are using Gitter and it makes more sense for more people, so I put a poll up in our Slack and it turns out that Gitter is the preference. I'll follow up for now in Slack after this call and we'll get it sorted, we'll get the group created. I'll be new to Gitter, so I'll figure it out and we'll get that going. But before the next meeting, I think we should be able to transition over and then all of our conversations should be more public too. And that's it for that one. So thanks everyone for voting in the poll. Okay, last item. So we have nine minutes by the way because I forgot to create the room with a proper Zoom account, but we can restart in another room if we run out of time. So Uli, can you please bring up at this point? Yeah, actually, this point is mostly a question if I should do something here, because I'm currently extracting the UI components that I'm using in the warnings plugin into separate UI modules. I've already wrote a mail about that and we had a discussion, we both on the poll request, where I noticed that Bootstrap 4 is not compatible with Bootstrap 3, which we are using in Jenkins. And I tried to get it fixed, but I came from one bug to the next bug because we are using not plain vanilla Bootstrap 3, we are using 24 columns. And so everything is breaking in my plugin if I use this old grid. So I'm wondering if it makes sense if I create a poll request for Jenkins Core that replaces this grid with a Bootstrap 4 version. So I'm not sure if I should make it, because UI changes in core are somewhat complicated because we have no tests, etc. So I just wanted to know if it makes sense, because we're currently maybe breaking other things as well within UI changes. So if we put it also in a poll request or if I should wait for it, so I just want to have some opinions here. Yeah, so yeah, the thing with the 24 column, I don't know why, why is that something I discovered earlier this week. It would make that change incompatible with basically everything. So that's an issue, definitely. That's something because I also looked that there are many plugins which use column 13, column 20. Okay. So that would break. Also, I think replacing the column, the grid system is not viable. We could deprecate it, but it's not viable. My recommendation here would be to create a new grid, maybe a new grid file, and I would name space it. It's rather easy. For example, you will have Jenkins dot call dot Excel dot one something like that Jenkins dot Jenkins dash role Jenkins dash container. That actually by the way that should we should be doing plugins should be named spacing there. Because Jenkins core should name space, its own, its base components. So really what I'm going to try to do is I'm going to try to bootstrap bootstrap provide several mixes to generate a grid, right, several such utilities to generate a grid. With little modification. You could create custom mixes based on those to create a name space grid. So please give me a few days and I will try to get a quick sus mixing a quick success code that will generate a great bootstrap like grid but with namespace classes. Okay. That's fine. Thanks. Just a question concerning warning and G it's for full page layout or for we just that are integrated into the rest of the UI of Jenkins. Actually, it's the last page of the warnings plugin that means if you're leaving the build information page you can open plug in details and on this page I'm using bootstrap for. So you're completely separated from the Jenkins UI at that point. I don't have so can you please repeat sorry. So when you opened the last page you're separated from the rest of the UI. And no I'm not separated because I'm also using the head up all the footer and the links on the left side so it's a little bit more complicated. Okay. Because if you had a completely independent page. Yeah, we can just say we don't care and that's all but yeah. But I don't want to have it this is this way I want to look it should look like yeah Jenkins. Okay. Okay. Any other questions here. I will try to do my best I tried to to make the base layout for the ones and you're planning to not break as much as possible. I left the base styles and the lay out commons in the repo not deleted so that you're planning the plugin can make use of those files. But if you do do try the new changes with the warnings and your plugin and raise any issue and I will do my best to solve it if possible. Okay. Okay. Okay. Okay. Does anyone want to say something else or bring something to attention. Yes, we're going to get recurring meeting set up so that we don't have to have last minute links. Sorry about that. Definitely we forgot to apologize and yeah something that's on us our part we should have gave these a few days notice. Definitely. We apologize for that. But, but that's it for my end. And I'm watching the clock here. Anyone have any other final notes and I'll follow up and select today as usual with links and the getter item. Cool. Okay. Thank you all. Thank you everybody and next meeting will be two weeks from now. So which day will it be 2021. Thanks everyone. Okay. Thanks everyone. Thank you. Bye.