GitLab Create Editor Group, 20 Nov 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: 2019 11 20 Weekly Sync

Description

Weekly Editor Team Sync

A

Right I should have said poppy once they that's.

B

How that would sound much more happy.

C

D

And there's pain cards to see if he was on his way and I guess I won't ask time enjoy the same question.

E

Are you all waiting for me yeah.

D

A

For that I'm still distracted reading for it's perfect.

F

I'll take it.

E

What sorry I.

F

Said I'll take it that we were waiting for you. It's pretty sure you beat me by like that's.

E

F

F

This is like, in the context, snippets and thinking about single file editor one of the things that Marcel and I were working on wills.

F

Single file editor discovery, design, I think this was. This was sort of a request for Paul or from Paul, so I'm glad that Paul is on I guess what we were selling I thought yesterday.

F

I think, there's notes below I can go and find the recording and also toss it up to you, but it was mostly I think Paul's s was like what is kind of like the components of like the single file editor like when we think about building components very like that you would want to reuse or that you would want, as some things I think that was sort of the s, but I guess I'm, trying to clarify what was the ask and then what are you expecting to come out of this because reality like if you look at the Ace Attorney, look at Monaco unless you're, like you, know, right click and you source, you can't really tell the difference between like the numbered lines on the left and the the things you can take on the right between the two.

F

So it what are you? What is the expectation coming out of this in terms of what you'd like to see or what would be an official good spy question for engineering.

G

um Yeah for I heard you mention my name so I'm responding now and now, I'm talking about responding.

G

uh What would be awesome for me is seeing where we're in all the places we do code editing what it's um reusability opportunities and what is the refactoring effort of like so here we're doing like a discovery, design I'm like what are the use cases course I'm doing editing in the web, IDE or, and the single file editor the ACE editor or in snippets kind of basically, what you're saying you I from an engineering perspective, yeah I'm interested in reusing the components that we have and to have the consistent UX is interesting, but mainly highlighting what are those reusability opportunities.

F

E

Would add? Oh sorry, I would add some thoughts. I think you'd be interesting to while you're doing this discovery stage.

E

If the proposal could be cemented on the basis of what we have right now, like you from our cell when you're doing the the visuals of the mock-ups, if you think about grabbing the one we have right now on the web, ID like full-page, shrink it and then write hiding some things tweaking some things: changing some colors, so, starting with what we have right now sort of like moving things away and re-enabling it in a style of that that would make our lives easier because then the rewriting would be smaller.

E

Then we just start something from scratch, but we were already thinking about that. But I just wanted to to mention that cuz. It's a good thing to keep to bear in mind is that useful.

H

And you can see these in the agenda right below our meeting we're. Currently, we have to sing the file editor, and these are only three places and the only thing we really have now is a text field. It's there's like the header and everything around it. It's already separated away from the ACE editor, it's our custom code, so there's kind of our first finding that right now, if we would move to any other place or any other editor, it would basically just require to switch out the editor field.

H

There's nothing around it right now, that's depending on ace.

H

F

At least from a visual perspective that we could tell like how those commits and save buttons and like how they talk to ace beyond, probably leave my understanding, but at least visually like it's, and that was that the ads were from where we stopped. It was like visually. It's the like the editor piece. It's the line numbers in the places you can type code is that's all that you used from the ACE editor everywhere.

H

These pieces countly don't take, for example, the code on the syntax, highlighting theme into account so that the single file editor already does not use like if you have a dark, syntax highlighting theme. It's still like on white different to what we have in the file view.

E

And I think that's the same thing for the web ID as well. So we don't correct.

H

A

E

And did you in? Are you starting to think about having some sort of chrome around the editor or for now we're just thinking about like the input, the text area, and that would be like our UI for a single Tech single file, editor.

H

We tried yesterday to separate it a bit and to see right now if we just want to replace eight at a time and if the challenge is just getting rid of face, what would that contain and I really just in the text field, whereas figuring out one code, experience for everything might be a bigger challenge that we also have to involve other stages in way more than in this first NBC.

H

E

E

That scenario of us eventually needing a scenario where we go from single file to multiple file, then that is still on the table. We just have to figure out what would be the action what'll be the UI that will trigger that change to like open a new tab or something that would only be available in certain environments or certain conditions like in the case that when we have multiple files for snippets, then we would probably enable that option not for the rest of the cases right.

F

Like if we end up supporting a use case of like if you enter into a single file, I didn't move it and then like somehow, you could expand it hit the tree view back and like tap out and do whatever right, yeah we're, not even thinking about it. Yet I think like the goal is like no, let's get Monaco in place of editor and in these smaller use cases, and then I think see how that goes and then work on the rest. Okay,.

E

Yeah I think that's a relevant point, because, even though we're not addressing it right now, it might have affect the way we structure the code like the tabs component with something that would be prepared to be enabled in a single file editor when we move and even like the in your inner workings, because they're gonna have to be some backstage infrastructure to export the content of the editor to the outside layer to the embedder. So so so to speak, you can prepare all of that to be instead of a file.

E

You could be already a list of files that only has one element for now. Does that make sense mostly to the front-end denison Paul yeah, because there will be eventually some API that will export to the whoever embedded to export the content that that's edited. I would like to have that API well defined, and instead of just starting off, which is the content, will be like a list of contents. Then a list of stuff any other thoughts.

G

Yeah well, while we're talking about this, and given we had a recent issue about hey, we could expand like a commit message for the web idea too. Potentially, support like fix of, commits whether I'm, editing just a single file or multi files that commit step is always there all of it to say.

G

There's, there's a it'd be really nice. If we had just one editor, because that step we have, if we have to end up duplicating it like there's, there's some overhead there, even though the process of editing just a single file is very the commit stuff.

G

Is it's duplicated, so I really like with Andres, saying like if there's a way to make a distraction-free multi edit, where it looks like it's single file, but very few people doing multiple stuff if I need to, and we just it's the same pipeline so that final commit step is the same like there's a there's, a really nice win there. If we can have really just one editor with like different modes, I'm, totally, jumping ahead into engineering and planning this, but yeah I, think that would also.

D

F

Think we've decided to do anything. Those were like my versions of how many other things were going on on. The page was like in terms of like what else exists in those screens like there's lots of things, unlike the single file that it blob here so I, just I called it like the large implementation, because there are more components. They don't like this snippets one has like fewer components and then the see I went, one has even fewer components, so I just gave them kind of sizes.

F

I could have just called them small, medium and large, and like drop the word implementation, it has nothing to do with engineering effort.

F

It was purely like a way for me to think about sizing, but also snippets I think we'll do first, because we actually own snippets and we don't own pipelines, so we'd have to talk with CI to do some work like a lead to require a little bit more collaboration and the differences between the two is purely that CI linting I would argue that the CIO ending thing one is this very hidden, probably broken experience today and like the the CI t, means to go back and think about that a little bit more and snippets like I, think we know what we need to achieve and, let's see, I'll ending one like you can go into your pipelines.

F

You click a button that says see, I went and then it just loads a blank editor that you could paste any arbitrary Gill mgimo filing and went it even if your project, like already, has a git web CI e mo file like it doesn't pre populate with anything in there and like let you I'm in private in tested. It's just this, like weird validation thing exits on the side of my point. So I don't know what it's used for so I don't want to mess with it yet, but.

E

You just open up a very big possibility right there, because they're gonna be scenarios where we're gonna need custom operations done on the content, depending on the context that it's used. If we already think in ways that we can enable that for people to develop that into the that single file editor, if we prepare the path for them to do that integrated into the web ID core, we would benefit from that on. The original multi file editor full-blown a web, IDE and I'm thinking.

E

If we sort out a way to do linting, we can provide a way for anyone to write their own linters and by adding support to or the web IDE. They will be adding support to the single file editor and that's a great benefit to have people come into our domain increase.

E

The web IDE features so that they can get that feature on the single file editor when they want to do the CI, CD linter, for example, but this is just for us to bear in mind that we don't want the same situation that happened to the merge request, which, where it's a place, that we know a lot of people want to play with, and we didn't do a lot of. We didn't do a lot of preparation work so to tell them guidelines or what they can and should do so.

E

We should think about that from the from the get-go and I'm thinking. Linters was just the example that guy was mentioning that I think is definitely probably applicable to more places, but we should bear that in mind that probably other people will want to play in that interface. Well, what will that look like? Is it a side bar that we can pop out, and just like, goes over the text as a report? What does that look like something from ourselves to think about.

H

E

Write down on the agenda that point I.

F

Think some ideas, and then myself we can talk a little bit more about helping to scope. This yep and I think just to clarify kind of like I. Don't know that we'll come away with designs, because I don't think, there's like a lot to design here. What we might come back with is like here's, some information about places that it's currently used similar like what's the oil, but maybe we'll get some more details here.

F

Here are some places about used and like functionality that exists, and that may mean we need to do like have a better technical understanding of like how different or similar these things are right, like you know, Paul mentioned like the commit branch, mr functionality right like if that just was the same in all of those places where is like the single file editor today.

F

Has this like multi-line text box, that you can write, commit messages in and the branch is just like a free text box, like you, know, there's no way to start a merge request for a single file editor right like if we want that experience to be the same, then, like you have to think about I, guess how we want that to flow, how we could use like the same stuff.

F

We've got in the web ID because we've, let's say that's our best working example of like how we want that to work, and then how do we reuse that or what that could look like? So, okay, yeah I, don't think it'll. It might just be like a series of recommendations and thoughts versus like okay designs, the.

E

Specific designs, we can work out in the issues once we pick them up and we can ask myself for clarifications at each particular step, though the other thing I would raise at this point is that for us all to be aware that there's tooth to big efforts in this scope, one is making the web ID embeddable and the other is enabling the single finite single file editor. So there are two significant efforts. The embeddable might only allow the single file editor to be enabled.

E

Would you we don't know, but the the embeddable part is something that is not out of the box. We have to figure out how how that would look like.

F

And when you say embeddable you're saying because currently the web IDE exists in like its own path, namespace, it's not like a appended slash edit to the end of like where you are, in the blog view, right yeah,.

E

Basically, it's like a full page app right now and you want to make it available in a snippets environment. Then we're gonna have to embed the the code of the web ID to run there, probably with the single file editor enabled, but maybe that's a requirement like if you embed it, it has to be in a single file mode or probably the single file mode only makes sense when it's embeddable, but still the work to support that embed ability has to be done, including as part of this effort.

E

It is important to were to understand the requirements of where they will be used and how and how should we enable that so the discovery is the first step anyways, but when we start writing code for it, when I have two big efforts, embed ability and single file editor, then it's you yeah I'm,.

B

Wondering whether depends on whether we'll have beast your parallel efforts or not like whether any of them should be prioritized or was just like, based on some technical availability or something like this I would say that embedding the editor is.

B

Could be could be considered bit higher priority because once the editor is invertible, we can embed it in different parts of the application of the product, even though I'm not supporting single a single file editing yet, but like, however, I'm not sure whether whether it will be useful useful at that point, if we don't provide the single file, editing yeah, is there any idea? What is higher priority in this I? Think.

E

You're right, just from my point, it's just like embed ability will always be the first step that we will take. Then we build a single file into it, whether we make that available or we announce it as a feature to be able to embed the web. Id is to be seen because we have to see that the shape of it all yeah.

G

No I think I'm excited about making an embeddable for another reason too, because when you embed something, you have to have a clear input/output for it right now. Our web ID doesn't necessarily have that and it's there is some technical debt there and that's where our bugs come from so to make it embeddable also implies that there's a good design here, which means that we'll have less bugs so I'm excited about prioritizing this also for the refactoring and for them just making things a little cleaner on the inside I.

E

Agree and then that basically includes that when it's embeddable, we'll probably disable a couple of features on the web ID like commits now your embeddable, your not, but we have to figure out what's what's part of the feature set of the embedded version and the other. What's the feature set of the single file because they might differ, I think.

G

Jumping ahead to engineering like I, think the engineering like I can see having one component with different modes being helpful, and maybe this is because I like using them. So that's.

F

Okay, I think I understand.

F

What we need to come out with I think we'll have to think about this, a little bit more, more so of like yeah I hadn't thought about like an embeddable version of I.

F

Just want to be clear what you're saying is like you want to see an embeddable version. I, don't think the entire web IDE as it exists today, hey was that what you're.

C

E

Feature set: I, don't really I'm, not really longing for that as a feature, because if I wanted to have the full full-blown web ID, where I picked the project where I multi commit whatever I just use the full-blown. So I don't see a lot of use cases for the for the embeddable multi file.

E

But if you're sharing code base with the with a big multi file editor in the single file editor on the embedded version, that's going to go into snippets, then it has to be embeddable now whether we'll be enabling the multi file flow of things to for people to embed anywhere. That's to be seen. But I can pretend see.

E

If we want to make this available for open source projects, they could just make their own website and have the web ID set to their project on github.com and they would open in their domain the web ID that, for that particular case, it might be an iframe to be honest but but yeah. So those I use cases that we might figure out along the way to what I'm saying what I'm raising is that for us to be able to put the web ID single file in the snippets page.

E

It needs to be reworking and into an embeddable shape. Now that doesn't need to be a feature per se embed the multi file editor, but the single file editor apart from being like a reduced version, needs to be embeddable. That's what I'm saying is that clear, clear I.

B

I, just I just wanted to have one point from like from purely from developers, point of view like if we are getting into the fields of I'm batting like allowing, for example, in the future Wow I, just don't see why we should not aim for that. But let's assume the web ID is available anywhere as an open source project right, so for for anybody to use this to connect project host don't give up, it was just one thing that that is certainly have that certainly has to be in web.

B

Id is the preview otherwise embedding just to edit the code, probably wouldn't be any any exciting or any. But this is just like the developers point of view and apparently be. This might not be even needed for the for get lapis product.

E

B

I, don't make it any easier. No.

E

No, no I know I get it so the the once once we have the the web IDE will have at least the client-side preview client side projects preview that we already have so that will come down the wire, but we have to figure out exactly what the.

E

One of the features that we're gonna announce to the users, because that the embed ability might just a step toward single file editor or it might be an actual feature that we promote I'm, not clear on whether this is a feature, but it is a requirement to get the single file editor as far as I understand it. Guy is that is that clear for you, I.

F

Mean it's I think clear for me in the sense that, like fine I, understand.

F

Vaguely I guess is the best way to phrase it like what you what you want to do first, and it sounds like so there's something we need to do before we say: let's go put a single file editor in a snippet. What that something is I think it's still unclear like what do we need to do the scope wise there and so like I, think we'll go down some more conversations, I'm, like figuring out? What is it? What are we actually trying to make embeddable, because.

F

Like the use case of like embedding, the current existing full web IDE is like my 32nd. Hot Lee was like I'm, struggling to figure out like what the use case is and like. Why would that end like, and it also is like that- feels like a lot of work, whereas like just taking the like the little code, pain and one of those and like putting it in snippets, feels like not a lot of work, but there's there's clearly like an engineering difference of what okay I.

E

Can build upon that and try to come up with a better answer. So if you think about the web ID as a whole as a as a as a as an animal right, we can have that animal be given different skills. And then we tell them all right now.

E

Jump on a chair, jump on a bed run whatever like having skills, and there will be one entity that would do multiple things right and if we have that one entity be the one that feeds the large web ID that we use today and the small web IDE. That is just like us, like a contrived reduced version of that anymore, but it's the same animal that needs to happen.

E

There's a alternative path, which is that to have that animal be split up into two, where we create a smaller version of that animal that feeds off the same core of that animal like the same libraries.

E

But it's a separate entity. It's a separate object right that would probably bypass the embed ability, but the inner-workings will have to be much more complex so that we can have because the benefit here we want to be able to use to benefit from the features we develop on the web IDE. You want to be benefiting from them on a single file, editor on snippets, that that was the big idea that we had in the beginning, whether we do syntax highlighting for supporting another language that will be benefited from scenarios on snippets and all everywhere.

E

It's used what I'm thinking here is we either we either grab one animal and we make it having different superpowers where I can adapt to where it is, or we have to split up and create this family of smaller animals that then we're going to have to feed and and and maintain which is harder to maintain so our IDs to have one one piece.

E

One entity that is adaptable that has modes like Paul was saying and for that to happen, we'll have to have the same code base be able to run on a full-blown web ID Multi file. As we know today we turn on the flag you just like smaller, but it's the same code that runs on that embedded version.

D

E

The idea yeah so.

D

If you using ability, but it's similar, what you're saying is a block of code that instead of writing, that block of code twice and changing in one place, just reusing the same block of code yeah.

F

I guess my question is: is like it's building beanie.

F

The large block of code, but then you could like take things away from the faster path, then building the small block of code and adding back into it and eventually replacing the web IDE hole with this like new, more modular version. Right like like it's two ways to get to the same outcome. I think is like either like start small with like we go. Do the single file editor, which is like just a text editor? We don't worry about the commit murder blah. We don't worry about excellent.

F

Like all these other things we say like, we want a simple text, editor code, editor and then like the next use case of the single file. Editor is like, oh, we need to add, commit merge, blah blah blah right like and then we go and we find that thing in the web IDE and we add it back into our modular version of the code base and like we keep going and like I guess the until we get to a point where there is like one of these, that is like individual pieces.

F

We've got like maintenance and double we've got double duty: maintenance things might break it's more overhead, but we build to the big game versus like building the big thing and then trying to like take things away to use in other places like I, don't know which one of those is more fun or faster or worse or whatever, but I.

B

Think you already will rehab the big thing right, so what you have to also recount for for our input data. We already have a big thing, so it's only natural for us to start here and go downwards.

B

If you would now consider building really new thing, then of course, your approach going from the small thing and like extended with some features, makes total sense. However, we have to account for something that we already have now and all the expertise put into it into the web, ID that we have now and I think in this case, going downward downwards will be faster and more efficient than doing something from all the way down to the top. That's that's my personal opinion. From the engineering point of view, two.

G

Circles, conversation back to the UX design effort element of this because I think there's a a lot of really interesting engineering ways we can go about this, but the way this all affects UX is that it would be great if the different modes that we're seeing with a single file view in the multi file view if they didn't differ significantly so yeah we're talking about stripping away features and being able to configure this.

G

Whether we end up having two components are one big component, but if we have it well for in single file mode and the way I edit and all of this is very different than my long-term vision for web IDE, that's gonna make things more difficult from the engineering side. Where hey, we can see a lot of benefits having just one big component, so kind of going back to somebody mentioned earlier. When we talk about what can we do from single file view?

G

Reusability is gonna, be huge of having this consistent, editing, experience between single file and multi file. However, we end up doing that in engineering. That's another conversation, but yeah we find. Let's design. Engineering is really interested in having just one component that we can configure this way, not necessarily having two different components for this I. Think.

G

Yeah and I think I mean it's different, it's different, we do it and that's what we don't. Naturally I think it's make sense. Heaven in the day offline, well an async conversation about this because yeah we could take what we currently have modularize it make it reusable or what I think I was saying is: let's start from scratch, whole things and make this reusable thing brand new and then like back ported to love, idea. I think these are both good approaches.

G

I think it's gonna, take some more thought and discussion and how to do this from the engineering perspective right now, we're just talking about the UX design. I think it I think. The thing to stress here is just the consistency between all editing of gitlab would be great, because then we can do it in just very nicely in just one component, where we're just stripping off features now I'm like completely changing or feature no, no pressure on you, Marcel no.

H

And I actually um I threw together something really quickly. It's not the general idea, but I would love to hear whether this is like the direction you want to hear for me. So I put together a quick example. So this is our current snippet view. This is what we currently have in the web. Ide and I just stripped out this editor window put something like tiny, add another file as tab in here and then pushed it into the snippet view. It's this kind of what we are talking about.

H

This is kind of what you need to see good.

G

Yeah, this kind of thing is very much so, yes yeah, you should have started with this myself.

H

Like two minutes.

F

Like the create snippet button is really like the commit button right, and so would you rather is this? Where, like we get into like the you want to see.

E

G

And I think I think when we talk about engineering like the output of the web, IDE isn't necessarily. The visual part of the tube output is also this API that comes with it like we're. Gonna commit these changes for something so UX do what do whatever it makes sense, but yeah just making sure there's not some stark differences between the two is I think most important, yeah other means a comma dear.

G

The rest of the conversation, Andre and I have our one on one and if we don't have it I'm gonna freak out so I'm just kidding no.

F

I appreciate it's a I think that helped a lot for where Marcel and I can get stuck in I understand more what you're, looking for so I think that gives us a place to go and think about this differently than we were thinking about it, which is good and then come back with kind of like here's how we envision, we would use this kind of all over the place and then, like understanding, like all of the pieces. You're looking for for consistency, makes more sense to so I think we've got a good good idea.

E

D

Thank you and myself. These discussions are being documenting like an issue somewhere. We could put these nice designs that well.

F

So the our discussion yesterday was is right below so we took notes and recorded that one. So we could talk about that. We didn't cut, there's no nothing. We didn't really come away with anything, but we will make sure that, like the design discovery she gets updated with whatever we come over.

F

Cool it looks like the next to work, covered or sort of read-only ish.

E

Anything you want to add urgently Paul to so that everybody's aware I'd.

G

Like to have a source craft conversation, sometimes in is there's some open issues about this and I want to make sure that we've are intentional about the state of it, with the release, posts and other things going on. So if we can have one today, I'm gonna just but let's talk about it on slide about to Justine. You guys on it right now. So very.

A

G

E

D

F

I have no internet good luck.

A

Good luck to you.

A

Man I hope you survive.