Whats wrong with WYSIWYG
The current WYSIWYG paradigm has been inadequate for a long time and we need to update and replace it. Using a WYSIWYG editor is pokey and horrible. Producing text this way feels like trying to write a letter while its still in the envelope. These kinds of editors are not an extension of your self, they are cumbersome hindrances to getting a job done.
The new generation of HTML5 editors take a large step forward. Not because they integrate HTML5 as such but they act on the elements in the page directly. That allows ‘the page’ to be the editing environment which in turn opens up the possibility for the content to be represented in a variety of forms/views. By changing the CSS of the page we can have the same content represented as a multi-column editing environment (useful for newspaper layout), as a ‘google docs type’ clean editing interface (see demo below), a semantic layout for highlighting paragraphs and other structural elements (important for academics) as well as other possibilities….
It is also possible to consider creating css snippets and applying them dynamically using the editor. This is in effect turns the editor into a design interface which will open the path for in-browser design of various media.
Lastly, WYSIWYG editors, while marvelous in their day, have had their day. They feel too pokey and ‘old school’. Largely due to the success of Google Docs users no longer want to poke around in a tiny WYSIWYG editor. They want large clean interfaces for content production.
The above screen shot is taken from the semi functional demo at http://data.flossmanuals.net/mercury/index.html (all demos work only in Chrome for now).
In brief summary, essential problems of the current WYSIWYG world are :
- representing the content in context is difficult
- the content is not part of a page so additional functionality like (non intrusive) annotations cannot be added to content
- dynamic rendering of content retrieved from the server is hard to achieve
- dynamic creation of content is hard to achieve
- they look ‘pokey’ and old school
- synchronous editing is possible but hard to achieve
- users want to see the content they are making in a much cleaner and clearer ‘fullpage’ way
- some users want semantic views
- some users want design views
- all users must be able to edit the content (designers, editors, content creators, etc) and do what they need from the same view
Online book production has special needs such as the ability to display the content as it might appear in the output, annotations, draft view etc.
A short list of starting list of features for a new editor might look something like this:
- harmonise edit, draft, proof, design features into one view
- live chat
- short messages which also support ostatus api (which is built on twitter spec)
- send to renderers from within the editor
- ability to switch on and off third party JS libs
- apply CSS templates to content
- create CSS snippets
- add snippets to templates
- share snippets and templates
- dynamic snippet rendering
- live template swapping including semantic layout and ‘output’ view
- synchronous editing
- per ‘chunk’ notes
Many of these features are relatively easy to achieve, others will take some careful thought and planning.
- backend hook up to git
- versioning of content especially for different outputs (A4 vs A5 pages, html, epub etc)
We need to develop with an editor in the hand. The current batch of html editors does pretty well but we need to choose one which has a good support community and a good feature set. In this there is just one option - mercury editor.
It currently has a new home page (less than 2 weeks old), and a thriving community.
Some demos if what could be done with mercury in a book production environment:
If anyone would like to work on this please contact me email@example.com
If you want some more convicing try this…
Its a math editor using Mercury and MathJax…try typing $f(x)$ into the window to see how it works
Or try this to see how AnnotateIt works in this environment: