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:
- We have a much better understanding of our user needs and product direction
- 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
- Maturity - how mature is the editor in terms of feature completion and duration existence
- Community - how active is community in reporting and addressing issues and submitting merge/pull requests to the project
- License - it should have an appropriate open source license for us to be able to embed it in our product
- Browser support - it should work in all modern browsers
- Mobile support - does it work on mobile browsers
- Skinning - can we modify the look and feel easily to adapt to our needs
- Extensibility - can we extend it with custom functionality to handle non-standard markdown
- Technology - is it compatible with our current tech stack and not introduce unnecessary dependencies
Behavioral
- Ability to switch between WYSIWYG mode and editing the raw Markdown
- Ability to hide the markdown syntax after applying the formatting.
- Example, typing
## Header 2
would remove the##
from the string and apply H2 styling.
- Example, typing
- Visual styling and management of tables is a very nice-to-have feature
- Ideally, it would also support copy/paste of tables from Excel or Sheets
Edited by Jean du Plessis