Some contributors find writing in Markdown is unfamiliar or inefficient. The overhead required to mentally parse the syntax can distract from the content editing experience and often results in a lot of context switching and extraneous markup. For example, creating links, adding images, and editing tables are all actions that can be done more efficiently in a rich text or what-you-see-is-what-you-get (WYSIWYG) editor.
The goal of the static site editor feature is to abstract as much of the technical underpinnings of the markdown language and template architecture as possible to encourage collaboration across multiple personas, regardless of technical experience.
Proposal
The raw text area in the current static site editor should be replaced with a WYSIWYG markdown editor, providing real-time rendering of content in vanilla HTML.
Editor Toolbar
The editor we will be using is the ToastUI editor. We will be enabling the following capabilities for the editor
Text sizing
Heading selection
Heading 1
Heading 2
Heading 3
Heading 4
Heading 5
Heading 6
Paragraph
Text formatting
Bold
Italic
Strikethrough
Text enhancements
Quote
Link
Codeblock
List functionality
Bullet list
Numbered list
Task list
List indent
List outdent
Object insert
Horizontal rule
Table
Inline code
Editor Behaviour
Make WYSIWYG view open by default
Heading selection will leverage the dropdown that is built-in the ToastUI editor
Headers should be rendered visually distinct and consistent with the GitLab CSS rules.
Table support
Support for rendering and editing markdown tables will be done with ToastUI's built in functionality:
Inserting a new table
Editing a table cell
Adding/removing a row/column
Available when the user right clicks the row/column
What are we not doing (yet)
// TODO: Is excluding image uploads actually more work than using Toast UI's built in image support? If we chose a default location to put assets, would this just work out of the box?
We will not be implementing a way to visually upload images or access any kind of asset library in this release. If images are added, it is by providing a direct or relative URL only.
Code snippets as a content source
A common pattern in visual markdown editors is to provide autocomplete formatting shortcuts. Fo example, when the user types ## then space, the hashes are removed and the line of text is formatted as an H2.
Images (from URL only)
Pasting CSV data from the clipboard to generate the table
Text Formatting
Underline (not supported by ToastUI and may be confusing with links. Suggested for writers to use bold to emphasis text)
What does success look like, and how can we measure that?
Success metrics
We have yet to instrument this feature for usage data
Acceptance criteria
A user can edit the content of a realistically complex page without writing a single line of markdown.
Is this a cross-stage feature?
WYSIWYG editing is something that's being explored by multiple groups. Our goal is to move fast so we can test the editing experience and the WYSIWYG editor is a big part of that. The Static Site Editor group will be sharing any learnings about integrating the WYSIWYG editor with the rest of Create and Plan. By maintaining a loosely-coupled relationship between our feature and the editor itself, we will be able to pivot to a different editor quickly if another group provides a better solution.
With respect to adding/removing a row/column, are we keeping with the same interaction of activating it by right clicking on a table cell when in WYSIWYG mode?
Is it part of the scope of this work to style the popups for "insert link", "insert image", and menu for add/remove row/column according to GitLab's style?
I did not know how "Pasting CSV data from the clipboard to generate the table" works using Toast UI or is this functionality we are going to add on top of the editor?
Do we really need underline and strikethrough? Looking through the handbook I haven't seen those elements used.
I did an audit of icons that I need to do and will start the design on this tomorrow
@mle that Figma link gives me a 404. Permissions maybe?
My 2 cents on your points:
I assume the alternative would be to add the options to the toolbar when a table gets focus? Either way I don't think its in scope to customize the default behavior for this first iteration. I'd say we still with default behavior and can look to customize in a follow-up.
@jerasmus my assumption is it wouldn't be too hard to style these popups?
This feels like something that should come in a follow up iteration
Probably not as the default layout. Future iteration we could allow someone to define which additional options they might want to enable in their .gitlab-sse.yml config.
my assumption is it wouldn't be too hard to style these popups?
IMO we should try and stick with their default styling as much as possible in this iteration. We can 'skin' these to match the colors in our style guide in this iteration, but ideally we should try and keep the scope small and not go too overboard. I guess I can give better input here when I have a better idea of what the popups will look like.
Thanks @mle ! Agreed with what everyone else has said, but to reply directly to your points...
Yeah, let's keep this as the default behavior. It's sub-optimal, but it's still better than writing tables in markdown!
I'll create an issue to style popups and contextual menus. If we can stretch it for 13.0, that's great. If not, we'll get to it next time. Either way, I think it'd be valuable to define the design spec for them.
I was under the impression that pasting CSV data from the clipboard was standard Toast UI functionality. If not, I'm happy to remove that from scope. I think this would be transparent to the user from a design standpoint regardless. @jerasmus Can you confirm this?
Good point. Our focus isn't entirely on the handbook, so if it's functionality that comes for "free" with Toast UI, then I don't see any harm in including it. As we prepare for integrating with the handbook, I agree with Jean that a line in the config file would be appropriate to enable/disable certain options.
@jerasmus As you wrap up the technical planning, can you verify the final list of formatting options that Toast UI supports "out of the box" that we can design against?
For example, in my original mockup, I had a scissors icon for something like a code snippet. I'd say that is not a requirement for our MVC. But if there are things like image uploads that sound hard but actually work with little to no configuration, please let us know. Thanks!
can you verify the final list of formatting options that Toast UI supports "out of the box" that we can design against?
@ericschurter@mle sure, in their example they have all of their formatting options available to try out. All of the options that were in your mockup are available (I assumed the scissor icon was a codeblock).
I would suggest that we exclude image uploads in %13.0 (or have it as a stretch) as it would require some extra work to upload and store it. I would also suggest that we try to stick with their default styling and behavior for popups and context menus as much as possible in the 1st iteration to keep the scope of implementing it as small as we can.
I agree, but the toolbar in his mockups matched the toolbar in the example for the most part with the exception of some icons that were different. I wouldn't associate a scissor with a code block either
Yeah, the scissors isn't my proudest icon work :) Agreed, it's not the right icon.
I agree, let's remove image uploads from scope and I'll create an issue to track that specifically. I think that will have to come along with some changes to the config anyway since the user will likely have to define the path to their images directory.
Default styling is 100% ok with me for this iteration too.
With WYSIWYG, I don't know what happens to the "title" and "layout" meta data information in the Markdown file. One way to handle this is to prevent editing this area in WYSIWYG mode.
Regarding scrolling behaviour, the text editor should take up available space between the footer and the title of the page. The toolbar is fixed at the top and the content should scroll inside the text editor.
With WYSIWYG, I don't know what happens to the "title" and "layout" meta data information in the Markdown file. One way to handle this is to prevent editing this area in WYSIWYG mode.
I think for this iteration we just need to render this with the rest of the content. It's risky to present this to users, especially since changing those values can/will break the formatting of the page, but this issue should stay strictly focused on implementing the WYSIWYG editor.
Can we exclude the image toolbar option for the 1st iteration?
Absolutely, yes. I'll create a specific issue for handling images and put it in a later Epic.
Make WYSIWYG view open by default
I propose that we make WYSIWYG the only option for now. What does everyone think about that? Eventually, I see the value in having both. But making it the only option might be a good forcing function for us to ensure all jobs to be done can be accomplished in the WYSIWYG editor and not use the raw markdown area as a crutch.
List indent (not shown in design yet - new icon)
List outdent (not shown in design yet - new icon)
@mle Can these be solved by using the spacebar or tab on the keyboard instead? I expect tab is the more natural user behavior, and I'd like to keep the formatting bar limited to the most important formatting options. But I could be persuaded that a dedicated space for handling indent/outdent is necessary. Maybe this is a later iteration?
@jerasmus thank you for introducing me to the term "frontmatter" I didn't know that had a proper name before.
@ericschurter Without an image uploading and not allowing people to edit the Markdown then the user would be stuck if they wanted to add an image to the page because there would be no way to do it. I would rather put off the image uploader for this milestone and have the WYSIWYG option still available.
Regarding indent/outdent, I had to look up how indent works whether it was a single space or 4 spaces. I think it is worth adding it in this milestone since the functionality is possible out of the box with the ToastUI editor. Also this functionality is also present in Google Docs.
Thanks for putting together the video walkthrough @mle
I like the idea of iterating on how we display the frontmatter. I think this might require a way for us to mark content as frontmatter in order tell our parser what content we intent on displaying. For instance, we'll need a way to distinguish between the following two scenarios:
---title: This is frontmatterlayout: handbook-page-toc---
Sure, we could look into how they identify it on the backend, nonetheless we can investigate and identify the best way to implement this in a separate issue.
@mle Nice work! Depending on user expectation, it might be worth having the title and layout controls prior to the main content editing. I think this makes sense as the title is the signage of the page content and thus should come prior. Anyway, here's a quick mock focused solely on the location and layout of the title and layout section:
Location Change
UI Update
Additionally as part of this frontmatter discussion, this area could encapsulate the various controls that we could generate from frontmatter. One obvious example is that we should be able to dynamically infer what the possible layout types are and potentially restrict which show based on which file the user is editing. This would be an exercise in itself, but knowing the range of frontmatter that's allowed and then inferring and/or providing 1st class controls would likely be a big UX win in addition to helping enforce consistency.
One obvious example is that we should be able to dynamically infer what the possible layout types are and potentially restrict which show based on which file the user is editing.
We can do this by introducing a .gitlab-sse.yml config file with an entry that lists the valid options.
Similarly we can configure this config to indicate which frontmatter fields are editable and what their types are.
There can be multiple entries depending on how the site is configured. For instance here's the frontmatter for one of our blog posts:
---title: Understand incident management with GitLabauthor: Sarah Waldnerauthor_gitlab: sarahwaldnercategories: insightsimage_title: '/images/blogimages/incident-management-blog-cover.jpg'description: "GitLab Incident Management helps your response teams focus on the problem and shorten the mean time to repair rather than waste time on the process itself."tags: DevOps, featurestwitter_text: "GitLab Incident Management can help incident response teams to shorten MTTR"featured: nomerch_banner: merch_onemerch_sidebar: merch_one---
We can do this by introducing a .gitlab-sse.yml config file with an entry that lists the valid options.
Though it may not be worth the complexity (if it is indeed complex), I think deriving and generating vs. manually editing this file could be ideal from an SSOT perspective. For example the layouts directory becomes the SSOT by its sheer existence. What layouts are possible lie within and a script could parse the directory and generate the file listing the layouts for downstream consumption.
The reason I would favor a config file over deriving and generating is because it allows us to operate across multiple static site generators more easily without needing to write custom code to understand the nuances between each of them,
@mle Love the thought behind these concepts. We talked about this a little bit on Zoom, but for the sake of the thread here, I'll repeat myself
I agree with @jeanduplessis, identifying and removing frontmatter from the file should be saved for a later iteration (we should do it soon though!).
I wonder, though, if we can embrace convention over configuration and skip the .config file entirely? Since the frontmatter is, by nature, the first lines of the file, can our editor use the same logic as the generator itself to parse out the frontmatter while still allowing similarly-styled content in the body.
I realize that each generator has a slightly different way of handling frontmatter, but it seems like there is a finite set of rules that would need to be written. I could imagine in the future that we have a single line in the config file that identifies the static site generator. By setting generator: hugo for example, we can then apply all the Hugo-specific nuances that we come across.
Regardless, this is probably worthy of a proper technical exploration and could be discussed in a separate issue. For now, we should leave the frontmatter as-is and accept the risk.
I wonder, though, if we can embrace convention over configuration and skip the .config file entirely
Happy to embrace convention over configuration, however in a way that implies you have a configuration structure (even if invisible), and especially for users who would want to have more control I would encourage us to think in the way of a configuration file from the start, even if we don't expose a configuration file.
Completely agree. We'll need some level of configuration, and eventually some of that will definitely need to be exposed to the user too. For example, we've briefly talked about having "field sets" where users can configure what WYSIWYG formatting options appear for any given markdown area. I love this because it would be an easy way for a front-end engineer to limit the "damage" a user can do to the layout by injecting unexpected content.
@derek-knox Thanks for that mockup. From the moment I was reading your suggestion of moving the title to the top I imagined the layout to be exactly how you presented your mockup
Your mockup was exactly what I pictured in my mind when you suggested moving the title to the top. From an information hierarchy standpoint having a title at the top makes sense.
Hello @kcomoli - I would appreciate you eyes on this design in terms of visual consistency with GitLab's design style.
You can leave the feedback in the Designs tab or the Figma file - either are fine with me.
Note: There are some aspects here that are not styled such as the tabs between "WYSIWYG" and "Markdown". This is the out of the box styling from the ToastUI library. I did not update the styling here to reduce the amount of work but feel free to comment on it if you see fit
@kcomoli Thank you for taking the time on the feedback. It is good that the things you commented on is something that I am working on addressing for 13.1. I'm excited to show you the updates shortly.
Updated the latest design to account for the icon colour and the active icon colour
Colour of icon is grey-500
Colour of icon when active/hover is blue-500
Also to keep in line with existing experience of the editor in GitLab, I have asked @jerasmus to see if it is possible to remove the border when hovering over the toolbar items.
@leipert It is definitely opt-in. When using the Static Site Editor, the WYSIWYG mode will be the default, but we will still have a way to edit the raw Markdown.
Also important to note that the Static Site Editor is not currently configured on the GitLab Handbook. Once it is, it will be a complimentary editing experience. It's not intended to replace the Web IDE or any of the existing editing processes.