Define the UX and technical requirements for a WYSIWYG editor

We originally defined the criteria for choosing a WYSIWYG editor for the Static Site Editor in this issue: #209325 (closed)

In the 4 months since we defined the original criteria out understanding of our requirements have changed in the following ways:

  1. We have a much better understanding of our user needs and product direction
  2. We have hands-on experience working with and customizing an editor to meed our use cases

As part of the re-evaluation of what the right editor for our product feature might be, &4030 (closed), we need to define a new set of technical and UX requirements to evaluate possible editor candidates against.

As a start the requirements below are from the original requirements.

Technical

  1. Maturity - how mature is the editor in terms of feature completion and duration existence
  2. Community - how active is community in reporting and addressing issues and submitting merge/pull requests to the project
  3. License - it should have an appropriate open source license for us to be able to embed it in our product
  4. Browser support - it should work in all modern browsers
  5. Mobile support - does it work on mobile browsers
  6. Skinning - can we modify the look and feel easily to adapt to our needs
  7. Extensibility - can we extend it with custom functionality to handle non-standard markdown
  8. Technology - is it compatible with our current tech stack and not introduce unnecessary dependencies

Behavioral

  1. Ability to switch between WYSIWYG mode and editing the raw Markdown
  2. Ability to hide the markdown syntax after applying the formatting.
    1. Example, typing ## Header 2 would remove the ## from the string and apply H2 styling.
  3. Visual styling and management of tables is a very nice-to-have feature
    1. Ideally, it would also support copy/paste of tables from Excel or Sheets
Edited by Jean du Plessis