The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
Content last reviewed on 2021-08-10
This is the direction page for the Editor group which is part of the Create stage of the DevOps lifecycle and is responsible for the following categories:
|Web IDE||Direction page||A web-based multi-file code editor||Viable|
|Snippets||Direction page||Small, sharable bits of code saved for easy access||Complete|
|Wiki||Direction page||Built-in, git-backed knowledge base||Viable|
|Static Site Editor||Direction page||Visual editor for Markdown content hosted in a static site||Viable|
|GitLab Documentation Site||Direction page||The GitLab documentation website|
|Navigation & Settings||Direction page||Features and UI patterns related to global navigation and configuration of settings across GitLab|
In support of these categories, the Editor group created and maintains two core editing components. These editors are intended to be flexible, extensible, and reusable across GitLab and while they don't meet the traditional definition of a category, they do have distinct strategies and backlogs. They are:
|Source Editor||Direction page||Our underlying
|Content Editor||Direction page||A visual Markdown editor||Epic|
With 7 categories and 2 foundational editor components, the Editor group has to prioritize aggressively. In general, the group's goals revolve around consolidation and standardization of editing experiences to improve consistency and maintainability. Our current focus areas and engineering investment are broken down by category below, percentages represent how much engineering time on average is allocated in each milestone. Since the Source Editor and Content Editor span multiple categories, investment in those is included in the most relevant category.
The Web IDE has now been refactored to use Source Editor which enables us to work on creating a more consistent, cohesive code editing experience to GitLab. One of the primary goals for the category is to bridge the gap between the Single File Editor (the experience of editing a single file from the Repository view) and the more complex but powerful Web IDE. We believe that breaking down the barrier between these two editing paths will drive adoption and overall satisfaction with the merge request and review experience. While we tackle that larger concern, we will also focus on extending the underlying Source Editor itself and enabling more advanced workflows like live Markdown preview or inline merge request discussions.
Snippets reached Complete maturity in late 2020 with the introduction of versioned and multi-file snippets. Snippets are powered by Source Editor, so improvements to that experience can in turn benefit the editing experience of Snippets. The next category-specific features we would like to focus on are around organization and sharing but the team will focus first on categories with larger user bases and wider potential reach.
The Wiki is one of our most used categories and there are several opportunities to improve the experience and drive growth. The largest and most strategically important opportunity is the introduction of a WYSIWYG Markdown editor, what we've come to call the Content Editor, which shipped in MVC form in GitLab 14.0. The highest priority for the Editor group here is to build complete support for GitLab Flavored Markdown so that the Content Editor can be used as a production-ready, default editing experience for Wiki. Afterward, the Content Editor can be introduced anywhere Markdown content is written in GitLab. This includes issue and epic descriptions, comments, and even when editing Markdown files directly in the Repository view or Web IDE.
The Static Site Editor reached Viable maturity in late 2020, however we identified a need for a more scalable and extensible WYSIWYG editor. This technical investigation resulted in what is now known as the Content Editor — an HTML-based rich text editor that is currently implemented in the Wiki. Our intention is to bring that editor back to the Static Site Editor or, potentially, use the Content Editor in a slightly different form to solve the same jobs to be done that the Static Site Editor was meant to solve.
The GitLab documentation site is owned and maintained by the Technical Writing team. However, the Editor group offers additional engineering support, particularly in the front end, as needed and when available. Our plan is to continue that level of support until dedicated engineering roles can be allocated to the Technical Writing team.
Following the release of the consolidated menu button and redesigned left sidebar in GitLab 14.0, we are taking a step back and lowering our investment in this category. There are still many opportunities to explore in this area but those will require additional validation and a team dedicated to implementing and maintaining the codebase. In the meantime, we will dedicate some time to iterative improvements to the consolidated menu and left sidebar while wrapping up existing UX research around new navigation patterns.