GitLab Working Group: Merge Request Report Widgets, 16 Dec 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: 2021-12-16 Working Group: Merge Request Report Widgets

Description

Thirteenth (yikes! knock on wood) weekly meeting of the WG.

Agenda: https://docs.google.com/document/d/1bcch8UUkwmgEHFolTWDrQFJtUiiXlv_yQFAGwSSDSUE/edit

A

Hello, everyone welcome to. uh Oh, I think it's the 13th uh bad luck um right. The 13th weekly call for the merge request report, widgets working group um I'll start right away uh sort of an announcement thanks scott for preparing our example, mr uh and for anyone who might not have been here last week, the scott added it to the header of the agenda document. So, if you ever forget it go there and find it or just bookmark it or make it your homepage. I don't I don't mind um the second part.

A

I want to make sure that everybody aware that the level two content support has been merged, so um the way that the texts are added are much more um consistent with what we discussed. So basically, the consuming widgets don't have to no longer have the burden of handling utility classes. They can just abide to the supported variations of the text that we support, and that makes for very much consistent and also we'll be able to update the utility classes on a central location instead of having to go to all the consuming widgets.

A

So this is a very good step forward and, as an improvement already discussed, thomas randolph was was addressing one of the bugs that gina had created a while ago, um he's going to be even improving it further to have a much more structured response so that we don't have to do like a text with a break with a line break element in the middle, so we'll be much more resilient in that perspective, so iteration narration. So that's good.

A

uh Yeah. Moving on to discussion items gina.

B

I had a couple things that um when we were looking at the new, mr, that scott created, you can see all of the widgets there all together. So um some of the another product designer had come to that and found some things. I wanted to point out. um I don't my my question is I listed all these different issues that came from that conversation with the other designer, but I'm not sure if this work is considered.

B

Part of the working group like if this should be implemented for all for the core component or if it's just specific to certain widgets, so I'm bringing it up and if you want, I can just go through each one. Whatever would be most helpful.

A

um Yeah, I so since we don't, since we have those two efforts, one to add the core support. The other is for the consuming widgets that scott and peyton and looking into, I feel like it's worthwhile discussing, um particularly if there's any changes that needed to be done centrally.

A

It will some people one of the people will take and if it's the further consuming than other people will take them. So maybe just briefly talk through them to make sure that we understand them.

B

Sure, okay um and I'll I'll share my screen. So it's a little bit easier.

B

So this first one about status, icons is really just in the case that oops sorry in the case that we have um something that has no degraded metrics, we're showing this like warning, icon still and I'm not sure, if that's the same case for other widgets, because we only have status checks showing here. But in this case we could just show this success icon. So I wasn't again wasn't sure if this was maybe just for browser and load performance or if it was affecting more widgets.

B

B

This is the second one, uh so whenever we have metric breakdown, I'm calling this thing a metric breakdown, but I think it's level, one subtext is actually what it's called. Whenever we have metrics that have a count of zero, we don't have to show those in the breakdown I'd. I also am not sure again if this is for all widgets or not so another thing to keep in mind and then the last.

A

Gina question on that. Just so I understand so, if there's a zero zero degradation, um we don't display it at all. We would just display five same and two improved.

B

Yeah, you only display five same and two improved, only the ones that have like a count to it. Basically,.

A

Gotcha, okay, make sense.

B

Yeah, um the last one is actually I I'm assuming that this will have to be brought in per widget, but the text that shows here, for example, like um the level one text. It's not always consistent, like you, can see here, test, metrics, colon, seven changes and then test metrics detected four changes.

B

I was trying to audit the different wordings that we use today and there's just specific ones that need to be updated. So I I'm assuming that that is like you have to pull that in per widget to be able to fix it.

A

This is really good stuff. um I might, I might ping amy qualls she's, our technical writer um and she's great, at coming up with uh documentation for guidance, so there might be an opportunity there for updating the documentation or something to help the future authors of widgets.

A

You know how to come up with that copy, but this this uh work is is great, so um you're right it would have to be updated at each one of the widgets, but uh there's probably some guidance lessons that we can take out of here of this very early stage of the of these widgets. So I will do that.

A

I it's not how I write my name and okay, I will think or technical writer. Okay, this is good stuff. I feel like all of these fallen and the consuming widgets um scott would be just. uh Would this come up in prioritization or how do we? How do we find someone to handle these.

A

C

Sorry, classic looking at a different screen, I couldn't uh see myself there. We go weird, um all right, yeah we can. If the issues are created, we can prioritize them accordingly.

C

um I don't know how high of priority they are, uh but we can work with ux to to figure out, because we only have one for an engineer right now, so it's just choosing very carefully which issues we take on.

A

Absolutely it's quite understandable and given the milestone that we're currently facing it, it makes sense. So I would say that if they were at the core level, we would take them as a higher priority uh since at the at the consuming level, it's mostly like taking the lessons that we can take to guide the future development.

A

I see that gen agrees um so yeah scott, whenever you have capacity for it. um That's great um all right. This is great stuff gina. Thank you so much for this, and I think uh pedro really has a great iphone. It was better right that caught this yeah.

C

A

A great eye for this, so uh I guess we'll just nag him every now and again to double check our our work. um But what makes me really happy to see is that we're not even like at the end of the support and we're already trimming the edges, if that makes sense right and that's remarkable to see so, thank you gina. Thank you pedro for for highlighting this. This is great uh tim.

D

Yeah, it's me. If you still remember me my face and myself we do. We do. We missed you couple of very full weeks, especially at the time with to the at some points, free stand-ups, on a daily basis, exactly at those time frames medium fund. We are currently reducing standups, which is a good sign. So I had time to join quite easily one. The first and biggest thing I wanted to leave here- is seeing it now in action and playing with it and clicking on it and seeing it for real is yeah.

D

It's great progress, thanks everybody and thanks for the great work this is just this is such an improvement. It is visible right away compared to what we have right now. um Yeah just wanted to. Let everyone know about my first impression here nothing to discuss. Then something came to my mind. So I was premature with writing nothing to discuss, so is it planned to unfold and click so clicking anywhere on a on a bar, because right now it felt really heavy to okay. Where is that the unfold button move over et cetera?

D

So is that anywhere playing.

A

Do you know anything if that's been discussed on the ux side.

B

I'm not sure I'd have to I'd have to look. I know that we're um tracking the amount of times that that thing is clicked at least so. That may give us insight into if we need to make the area larger I'll I'll check, though I'll get with some other um uxers and ask them.

A

Thanks tuna uh tim, I will just like plus one that I think we've in the past. That was the first thing I noticed as well, um so I I definitely feel validated so thanks for wasting it. um The one thing that I that I thought at the time is that we can't just make the whole thing a link, because those actions might have multiple, but we can totally default it, and we did that for the repository file browser where we default the whole row, but you can have multiple links there.

A

So there's definitely some challenges there for the market, but it's only doable for if we have javascript involved so keen to implement it I'll uh I'll prioritize that if the ux chooses here's the benefit, it can be done at the core level. So all the consuming widgets will immediately benefit from it, which is great to see.

D

And I totally it doesn't put to be a link or anything it might be even totally fine, if not even changing the mouse curves and just having it on click handle, because I'm also like a person yeah. I need to find absolutely too often and.

D

One thing that, um because this is something I'm thinking about- and maybe targeting this also in the next quarter- is we have now real time. As you know, we have issues and we have the possibility to do real-time updates for websockets, so any data that is in time change can update, which means that we also need and might think I need to think about new ui patterns of updating data to make it obvious.

D

Okay, there is something that has just changed and not just like, and you are like something moved uh so that we think about also that and maybe incorporate, I think, with pipelines, especially this might be a nice and interesting topic, because if we are able to put web sockets in there and we can really show and count up, for example, uh the number of tests that are done uh might be a different pattern for okay. This has changed from green or from running to red, maybe or to green.

D

So this might be a different pattern, so I think the earlier we incorporate something into a complete new pattern: the better.

B

Where are you speaking to both like the loading, the loading states that we would have, and maybe a state to show that stuff has actually updated? Does that make sense.

D

So that that is really now even further, because this is now for issues we already have it. So we have then a constant connection to the server and the server can then basically tell the page: hey the signee has just changed and it pops up. There is not even we are loading the initial data, but we are also listening to any change in the background. So it would be even without a loading thing, because we have a constant websockets connection to the server.

B

A

So um this the topic of uh not real time, we discussed it as the polling, but real time would be even better. um There's two things there. One is that I don't think at the time. I think the consensus.

A

What was that we wouldn't have a specific polling mechanism at the core to start off with probably the first widget to need it would implement it and then eventually would absorb it into the core if it makes sense to standardize it, especially because of that thing like we can port the polling code, because then we don't have the real-time infrastructure yet, but then we'll devolve it into the real time uh with websockets and stuff.

A

The ui pattern is something that we can totally uh support at the core level, because right now I think we would probably either replace the whole thing uh or not at all. So we would have some way have to have some ways of diffing or something like that. So we definitely need to come up with a better way of doing those updates. uh I'm going to create an issue for for discussion because I was looking through the epic and I don't see any issue about polling or real time.

A

uh We have had discussions here and there about oh wait. We do have it support polling, so I will put the issue in the agenda and we can discuss it a little bit further. I don't feel already there scott already. So let's take the discussion into that issue. uh Updating with this particular aspect of having an uh ui way of highlighting updates.

A

That was hard to say.

D

Thanks phil, we.

A

D

We have real time by now, so realtime is activated.com good.

C

D

Issue is using it already, I'm currently looking for the slack threat, even one of our community contributors who is working on service desk stuff. Is he loves that stuff so he's building it now to anything that he finds awesome.

C

And he's so excited.

D

He's always pushing videos, that's why I'm looking for it. I'm.

A

Gonna change the title to say real time so that he finds it and builds it.

D

Yeah from the tickets.

A

Good stuff uh yeah, what I meant was that so correct. If I'm wrong, we do have support for the real time, but we still have to have some back-end implementation of it right.

D

Yes, but it's fairly easy: if you have graphql as a basis, then you can go.

A

To subscriptions.

D

Get yeah exactly have subscriptions pretty pretty easy.

A

That's good news yep. um It would be nice to.

C

See a lot of these widgets I have our dependents are still dependent on rest. uh End points, so I don't know if we can easily switch them over.

A

But that would be the reason right. Scott like that would be great yeah.

A

But it's important to understand. Like the the nature of these widgets, I feel like you, you have a good point like the ci would probably be the best example, but I don't think the ci part of the widget is included on the report which it's it's a separate part. It's where we call the merge widget. So that's separate part of this infrastructure that it's built on their own.

A

We would totally respect the ui pattern that is devised by this working group, so whatever the whatever the ux framework decides to be the update, we'll respect that on the other part. But since this is the report widgets the ci would be covered, the other ones. Scott. Do you run multiple checks on on like browser performance and load performance? So that's just once that doesn't update yeah.

C

No, I don't think it updates, so we just uh there's no pulling on those on the.

A

C

The current ones they probably should update when the pipeline completes, but I don't think there's any implementation of that.

A

Then that would be a moment to leverage real time if we could. But uh let's uh let's discuss that on that issue and bring that forward, um it's a great, a great topic. um Anything else tim.

D

I posted uh link slack thread where lead ticket is showing how it's currently done on the issue side, where he is incorporating that on service desk, for example, there it's just switches without any, I think so we might simply think about it. I know that that that I used a react library long time ago, where you were able to have like a pattern where you could say: okay, I'm changing this value with with um an animation system, so that there was a very, very basic behavior on it. That simply said.

D

Okay, I'm not changing this value immediately. I will wait for 300 milliseconds, because I'm injecting a css animation class which fades the thing else for 300 milliseconds. I change the value I fade it in again and then you have had a very easy way to simply say like um uh in view. How are they called? I just I'm, using forgetting all the terms.

C

D

We have those those petals on top that we can set um and those behaviors and if I think we might be able to do the same thing so that we say okay, this label, if a value is changed after first load, then we can apply an animation pattern whatever. It is, for example, or a flash or a color change or flying stars or a rainbow. So.

A

Yeah I, like the color rainbow that'll, be nice um good. This is good stuff, um any any other topics we're at the end of the agenda. Anything else you want to discuss.

A

All right, then, I'm guessing next week will probably be. Should we skip the next calls um 23rd, I won't be here. uh Should we skip? What do you think? Should we still take them? If we have any, should we just skip them.

C

You can just I'm not I'm not going to be here either.

D

Yeah and I'm alone, so I will be still here.

A

Yeah, so even if you are, it will be very lonely experience so we'll skip both of the next weeks and we'll see each other in the new year. Thank you. Everyone for the contributions like like tim, said it is pretty remarkable to start seeing this thing come into fruition and we're going to be kicking it off in the new year at high speeds. So thanks everyone and have a wonderful holidays and have a wonderful entry in the new year.

D

You too, take care everybody. Thank you. Bye,.