Research and evaluate editor options against UX and technical requirements
Requirements
Evaluate all the candidate editors to determine the best suited editor for our long term needs. Evaluation criteria as defined here: #231724 (closed)
| Category | Requirement | Definition | Evaluation criteria |
|---|---|---|---|
| Technical | Maturity | How mature is the editor in terms of feature completion (stable API) and duration existence (has it been used and been proven over a period of time) | • Who/what type of projects are using it • Release version looking for API stability • Feature completeness • Test suite • Release changelog |
| Technical | Community | We want to ensure that the project is not only worked on by 1 or 2 developers, but that there is healthy activity from the community. Essentialyl we want to avoid a Middleman situation. | • How many issues have responses, and rate of response • How many stale PR/MRs there are (how old, lack of comments) • Does the project have sponsorship (Corporate or Patreon etc) • Open to community input in shaping the direction • Community authored plugins |
| Technical | License | The project must have an appropriate open source license for us to be able to embed it in our product | • Check licence compatibility |
| Technical | Browser support | Our Editor use case requires us to support not only desktop browsers but tablet and mobile form factors as well. Desktop: - Match GitLab browser support (last 2 versions of modern browsers, no IE) Mobile browsers to consider support: - Chrome Mobile - Firefox Mobile - Safari Mobile |
• Must work on mobile |
| Technical | Themeability | The ability to change the UI to match GitLab design system specifications | • Clear separation between presentation and functionality • Very desirable is theming framework • Use of SVGs instead of image sprites |
| Technical | Extensibility | The ability to extend the functionality without the need for elaborate workarounds/core code customization. The parser we use to process and render markdown should be extensible The WYSIWYG editor should allow extending the editing functionalities |
• Architectured with extensibility in mind (events etc) • Well documented API • Does it have plugin ecosystem • Text selection/cursor manipulation API |
| Technical | Technology | It needs to be compatible with out current tech stack | • Either vanilla JS or Vue JS • No jQuery |
| Technical | Rendering flexibility | The ability to customize the rendering of custom template syntax and load partial pieces of content async | • Must have the ability to process custom template syntax • Must have the ability to load content asynchronously |
| UX | Blocked based editing | Content consists of separate blocks: paragraphs, headings, images, lists, quotes, etc. Each of them is an independent element in the editor. | • Has a block-based editing approach |
| UX | Block modification | The ability to edit a block through UI interface once rendered (think table editing, image properties, link editing etc) | • Does not have to provide the functionality out of the box, but must allow for it to be creating |
| UX | Block re-arrangement | The ability to re-order the blocks on the page | • Should have block re-ordering functionality |
| UX | Markdown Shortcuts | The ability to type markdown syntaxt in the WYSIWYG editor and have it automatically converted | • Provides the functionality as standard with option to extend • Or, must allow the ability to listen for input and transform input into presentation format |
Candidates
- TipTap: https://github.com/ueberdosis/tiptap
- ToastUI: https://github.com/nhn/tui.editor
- CKEditor: https://github.com/ckeditor/ckeditor5
Comparison analysis between CKEditor5 and TipTap
Final Decision
Edited by Enrique Alcántara