GitLab Source Code Group, 28 Jul 2023

Previous Meeting

Next Meeting

⏯

youtube image

►

From YouTube: Create:SCM - Discussion of frontend/UX inflight issues in 16.3

Description

Alignment on issues between UX and frontend eng manager

A

B

A

This is going to be a discussion.

B

A

It was supposed to be prioritization, but um I think this column is now more is just like alignment on where we see things because um Andre is going to be taking some leave for two weeks and now I'm gonna be taking something so I just want as a checkpoint between all the little things in the UI space front-end side that I've been looking at. That I feel like will be ready soon and finally, um but.

B

um Yeah I just wanted to see where things are at because.

A

Firstly, um I wasn't paying attention too much to like this feature of the blame file: information within the blog view, which is a cool feature and.

B

A

Was in really Hands-On on that one and it's actually related to another one that was I was more Hands-On, which is the gutter size that we have right now. um It's really big and I wanted to make it smaller, but um they're very related. So.

B

A

I guess the question is like what.

B

I see is important.

A

Is like these guys here, yeah like like.

B

A

A stack rank this and.

B

A

Guess the other part is like yeah, where.

B

Do these other.

A

Things kind of Stack rank right, yeah, um and maybe you could help me out with that, so that hey I can like prioritize how I get these things ready and then okay, yeah.

B

Yeah you wanna go one by one.

A

uh Yeah sure navigate repo with the poetry.

B

A

B

Remember that issue.

B

Move the cursor out of that thing. Sorry, um is that so that and what's the status in terms of like uh UI, do we have already everything we need is to build.

A

Well, uh I didn't design the tree at all in this scenario, I think I'm. Just taking that advice that you gave me that I'm trying to use the Mr tree as much as possible.

B

um So I didn't design.

A

What the tree should look like um and right, just it's more like a lift and shift there, and it's more like the space that it will take up is. Is that, like gray area that, like in the mock-up stair in.

B

This some questions that shock raised.

A

But I feel like those are answerable by the start of the next milestone.

B

Yeah I think that's. That would be a good one. I think it's also good for parity uh with competition. um We do have the components around. It's just a matter of potentially refactoring them a bit into being more reusable, um but I think it's totally totally I think the biggest guidance we need is exactly at the toggles, um how you open and close that navigation, because we do have I think I think we even had discussions about breaking it up into two um steps.

B

Let's see, I think it would be first. What was it anything where we found the issue for it because we um or where we had this discussion.

A

You left the comment uh of breaking it. Yes,.

B

You found it, we were thinking of splitting this up into two steps: first blog with tree and then two navigation with expansion in place.

B

The the tree with navigation with expansion in place is the trickier one, um but the blob which tree should be pretty um simple about just swapping the render between blobs and stuff uh sibling, blobs, so sub Bobs in the same folder would be easily navigatable to um what then becomes tricky is, if you start expanding folders, and uh we will throw them into the repository tree navigation without the blob being seen and stuff. So we can alternate through that, but that's totally doable uh I think um editing.

B

So you asked me if I meant the editing view here, no I meant the view blob um and it could be again one of those things where, if you go to a Blog, Page um you're navigating to the file tree, you get to a Blog Page. We can decide whether to make the file tree visible or not and prioritize rendering The Blob, but it's easily accessible right. You can expand it and pull it into view and click something else, and you just immediately swap since what you're trying to do is save save cops right.

B

You go you're in one file. Instead of having to go through the file tree navigation again pick the file go to the blob, you'd be just swapping the blob from one to the other immediately, without changing the page.

B

So yeah, so this is actionable right you we should be able to get this ready for picking.

A

B

Fairly right, okay, yeah.

A

um I guess this one's in flight, so you can chat about it and it's related issue, um rendering The Blob information within.

B

uh Rendering the blame.

A

Information within the blog with you say that that's above this above the tree or if another tree I'll.

B

Say that it's below the tree, mostly because of complexity, uh the render blame file information. uh Just so you understand I, think our our perspective in terms of front-end is that it leverages all the performance, improvements and mechanisms we've been putting in the blame page and sorry in the blog page that allows us to you know. A very large file on log is already.

B

We already have some mechanisms to prevent it from being super bloated, and by being able to request slices of blame information, we could be very easily just toggle between blob and blame, render like 100 lines above and 100 lines below the viewport and don't have to load the whole blame information until the user goes there, and you can prepare that experience to be far more take a peek and then go back to what you were doing right, which.

A

B

Experience that I haven't seen a lot, but it in in competition even but um the thing is that, when you're looking at a blob, you- usually you want to see who wrote that blog, who you want to see who last touched that line similar to the um git lens on vs code and stuff?

B

um So we, the decision we want to do, is: do we keep the gutter um information? um Do we keep the gutter?

B

Do you seem to keep the ghetto layout uh to render the blame information, or do we want to go with something else um and in the in so, for example, like a git lens approach, where we throw the information of the commit at the end of the line of the code, so you can explore that and that's the part of the UI that we kind of like it's a bit unanswered is how do we want to show this information and it could be the the the way that the API is being done?

B

um It's uh it's just to provide a way to render the same thing, but we can make some tricks since the work is in Flight we're just discussing this this morning we can make some tweaks to kind of like ask for a specific line. We can ask for give me the blame information of one specific line, but it can also render the whole thing so think about what exactly would make sense um here and we can. We can um think about it.

B

We've done a lot of work with prefetching of stuff like if you hover over a file we get the file. Maybe we can do if you hover over line, we could pre-fetch the the web information for that line and display it at the end, um but it's really up to all the whole vision of how do we minimize cut uh clutter in in the gutter and and the whole blog page, so the rendering the gutter blame style layout is totally easy for us in terms of um just. We wouldn't need too much UI guidance.

B

We just replicate what we have on the blame page. If you want to tweak it, though change a little bit. That's how we probably need a little bit more information, but the implementation of this will be fairly complex. It's new apis new layouts. We have to create new modes for the blob for the blob itself, so it's kind of a bit involved. I would say that it would probably spend two Milestones developing that even navigating the repo it's a it's one feature for one, and the other issue could follow straight up.

B

uh Okay after that much.

A

Much simpler, all right cool, it sounds good, um so this is one that we talked about maybe two weeks ago about yeah. um Where is this so far in, like sure, in the front-end side, right.

B

So the refactor, the repository commit view, is the big one. This is the largest refactor that we have been discussing because it will essentially the work for the repository. Commit would also affect the compare branches page and affect the merge request, page itself, um which is code review right.

B

What the latest discussions we've had is that it's such a complex and intricate discussion that, where we're thinking about it, is to take it through an architecture design workflow during the next quarter, so that's bringing source code code, review, back-end front end ux together more more between engineering, but ux is always part of it right um so I think that's going to be a long effort of planning, still we're not anywhere near implementation.

B

We've been doing some pocs on code review to kind of like understand, what's the status and how we're going to be building this because there's questions like should we uh should we put the um um caching on the client side uh on on on? Will that work for us? uh So we're not really sure. If that's the way to go, we also testing server-side rendering, but can we do that with the current architecture?

B

We might have to change a few things, so there's a bunch of like technical questions that we're now ready for answering just yet.

A

Okay, all right! That's.

B

A

B

A

This one here improves the flow between repository and branches field. This one is an issue that came out from a ux research, and it was kind of raised as something that we should explore as because it showed up as like a.

A

B

I can see that.

A

um It's related to that. Well, let me jump back to.

B

Thank you perfect.

B

That's using Arc.

A

B

A

B

So so that issue.

A

That I Linked In the thing was more of that, like the issue that I feel that we should tackle to address this suspective analysis um feedback. um It's.

B

A

These navigations between uh chord Pages, like Branch, commits and repo, and so, if you're like in the code view, how do you get to the commit view if you're in the commit field? How do you get to the code um and vice verse, like just navigating between all those different pages.

A

I have a lot of ideas around the space.

B

A

And some of it is just lifting and shifting a lot of stuff that we've already done in other places, so, for example, with branches um like Forks.

A

One pattern that we could leverage here is to display the commits ahead and behind block like we do with them Forks, but for branches as well. So this way we have that information there. We.

B

A

The UI for it- and we already went through like the work for it for dinner Forks, but Forks are essentially branches, so it could be something that's doable.

B

Where would this be displayed.

A

It will be in there like a gray area. You know the blocks at the top of the repository page, yeah, sure.

B

So when we have a commit area, information yeah, the.

A

Last the last commit.

B

Would be displaying that information, okay, yeah yeah, that seems contained that seems pretty fairly straightforward to cover that the uh the improved flow between repository and branches view um the way we so our effort in the beginning for the repository was to unify everything related to the repository, in the same view, app right. As you see you navigate from the file tree, you go to the blog page.

B

All of that is the same view app right, um so it wouldn't be um alien to bring like um a branch summarized View into that app to be able to operate.

B

Do some operations on the branches of them themselves without losing the context of where you are right now. um Do you have any ideas about it? Are you still like in the first stages of it, I.

A

Have a lot of ideas that um the hash out? Maybe the real question I have here- is in.

B

Your well you're away, um yeah.

A

Who should I lean on for, like.

B

A

Because I I feel like I I need engineering feedback to like of.

B

Course, temperament, of course, yes, Jack, like Leverage Jack as much as you want he'll, be a.

A

Great, a great great help, cool. um Oh, it is what you just said there. Where you know. Is she yet but um everything's one one View think about.

A

A

B

A

Would make sense to me tomorrow morning, good.

B

Thing I understand: uh Saturday, you mean Monday.

A

Yeah Monday yeah.

B

A

The where to me, these issues probably have no issues yet like they're, not.

B

A

Fine um but I don't think the proposals for them will be too complex, so um yeah, that's good and yeah, because we have a bit of time left. I, guess the one that came up last week that was kind of hot was the merge label in branches.

B

A

Removed removed.

B

A

In the sake of like misinformation um in.

B

The scenario of the empty.

A

Diff um in the scenario the empty diff, we would label that as merge just based on the calculation um there.

A

There is a few ideas I have around on the branch page about improving the filtering and sorting abilities so that it sounds like a workaround from depending on the merge label.

A

um I think whether filtering and sorting is possible is like a one question from a technical side, and then it's like there will be like us, like the issues correct in that, like people who've been depending on this merged label for manual emerge operations,.

B

A

We'll be um annoyed so.

A

So, like a part of me is just like I think we can move ahead with this. If this works it well, then it it trumps this. If we like do some communication, maybe we need to figure out a way to explain that merged is gone and you can find it somehow, but I still stand behind the decision that we shouldn't just introduce it uh reintroduce it, because we haven't solved the empty diff scenario right.

B

Right, which is that that whole contained in um question.

B

Yeah I think my biggest question. There is about the operation of deleted, merge branches.

A

B

That mitigated already.

A

um That is mitigated with the filter.

B

A

All right, yeah so.

B

A

Link to that issue because that'll probably make more sense.

A

A

B

Rather than oh,.

A

A

So delete merged branches itself is.

A

It's like an action that is kind of weird in my eyes, in that um it does too much it like deletes things that you're unaware of, and you won't be aware of. So this is like the bigger idea is that by filtering you can then select things you want to delete and you press.

B

A

Select the branches- um it's not as powerful as the late merge pages, where it just go through your entire repository and just figure out what to delete um so um yeah. This is my proposal to like go against delete verse, Bridges.

B

No I get it and, if you think about, if you think about the uh the book actions of Ed of issues and merge requests it, it is always tied to the concept of filtering.

B

um It has a filter bar that you can a filtered search. That can add has many queries you want and then the result list you it's predictable, like you know what you're going to be deleting so I feel like that's some far more powerful solution. This doesn't have the filtering, does it or do you.

A

um The filtering at this stage is just by name, um and it says templated.

B

More distorting um commits ahead, then we'll just set up a couple templates commits the head merged whatever, and then you can have that selection and you can just select all and is that it.

A

Yeah yeah that that's pretty much it I think. Let me shares some other crazy.

B

That was the sort.

A

B

I was just thinking that was the sorted I thought. The commits ahead was the filter, but no it's just sorting by commits.

A

Ahead, it's just storage, yeah.

B

It should be the crazier I, like the crazy problem.

A

You're, the craziest one.

B

B

A

Let me share a different screen.

A

A

So this is probably like the work. The path is a crazy one. So at the moment this is kind of like the buttons that we have in our branches. View.

B

A

B

A

Change would be then, to introduce this ascending descending, based on the field that you want to select. um This is like the updates.

A

So we have at the end, we would have a lot of stuff here. This.

B

A

Really long and crazy, this is like branches aligned more with um virtual quests and branches. This is probably like the crazier risky thing, because we in this scenario here there's no tabs, but it's handled by this thing, so this might be.

B

A

Something that we need to just sense check: um okay,.

B

A

It does open the world up to like more filters, um so, whether your branches, all branches, still branches, Birch branches, I I, don't care like this. This can.

B

A

You're not limited by the tabs and then the sorts here so okay, yeah.

B

Is there any reason why you're avoiding the filtered search.

A

Filter search here.

B

No, so the quantitative filtered search like we have you know for issues, merge, requests, but also members of projects, so.

A

B

Filtered we have the the queries or the filters themselves: they're they're, specific per page right so on the membership of a project. The filter that they have available for is membership is direct okay. So it's so it's a way to remove all the inherited memberships of members of those projects and what I'm, seeing here like there's so many criteria that I could compound if I have filtered.

A

B

Like I could go and check which ones are you know your branches.

A

That are still your branches.

B

A

B

Protected or I mean protected, I wouldn't delete but um or are not protected, and the thing is that the filtered search allows you to do that.

B

It allows you exclusions, um it isn't it isn't the most Pleasant code base to work with, but it is very powerful in terms of allowing that composite composibility of queries, um I'm not entirely sure whether today we have the back end mechanisms to allow those kinds of composed queries, but it will be something worth investigating to the point that if we are going to be updating the UI I'd rather go in the direction of something that is again more complete in terms of experience.

B

um Even if again, I, don't know how many people actually use the page, but if we're forgetting told that people are if this little change is affecting their workflows I'm guessing that, even though they might not be very used when they are used they're very important. It.

A

B

Not be something you'll be seeing in the numbers, but um Branch branches. Cleanup is always a important thing, but I don't know yeah um if we were using components. It's just a matter just a matter of like make sure that we have the endpoints ready for that.

B

Cool but I like it, regardless.

B

It's definitely bringing some love to this area and I like that.

A

Yeah, that's cool awesome, um that's that's! All I have for to discuss today. I think awesome time. Anyways.

B

Yeah no I, like I like where this is going um and I, can see that there's a couple of things so out of these ones we talked about um which ones do you think you'll have actionable by the end of this milestone?.

A

The thing that.

A

This one I think at.

B

A

Moment um I'll be ready for all them, as probably yeah all.

B

A

Them will probably be yeah.

B

A

B

A

A

B

Know probably like feedback.

A

B

Issue I know you, you.

A

Asked for me two weeks ago, but I think the main thing in this scenario here that has come up multiple times with the commit view is filtering. You know date and ranges I want to see commits between uh September and November, because that's when, like about introduced I'm.

B

Glad you mentioned it because that's not what I'm thinking when you say repository commit view to me is the commit details, not the.

A

Commitment: okay,.

B

Okay, commit list commit list, is one of our simpler refactors and one of the ones that will be up to start whenever we're not depending on anybody's. So we call that the commit list view uh okay and that, if you can have some guidance again, if it's a filtered search like we can totally work on that as soon as we have guidance and we have support from back end, um the commit detailed is the one that would block by code reviewed for sure. Okay in that whole video. Thank you see.

A

This meeting was super useful now I.

B

Understand there it is, we do this more often when you're, when you're back and everything we'll kind of make it a a regular.

A

B

Cool cool anything while I'm out leverage, Jack and he'll be happy to help out with some guidance. Okay,.

A

All right, perfect thanks all.

B

Right take care, I'll catch you when I'm back see ya.