WYSIWYG matters…
When IBuySpy got started - and later superseded by DNN - WYSIWYG was all the rage, because we all thought that content management should go from being a web-designer activity (using Dreamweaver) to being a document-editing activity like word processing.
Based on this idea, the WYSIWYG was a strong focus of DNN, which lead to including the telerik-rad-editor in the distribution, and also lead to people saying funny things like "DNN is a CMS because it has a Text/HTML Module".
…much less than it used to matter
We were wrong. Turns out that content management is its own thing, incomparable to anything before - with requirements and possibilities far away from letter-writing technologies. Many wanted to ignore this and keep on following the WYSIWYG-way, but it finally became clear with the advent of responsive design, that separating the content-design from the content was the only way to go. You can read more about this in my old post about the death of WYSIWYG.
A good WYSIWYG in 2016 needs to do much less…
With a professional separation of layout and content (requiring an appropriate module like 2sxc - download in the forge), the WYSIWYG should do much less. Basically it should help the user get things done quickly, the right way. It should…:
- …promote good practices (like using headings, strong- and em-tags)
- …prevent bad practices (like copy-paste word-formatting or using font-tags)
- …discourage but support retiring methodologies like placing images in your text
- …discourage but allow advanced actions like manually editing the HTML
- …simplify common tasks like cleaning up formatting
- …manage content-specific assets as most downloads/links/images are never reused
…actually do as little as possible…
Even if the WYSIWYG editor could do way more than what is currently needed, we should not enable cool, special features. Because "special" features always have 2 important downsides. First of all they promote bad practices - causing users to create solutions which don't scale and don't update in the future. Second of all there will come a day where we will have to replace the WYSIWYG again, so by focusing on the important features (which the replacement will have as well) we can ensure that such a migration will work again in the future without much pain.
…but do this very, very well
The list feels very simple, but to do this well is very challenging. Simple examples:
- The entire implementation needs to be JS only + some WebAPIs. Anything using server-side code to render is already obsolete and prevents real use in JavaScript based Apps (you can read more about JS-Apps in my blogs)
- …but not depend on additional large frameworks like jQuery
- Managing assets in a full file structure discourages users from working well, as it is so cumbersome and time-intensive that users will automatically become lazy and chaos will prevail.
- Copy-pasting from word is so common, it must be auto-cleaned with 100% reliability
The old editor included in DNN failed at this and the CK Editor as it is implemented now is also not up to the task.
The Evaluation
I started an extensive evaluation in the summer of 2015 and did the following
- Create a list of relevant user features (like bold, italic, etc.)
- Create a list of technical requirements (like CDN support, non-jQuery, etc.)
- Create a list of configurability (like toolbars with custom buttons to browse the DNN files)
- Create a list of management requirements (like open-source license, widely used, etc.)
- Work out which criteria will be the bottleneck (like no-jQuery) to focus on these first
- Create a short-list of about 10 editors based on the critical criteria
- Re-Evaluate in detail to reduce shortlist to a favorite and max. 4 contenders
- Try to implement the favorite and see if it fits
Let's get started with part 2!
Daniel