GitLab CI/CD UX Team Design Reviews, 21 Nov 2019

Previous Meeting

⏯

youtube image

►

From YouTube: CI/CD UX Team Design Review | 21 November 2019

Description

The first Design Review session of CI/CD UX Team.

- Juan J. Ramirez | 02:01
Show a graph for code coverage changes over time for a project

- Iain Camacho | 36:48
Package Detail View to include GitLab Metadata

A

All right so welcome to our first. Yes, it is under view. This is a pretty exciting. I was actually really looking forward for design reviews to be a little bit smaller and cozier for us to be feeling maybe a little bit more yeah, confident and like you know like getting a little bit of of the design feedback, rather than just showing them the work which I will have, which I think we'll have plenty of time today for because I think I scheduled this like 450 45 minutes, we will see how much we will need.

A

I also want to say that yeah. This is obviously for us, an experimentation. You know like we don't have a clear guidelines here. The main idea that I wanted us to go through is basically how few people showing some work will be. Research will be designed what we shall or whatever surveys anything else that we can share and just to like, give each other some friendly feedback and some suggestions maybe exchange some of the experience between the stage groups because I'm hearing a lot of this question. How is this done in that stage group?

A

In that and I think it's just best for us. If we have a platform to talk about that between ourselves and thanks for to volunteers today, so we have fun in Ian who wanna show something so I see almost first on them. I'm. Looking at the agenda document, so I see there are two people, so one maybe I'll just give it over to you sounds good, alright. So.

B

Let me share my screen because I think that's what makes sense sure.

C

A

Free to point us towards the parts where you feel like you need the most feedback. You know like hey, you know, I, don't I'm, not sure about this yeah.

B

For sure yeah I'll do that I think the first thing that I'm gonna do is I, wanted to explain kind of give a little bit of context of what I'm working on, because I always feel that, like we, although we're on the same stage, it's not necessarily that we know everything that we're doing like I mean it's we're in contiguous groups, but that doesn't mean that I understand like what are the challenges in package?

B

What are the challenges and like in like CI, you know like I I should but like I'm still kinda like trying to get all that context. So, like I, think it's it's important to provide context. So I did a small I think to just explain what I'm working on if I can move these to the top.

B

A

Just have to select the first slide cuz now the law. Oh.

B

No, you know it's kind of weird it's it's not I have like. So how like four screens so that's the problem. Let me just stop sharing and share the right screen.

B

Sure it's this lock screen all right. So.

B

Now you see it right.

A

I, don't see anything you guys. Oh wait. No.

D

Not yet I don't.

A

See anything shared so it looks like you're, not in the screen. We see your slack yeah.

B

It's what I don't want you to see it first, oh.

E

B

A minute play all right: now you see it right. Yes,.

D

What it's good.

B

A

B

Cool all right, so so some context, I'm working on adding code coverage, historical measurement so like what we want to do is like a de Graaff where people can go and just basically see how the code coverage has been changing on their project like initially, it's gonna be the last three months, because that's kind of like the there's many reasons why we would pick Tremont. One of those is performance like basically making those queries. uh It's kind of like expensive, like performance wise. So like three months.

B

It's like creation of all time, and we also feel that it's like reasonable from our perspective of like usefulness, just to see that the last three months, maybe like you, know bi-weekly or weekly basis, but you guys probably can give me a feedback on that as well. So anyway. So what is good coverage? So code coverage is a measurement.

B

The develop development teams used to measure how many lines or blocks of code are executed, while the automated testing is running right so, like you, have like a bunch of tests that run and execute the code and then like basically, that's kind of like a percentage of how much of that total code is being executed. So I just didn't count like a small I, don't know like keynote animation to explain how it works so so, basically, the way that it works is that there's gonna be a code. Change like a developer is gonna.

B

Try to merge or like it's gonna. Try to push like I could change to the the main repo or code base right. So when you have a repo on a code base, you basically have like two pieces right. You have the executable code and you have the tests and the it's like kinda like a one one-on-one relationship, but usually you have like one file of executable code and then you have like a corresponding file of tests.

B

So, in the case of get lab, for instance, we we have like a ruby file that, like it's basically rendering UI and we have an r-spec file that basically tests. That file writes like what the file is doing is basically making a lot of assertions about the code that exceed like that's gonna, be executed so like does it have this bottom? Does it do this when I click it does he do this and that when I like undo it, whatever there's like many things that you can test there?

B

So basically, like- let's say in this case, the person who is gonna make the code change. He's gonna like basically make the code change, but he's he or she's, not gonna write like the corresponding test. For that right, like it's just gonna, be like a code change that doesn't help like a a test yeah, something that tests the code that they just wrote. So in that particular case, like that executable code is when I get move into the repo and that's gonna increase the amount of executable code.

B

But it's gonna decrease the the amount of tests right so like that ratio between executable code and tests. What could correct in measuring? So basically, if new code gets added without the corresponding test, then the code coverage goes down. So, in other words, what the means is that more code is being executed without test which can increase like more or like box or like regressions for like at the very least.

B

It's not a good idea to how, like code, that it's not being tested because, like it, means that you're not kind of like thinking holistically about how your code might impact other area so like the whole code base. So you don't want that. You basically always want to be like very high or, like I mean ideally at 100%. Coverage, which is kind of like apps, were like nothing like. Anyone can like reach that consistently, but you you wanna, be pretty high.

B

You know that's that's kind of like the goal of code coverage, so, oh sorry, I just so basically kind of like what it is is basically a measurement. It's like the ratio between the amount of code and the code that gets executed on the test, so, for example, I could crash of eighty means that 80% of the code is being run through the tests and there's 20% of the code that never gets run the right test.

B

You know so the reason why this is important, because it's because, like maybe for development, lead, you wants to know why 20% of the code is not it's not getting run under the test. He wants to understand what type of changes are making like the code coverage goes down and he or she one might want to understand why those changes are happening. I like how he or she can like, contribute to like not like how can they contribute to like preventing like code coverage decreases.

B

You know, so these also kind of gets mapped to other measurements like they might be, measuring things like the amount of box that they are releasing the amount of regressions that they are releasing. So it's very useful measurement because it allows them to understand. Why are our tests good enough to like prevent box for regressions, or maybe we need to improve our tests? Maybe when we have a lot of good coverage, but it's not like the right tests or like that?

B

The code is not being tested in the right way, so it allows them to like see many angles of how of the quality of their code. So it's just a percentage, but it has a lot of meaning for developers it. So it also has a meaning for product managers, because product managers also want to see like well.

B

Usually a product manager has the job of prioritizing the road map, and if there are a lot of regressions- and there are like a lot of box- they did they did one understand what's causing that and they want to see like okay, I I fill the code coverage is low, I'm, not confident that we're gonna shape without regressions. You know, so it's a good way for them to also plan ahead to see like there's gonna, be like future work.

B

That's gonna be like bug, fixes or regression fixes, so not like it's not that straightforward, but usually like a local coverage, means like more regressions, more box more stuff. So it's kind of like a proxy to understand, like the amount of things that are failing right so now, I can share my actual screen. Sure.

B

All right, so what I'm doing what I'm working on is basically this graph that I mentioned at the beginning. The first thing that I wanted to show you is like: where do we have this data nowadays? So nowadays we we show this data. We surface this data to the user through the batches right like so like the projects can have badges and, like the badges, are like showing things like the PI one I see it's CI best practices surpassing it's maintainable, and in this case we have two things here.

B

I already got some feedback on these like something that I we got a change in these. You probably already know what I'm talking about, but like it's kind of weird that it says coverage and then like there's another coverage, that's confusing because, like what do you mean like that, there are two coverages and yes, there are two coverages in this case, there's one for our Ruby and there's one for JavaScript.

B

Unfortunately, the the tag doesn't show that so I think that's kind of like something that we need to fix. So that's low-hanging fruit for us to fix. But this should say like oh gosh Ruby and it should say coverage JavaScript. So this is interesting because this one has like 96% of coverage. It's pretty good. The JavaScript one is very low, is 51%, so there's like if you're gonna use code crash as a proxy to how likely are you gonna ship regressions box like this means that the the Jes is more likely to fail somewhere right.

B

So we have this data. What the use case that we're trying to fix is doing is trying to show this data historically right. We want to see three months of like these data changing multiple times. You know so you can see like. Oh, we may be introduced this big change of code and we want to like see why we didn't create tests for that.

B

So we had this issue and we start exploring based on the things that we got so I I did a lot of exploration, so I'm going to start with the simple ones and then I'm going to show you the one that I arrived. That I feel is kinda like the so far is the MVC, but it's also the one that covers the most things based on the feedback. So I started with this one. Basically, what you're, seeing here these lives on the repository charts.

B

So basically in the repository charts you have like, we have already this kind of like code language graph, so it made sense to like basically show this graph here as well. There has been a discussion if we should perhaps show this on the CIE chart. I don't know, that's I think we decided that this is better location for this, but that's another area where I would like to get feedback but well.

B

I started with like this kinda, like full width graph, showing the coverage like across the last six months so now by weekly basis, so like I'll, go 6, August, 21st and then like it's, showing how it's kinda like changing and then because I already told you that it's based on language then, like there's gonna, be a defaulted language in this case in the JavaScript and then like you can just go on like change the language like in this case, you only get coverage for like, but in the things that have tests in this case is JavaScript and Ruby, so you will be able to change it Ruby.

B

That was one exploration. Another exploration was kind of like giving them that same graph with a defaulted language, but then giving them like some useful data on like like this, like accumulated data, so here we're showing like the overall code coverage like a number like the 99th percentile coverage for all the languages as well. The average week by week by Ryan's, we talked I, talked with the team about these data like this could be helpful but, like not super helpful, I. Think they're more interested in the raw data or like see like okay.

B

This is the number for August 6. This is the number for August 21st, so I kept exploring that exciting. We don't necessarily need to show that those those numbers, but we could be showing something useful here. I mean like we already do it for commits, for instance, so, like we show the total amount of commands and the average per day the author's so I felt that there was like something there that we put surface, that it's valuable for the personas interested in this feature.

B

So I kept exploring like in this one I'm showing like the overall and then I'm sure, like the specific one to to the language, you can show that to JavaScript or to Ruby and then like something else that I change on this iteration is like in this one we are just showing the like. You need to change the language in this one. We are basically showing the language stacked in the same rap. So, like you see like the Ruby coverage and the JavaScript coverage on the same graph, let me.

A

Actually, make.

B

Ya, curious, that's a great question, I think very rarely. It would be more than 600, sorry more than three I think it's usually the front in language, the back in language and perhaps there's something else on there doing like. So you should like a language like Lua, for instance, which sometimes like it's glue between different things. You might show up here, I, don't.

B

Know that will never happen like uh like the most likely scenario is just one right so like if you go to like a repo like the runner repo. Let's just go, you know, go I'm go is the only language that like lives there you know, and if you.

A

B

Like a web project like good luck, it will be like Ruby and JavaScript, but all these things that you're seeing here like CSS vu1 HTML, you don't do tests for that. You could perhaps but I mean I, haven't seen that, like the view, is just kind of like a wrapper and top of JavaScript, like your JavaScript coverage, is already taking care of that.

B

So I don't see more than three, perhaps four, but that's a stretch. You know, I, don't think that there will be a lot, but that's a great question.

A

Asking that, because if there will be like 20 than the color overlap, won't really work but yeah yeah.

B

No, no, it's what 20 wouldn't happen, usually working just one language and then like. If your projects break complex, you make my heart toward free language, languages kind of like like wrapping themselves around, but like that I think. That's that's prolly stretch under.

D

How that works with the Mona repose, because Mona repose can get insanely huge with a wide variety of codes. Language is used.

B

That's true but I, but I think he will still be just a couple of languages. Right I mean like you're right profile. Perhaps I don't think you can do code cooperation, Mona repose, but you know I'm going to take a note of that, because I think one of the reasons why people are like, like don't like more repose, is that you cannot do like that's odd. You cannot measure this type of things, but I'm gonna. Take note of that and ask yeah.

D

That's a thing right with mono repo, some of the companies or you know, big clients that we have, or they cannot do differently venom on a repo, so they're kind of bouncing. That's.

B

True I'm gonna ask that one.

C

Thing I'll point out, though, if we do go this route of multiple graphs on kind of stack together during prior to you, starting probably six months ago, we did kind of a color audit for accessibility, and one of the things that came up was layering charts over the top of each other and Annabel was in a situation where she had to put multiple lines hearts on top of each other like this, and it was a full-on nightmare.

C

So it might be worth going back and looking at those issues to see the difficulties that arise and trying to put multiple multiple charts on top of each other and then still being able to be accessibility. That's.

B

F

I'm a little bit of what could be a silly question: one yeah when I'm looking at the chart, the yellow section, is the JavaScript test coverage correct right.

F

So in this graph, the purple section just above it does that represent how much more test coverage ruby has been JavaScript or it does really already have four percent more coverage in total.

B

No, that's! That's not absolutely question at all. I think that that should be more clear on the graph. So yes, it's basically the the first thing that you said like so like in this particular case, like let's say like if we see it here in the first six JavaScript has like 64 percent and Ruby has like 80 percent. So the.

E

Reason why they are like.

B

Stuck here is not because they really have like a meaningful relationship, like the only meaningful relationship that they have is that both of them want to be at 100% I, don't like that, make sense, but that that will be kind of like the case way like like the ideal scenarios that you wanna see just found like a block.

B

You know for both and if that's the case that I don't think that will ever happen, that's kind of like an edge case because then you have like, but you have to stack wraps that are there at the same level we will have to like perhaps address that. Somehow now you know like the more you guys talk about it, the more that I it happens, but I'm kinda like wait like we thinking the fact that we should be like stack. You know, yeah also, if I had.

A

If a person would want to see like them their results for like almost 5, it's pretty tough to do that right, because there is no zooming in zooming out no date arrange component. Nothing! So in that, in that graph, that you're showing there are like date, points each I think every week you leave from here.

B

Bi-Weekly yeah, if.

A

I'm, the on that particular day- maybe that's not really sick use case here. Would you do that? Yeah.

B

I have uh I have uh I'm just gonna jump to like, like the last iterations, which are.

B

For me, okay, let me just jump to.

F

B

F

Not silly, but so I wonder if we're looking at the chart that has the total test coverage I'm wondering if users would find it valuable if say, would you mind zooming in on the.

D

F

Sure so on August 6 I wonder when I first read it I as I thought that there was 80% total test coverage and then tried to break down that there was 8 percent coverage over Ruby and then 64 percent of JavaScript I'm wondering if.

A

F

To see total test coverage, if they're viewing the all section and then the percentage, oh.

A

F

B

Then, like 30.

F

Percent of it, so it reflects the graph above it too. So there's kind of that doctrine that that's a great question so.

B

We talked about these and apparently they don't care about. Like the overall coverage of the project, I mean like it sounds weird, because I thought that that was something that they wanted to know, but apparently that's not like a uski is the only care about like individual code coverage so like they care about, like ruby coverage and JavaScript coverage that they don't care like, like the overall coverage of the repo, it's kinda like not a meaningful measurement for them.

B

Does that answer your question yeah? It does. Thank you yeah, all right, so I just jumped to this one because, like this is just like one iteration before like the final one, they arrived too. So there's there's one thing like so, first of all to one certain area, so what we decided is that, for the MMB see you'll be able to download the raw data, so we have this button and what this is gonna give you is gonna.

B

Give you like a comma separated value file that you can open on like Excel whatever, and it's gonna give you like a day-by-day code, koresh change, so it's gonna give you buried raw data and this already kind of like this array. What they do. I know that Elliot is doing this he's kind of like he has a script that basically downloads the code coverage and then, like he, basically computes the values that he needs. Out of that we talked about. This Andy seems to be like a useful solution for the MVC.

B

A

I think I I have the data in the passage in my with my previous company. We've worked on the dashboards a lot and it sounds like users are never well very, very happy with the filtering capabilities that software provides especially like kind of like corporate software and then.

C

A

Feel, like people often have a preference to be able to download a role, data with CSV and then be filtering it within using like Excel, XLS or something so I. Think it's good yeah totally.

B

Yeah no I agree with that. I think that an CSB is like it's it's uh it's something that you can use like. You can like create like Python scripts manipulated or you can I use like Excel or Google spreadsheet, so I think it's a very dynamic format.

B

We just export data, so I think that would be that's what we're gonna do to like cover that like down the line, I think we want explore like maybe adding a table, or maybe maybe adding like some way to you, know like change the data on on on the actual view.

B

Basically, what happened in this iteration is that we talked about it and I think these data. It's not really that useful, I think they're more interested in seeing like the the like the change of the code koresh true time. So what we decided was, oh by the way, there's something that I added here. He's kinda like this health bar. So if you hover over these I, don't have the mark for these.

B

But if you hover over these people, kinda like say like code coverage, shell and that's basically like a mapping back to these colors that you see in the badges I, don't know, I, don't know how they're determining these colors, but I thought that that was kinda like a nice thing to add nice show like it seems that your code coverage is healthy. You know like maybe it's not, but like at least can I give them that idea of how healthy it is.

B

This is totally subjective, so I I'm still not sure if I will show that, but like I thought it was a nice addition. So the the last iteration that we arrive to is basically these ones to like no data to show they're, both graphs, which stack and then you can download the raw data.

B

And then you have like a full width graph, where you see everything right based on the feedback that you guys just gave me I'm, now rethinking a little bit the the fact that we should be stuck for two reasons once like mono, repos I, don't know how that's gonna behave with bone or repose as Dimitri suggested. That's something that I need to figure out. The the other thing is the accessibility issue that might suggest that that there might be like an accessibility should be with stat graphs.

A

C

My printer I'm still trying to find the trying to balance listening, but maybe I'll get with Annabelle after this I know. She's worked on it I'm struggling to find that issue, but it is fantastic and his inquiry. Walkthrough.

B

Probably uh probably being her after D, so so I can get her her thoughts on these worst case scenario. I think I would just go back to. It would be like this like exactly what we have here with the download raw data and everything, but it would be basically the first version that I did so I. Think I was like kind of like already onto something with this one. You will just need to change between like languages and we will default to one I.

B

Don't know what Harry sticks we will use to default, perhaps the one that has them. The greatest sure is the one that gets defaulted. I, don't know, that's something else to determine, but perhaps it's another solution that doesn't conflict with that doesn't generate conflicts with accessibility and like it might be the case that I want to find out about the mono repo thing, but yeah in might be another case like if we actually have like a lot of language used to show here. This would be the right solution, so.

D

I have two remaining questions after for this, for this issue, I don't know if, if any points to I didn't want to cut you off, if you want to complete your story.

B

So I know I can't good I can open your questions and feedback now so.

D

One of the questions I had is so my assumption here is based on you know. The graph you've displayed that there is a like there's the need to see over time how coverage is done right, yeah,.

B

That's pretty much 31.

D

B

D

Because I was wondering like is there also need to just know about what the current coverage is per language, if that is like a separate or because, if the.

A

D

Another graph could be a possibility for just that specific need of understanding the current need or the current coverage, and my last question kind of ties into that, because you know this is a specific spot where you could put such a graph. But I know in the past that there have been discussions on this specific page on charts that there was the discussion of like hey. Can we can we get rid of this page completely and put these graphs in two specific places inside of our application, where they are? You know within context. Instead, right.

A

D

This this, you know summary of different data points, gravel together, basically so, but.

B

When I mean it.

D

That has been part of the discussion. It.

B

It has been actually that's a great question. First, I think your own point with those comments own. Let me first like address here. First, the first part of the question like understanding the current coverage.

B

I, definitely think that that's part of these, but they already get that from the batch, like they already kinda like if you really want to see like what's the current coverage of the repo, like the bass, shows you that so I think, like perhaps what's missing here, he's just like a tally that shows you like current coverage, like just another kind of like value somewhere here, which I think that's a low-hanging fruit. We should definitely do that. I think that's that's something valuable to show so not an issue. I'll definitely do that.

B

The second thing that you mentioned.

B

Yes, actually Neriah can I suggest that, like she gave me like I'm feedback on this issue and these kind of like spin off like another discussion about like the these pages, I think everyone I know this. First, these pages are not pretty.

B

Second, they are how like hidden discoverability wise is like oh I need to go to charge and like find the charge and like then like that's where I get data you know like they are not useful if you're really not seeing this in the right context, so I think you're 100% on point with that, I think there's basically another parallel discussion on how like we will change these pages and if it's part of the discussion I, don't know how that's gonna evolve. But, yes, we have we're talking about it and James ypm.

B

He opened an issue where he is basically gathering feedback about that zone might happen. I, don't know, I think for the MVC. Maybe this rule on here, but I think midterm. We might do what you said. We unbundle this page and they're like charts, go to other places, I think.

A

This is a good point, because I see I actually started like I, see that there are different charts in different parts of the navigation like charge dedicated to each of the separate, like stages themselves, right, yeah,.

D

It's it's kind of leftover of.

A

The navigation.

D

Change back then, and I know that we didn't know we'd be well what to do, and it was like all right. This will be decision for later, but perhaps you know this year or next year will be finally the year that we something like that. No.

B

I realize that idea, I think I'm, bundling the charts and like making them more contextual to where they need to be makes way more sense, because, quite honestly, I don't think like customers, unless the customer has like a very, very specific reason to go to this thing, like perhaps like people who need coke koresh do then they will never find out about this. You know so, and it's kind of hard to like hunt for them.

B

You know so there's charts in repose like if you go to any like, like let's say you go here, you have like charts in there in the repository. Why you have this charts and then like that's one page with charts, but if you go to see ICD the you also have charts.

B

So we even have that thought about like where discharge should go, you know, should it go in the rib or should it go here? You know so, oh by the way, this one is stacked. So I don't know Mike white who, like my dad, that's an interesting thing to maybe like also see because, oh that one also has the issue. I did.

C

I did find the issue apologies to Annabelle. It was not Annabelle, it was Amelia. Okay,.

A

C

Linked it in the chat, the link to the issue- and there was also presentation done on what we used to do- the group design feedback so that one might be worth watching I think it's con gitlab unfiltered got it I! Think.

B

C

All those there, but the link to the issue is there in the chat all.

B

Right, no, that's awesome thanks for that, I'll definitely check it out all right. Any anything else. I did have one thought on the health bar yeah.

C

B

Let me go back to the somewhere.

C

So just a thought- this probably definitely is not MVC, but you know like the the red to green is sometimes your organizational goals may not necessarily in line with that, and sometimes it's frustrating when you see something red when you're like yeah we're at this point and the thing so something's red and it seems like a problem so whatever suggesting is, maybe a future enhancement could be setting a goal right. The goal is always a hundred percent, but it's never really a hundred percent right like right. Here's the.

A

C

Line of code coverage that we're willing to have so you, if you could define that then maybe have a line across the chart. That's.

B

Awesome, that's awesome, feedback and I think it actually ties back to another issue that I'm working on, which is eventually what we're gonna have is something we're gonna.

B

Have the ability to block a Mars based on initially is gonna be code quality, but it can't happen to be that it's also based on code coverage, so the way that it's gonna works, that you said like a threshold and then, like you say, like you know, like code coverage, can never go below 60%, you know, and if it goes below 60%, then you cannot merge so that basically means I or you either write a test or like you cannot merge.

B

You know, like that's kinda, like the type of feature that we want to what so we're gonna start with code quality, but basically tie this back to what you said like. In that case it would be very meaningful to just show the line. This is the threshold right like you can. This is where we once stay at least right and I.

B

Don't know like right now. How will we feed the data to because we don't have any anywhere to capture that? But it makes a lot of sense. What you're saying I think: that's definitely the the few, the future of these cool thanks all right anything else.

A

I was like you did thanks Aaron for being so active, Ian and Sophia have enough time, but if no, we can also discuss that back in the other and actually I specifically didn't want to stop this conversation because I love this and maybe in the future. We have to just educate a meeting per one case, so we don't feel rushed but yeah thanks. Thanks comments, I moved all of the comments and they made the notes in the doc, so I think.

B

That yeah and I apologize, if I you like run over, maybe I should have like it's.

A

Because it's like it's too short, then it's not really useful, but yeah go ahead and if you will need more time, we can also come back to the discussion next time for.

F

Sure um I can jump in and give an overview of what we're working on and then I have it set up in the design tab of an issue. So if you have more feedback, we can also dive in from there I suppose. I should share my screen too.

F

So what we've been working on is what I want to share with. You is we're going through the solution, validation, phase of kind of a big design initiative. We did the problem, validation with testing the assumption that if we included more robust project and pipeline and see ICD data with packages, we would better enable our users to kind of do what they need to do. Problem validation is done. We did a ton of research on it found out.

F

Everyone is very excited about the idea, and so what we're doing now is I put together kind of a big design that has a lot of different features on it and we're going to go back to our users and find out you know. Does it make sense? Is this data valuable, as well as get information on where their priorities are so for context? This is the current state of a package.

F

This is an NPM package. You have a name of version when it was created when it was updated, which is almost always identical, and then some basic instructions on how to set it up and then because it's an NPM there's just the one file, but we are really fortunate, even if it seems a little bare bones packages to set it and forget it feature. So as long as we can store a package and then get it, you know allow for it to be pulled we're succeeding.

F

So we're already at that stage, which looks kind of great. We want to move into the next step. I would love to get feedback, maybe not on the MVC nature of it, because it's not MVC at all, but around. You know if the data makes sense if it lines up with other patterns and get lab stuff like that, I'd really appreciate your expertise, so everyone see the updated design. Now.

F

Yes, take your silence awesome perfect. So we wanted to create a page that was a little bit more of a home base for packages and gave a lot more information. The information we're sharing and showing is based on the research that we did. So we know at some level that it is important what I want to test for in the solution. Validation is: are we picking the right things? Are we displaying it in the right way and at the right time, I can just kind of walk through it.

F

There's we kind of followed a pretty similar template to a lot of the different pages in yet lab. So we have a nice like image, a header, that's the package name. We added this verified idea, which would require a whole, mr for an issue for itself, but it's basically the idea that I, a DevOps manager can tell my company yes use this package, it's the safe version.

F

We wanted to quickly direct them back to the project that built this package in a lot of cases for microservices. This tends to be the project it's already in, but for mono repos it could be coming from very different projects or be hosted very different places. So it's kind of important. We list out the different versions of this package. Currently we just display each version of a package as its own unique thing and that doesn't match the way that users think about it.

F

They think that this is the golden package and it has 23 other versions of it as opposed to there are 23 different packages. They also have a unique identifier, so this could be latest or a master and then what branch it came from is also pretty relevant. They will several organizations only use packages that are built off of a master branch, which means they got successfully merged and went through all of its tests. So we want to service that pretty quickly, and these are the different tags this package has.

F

We added the instructions in this adds a project right now we just kind of give you the NPM snippet or you could copy it put it in your terminal and away. You go there's other options that we're exploring around creating a merge request that automatically adds it to the package Jason and it has a pipeline that builds it. So this can and expand in future I'm going to fast I'm, really sorry just want to make sure I get through this.

F

um We added an alert for some basic testing of the package, so this is an example. If a package gets built through the pipeline and ends up in the registry, that is zero kilobytes. It's a really big sign that something's wrong with the package they inherently shouldn't. They should consume some space so giving some some heirs.

F

We created, use the tabs to highlight different aspects of the package, so the list of versions is on its own home and has the ability to kind of expand and contract, as it needs same with the files giving it its own place means that you can kind of do the full file. Experience like we have in the repository level and then dependency unlocks is the same thing. The description is just the piece of metadata, so we just surface it up.

F

One of the this is the thing that users are most excited about is they would like to know what commit and what pipeline built this package, usually when they're coming to the package UI, it is purely because there is a problem and they're troubleshooting, and these are the first pieces of information that users go for. They constantly report that they need to commit sha that ended up building the package and we discovered that was what they were using to find out. What pipeline did it come from? What branch was it on what commit etc.

F

So we just kind of surfaced that data we did some use of Statistics. This chart is very ugly, so I fully accept that one I'm gonna be working on that before we do testing and then we added the ability to copy some of the metadata so, for example, maven in order to install it, you have to have both the package name, its registry and its group. Id all is three separate things, so we're trying to provide that and they're pretty easy to to get way. So we added this little copy function.

F

I think that's the fastest I've ever gone through this design. The big things I'm looking for is like a any like glaring UX issues. I obviously want to resolve that before we put it in front of anyone and then in terms of just kind of get lab, eNOS I'd really like to make sure that this page feels natural. So if there's anything that seems out of sync with the other parts of gait lab I'd love to hear that too.

C

Did you explain the four tags and then there were also tags to the right of that? How those are those related? Are those tags, those tags or are they? Yes,.

F

That's a good call, cuz I, say four and then show um actually so there are four tag versions of this package and they each one could be lightest, one could be canary, one could be beta and then one could be in development. Those are four different packages. This package has the latest in master tag on it. Yeah.

C

It's that so that I think there's a bit of a collision there, ass namespace right like tags and tags, I totally.

F

Yeah, would you call it a tagged version? Would that be enough of a differentiator? Do you think I can explore it I want to force you into solutioning sorry, yeah.

C

F

A good call out I'll, look at that and.

C

Then I, don't I, don't know I've been here long enough to know but then verified which I think it's fantastic, but that seems big seems tall. I, don't know, I, don't know if that's a real thing or not, it seems taller than normal yeah.

F

I use the I used the large tag, I'm still getting used to pyjamas for sure, so I think if they were capital letters and it would kind of feel right, but because it's not a little different but I. Maybe.

C

I've just never used a large one before yeah.

F

I kind of want to shrink it down anyway, cuz it does kind of dominate the top of the page, a little bit and I wanted to, but maybe I went overboard uh regarding.

B

The tags, I think I think needs to be cold tags because that's so, basically, the way that it works is that the point the package so you're gonna, download a package right and then, like you like what's gonna happen- is that the your package manager is you're.

B

Gonna, look at the actual gift tag, so it's gonna be like one point: zero one one point zero two or like that release or whatever you want to call it so I think it's called tags because it's actual key tags not because it's like I may be wrong, but I think that's how it works right.

F

So tags are used in different ways depending on the package manager, which is kind of frustrating. So for NPM the tag is kind of like a label. That's attached to the version latest is the default, so whatever the newest package that gets uploaded will automatically get the latest tag. God there's another rule where, if the man the branch is master, then it gets a master tag added to it. So sometimes there's only one package that has a master tag or a latest tag and then another's and many packages could have them.

F

That's why it kind of gets confusing got it got it yeah make sense. Well.

C

Maybe that's a solution in there was was. Is that his tags- and maybe the other things, are labels right? That's how we will tell we use them in like issues and things like that. We call them labels, not tags. So maybe we just refer to those as labels. Yes,.

F

Sure I will explore that just because tags have a special meaning and I'm, not a tech person I'm still pretty new, so I will reach out to the developers and see how they feel about differentiating these two ideas do.

B

You guys explore the idea of HA being dependent because I see do you have dependencies, but I think that it's like dependent it's pretty useful, because it shows you what packages depend on this package and I. Don't know if that's like what part of the scope or like it just was left out. Yeah.

F

So part of what we're doing is we're reaching out to our users with basically a synthesized version. If this is what we heard, you wanted and I'm gonna gather feedback about. What's important, one of those questions is around what is most important about the dependencies area. Is it knowing from a security aspect? What this new package depends on? Are they all secure and safe, or is it the other way?

F

Where do you need to know how many other things depend on this one package, so that is definitely a whole area to explore and and I want to for sure do that.

A

Dependence yeah.

B

So it's it's usually I, like the way that I have seen it broken down is like dependencies is like like these particular package. Like depends on like these 500 packages right and then like there's. The pendants, which is like these 100packages depend on these particular packages. Like there's, there's waste upstream.

D

And downstream yeah.

F

Excite exactly, would you just looking at the design? Would you expect dependencies to house both of those ideas, or would you expect the dependencies and a bit dependent, tabs and separate I.

D

Will actually yeah.

F

Will actually expect them to be separate to be honest, yeah.

D

F

Okay, so dependencies and dependence yeah, okay, cool, that's really important to know I by.

D

The way I had a question on how does it reduce an NPM package? How does this look for, for example, for a maven package or.

F

Short, that's one of the big things. That's been a challenge with this and why this kind of research data is so weak. Npm packages don't have any metadata, so this would be enough to kind of operate it. They really don't have much. Maven has a collection of four or five metadata points that have to be there to use the package. Coenen has 34 pieces of metadata that has to be available, so part of what I need to do is once we get to that metadata portion and really explore is.

F

Is there a pattern that all package managers follow, or is this something we custom design per package manager, because it that question is very tricky to answer yeah.

D

But I was thinking also in a from a styling perspective as to be able to differentiate upon first sight of this page. Am I looking at an NPM package or am I looking at maven package or any other for that matter? So.

F

On the ListView and this didn't carry over, we actually show the package manager, name and kind of logo and label to give it a different differentiation. I think you are right. We should include it on this detail page. So at first glance, at a detail page you can say this is an NPM package and not have to think about it.

D

Great yeah, that was exactly what I was thinking. I.

B

Had one more comment: he's uh are you planning to maybe have like the the command line like the command like? Oh you, you click that any choice up there.

F

So this would expand into a little call-out and it by default. It would have those commands that you would expect, and then it would also have there's. Npm is a bad example, because you can really only install it using either snippet or adding it to a file. Navin there's a collection of ways to pull and install and Conan I got is the same way. So that's why I kind of hit it into here, so it could adapt based on which package it was got.

B

It yeah so like there's, it can be like dynamic, based on like the package manager and everything I.

F

B

A lien, though,.

F

But exactly what you called out is people are going to expect at least just the code snippet to be readily available and then maybe bury the other installation option.

B

Yeah, that's what I was gonna say like that yeah I would very least I will expect to see somewhere like if this an MPA package I would expect to see like MPA me.

F

B

Jl golden package and like the way of copying that, with a click.

F

You know, would you see in the screen that you see, would you gravitate to this add the project to find that or what do you think.

B

F

Mystery I thought that, like I.

B

Mean like a struggling a little bit, I will but I almost thought that what was gonna do was like kind of like I. Don't know how I honestly was a little bit like what did that? What what he's gonna do? You know if I add to project it's gonna like I, automatically added to the project, and then it's gonna create its own. Like army, that's gonna, I, it I, don't know! That's why I thought it will I honestly am a little bit confused with that add project, but I don't know like I might be.

B

It might be. Just me, you know, I was what I'm thinking of.

C

I was I was about asked the exact same question and I would have no not I mean now that you say it. It makes a lot of sense, but I wouldn't have not have thought, add to project I, think NPM, org or whatever it is, has taught us up that pattern right. We look at the upper right hand, side like that's where npm install' is so.

C

I think that might be like an unfortunate like that is just the pattern that human it again that specific the NPM, but like that pattern, that in green in the front of the what.

F

I've been debating about is adding adding the field with a copy button link. We have everywhere else and then have like a plus sign a green plus sign next to it. So you can expand and see the additional options, but the option you would most obviously expect is within view. It's kind of my next exploration idea around that cuz you're, certainly not the first to to have that same thought. I.

B

Just send you one for like the registry of composer, which is the PHP package manager and although they don't show it like us, Mike said like on the yeah I think that setup pattern that we already can I got used to it. You see it also they're like available right away. There's like below the title, it says, composer require symphony, slash security or so I almost seem like the pattern that we already got like God used to. It is to see the the the command somewhere.

B

You know it was like oh I gotta copy that command like that's the way that I install it yeah.

F

That makes a lot of sense and I have a very strong feeling that, as we do the solution, validation that will be one of the most common things I hear that's my hypothesis.

F

Any other thoughts why.

A

Should we usage data graph? Is this something from the pattern we have those already, because it looks kind of like simple this.

F

Was me putting in a graph to demonstrate it was a graph that is the end of the design effort there.

A

F

Don't currently show it so if somebody has a great example of a chart that would look good for usage data, I would love to see it. Okay, I can create a consistent experience, so the.

B

Charting library that we used these because I had to figure out these for my test coverage each charts and they have a playground where you can just like basically I'm gonna, send it to you right now, Oh perfect. Thank you.

D

If a last comment on usability in terms of the tabs, because I was wondering if the little call-out you've created there and might also be and able to put inside of the tap instead of above it like because I've noticed and like I, that's why I like so much? We change for the merge request page where they're finally putting their tabs at the top of the page, because people are scrolling over it, just not seeing that they're, actually additional tabs for them to click on and I.

D

Think that you know dependencies, for example, is one of the more important tabs that I would be interested in when checking out a package. So just a worry for me there as to usability.

F

Of the tabs, so most packages should end up looking like that, a majority of them won't have alerts. It's only the extreme cases that, like obviously something's wrong but they'll, see that so it would be header and then immediately funk. Attempts cuz, I, agree, I, think when you bury the tabs too far, they end up getting lost. Most people can't find the design tab they've been struggling.

F

Exactly that's a good call out, though I think one of the important things is to make sure this alert is obvious, but pretty straightforward and small, because otherwise things could get buried pretty quickly. The.

B

This has nothing to do with your design is more like about the like. This is like a comment for everyone in school, but I have the feeling that our tops are extremely subtle. That's why they sometimes are not discoverable. It's like you, the cowl and too much with the designs. Like you, never kind of expect them. I, don't know if it's the gray or something but like I tell you. We think the tabs are disabled.

F

I, don't know why exactly.

B

F

I feel like they're, not.

E

There's the funny I get the feeling.

A

Who wants to address this? One should be anything.

D

Sorry to address the taps issue mean I mean.

A

Maybe we should submit an issue movement for this or is it? Is it their pajamas or like I, don't know? If so many people are being on this it it looks like they're, disabled yeah,.

D

I can do that because I can immediately validate it with the last UX research from the UX scorecard. One of the insights I believe I have documented is that people are just not seeing the path one step within the merge request page and it's in it to some extent infuriating to see that happen. Time and time again.

F

Yeah user research like hearing that in conversation, guys.

A

I'm so sorry I'm having one with Christy so I have to run.