GitLab Create Editor Group, 30 Jul 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Create:Editor & Plan:Project Planning - Sync on WYSIWYG editing in issues and epics

Description

Product and Design from Editor and Project Planning groups discuss their future visions for editing issue and epic descriptions and how the Content Editor may help.

A

Great, so now that we're recording, I will reframe the discussion. This is just a sync between the create editor group and the plan um group to talk about uh sort of more rich editing experience in issuables and, in general, the the overlap of the content, editor that we're working on and the possibility for um using that in issues and epic descriptions to make a little more um immersive editing experience.

A

So let me just start for like a three minute summary of why we're building the content editor and why it's in wiki first and what how we got here. So we started out as the static site, editor group um and we were building a wysiwyg editing experience on top of markdown meant to uh bring content editing to non-developer, personas or people who might have been intimidated.

A

Writing a markdown and working in an mr workflow within gitlab, and so that sort of uh that category sort of evolved a little bit and we we had an mvc and it's working and it's in the handbook.

A

But we learned a lot along the way and one of the things we learned was that the wysiwyg editing library, that we chose wasn't extensible or flexible enough for our future roadmap. So we took a step back and evaluated some other alternatives and found um this library called tiptap, and it is a rich text, editing library built on top of prose mirror and without getting into the weeds too much.

A

We basically built an architecture around those libraries that has a more modular architecture for being able to replace these elements and extend them without having to get too deep into like customizing, one particular library. So we now have um shipped our first mvc in the wiki, because the wiki has a much more like standard implementation of markdown content. You know it's like a little more confined the the the content itself doesn't go off into like using data driven templates like our handbook.

A

Does it doesn't rely as heavily on like mentioning issues, although you can do that it doesn't have as many complex requirements as like an issue description, so the wiki is sort of our first stab, but it is meant to be an editor. That's used wherever markdown is written in gitlab, so the idea being you could you, as the plan team or or us helping, you could instantiate the editor in an issuable and use it and have a consistent editing experience with anywhere else markdown is displayed.

A

We intend to resurrect the problem space of the static site editor whether or not it's called the static site. Editor group down the road or the category changes names whatever, but the the problem to be solved of collaborating on markdown content on a static site is still one we're very interested in, but we just so happen to have also built something that's reusable across gitlab, and we hope that other categories and other areas of gitlab adopt it nice.

A

It was more than three minutes, but let me give you a quick demo of um the wiki and I'll show you it's. uh I can't.

B

Wait to see it.

A

It's live as of yesterday we turned on the feature flag on dot com and it will be um available in the 14-0 release, so I'm very excited about that, find the right window to share and pull up the wiki demo page we have.

A

So this is the old or classic editor that we have uh it's written in markdown. There is a preview tab, but you know you have to switch back and forth between preview. This is the standard experience.

A

So if you click use new editor we're working on the messaging on here, but we're just replacing that um content area right now with the with the nvc of our content editor. But we have vision to make this page a little more um open and we have a whole lot of work that we intend to do on. The content. Editor experience itself, but this is it so here you can start typing.

A

You know this is markdown, that's fine, but now you can go and use your shortcut keys or your toolbar to change the content, and you can do that in the old editor. But you didn't get the rich preview you. It would just add the syntax around it right so now you can be confident that you're doing what you want to do and then even better is I can do markdown shortcuts. So if I want to continue typing in markdown, I can't so I ha uh you know pound pound space.

A

Now I'm writing a second header, nice and I hit return and I'm continuing to edit. The page so same thing goes with lists. You know I can start a list and say item one enter or return and then item two return return. Just like editing, google docs, I'm a little further down the page.

A

um So this, then the you know gets committed just like everything else and written out as markdown, and that's that's one of the key differentiators here that um other folks, like confluence or or even like, you would see the the benefits of something like notion or there's editors there's one called ghost and there's a whole bunch of html rich editors like this, but most of them require proprietary data format underneath because it's easier to transform and keep consistent.

A

But the content editor is built um to write markdown out and keep the single source of truth in markdown, which is probably the most important part of our architectural strategy, which is, which is what makes it reasonable across categories. So we don't need to force anybody to migrate to a different file format and we can continue having contributions um directly to the code without sort of abstracting or obfuscating the source.

A

So that's um that's the demo in the future, uh as kristin mentioned about uh at the top of the meeting, we have vision for um shifting this experience away from the toolbar to be more like uh editor, like you would see in medium or in notion or in some others.

A

There's a um one, a wiki type uh product- I was just testing out um and the name escapes me, but that it's a pretty familiar pattern at this point where, like you, hit return and you have a little menu uh in context of your cursor that lets you add different types of blocks and I think that's um that's a big part of our future roadmap, because, right now, as it is like okay, a rich editing, markdown experience, that's pretty that's limited to bold and italic. Isn't that exciting?

A

But when you start thinking about uh embeddable content like embedding snippets or like pulling up an issue browser or a label browser or something like that. Within this experience, you have the ability to extend the core editing experience in really a lot more directions than than we had at our disposal before.

B

That was my next well further down just a question drop like dropping in queries to an issue list or things like that, where we could have embeddable content, either from like hitting a plus button or a slash command.

B

A

B

That going forward.

A

Absolutely I mean the idea behind the editor is that you can extend it using simple. It's it's based on view. You can build custom ui on top of any of the extensions.

A

So if you wanted, for example, to build an extension that edited images for for uploading designs or something like that, you could, you could extend the editor to um respond to a shortcut or like have a new menu option that brought up a custom menu, allows you to upload an image and then like export it in multiple thumbnail sizes and crop it and like make some simple, notations or add a caption or something like that.

A

The the challenge there is when it gets written back to markdown, it's likely just going to be put into raw html, because there's no analog for that in markdown.

A

But what the process of writing extensions is something that we're documenting now ahead of time, so that everybody can jump in and contribute as soon as possible and build those kinds of extensions so that we don't have to be the gatekeeper for these experiences, um and that was fully the intent so when, when it comes time to bring it into issues, if you had ideas like oh, like a great idea like bringing discussions in there, you could introduce a comment button and that comment button.

A

The experience there is completely determined by what you can build in javascript and html. It's not limited by any particular framework or like a extension library or anything you can just you build the experience as you need it. You can insert custom ui and you can write that back out as html.

B

That would be really cool because I know holly was trying some left right experiences with comments and having them be up near the text and things like that, but like being able to actually like medium, you know when you select a piece of text and you do like the common content on it or comment and or a whole block and then do a comment. That would be really awesome.

A

Yeah, I I thought about this. uh We talked about this in slack. I think I mentioned this nbc. I got real excited about this uh direction as well. I think a great first step would be like just let the content editor be aware, that there are discussions and so build that in that connection, into an extension for the content editor that lets.

A

You know that this span of characters has, um you know, been referenced below or something like that like, even if we can't at first bring the information up in custom ui and like have google docs type conversations in the gutter, if you could at least indicate that there is a discussion by highlighting text or something like that, and then click to link to it or something like that'd, be a really great proof of concept to to build that connection between the um the the discussions below and the the content above.

A

But yes uh to get to your other questions, so I don't ramble too much my. um Can you edit without mode switching? So um do you mean, in the uh context of like an issue where you're in a read view, and then you you want to edit.

B

Yeah or like easy, like some of the designs that we've seen have like, you, can just start editing the title, just click on it or, like just start, editing the description without making that shift from view to edit.

A

We haven't tried, this can.

C

I jump in here yeah, so this is very interesting um back in the static site editor days, we tested a flow where you just go in from edit the page and then jump into like from the handbook to the editing experience, and there were a few users who were like just sitting there like and then uh like.

C

Okay, what's up and they're like yeah, I'm used to seeing like the edit button in gitlab to like enter editing mode, so that was very crude, probably, but um I think aspirationally like the more natural it feels like kind of like you know right now, when you switch between writing preview. Sometimes you want to type in preview, and you can't and that's like this is one step further.

C

I think in the long term, if we can like make that editing, experience right then, and there would be ideal, but there are edge cases like accidental edits or you know changing something without wanting to or not being able to revert because like oops, I just uh clicked the table and deleted something. I I think those things down the road are can be resolved. But at the moment, uh having like an explicit, I am entering the editing state is probably like the right thing for users um we can make it.

C

We can make it once you're in there it's. It looks like you're editing like a modern application rather than a text box, but um yeah.

A

I think the other thing that we can do is get clever about how we initiate editing like if focusing in the content area is what triggers the edit action like. We could display the editor without having an edit button, if that makes sense, because the the uh content in the content editor can be displayed in exactly the same styles as the read view that there it would be a seamless transition.

A

Hopefully- and you could, you could get clever about which action initiates the switchover, what we haven't explored is any performance or usability implications of using the content editor to actually render the text and just always have a live edit mode, but that's something that we could explore and we're actually doing that in the on the source editor for code.

A

The repository view is actually introducing our code editor as a read view.

D

A

That it can quickly switch between edit and read, which is an interesting analog.

B

It's really cool, it makes it.

D

B

To be able to back up sorry, you'd have to be able to undo that's the other thing.

D

B

It's a really good point that that architecture would have to be in place.

D

Or have like a log right kristen where you could kind of revert that makes sense yeah. The usability is like the hardest aspect. I think to michael's point. um I think the inline editing of things like metadata is more forgiving than the actual content, because it's you know you're interacting with the content. So much and it's like is the user trying to digest this information?

D

Are they just viewing or are they intending to edit and if they're just intending to view it might be kind of like frustrating to have all these little interactions going on when you're, just like trying to digest that content, so um yeah usability could be a good focus. There.

A

um Alexis you.

D

A

Question, do you want to voice it over or I can just jump right into answering? I have a bad.

D

A

Just like trying to.

D

No worries, no, that's good. um No! You just mentioned different, like content blocks, that y'all are thinking about um beyond the extensions I guess like which ones are y'all thinking of focusing on first, as you add, in kind of this, more rich editing.

A

A

The primary focus right now, probably over the next few milestones, is to get full support for gitlab flavored markdown extensions. So that means everything that shows up on the document. So I would, I would have answered mermaid diagrams, but those are technically part of git lab flavored markdown. So I think those are that's our target and once we hit full support for for everything that can be thrown at gfm, then we can um explore bringing this into issues and ethics, because then we have complete support. um I have ideas for other things like I.

A

I think we're gonna try and do a little proof of concept of embedding snippets to use, as you would writing code blocks, but instead you embed a personal snippet and now it stays up to date and you can use it anywhere.

A

Other embeddable content like figma and stuff like that, would follow. Once we solve embedding snippets, we could extend that experience to embed other types of content.

A

um Yeah again, I would say, like video and and stuff like that, but that's part of gfm, so really that's our target is just get that flavored mark down and then we'll take it from there.

A

That's going to be quite an effort, we have. We have an epic to track I'll um I'll link it here. But it's it's there's quite a few extensions. We have on gfm, as, as you probably know,.

B

I haven't asked in that too. It's like this might be a rendering issue, but our tables are awful in terms of how they render equally like they don't ever have equal space columns.

B

Maybe you can fix that, while you're in there but.

C

Like you need the content.

B

The length of the content makes your column go wider, which is so ridiculous. I've tried to hack it so many different ways: non-breaking spaces fixes it. If you just put a line of them, you can get like three equal columns, but if you can make an awesome, embeddable snippet that just puts those types of equal tables in.

A

I I've joked about this, but I think if we solve tables like we honestly have probably the biggest competitive advantage, my my groups can offer to the company.

A

If I never have to write another table or like look at a poorly formatted table again, then I think we probably will have generated 200 million more dollars for the company.

D

A

That's our biggest contribution that I hope we can my legacy. um I I agree tables are a big thing. There are there's going to be a decision point for whether or not we write tables out to markdown or not. A lot of those limitations are just because markdown tables are, are they.

A

You know they're limited, but if we write properly formatted html tables our options open up, um and you can actually see some of that in the tip tap demo on their their like project page there's table editing and you can like do things like add columns and span and group things, and um it is something that we are working on soon tables we're not in our mvc because of the complexity for adding rows and columns and building that custom ui, but um that'll be one we pick up shortly.

A

uh Let me see: where can I here's.

B

Have you ever used the excuse me, the wordpress elementor product before.

A

No, but I know about the project like gutenberg stuff, like the block builder and stuff, is that similar.

B

It is similar yeah yeah yeah, I'm wondering if this has uh like that level of possibility, and I haven't looked at tip taps documentation. Yet so probably they've got a lot of this outline there, but just curious if you were familiar if they offered that level of, like you mentioned, being able to add columns to a table, for example, and kind of building out a structure but kristin.

B

The reason I'm asking this is for the extensible issues concept like. Could we potentially allow the ability to from an editor ad like the breadcrumbs widget or you know, some other aspect of our current issuable layouts from from just this editor? Is that functionality we could build into this.

A

uh I would have to say that my aspirational answer is anything you can write out to. Html can be integrated, so if you can at the time that the editor is open, if you can pull the data from somewhere and you can write it out to html, I think the answer is yes. uh I would love to have an engineer validate my answer on that, but I I think that sounds doable.

C

All right can I jump in here, uh so I think holly, you kind of said the magical word in your layout. So this is uh the fun words layouts templates and things like that tip tap itself is like purely text editing or like things around the world of the text. Editor.

C

I think aspirationally, like eric said, like the wiki is under our domain, and maybe people don't want to have this single plain wiki page, and you want something more unique, as you said like adding widgets breadcrumbs et cetera, I think that then we probably look at like layout as like a separate uh problem to solve there, not so much the content, but I'm just taking a look at the elementor website right now and the spirit of having like a panel that pops out to insert content.

C

That is something that we've been uh talking about a lot in the spirit of embeddable media such as, like um you know, google docs figma, whatever, where you can like pull that up, be it snippets in the future, maybe, but using some kind of similar pattern like that, where you can like okay, what can I throw inside this text? Editor well, which is like really, you know if I use templates, it's like.

D

C

Boring just one giant column, so yeah from that level. um This idea, where eric says like yeah, if you can convert it to html, it can happen in there and it's there, but I don't think it's going to be as sophisticated as uh yes. I want this to.

D

C

Side at all time, fixed and kind of like a beautiful layout engine and customize all of my stuff um think.

B

About that that makes sense right.

C

B

No, no, please go ahead. I'm sorry.

C

Yeah um yeah, I was just saying like yeah right now, we're just focusing on the blocks and putting all the blocks together.

B

That makes sense, and thank you for for clarifying. There go ahead.

A

I would just say one of the things that we're trying to one of the things we explored when we were doing static site editor was: should we move in the direction of like a cms where we're managing structured content, or should we move in the direction of a page builder, where you're actually like building the layout of a page, and we specifically said that problems being solved by others and solved well, and we aren't equipped to to work on that.

A

Yet we could start solving for content and get to the point where we like introduce ways to customize the layout, but we weren't we are specifically not building like a a layout builder, a page builder.

A

um I think that still applies now with the content editor, where, if you think of it, it's one column of content and as we extend it, for example, like with images like you might want images to have, you might want to build a gallery image, widget or whatever, like that, like you could impact the layout within that content block in various ways, but we're probably not going to have like a uh split like in notion where you can like all of a sudden split into two columns or like you, could you could pin something to the top or something like that, it's probably more advanced than than we're going to get anytime soon.

A

I uh I see in your chat, I think um I agree. Let's move on and touch on those I don't have a hard stop, but I want to be respectful of everybody's time. Real-Time collaboration.

D

Oh, this was more just like um demo, but I guess the content block thing is relevant, but um yeah like within issuables or planning objects. I think we all kind of like touched on the aspect of uh you know collaborating on actual like items within the content. Right like how do you highlight something to comment on? How do you give like real-time suggestions, comments? Things like that? um I don't know if that's feasible anytime soon, but, like you said some things have solved this well already.

D

um We can keep thinking about that for the content blocks themselves and I think, like michael touched on this, with templates layouts.

D

I was thinking about that a little as well, and I think that could be exciting from a growth perspective as well like how to better guide users in creating um content and like actually finishing creating their their content and um uh better issue hygiene. Things like that, um so thinking about like empty states how to go from there and then like actually adding content blocks to the issuable or planning objects themselves.

D

um Thinking through that a little and we could keep collaborating on this, I don't think we have a lot of time for it, but um yeah like even the fact of like where's the toolbar. um How do you access this at any time? What is the interaction? Am I just like hovering over a thing? Is that usable, um different types of toolbars? Is there like an over overall like planning object?

D

Toolbar? Is there like an edit mode versus uh view mode kind of like what I touched on earlier?

D

um What are the different types of uh content we can add and then how to like actually interact with them in a usable way, um small things I am thinking through that I think, maybe michael it might be helpful to holly and you and I work on at some point, but um it sounds like we just want to get like parody with what we have for now. Within these kind of content blocks right.

A

Yeah parody yeah absolutely, but I think that this has me thinking a lot about what I was mentioning with embeddable snippets right. So essentially an embeddable snippet we're just gonna. We're gonna write out a script tag. So if, in the process of thinking through this, you find a way that you wanna, basically embed a planning board or embed a road map view, that's completely reasonable and achievable, and I think that we could collaborate on that and help.

A

You understand how tip tap, provides: contextual toolbars to your custom content block and what how to inject like icons into that toolbar and things like that. That's all very much in line with with what we had in mind.

D

And it sounds like um at the moment we have kind of that write and preview mode still like we're still kind of in that world with the ui, but y'all are looking to evolve. That a little further is that correct.

A

Yeah and- and you also mentioned collaborative editing- and so I should at least address it- tip tap- has support for collaborative editing. We have a lot of work to do, as you probably have heard, to get our data format in a way that it can actually be. You know, reconciled in a real-time manner and um and edited by multiple people at once, but it's a it's a big focus for several teams and something that we're we're keeping in mind as we build it.

A

uh It's not something we're gonna get for free by introducing tiptap, but it is something that tiptop kind of supports. uh If, if that, it's like a model that it supports, if that makes sense,.

D

That's awesome, I think that's like one of the the biggest things probably holly has heard too from research without, like collaborative real-time, editing is and working on um something with others. Collaborating truly with them is helpful, michael, I think you're talking do you want to.

C

Yeah, I was just going to say like I, I posted a link to the collaborative editing feature in tip tap, but um this is something our engineers have like told us many many times, even though this exists on the front end and it works in this prototype.

C

A real collaborative framework requires a lot of back-end work to make it sink properly at the same time, so it is gonna. If, if this is gonna be a thing, this is probably where we're gonna need, like eric and kristin here to like push up and like this is gonna, be a.

B

Big big effort, as.

C

In like, we need to introduce a lot of uh technology in the back end to support this, so that the front-end frameworks like tiptap has these, like libraries that are ready to get like updates, um get those updates in the right sequence. So that's something to be aware of um yeah with your toolbars and, like you know whether they pop up contextually or not. I think that's something we should collaborate on in the near future.

C

um I can walk you through some stuff that we did so far in solution, validation, um things we learned, probably like really basic stuff for you, but yeah, happy to share that uh stuff.

C

Yeah, it's already done so I can send a link to that um research now, but um yeah. We can talk about that later down the road.

D

Yeah and gosh you talking about that made you think about like permissions and all the rat's nests that will go into that as well like who can add certain content blocks and what do they have access to and how do you lock things so people can't anyway, we'll go down that later, but lots of fun stuff in here.

B

I think at some point, embeddable wiki pages would be really cool too, like just so they render as little thumbnails or something you could have them. Wiki's more connected to actual planning objects.

D

um And then kristen, I think, last time we talked you brought up the the concept of like a content block in a content block like I built a content block, and then I saved that content block. It's like this is the design management content block and you can edit that and there's a lot of good things in there.

B

That's exciting where this could all go. Thank you for taking us through just kind of the high level vision of it, and so we understand kind of where it's at. I can't wait to go. Try it in the wiki today.

A

Yeah, I know we as a company, don't use the wiki all that much so it's hard to say like go, try it out now, but um uh it it it's there and uh we appreciate any feedback and we're very excited for the next few milestones for for rounding out the experience and the rest of the features.

A

I I I think we should probably touch base again real soon and obviously you know sync up with michael any time and he's always happy to I'm gonna speak for you, michael, but always happy to jump in collaborate on design stuff.

D

Y'all, that's so great here, though, I'm really excited yeah. It's awesome.

D

Well, thanks for hanging all right, cool.

A

D

Everyone for joining thanks again.

A

D