GitLab Static Site Editor, 7 Oct 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Static Site Editor - Think Big! October 2020

Description

Monthly Think Big! session with the Static Site Editor group. This month's topic: how we might handle partials, includes, components, and other types of re-usable content in the Static Site Editor.

A

All right so now that I'm actually recording I'll just restate what I said: we're going to focus on a job to be done and have an open discussion, static site editor group is having their first formal, uh think big session in a while. So um the job to be done, I'd like to discuss today is uh when creating new content on my site. I want to be able to reuse it on multiple pages, so I can reduce repetitive tasks and yeah.

A

Let's, let's chat about reusable content and and avoiding repetition within the the construct of a static site.

B

um What kind of content is there um like? I know that we have yeah mo files, but um besides that, are there other types of content that could be edited like this.

C

I think that the partials that are like uh small views are embedded in other pages is another example.

B

And are partials also yaml files are. Are they like like what's the erb file? Is that, like a ruby thing or.

D

B

D

So the way most of the extensions work like they're nested on each other, so there could be an html.erb. So that means it's intended to be pre-processed and there's some inline ruby.

D

uh I think enhanced ruby is what it's for and then once it's run through that, then it's turned into html or there could be like erb.json or.

D

Erb.Camel.Html right, you can have multiple levels in there. The pre-processing passes it down to the next extension.

E

And in the context of not just the handbook, a partial could be like a view component or a react component or basically at a high level, any amount of code that needs to get pre-processed such that its output is basically some amount of markup that's going to render in the browser.

E

So that's that that's basically kind of the tricky piece is: how do we differentiate content, which is just like typically images and text that the kind of a general marketer might want to be wanting to change and then something that's kind of generated?

E

um I think that's kind of the best way to think of the difference, maybe is what's statically there and then what actually needs to get generated uh might be a good way to think about that. Maybe.

D

The the other thing to you to be aware of, I think this is in context for this- not me if it's not is that, like the example of proxy resources in middleman, where it's actually just mostly an empty file, that's driven at static site generator, build time by data files and, what's actually contributing to that content being generated, could be multiple data files, multiple logic in ruby files and for different static site generators, for example a go or hugo. It could be a completely different language or completely different data files.

D

It could be coming out of a database. You could really do whatever you want. So it's it's not like. We can solve every case, but you know for the ones that we support. We could try to do some, but it'll. I think, in the more complex ones, always involve a lot of knowledge about what the static side generator and your particular side is doing.

E

We I'm just spitballing here, but we may be able to. I agree with you. First of all, like salt, we have to be very selective, especially beginning, like what we're trying to solve, um but we may be able to add a high level bucket if we can anyway bucket what is actually like source data which what right now in our handbook would be like yaml files, and there might be other things like. I didn't. I wasn't aware of what you just talked about. Chad like it sounds like yaml files generate this proxy file.

E

That then is used for other generation or something I wasn't aware of that. um But maybe, if basically I think, there's three ways we could bucket things. I think source data, that's in like gmo files, for example, kind of partials things that get generated in the templates themselves and then actual static content itself, which is again like text images. So I think those are three ways we could bucket it and that might help us solve problems.

E

Basically, it's like we could solve it in a particular bucket, knowing how its impact might impact another bucket or something.

D

And related to our particular discussion yesterday, around proxy resources in gitlab there's a feature called route maps that could possibly help with this uh and they're they're used for review apps, but they're a way of mapping a given url path to a file that lives in the repo somewhere. That may be in a different location, which is really similar to what we're doing for review. Apps they're used. So when you click the review app button, uh it's actually a drop down and it it can use this route map yaml.

D

You know it's under get lab route maps yaml to look at all of the files that you've changed as part of that merge request, and then it gives you a drop down of links uh which will go to that corresponding path in the review request, whatever that url is based on the file that you modified from and it uses that route map. Mapping for that and I'll drop the link in the dock. For that feature as well.

B

Is mapping a thing of middleman.

D

B

Is it a thing of gitlab the product.

D

No, it's a it's a feature that, like I said, is intended to support, get lab review apps in the ci workflow. Thank you.

E

Yeah, I don't know if that's the exact same thing, but it sounds very similar to kind of just the excuse me like the gut solution. I thought of in terms of uh what started this job to be done is basically like. We can pre-cache the directory structure. We know what that is right, so that we can very easily provide links to the actual file, that's being referenced in the current file. You're editing. um That seems to be pretty straightforward. I don't obviously there's always more.

E

It's always more difficult than you initially think, but that seems like pretty straightforward to solve and uh is that, like the? uh How close is that chad to the route maps thing.

D

I I think it is like a couple of days ago when sid was asking about this. I remembered I was like wait. That's almost exactly what we need. It's a one to many mapping of uh past relative to the web route to multiple paths in the repo. Maybe it's not one to many, but it's definitely many paths to many mappings in within a repo.

E

I'm definitely solutioning, but I can see uh an example where we have the file. We have its uh associated dependencies and then that's just a tab structure of all the files that you can edit associated with that like so we bring it to the user. They don't even have to opt into it when they want to.

E

I don't know if that that obviously might be a ux thing, but and I'm definitely solutioning there, but that's a potential path.

D

And the nice thing about this is like not only that it's already built into gitlab. It's like a standardized file format, but that in these cases where we said it's, where it's completely dependent upon how they built their site and what their static site generator is, they have control over it like they can edit this file to set up whatever mappings they want. It may be hard and tedious, but it it would be. In any case, I think it at least makes it possible.

C

So once we uh discover the file uh that the user wants to edit, that has a content. What is editing experience that we want to provide? uh There are many types of content. uh It could be a code that I've got a file in general. So what?

C

How do we want to display that that information? uh What is a user? What is a user? We are going to do with that file within data.

E

That's a great question: I can't help but think that if you're opting into that you're you're you're kind of leaving static side editor world in the sense of this isn't a wysiwyg most likely. Obviously we could have some kind of like dedicated ui for a yaml file right but which would be cool, but my gut is that wysiwyg for, like the core content. Obviously the things that are generated you kind of were going into codeland and then that's probably a more common code.

E

Editor like our editor light or whatever would kind of be my gut yeah. That's kind of comes to mind.

B

That sounds about.

E

B

Going on in my head for that too, like clicking on one of those things jumps into the data files like yaml and json, and you just don't know what that structure is looks like so having a custom editor for that is kind of tricky, but yeah, I think starting off is like just taking them to edit it light um but yeah.

B

I think this will segue too, like a further question is like how big is this problem like um like how many times do people actually run into an issue of editing like the performance indicators or the teams.the ammo like like? I actually don't know how big this problem is, like. I think, sid followed up.

C

B

Like 20 days, so it feels like it's a monthly thing but uh yeah. I just don't know how big this is so.

D

The one way to maybe segment the problem that enrique talked about is you know anything that is ultimately html. We can add it in the wizzy wig editor right, uh maybe other things, but.

B

D

The current approach that we're going to use some something to transform stuff into html. uh We can do that. I think, even with that, one of the questions is: what do we do with partials like are partial shown layouts or partials? Are they shown in separate tabs as different files? Or do we somehow try to leverage the block editing to try to nest them uh in a single wysiwyg editor how they're actually rendered, which that seems like a much more complex problem.

C

My expectation could be to to load uh those components uh on demand. Like oh look, there is a some embedded content in the document, let's load it on demand, and then let me give you uh based on the content that I'm fetching. Let me give you the the best possible way that you that we can give you alternatives to edit that content.

C

So I'm wondering when what is expectation of someone like sid when they, when they are editing, editing a page and going to the to a certified editor? uh Is he expecting uh that content that looks very visual in the page and then they? It is actually something is generated from a jammer file to appear.

C

Also, like you know, in the the final outcome in the satisfied editor.

B

That's a good question enrique.

F

B

I think without uh asking him directly like I'm just guessing here, but, for example, the performance indicator pages are listed in tables right, so it's generated in a table so jumping into static site editor in a in. Like a you know, perfect future.

B

It looks like a table and I just edit, like I update my status of my performance indicator to say like yeah, it's uh on track or whatever and those things are. I don't really care that that underlining data is yamo or anything like that. It's just whatever it is. The the short term is probably like. I just want to change the text of that file and like- and it's so hard to get to that file right now, um but yeah.

B

I think in the super in the future, where you can actually show what the yaml file turns into and allowing people to. Edit is probably like the think, big kind of vision of this and that's a lot of effort, but I guess that's why, like? How often do we need to do this? I know like product marketing probably probably has a few pages that are generated by yaml files and but uh yeah the ideal world is, it's almost like. What you see is what you get for everything.

D

I'll go ahead.

E

um I was basically just gonna echo it. uh We just said michael's like yeah. How big of a problem is this? This is kind of right now. It seems like a nice to have, um if I remember correctly, because I did respond to the the thread in slack. It really did just seem like from a jobs to be done. Perspective he's like I'm, editing this file. I have internal knowledge of how gitlab works.

E

I actually know that I need to update the the data because it has a source, that's generated, that's the then output, so he just like. What's the I know, I know what I need to do. I just want that file here, so I can edit it like. That's really what it seemed like um again. It could be wrong. That was it's really what it seemed like.

D

Yeah, I'm I'm reviewing the thread and like what he said. Can we make sure every performance indicators item generates a link to edit it somehow which uh to me means like it just wants a way to know, because that particular page there may be multiple yaml files backing it. You would maybe want like a link from that to the ammo file that uh bats it, which that might be hard. uh We really need to find out if the route maps is like one to many or not.

D

If that's going to be able to support what we want, but um even that is a hard problem like editing it in in place or like figuring out and making a link to the the doc that it is all of those solutions involve knowing about the code that generates it, because that that code, linking that piece of it html template to the yaml file, is in ruby somewhere and it seems I don't want to be a pessimist, but I will be.

D

It seems almost impossible to implement that in a generic way that we could figure it out.

B

Yeah um so yeah, because it's like yeah, it's tricky um how I envisioned this was like. The first thing we do is like figure out what that link is right like a way to generate the link. So if you, my thinking of the progression, would be like step, one is get a link and then present that link on the page step. Two is like: now you have the link.

B

You can do what enrique kind of suggested, like click a button and like load on demand, you know, and then the future of that would be like cool. We actually have a special editor for this, because it'll look like a table and here's a table ended.

C

B

And we like transferred it back to yaml and like that was kind of, like my progression of the thinking of um what we could do now to like this future of what you see is what you get um yeah but yeah, getting the link yeah. Maybe it's worth like doing a spike to see if route maps will help with.

D

B

D

So, looking at it really quickly it it's basically just an array of of pair mappings and the source is, uh and this this looks actually a lot like the mounts thing that we just added to the config file. It's an array of pairs and the source is a regex that matches your uh url right and the or that the source is a regex that matches the file and the public is a a path that matches the.

D

File in the repo, or vice versa, but it's really just pattern matching on links. So, theoretically, if there was an anchor link in the html, we could try to match against that and pull a mapping out of this file.

D

E

Kind of a cool idea I, like that, that's going even deeper than where I was that's that'd, be kind of interesting.

E

I was thinking of like what is that source uh config file, essentially whether it's the mounts or whatever, like ideally that thing's generated but chat to your comment earlier, like for other non-handbook repos high level, everyone wants it generated, but if you can't, you can at least still manually create it for small sites that might work, but my gut is like the usings, the imports, the you know, whatever picture, whatever language you're in you can likely create, generate a at least at the very least, a dependency graph and then, whatever file you're in you just map you just kind of go to that.

E

Lookup with the of the metadata of this is what file I'm in it's already predetermined. What dependencies are associated with this file? Those are the ones we link to like that's kind of what it seems like again might be way harder than uh might be way harder. But just from the very I mean that's how, when we import our code, that's what's going on right, like it knows, you're using your imports, so we can at least link to those. But I don't know and chad you might be able to answer this.

E

Is there stuff, that's like somehow in a global memory, during a build step that like it's just there and then there's no way to reference to know that it's referencing? Something like I just don't know.

D

I don't think so. Okay, uh like you definitely but looking at the route maps, the the source part of the the mapping, which indicates the path in the repo is a regex. So I think that me- and I think this is the way the review apps work too.

D

That means, by definition it's a one-to-many, so the the public is the url which is absolute and I maybe it can contain anchors too, and the source is a regex which means that may map to one or more files in the repo, at least, if it we could use it that way, even if route maps doesn't necessarily attend, it.

B

I like this discussion about maps, because when I was thinking about a link back to the original, like the reference file, I was thinking about. You know when you like minify css or it like includes and like you have a setting that like tells you where it is like. The original files like source maps or stuff like that, and I was wondering if like middleman, has the equivalent of that, and then we leveraged that somehow but and hide that from the user as well.

E

I think your spot on, like the source maps, ideas like I, I totally get that I don't know if that's the exact same thing as a dependency graph, but that's the same idea as like. It should already kind of know that like and it's just a matter of us caching, it is kind of how it sounds.

D

So I think we need to be aware of how similar this is to the the mounts concept that we just introduced in the config file. It's essentially doing exactly the same thing.

D

Mapping, you know something in the page to a real file, so we don't want to doing it in two different ways.

E

I guess my question would be: do we and again we'll have to figure out if it's worth having a spike or not?

E

But I guess do you do you expect us to be able to have that that file generated, and then we simply as part of ci, I guess or something pluck the small portion that actually maps the corresponding file you're trying to edit and just insert that in the amounts does that make.

D

Sense with it being a regex, and I would think it would have to be done, client-side right unless we like to use that regex to generate a list of every possible file it could match and and ship that over as the the payload when the page loads. Otherwise, we would have to have an api that passes that regex to the back end and gives you a list of files yeah. I.

E

Guess we're getting maybe.

D

A little interesting I don't know.

E

I think uh yeah it might not be super clear. Basically, what I'm thinking is. We already have a pre-cached like a like a a static file that exists that was already generated so and it understands the dependencies, that's what I mean by dependency graph and then, when we query a particular file to edit from the static site editor. The backend then looks up again in that static file, or maybe it's in a database.

E

I don't know, but it probably makes more sense to be a file and then plugs out just the small portion that needs to go into the mounts, because just that one file maps to you know whatever dependencies are associated with it and that's the payload, because yeah we don't want to send that entire thing down to the client either. um Does that make sense.

D

Maybe I'm a little bit vague on what you're talking about, but it's kind of a performance optimization, I don't know, maybe a little bit in the weeds.

D

E

Just curious, if you're.

A

Talking about sending.

D

The data over versus sending the whole page over but.

E

I don't know, I guess the high level like can we do we have the capability to generate that file and understand the dependencies like if we.

D

Don't have that.

E

Then we're screwed.

D

Thinking about it, conceptually like this, this concept of mapping some url or the the href attribute of an anchor tag to multiple files. That's conceptually what we're doing and then it's like it's the ux issue of like how do we display those files? Are there different tabs? Are they in line and it's the technical implementation issue of like? When do we pull this data down? Do we do it at load time? Is it on the client or the back end or both, but conceptually it's mapping.

D

You know web routes to one or more files in the repo.

E

Okay, that might be where I had a personal disconnect. I was still thinking of the dependency graph, just being like the imports at the imports level, not like, which I think your idea would be even better if we had that and understanding all the links that it links out to that's where I I think I had to disconnect with you um that'd be awesome. We could do both, but I was thinking more of this file.

E

What did it depend on to generate its content? We should probably be able to know that in advance and that's what I was that's where I was.

D

Oh, so, being imports that could in html language, that's like a style sheet tag include a javascript include or whatever language that it's in imports or requires.

E

Exactly that's that's a different way of doing it. This specific example. What I was thinking of is that the yaml file like we know that yaml files needed to generate the content in here.

E

That's what I'm can we understand that in advance and have that baked and then once we know that, then, when the client actually requests editing that specific file, we already have the prebaked understanding of the dependencies, and now we just pass on the links and the amounts with that, and we can say either you can link to it or we can actually let you edit that file or we we can do whatever we want, but first and foremost, we need to understand that dependency. Basically, that's how I was thinking about it.

E

I don't know if that makes sense, but I, like your yeah, I like the idea of understanding even deeper, like the links that it links to like that could be interesting as well, but.

C

I wonder, and this this is probably a tangential question to uh to the program um I want we we are building or thinking about. I want to require building or thinking about a solution uh in the context of a project that is very wild and complex, like the handbook.

C

And you know if we, if we, if we had more control over the static side generator if we had more control of and being capable of setting constraints on users about what they can do and they cannot do uh could be. Could this be a a simpler problem, um because I think that every time that we are designing a solution, uh we have, we have to think about global optimization.

C

We are, we have to think in the context of a project that has like many types of uh supported files and it has like a complex dependency graph uh like that they have the hundred dollars. uh You know like it's, probably crazy, but we're thinking big. So I wonder if, in the future it will be beneficial for us to vertically vertically control everything uh within the the entire. You know, process of create of of a user having the the product of you know the statistic generator and the hater.

C

At the same time, I don't know I'm explaining myself correctly.

E

I think that makes sense, you're basically like yeah. If we can put rails on what you can and can't do, that makes the problems we have to solve much more, you know simpler and straightforward, and that kind of thing I think that's what you're saying and is that what you're saying.

C

Yes, that's what I'm saying, uh because uh right now, perhaps all the reasoning that we are doing is in the context of uh what we found in the middleman or but what happens? uh What? What are the ideas that or in which way, those uh those ideas are implemented in a different static site generator, and that's for me, uh is quarrying.

C

Because I, just by by looking at other implementations, uh for example, gatsby- that is a modern one they are so. I think that they are solving these problems. uh It's slightly different right.

E

Do you happen to know like just roughly what how they're solving that and when we say that, do you mean like the idea of partials or dependencies.

C

um Well, they're they're using react components and every every page is a react component. So that really changes the rule of the.

E

D

D

I like the that sentiment, but I think that the 80 case is going to be that there's always some edge case like, for example, hugo has has data templates, there's most popular static site generators are probably going to provide a way for you to do something: custom with data or for building pages, and most people are going to use those at one point or another.

D

The the thing I like about leaning towards the the route mapping approach, where a url maps to a regex or maybe multiple regexes, is that's generic and even though it needs to be manually maintained as as an initial solution.

D

If somebody wants to make it work, regardless of how their site is generated or what status that generator their use, they can still make it work, but with some maintenance and anything that involves like magically figuring, this out is, I think, gonna, be a lot of work and very coupled to a specific generator, even if they're they're, using it mostly out of the box.

A

I, like your question, enrique though um I think we've we've gone this far specifically stating that we are not looking to create our own static site, generator or or template language, or anything like that, and um we're not looking to we're looking to provide a solution that that encompasses many.

A

If not all or you know it can be as universal as possible, but I think it's okay to challenge that, if, if we solve problems more efficiently or more elegantly for our users, um I know, for example, that I think the foundation of stack bit is based on that or just it's. It works universally, but their platform is based on their own static site generator where they just like bring everything into it. And then you can manipulate your project using their template, markup language, so they have more control.

A

I think another one publi or something like that. Does this a similar thing where they have their own flavor of a static site generator? um I don't think it's off the table that we could.

A

We could think that big down the road of having our own, our own uh generator and our own rails, to to run everything and just hope that everybody wants to join us and and not necessarily bring over any of their projects or make importing those projects really easy. um So yeah, I think that's a it's. It's an important question to ask while we're thinking uh this far out and yeah. I don't think it's that far-fetched, because others are are certainly doing it.

E

It might be a different way to look at it, but I think what enrique is uh talking about is that we're actually already doing that like in front matter. We only support yaml. So that's where you know that in a way we're kind of doing the same thing. I don't know if that's exactly what you're talking about enrique, but I mean that's kind of another way to look at it, at least for me,.

C

Yeah, well, it's more like um we will be moving faster if we have control over many of the decisions that the user is taking, but it's like those decisions uh are forcing us to implement uh support for for them. I wonder if, for example, uh a platform like uh that is providing a cms solution. uh They can create a user interface because they are, they are they have control over the underlying platform.

C

uh So it's like um thinking in that direction.

E

Cool thanks for that.

A

um We don't have to get to all of these, but I left a few prompt questions that we can pick up uh in the agenda, to kind of reframe, on um sort of user intent and and maybe get a better sense of what what they're really trying to accomplish when they're, creating reusable content. So when users are um either creating or or trying to find other content that is already created to be used in their page.

A

um You know what types of I think michael asked this at the top, but like what types of content is that we've talked a lot about data and the ammo files. But are there just examples of other type of types of content that they want to use?

A

And I like that, you mentioned the react components, because I think um in my mind, I'm approaching this very similar to like a a design tool problem like figma or sketch, where these um these bits of reasonable content behave a little bit like components or symbols, uh and and they might have instances of them in the document. But would a user be expecting to edit an instance of that or um the source of of the reasonable content? um So I'm curious what your thoughts are there? Maybe we can tease apart that kind of statement. There's.

C

A

Few others, if, if you want to browse over them and if they spark any other interesting topics but I'll, let you respond.

E

That's a good comment, the yeah. What what is the initial intention? Is it the source of the instance? I totally get what you're saying there. I think that goes back a little bit to what I mentioned earlier, where if we in theory have those buckets that at least kind of helps us right like they're editing, not data, they're, editing, not static content in text and images, they're editing, you know a partial, essentially a component, and then it's like. Is it the instance or is it the the original.

E

But yeah I like the the because yeah design tools, that's a big thing. I never thought about it that way in terms of like content like a site content. Really that way, I guess.

B

Another way to frame is like slides or google docs, where you have like the header and footer and like you, see it and it changes dynamically. But if you want to edit it you like edit master templates or whatever the root one, and then you change it um yeah.

B

Maybe it's worth doing all the the different types of content in the context of them to see how it's used in the scenario, data and data yaml files- that's probably just used as to generate the same data across multiple pages but yeah where they're. So something like the footer is like probably an example of something that gets included across pages, but that feels more like the whole page kind of template, rather than what we're trying to solve here.

A

Yeah, I think you're right on their footer content, is a good example of reusable content, but one that would probably be in the page template itself. I don't think it necessarily has to be, though, if somebody had architected their page where the footer was not included in every page and they wanted like a different kind of footer for the blog page versus um another marketing page or something like that. You might actually be opening a file that contains uh data about footer links um so yeah.

A

I think that's a that's a good example of something that's not too complex, just a list of links, but that somebody might want to include inside the page.

D

One thing: okay, go for it, thinking about uh like the route maps versus the the mounts config that we just added in a config file. The mouse uh thing was inspired mostly by hugo, and one difference between them is the at least following the hugo example.

D

It's saying, okay, this particular path maps to everything underneath here and it's assumed to be an exact relative match for the the subpart of that path, whereas the the route map approaches is more flexible, it's a given path like we have a regex that could possibly match you know anything in the repo. It's not necessarily uh considered to be a subset, and I don't know if it's relevant, but there's just wanted to point out.

D

There's two different ways of thinking about this problem like something that's directly relative and and maps, maybe just without the extension or we're just pulling in a random file and like in terms of the footer. I think, like I was saying stuff. That's html, like that's sort of clearly rendered and if it's a partial, like we're, still going to have the the reused partial, but the data file is sort of a different category like you have to find that via some mapping and you're.

D

Not there's really no way to show that in line it needs to be in a different tab, somehow or displayed separately in in a different editor, because it's not html.

A

I'm just picking up off your last uh last sentence there. um I I was curious to to pick up that thread about linking out to a different editor. What do you all think about the experience for users um leaking out from the static site editor if they had maybe an open session and they're editing content in the static site, editor and then they're presented an opportunity to go out and to a different experience to edit related content? How do we handle that? What do you think the user journey looks like there.

B

A

B

So, like a simple like one of the things is like if I make the change in the yaml file- and I make a change in my current page- is it one, mr or two separate mrs, and then that kind of dictates that flow? um Do we want to be slick and have like the editor like in page and split the page and do the side by side like this is the data.

B

This is where it's going to go so almost taking that idea from a stack but where, instead of having nice label fields like key value pairs, you open up like the file raw data file on the side, and then you make the change and you click save, and we render it on the preview and you're like cool. That's what it looks like um yeah, um yeah thinking.

F

B

I probably would say what you see is what you get all day, but um short term yeah. I think in the spirit of nbc is I see nothing wrong with opening it up as a separate.

C

B

Like the editor light and then going from there, um the the the one question I have is like, like I haven't, thought about it. Deep enough is about what that merge request looks like or like how do you know that? Okay, that that change I made this should be part of this merge requests, but that's probably something that you know we can think later.

E

My gut says that it's the same merger question, that's like that would be like a common thing if you were to just pull it down locally and not be on the static side of it or you're, making a change here, you're expecting a file, that's completely somewhere else in the repo, like that's they're, still, that's kind of the intention. I think um one thing eric you mentioned, obviously like link out. Obviously that's one solution where that's kind of uh less than ideal.

E

If we were to then still be within the same ui and just have it be a pop-up or another tab or whatever the editor like. That's just like a small subtlety.

E

That obviously creates a different experience which may be intentional or not depends what you want to do there.

E

One thing that definitely comes to mind is once you go down this path of editing the linked file, we're kind of.

E

It's kind of for the uh it's, not our target user, almost anymore. I feel like because you're you're kind of editing code now and the whole is kind of how I see that, if you're editing, a partial, you're, editing, kind of a yaml file, you're editing code and that kind of takes us away from our original target user right. So then it's that's still still maybe a feature, that's desirable, but we need to communicate through the ui that, like you know, this is like it's code time.

E

So it's going to be a little more difficult or whatever. Unless we get to the far reaching goal that michael just referred to as like everything's wysiwyg, then we don't have that problem, but otherwise it's yeah. We need to clearly communicate in the ui that, like it's, not wysiwyg mode anymore, just the same way you go to markdown mode. It's like you just know this isn't. This is just raw text and that's basically what you do. Is we okay you're going to be editing raw text now, um at least.

A

Do you think, do you think these partials are always going to be code based or is there a use case for reusable html that could be presented in the whizzy way.

E

I see what you're saying yeah good call. I forgot about that idea like basically having a library of plugable uh yeah. I get you as you're saying um yeah. I forgot about that idea, but I think of a lot of it is the the I think that's two different things actually is. If this file has particular dependencies, that's those are basically code dependencies, almost by definition.

E

If I, if I'm understanding it correctly, then if you want to reu like reuse existing like snippets, essentially that's a different thing, I think am I understanding you're right.

A

Yeah, I think that's an important distinction so dependencies in linked files and this source map that we've talked about um could be treated differently than like snippets of reusable code or components that are in a library that could be used within the page itself.

A

I think that's a potentially an important distinction for the experience, maybe at least in the near term like like michael said, it might be nice down the road where no matter what the content is. It opens up in the editor in an embedded code editor if necessary, or something like that, um but yeah. I think that those are probably two distinct use.

A

A

I just realized we're over time. um This has been a really good discussion. I don't want to keep it going too long um any last thoughts before we stop recording and um doesn't mean the conversation has to stop. We can continue it in the dark or in slack and we'll have another one of these next month.

F

I'll just quickly add I missed most of this meeting because we were having a remote. You know they were. One of the questions they asked is like is your handbook? Open source can be forked to start off kind of thing, and you know it just reminded me of this concept of the handbook as a product, but also how valuable you know the static site editor could be. In that context.

F

There are a lot of non-engineers on there that were interested in in this way of working, and it just kind of like reminded me that there is a market out there for the static site editor, and it can play a really really important role in in people's adoption, specifically of not just static sites in general, but handbooks for for large enterprises. You know like for for a while. I've been wondering you're like how do we monetize? Does that exciting, but can it?

F

You know it can be a great uh retaining factor for people uh to stay with gitlab or even go up to a higher level in their packages and stuff so yeah. It's definitely valuable.

B

F

B

That line um handbook as a product and yeah that's an interesting thing to think about.

D

I think the final thought that I had is uh maybe not from your ex perspective but from a technical perspective, uh an mvp boring solution of something just to like solve the problem.

D

Sid wanted is feasible, but I think what I've realized is that we need to put some thought into what we're doing with that mounts config and when it's actually going to be used for and how we're going to use it, and maybe it turns into something that drives this purpose instead of route maps, which is really not particularly intended for this and might not be as flexible as we went down the road.

A

That makes a lot of sense and, um I would say, yeah we absolutely want to be iterative, and I think there is an nvc that we can ship to address to specific requests for this. It sounds like we.

A

There is actually uh um a likelihood that we can solve this, um which is great, and I think, though, sort of a good way to just think about this as we leave this meeting might be, how would we make the static site editor and the handbook architecture different, so that he could accomplish the same goal of embedding that data file without having to write that custom, ruby helper and include it on the page that causes us to have to render it the way it renders and then solve the problem in this way.

A

So could we solve the problem upstream, a little bit differently, allowing users likes it or users like whoever's, making those um performance integrated indicator pages um import the data differently so that we can handle, I think, to enrique's point earlier. So if we had a little more control over how they brought the file in and how they created the page, maybe then we could control the experience and editing it just a thought. A closing thought.

A

But thanks everyone for um your input, I I tried to take notes but um feel free to clean them up or add any additional comments, and we will, um of course talk about this and many other jobs to be done um in upcoming.

A

I think big sessions and weekly meetings and if you have any, if you have any desire to to keep um to schedule like a longer synchronous session on this topic or any others, just let me know we don't we can do it ad hoc as well all right. Let's stop the recording thanks. Everyone.