GitLab Create Editor Group, 23 Sep 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Design exploration of switching between Content Editor and source editing - Create::Editor

Description

https://gitlab.com/gitlab-org/gitlab/-/issues/341512

A

My name is michael lee and I work in the editor group and today I'll be talking through my thinking about how we toggle between the content, editor and the classic editor or the ability to edit wiki pages using markdown or whatever source formatting that you desire.

A

So taking a look at toggling between the two states, I kind of looked at the different components that we could use um for this interaction. So here's taking a look at check down so check down, check box, um yeah um toggle, I think a toggle is very common, but you know the way our toggles are um they're very big and they're very um non-discrete, so we could iterate and think about how we style this, but um I just chose to explore uh other options for the time being um check box again.

A

But this time in the gray background, I think the segment control kind of works pretty well for this interaction, because you have two options: either rich text or the content, editor and markdown. But I think markdown is not the right word to use here, because the format could be markdown or ascii doc or whatever the user prefers. So we'll probably change the name of that later down here is the segment control.

A

This is like an updated styling change that camilla is working on, so this is how a segment control could look like in the near future and, like I really like how that looks um in context with the rest of the ui, and this one looks like it's the same exploration um I looked at potentially putting in a in the overflow menu, where you kind of show markdown hide markdown, but this kind of highlighted the fact that reusing the existing shortcut key for toggling, markdown and plugging down or markdown, and the rich text is not really the same thing as toggling between write and preview.

A

This then informs some of my thinking here around, like my assumptions of my design, so toggling between the content, editor and between editing source is not the same thing as toggling between write in preview, because you're actually changing the entire editing experience, not just like a look and feel of what's uh what's in the page as I move along with this uh changing the layout of the existing pages in the remit of or the realm of possibilities, which should be a way for the user to navigate from the content editor to the raw source editor and vice versa, from the raw source editor to the content editor and then once there's parity functionality between the content, editor and the classic editor or the raw source editor.

A

I have a strong assumption that users would not need to toggle between modes that often, while editing a page. I could be wrong. We could learn down the road that we should always have this ability. But that's my assumption for now and in the future I'll be taking a look at um prompts earth guides.

A

Helping people inform that hey. If you need to get back to doing something. Switching modes: uh here's how it can help you so where my thinking's been influenced is looking at like in this wiki editor. Here I kind of mocked up and changed up some of the text in here. It's just to get a view of what that could look like. So, if you're editing source it is this editor if you're editing enriched text, then it's like this.

A

um So that's so that's where I kind of got the idea of potentially either using tabs or the segment control.

A

um The idea of prompts and guides is kind of like this here from wikipedia where you have these pop-ups, that tell you hey you switch source, editing so I'll go here to visual editing.

A

Let's switch to visual editing, there's a nice little prompt here. That tells me that I can go into here to change it. um If I go in here, you can see source, editing and visual editing in our world. We call it content, editing and yeah classic editor at the moment, but um that's up for debate of um what we want to change. That name to um this drop down is very clean.

A

Like uh in my explorations and my thing, my designs, I didn't look at drop downs uh just because, and it takes a bit of space, but here they used a pencil icon for indicating the type of editor that you want to use in the world of gitlab. um The pencil editor is reserved for editing, so I think reusing that, for this is not the right approach, so I'll show you where I landed on with my thinking.

A

So if this is our current homepage,.

A

Where I'm thinking that we could clean things up is take this opportunity to also take a look at restructuring the normal wiki page, this gray area here is just the standard commit flow, that's existing on the page, but here we're using the segment control to switch between the two views and by clicking on content editor. It switches you to here. You have the different toolbars um different experience for writing here.

A

There's no format selection, because in this view another assumption is that yeah there's no need to specify the source format, uh so I just took that out for now um yeah. I think this is a a good way to swap between the two and we don't need to worry about trying to embed this component somewhere inside this toolbar or this toolbar. It's just outside this, uh this box of editing, cool, moving forward.

A

Grand vision of this is that we don't need to switch between our users, don't need to switch between content, editor and rich text editor once we have parity, and this design also encompasses uh something else that we've been talking about is consolidating the commit flow. So, by consolidating the commit flow, we can remove the commit flow box at the bottom, but at the top, and then that dictates the flow at the top.

A

There switch to content editor boom and you get into this world this area down here is is now the content editor and you can edit your heart's content.

A

Moving down, um I noticed that, with the difference between the classic editor and the content, editor is that there's like this little footer here, but there's no footer over here. I thought about kind of thinking about changing how that could be. um This was influenced uh kind of by this, uh where you have this ability to see um tips and helps of like how you might be able to write markdown, so keyboard shortcuts and things like that um yeah, I don't know if they have guides here but yeah.

A

So the idea here is that when you click on this, so I got rid of two things. Sorry first attach file um that can get.

A

We can introduce the plus icon, which we're planning to do anyways to insert different types of objects and embeds, and this opens up the door for that within the classic editor and it allows us to remove this attached file. The way we're going to remove the markdown supported is by adding this extra button.

A

I chose a light, bulb it's kind of an icon for a tip, but um yeah. We can think of that of a better icon to use here. I didn't want to use the question mark because that's currently being used at the top in this area for help, and I think that's just too many question marks going on there, so a light bulb for now um feel free to.

A

Let me know if I should change that clicking on that um spirit and mean see we could just load our get lab flavor marked down in a drawer component that pops up um yeah nothing too crazy here, um rather than of taking the user to another page completely. What we're doing is bringing that content into the world of gitlab, which is loading the url that we would load anyways.

A

I added this little pin here and the idea here is that, if you pinned it now on the desktop, you would actually have enough space to have like a side with your markdown guide and your content. Writing. So and if you switch your format types you know everything maintains.

A

uh Going down to here, um you know this is what the edit page eventually would look like. Yep title format, everything! That's there right now in the existing wiki pages here in this visual layout. This is the equivalent in the world of.

A

In the world of the content editor, um and then this is how it could look like uh for mobile view where um these cancels and things just go up at the top. The title goes there and then the all toolbars go to the bottom, and the rationale for moving the toolbar to the bottom is that when the keyboard pops up, it's close to where you need to access the actions, there's an opportunity to consolidate the actions here.

A

This is something that we learned from looking at the wikipedia layout that there's potentially better grouping opportunities here and yeah. That's that's it for uh this page here. um Some further thinking around this is when you're in the um content editor one thing that we can start.

A

We talked about this, but the ability to hide the toolbar, and I think this is a valid option to introduce once we have the parity and we're happy with the user experience of editing here, and that would give us this experience. uh The beauty of this is that now we can get some analytics around how many people actually want to hide the toolbar in the existing experience, and then we can make a decision on how to move forward with that.

A

So these are the things that I'm very confident about so taking their existing page, changing up the layouts um assumption that people don't need to switch a lot. So if that assumption is true, then we can stick it inside an overflow menu to swap between. If people need to do it, then we'll just keep the layout similar like this with the segment control.

A

um Further thinking is like thinking about changing up the the header and stuff like that, but um I think right now this would be a good step forward for us. uh It gives us an opportunity to um toggle between the two views experiment with other ideas we have. And yes, uh if you have any comments or comments below please or questions, uh please feel free to jump onto the issue which I linked below in the description and yes until next time. Bye.