Jenkins User Experience Special Interest Group, 1 Apr 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Jenkins UX SIG Meeting - 1 April 2020

Description

Romén showed his work on the alert banners. He identified several types and styled them using bootstrap colors and material-ui icons.

Oleg shared the new roadmap definitions and gave some proposals how to represent the UI revamp in the roadmap.

A

I'm gonna go ahead, trim the screen.

A

All right, can you all see that yeah perfect, so we have a very brief agenda for today.

A

We're gonna take a look. Actually, let's go through a point-by-point like we usually do, and does anyone have anything that they'd I think we all know each other in this particular group small group this week? Does anyone have anything they'd like to add to the agenda before we dig in.

A

All right no worries, then the first time we'll look at it's going to be a relatively brief design, deck looking at some button explorations and interactive States and then Roman. You want to talk about your exploration on the alert banner styles.

A

So let's take a look at this deck first.

A

And please, you know, let me know if actually I'll go ahead and just make this fullscreen here.

A

We're gonna skip past since I think everyone on this call has seen this the standard slides with the regular information and we're going to start here so essentially something that I surfaced. A couple weeks back to the previous big meeting was that with our April goals.

A

One of those elements that we wanted to tackle before the end of April was button Styles throughout the Jenkins interface and that the first step in doing that was to conduct sort of a style audit to see what existed currently throughout Jenkins, and then what functionalities were tied to those different button, styles kind of bring them all together and you know for lack of a better expression, sort of audit them, and it's really important to be able to see where we're at now and what those buttons all do right now in order to be able to move forward and made me introduce some some more for some more formality to it here.

A

So this is what we're looking at here is: is one of the result so that exercise I could have put a whole bunch more screenshots up of things we collected and there will be some of those on one of these next slides, but I'm not super necessary, and this is what it has boiled down to and I should point out. You know like with most of these meetings. What we're looking at is a work in progress. This is subject to change and we can talk about it.

A

This is why we're talking about it here right for feedback and that sort of thing, so this is not set in stone. Necessarily there may be things that I've missed. Certainly there may be things that we haven't thought about yet so, with that said, have I done.

A

We have identified three different categories of button and we'll take a look at those in just a second and and those examples, but those are what we're calling standard, expandable and Submission buttons, and within those three categories, we've identified the need for four distinct button: styles, primary secondary warding and transparent.

A

Now, for each of these styles, of course, there will be multiple different interactive states, such as the enabled state disable hover, States oops. My mouse is misbehaving for each of these styles. Now this gets a bit, perhaps a little bit unnecessarily complex looking at it, so we will look at it and graphically just in just a moment, but first I wanted to review the idea behind these Styles.

A

So the primary style is the most high emphasis style button right, it's what we would think of, as usually those blue buttons throughout the or by right now, but it's not the default style, because in most cases we don't want more than one of those primary buttons on screen, so our default of style would be actually that's secondary. That has a slightly less intense design, so we're for slightly lighter emphasis. Haley welcome, but it's a lot more common throughout the universe. This notion of a transparent style is something new here.

A

It's very low emphasis: hey there, it's very low emphasis and it's essentially it has attractive states that resemble a button, but it's just primarily in its default state appears it's text. However, it not the same thing is a text to link again we'll look at this in just a second, the final style here being warning. This is high emphasis and it's very similar to primary.

A

However, it merits a distinct style because we don't want to start introducing a whole bunch of different variations and edge faces to the primary style, which should really be just one color from the palette across the board. So that's why warning is a distinct one.

A

So, let's back up for just a second and look at you know, this is just some screenshots essentially, but this is a what we're thinking of when we describe standard buttons throughout the interface. So these can include these primary or secondary styles. But this is that standard category right and this is the current iteration, the first iteration of the redesigned buttons. So we have four rows here for each of those four styles, the primary secondary the transparent and the warning.

A

Again, as I said, you know these being the most common. These are the most common throughout the Jenkins interface, and the idea here is that they exhibit really standard button behavior. So they have really standard typical, interactive States right, enabled disabled hover state, a focused state and a down state.

A

Now we think- and again this is just the first pass, but we think that this variety of styles and these various interactive States should cover all the use cases we've identified for this standard button category throughout Jenkins. Anyone have any thoughts or questions on that before we keep going.

B

Just a question about the intent between the two disabled State for the primary and the warning: they are not very different. Do you expect that? Oh, it's just it's disabled, so we do not care. Actually, it's.

A

A good question you know: I saw that it's. It would be a little bit abnormal to to have a distinct disabled state when really it's just a color difference between these two they're, both high emphasis but I- think that this, the fact that it was a warning style to begin with is certainly lost here.

A

So I think that merits a little bit more exploration like you're, saying yeah, because because, if it's disabled, for whatever reason the user does lose, that that insight into the fact that it was a high-stakes element to begin with right that it was a warning of some type, that's completely lost in the disabled State. We don't want that so great great question. Let me look into that and.

B

Just a note of feedback there you are using blue and Nevada for the choral differentiation between the primary in the warning. We have some current blind user. Do you think it's sufficient to differentiate the two.

A

So what I've done so far for testing is I've tested the the text in various weights against the colors and that works, but let me go ahead and also do that for sure text. The excuse me run these two buttons side by side through the various filters. I have a tool that allows me to do that really easily and and I'll double check, but I believe and, of course, these colors are all coming from that palette. We looked at a few weeks ago.

A

I believe that that shouldn't be an issue, but I'm gonna go back to double-check. That's the point. Thank you for sure.

C

I, have a question about industry. Mark also had a question first, okay, so my question is just clarification. So are these buttons only applicable to the Refresh UI, or are we also planning to apply them to the older standard, UI objective.

A

So the idea here is sort of like with everything that comes to these meetings right is that it would be implemented into the current interface and that we're updating it piece by piece. So these would become live at some point in the near future.

A

You know there's no PR yet, but because this is just the first iteration, but these would become live inside the current interface, okay, yeah and in fact we started looking at it inside of the current UI, and that already revealed some inconsistencies right, like we've already identified a couple places where these need to be improved as straightforward a design as they are so that they don't clash too much with the current UI. So these will be improved as we go here. Yeah.

D

Say these women we find out they break applying or something we will put them as a part of a new uri. But our intention. We always aim for it to integrate it into the mainline able by default.

A

Awesome and then here we have a second variation here, so everything about this next screen is the same, except that these buttons have a paired on with them. So we have some more work to do around defining how we treat icons in as part of this project right. We have a lot more investigation to do there frankly, but one thing we do know is that we're leaning very heavily on the material design library. So these states are the exact same.

A

These styles are the exact same, but we want to be able to incorporate the option of having a paired icon using material again because excuse me again, because material has widely recognized widely standardized iconography to improve recognizability and understand ability of what's going on in the interface.

D

I need anything anything there. Any thoughts, yeah, there's something I want to mention here. So here's a jacket, the objective is to show how we would style by default icons within buttons. It's not like. We are going to say, okay, this button with this class will have this like, and this icon automatically by default. No, if would you put an icon, a certain class within an icon? It's going to look like this okay, but you still need money and put the icon intentionally.

A

Great point: it's.

B

A

B

Proposing that capability, I will just suggest you that you are also creating someone guide but which icon to use to which usage to keep some consistency across the application, because, if you just let the maintainer or developer, choose any icon, they want in the set. You will have a lot of different things that are not good. In essence, yeah.

D

But I think that's a composition for the icon, for when we tackle and iconography and first we want to get through the buttons and the sidebar, because iconography is going to be a really complicated task and we included these definitions and everything so I want to I.

D

Yeah I don't want us to be blocked now.

A

D

For that, for something to come after yeah.

A

We definitely need to provide that those guidelines and write up its system, but yes, you're, absolutely right. I know work on that, just not not next, but very soon, because you're right having that those usage guidelines standardized goes a very long way.

E

One question: do you really need guidance, or do you just in the template, library or whatever supplied by Jenkins, so that users can just get these controls.

A

um I think it I think you can go. Okay, that's fine! Both.

D

Ideally, what we would have his component I storybook, or something up of documentation, place for the UI for UI widgets, like what the turf has like well any other tools house. Let's say that flavor intensive so and that's something we will not be having any time soon. So at least.

A

D

Want a place where we can say you want to put icons. Do it like this? You want to see what icons, what icons are available. Look at this page from appear other than that I really don't know it will happen. There is much we can do with it all of the alternatives to document these processes take big time.

D

Basically, that's an announcer by the way, but yeah, that's not really I, know that's unknown answer or look what it's really complicated to find the venue how to document something when we don't have a framework document, a component library itself.

E

So we will have Jerry talks. Maybe it's not an ideal approach, but detectives has automatic generation for the communication. So if you take a look at Jenkins right now, you basically get some documentation. Obviously it's not perfect for front-end, because it's basically a Java doc, like think yeah, so we'll provide some documentation and yeah. We also had the drinkers design language but Jenkins design language documentation would need a minor maintenance which is not something I would wear ties. Yeah.

D

Yeah, to be honest for what it's worth all worthy options to display a component library are manual. Basically, okay, you crazy ass items. You have you select a spool you'd need to have money on the house and that's that's sort of unavoidable I.

F

Have one question: what is about the size? Are we intending to create buttons only of the same width, or is this still up to the users, because I think currently, our layout is totally strange because some buttons are 25 pixels, some buttons are 200 pixels. So from my perspective, it would make sense that we also define a default size of each button. I.

A

Think that's defining a default and then allowing the flexibility is probably the right path forward. We haven't really answered that yet, but do you have any more thoughts on that I? Do.

D

um What I'm doing doing my POC implementations is removing all button styles from from Yahoo UI. Oh I, miss tiling the buttons through the Jihu UI classes, but I'm removing all existing button styles, so that they are a clean slate and, for example, there are two plication, some certain area widgets, for example, buttons restyle. um He terrorists around repeated elements at restyled on Java forms, I'm remain trying to remove all of that and make them playing basically um make them the same everywhere.

D

That's said we will break some display, so I can so know. When the back reports coming, I will re-enable the specific styles for specific widgets, but that's in the report for when the reports come.

A

Alright, something that just popped into my head here is I'm looking at the screen a lot of these colors for some of these states that we see between these two screens are very light and close to white, and that's because they don't always need to stand up against their background if they have a stroke. But the reason I point that out is because, depending on your particular monitor configuration as we're looking at these, the styles can look very different.

A

So you know we provide these decks and you can always pull this up on a different device or look at it after the call, because I think, even as we're looking at things together over zoom, they can be translated differently. So I thought I'd just point that out and you can always check these out after the meeting all right. That is about it for this deck. The next styles that I'll be sharing with you in a future meeting will be for this category of expandable buttons.

A

I understand that name might not be perfect and that's okay, but that's sort of this, this grouping of buttons, who excuse me of buttons that have this functionality, where you can drop down and select something from an item list and that third category being Submission buttons things still thinking about the existence of this category. This might not merit its own thing. Perhaps they should just be primary secondary buttons on the bottom of a field and that's okay, too, so doing a little more investigation there.

A

But these are for the next cells that we'll look at together. It's great yeah just to.

B

Comment on the submission button, correct me if I'm, wrong or leg, but I, think this button are present only on the job creation page and no errors.

B

So perhaps if you want to just give way to beat that page or to keep that aside for the moment, it could be potentially very valid to not spend you a resource on things that will be changed after all. So.

E

Regarding submit and apply buttons, you can use them in any form because it's a part of formal main space in JD Turks, so you can create custom form customer configuration and there are examples of such kind in Jenkins a way you would use basically the same buttons.

E

Okay, good. Also, a system configuration and job configuration I believe they use the same buttons. Small.

A

D

A

Six sorry I.

D

Think I want to mention is that I chose you. You said we will probably be updating these three style guidelines really soon I mean please, but we will not be sharing them. I, don't think we will be discussing ganging a futuristic medium because we want to move ahead with the buttons. So probably you can expect a draft EPR before Monday or Tuesday.

D

The code is the code is a bit complex, but at least we want to create the PR and have it out there, because the button is something that should it's really different from looking at the designs and actually playing with them. So hopefully we will be. The initial PR will contain at least here's the normal buttons and the drop-down styles and the submission patterns for you. If you want to call them like in that way, we'll maybe may come later, but yeah so good.

A

D

That's right, Monday or Tuesday- maybe make me in the weekend. If I have time.

E

One question I: do want modify the jelly. We do want to touch a JavaScript layouts, nothing.

D

Yes, I'm just I'm just changing the styles on the yahoo UI classes, I'm, not even.

E

D

New classes, new CSS, okay,.

E

D

Would like to, but it's useless, because all the buttons right now the plan is everything used, a dot. Give you a Yui bottom I haven't want to complicate it. I just wanted to.

E

Okay, my name is me Soho, my.

D

E

Them get update, everybody.

D

E

A

Awesome and then I think these other items edit here are not actually correct me if I'm wrong, not agenda items, just sort of notes from from the discussion, so I'll move them down here later. If that's right, Oh, nobody.

D

Was taking me need them this.

A

Is a brief meeting, but we can add stuff there using the recording. So so is that right, Oh, like? Are we good to move on to item number four or was there something else to talk about there? No.

E

I think I was just putting some notes during a discussion. I just joined but I start putting down so awesome.

A

So I think the next thing for today's call is Roman. You wanna share, um so I'll go ahead. Stop sharing my screen.

C

Alright I think someone has to give me permission to share or do I have that already.

D

You should be able to share already oh yeah.

C

Green button here, it's okay, okay, sharing my desktop here. Can you see my screen alright? So this? This? Is the this pull request on improving the alerts that we have so there was this ticket reporting some weird behaviors in our existing alerts. So we had this Saturday so-called success honored. That appears when you apply changes to an existing job. For instance, you will see this.

C

She was broken in the sense that it seems that the Napper had changed its height, but they did not the alert, hadn't and also not is like at the same time, this was maybe using like a beach strange, colors and the icon was definitely like was a small size, PNG icon that didn't scale very well, and the same thing happened to in other cases like in this particular case, which you are copying a token. You would get these alert.

C

Also looking weird so I was doing some research and found there's several. There are at least four alert states, so the green one for success, the default one used for copy, but broadly stuff as well, and then we had warning and errors. So initially what I was doing was looking at bootstrap alerts, the colors they had it be I linked it here, so I can show so was taking the DS as kind of sort of standards applied them. There was some discussion in the PR and I think we provided these good resource.

C

This idea of the react material material packing it was kind of similar to the bootstrap, but included icons with different colors. That I think make alert more visible, noticeable and nicer as well. So I went ahead and apply those changes. So these are the resulting alerts.

C

The successful one, the default, which is used for copying, that use case that I showed before warming. An error I used the material icons that we had already included in Jenkins Jenkins already had some material icons in the source code, so I just reuse, the ones that were already there, yes to the ones that were more similar to the ones that I saw in the example of the material we had material plan.

C

Apart from from that UI visible changes, a discussion with Felix we were using maybe can show that quickly from the files changed. So basically, all this behavior it was embedded in a J's file, had some behavior that was using the who UI animations. So everything was in the in the ES file, the JavaScript file. So all the colors were right there, so it was kind of not very nice to maintain so fell.

C

Exciting was to move them to CSS classes, which I did now so I include these CSS classes for the different notifications and also same thing for for the animations right. So then, all we are doing in the J's file is each state has a class also the default class and the icon, and then we said, remove or add the class accordingly, when hiding on, shall we so just to show this running? I have I have Jenkins running here, and now you can click apply.

C

It will show the new other with steam, with the fight trading will fade out effect very similar to the one we had now to be shorter in the fading and it definitely matches the height and I think the colors are much nicer than the ones we had. The the icon is SVG switch scales, so I think it's I'm quite happy with the result and that's why I wanted to show this small change, but I think every little helps so hope.

A

C

A

Think it's a dramatic improvement from it. I think it's awesome and thank you for working with us happy to help.

C

And contribute and trying to find it page again just to stop sharing my screen, but I kind of find it yeah Jim hi did I assumed.

E

I'd apply there thanks a lot for doing that. You have something like two months before the next year's baseline cut off if he delivered her many such features in there, but if we can make a really big difference in the next I'll see the baseline.

E

The recent one, which was shipped last week is also also contains some improvements: special thanks to Felix for formed changes, because the dinkus looks really different. Now, when you deep-diving different yeah, such minor changes really improve the situation. World.

C

And actually I had a question, not sure if this is what you mention are like, so them LTS Jenkins. So how do we? How are we, including because in the past I mean these PR goes to LTS? Is that still the thing or are now we so.

E

Now there is a, but porting process is documented on jenkins website. I can show you some examples if you want just a second.

G

I'll share my screen. Well, so so romantist for clarity. I, don't think you want to back port this change! I assume you want to go forward in the next LTS and it will naturally be included in the next LPS just naturally, so no need for an LTS candidate, LTS Canada's used for things that we port backwards to a release.

C

That has occurred previously.

G

C

Okay, wasn't sure about there. Okay, appreciate aggregation.

E

Yes, so basically, we bug fixes and improvements. Well, small. The improvements could be a theoretical but ported, but generally we target the next baselines. So right now we week second week five stage, so we just released dot 1 LCS last week and we are rolling towards a schedule.

E

So you can see that it will be decision making in five weeks yeah we shifted to the dates, so we will be choosing the next LCS based on in five weeks commonly it would have been in seven weeks but taken there be some very issues we made it respective and adjusted for that. So yep five few weeks is not delivered some things here. There.

E

Kim doesn't answer the question yep.

C

E

You mm-hmm awesome.

A

Thank you again remember that work that was actually the last output, so this being added oh yeah,.

E

I just added one quick item, so if I'm different, I'm sure yeah, you might have already seen that when I start to change screen, so this dashboard is exactly why you don't let me work on UI, but yeah, all sort of shorts. We are working on making a public road map, so basically a community driven way to highlight them all. The stories which are critical to the junk is coming Indian and right now we have a story for you: I ux3 mom there.

E

Basically, it represents what happens and user experience. Special interest group and I wanted to get your feedback, but it's enough or whether we could add more cans. So, for example, if you go to the documentation which is linked from here with the development version yeah so here, basically there are two milestones, so one is CSS develop. Another one is follow the work.

E

So, for example, we could have split it two times in the roadmap or we could add more items, every interest from other sig numbers, but it really needs a feedback from those who work on this area. So right now, this roadmap is not complete. We are just working on that, but if you see something which could be edit, please let me know.

D

You may be right, you don't have a point saying that it may make sense to separate just pure styling stuff from from more complex changes.

D

We are still discussing within classes. What to propose to go next after styling probably will include the other styling things we we'll keep doing styling rolling, but we are also looking at more deep changes. Maybe it will make sense to create another entry for those. If you also want to create an entry, for example, maybe it can be good to put tomorrow to give more visibility to the just just sort of changes for forms. They're, really big I think it's great to call.

E

D

Those because it will be a huge change for the Jenkins experience, just changing.

F

D

F

D

Those are relevant enough.

C

Yeah Mike my two cents, where, along those lines, that would probably be good to have some more granular items so that we people feel that we are actually delivering stuff, because if we have up to be over a task, maybe it takes a very long time to be completed. You have wrinkles is what Alex mentioned like changing forms from tables to date, maybe that to be something that we can mention. Maybe other staff as well yeah.

E

So idea for this roadmap is to hinge stories on the top level, because there is a lot of initiatives happening in different areas and yeah. This list is not complete. It will look completely different by the release. Sorry about that, but yeah, for example, of how it works there is, you know, and, for example, heat to York's ongoing projects. So if somebody is willing to update this page to highlight a key statistic once by Josh, maybe a story's only is working on in terms of JavaScript libraries etc. We can point to that.

E

So visitors can go here and discover more details, so you can reference delicious, epics or github wishes. Basically, whatever you want, it's just a gyro.

E

Just think about what you would like tried, whether it's related to user experience or not, but they will hope the day. In couple of months we will publish a most final version in which we can Oh jinkies users. Oh.

A

A

Anybody else have anything for this meeting.

A

All right and I will see you all in two weeks and I expect everyone are very creative, zoom backgrounds. By that point, I will success and.

D

I hope everybody will have better than this, give it up for the buttons and maybe the.

E

D

Tiger, who knows yes,.

A

D

A

Right thanks. Everyone thank.

D

C

D