TL;DR

We’re considering consolidating all our UX for writing Rich Text Content around a single Editor to provide a more cohesive and comprehensive experience. We’re committed to study each content-creation scenario and provide the best experience for that specific use case.

To do that, we’re planning to remove the currently supported variability and configurability of WYSIWYG Editors in Liferay DXP 7.3 and focus all our efforts in providing the best possible experience built on top of CKEditor 4.

Please, reach out to us if you’re currently using a different configuration than the one provided out of the box explaining your specific use case so we can consider the best upgrade strategy.

Context

Since the early days of Liferay Portal, creating content has always played a vital role in the possibilities of our Digital Platform. As the Web evolved and became more ubiquitous, so did the need for richer content. This caused the advent of WYSIWYG (What You See is What You Get) editors that allowed non-technical users to create rich and beautiful content.

As a Platform, Liferay Portal has traditionally allowed administrators to change the specific instance of editor used in several fields. This was traditionally done by specifying the name of the desired editor in a portal-ext.properties file.

editor.wysiwyg.default=ckeditor
editor.wysiwyg.portal-impl.portlet.ddm.text_html.ftl=alloyeditor
editor.wysiwyg.portal-web.docroot.html.portlet.blogs.edit_entry.jsp=alloyeditor

In initial versions, developers could override editor configuration replacing some specific files like ckconfig.jsp via hooks. This soon proved to be a bit too restrictive in case different instances needed different configurations. For that reason, since Liferay DXP 7.0, it’s possible to Modify an Editor’s Configuration or to Add New Behavior to an Editor in a very dynamic and flexible way.

Challenges

Providing a universal WYSIWYG interface is incredibly enticing from a purely engineering point of view. Delivering such an API, however, results in a series of challenging scenarios that are hard to solve satisfactorily.

Editor implementations (CKEditor, TinyMCE, AlloyEditor…) are not functionally equivalent.

Different editors have different sets of available functions and plugins. They also provide different configuration mechanisms. 

Providing a similar experience and the same functionality for each one of the supported editors requires either a huge investment that usually requires to:

• Provide a common configuration abstraction

• Mapping similar features of different editors

• Mapping similar plugins of different editors

• Filling the gap for missing functionality

• Building custom plugins for all supported editors

Editor implementations (CKEditor, TinyMCE, AlloyEditor…) are not visually equivalent.

Visual appearance is one often overlooked characteristic of WYSIWYG editors. Implementations such as AlloyEditor (or equivalent modes in the rest) aim to provide a seamless writing experience by reducing their visual weight to the minimum. This makes them specially suited for specific cases.

For example, our Blogs Application UX is specifically designed to mimic the final result your blog posts will have when published. A similar approach is followed for our new Page Editor feature where the editor needs to integrate seamlessly with the rest of the application.

As one could imagine changing to a completely different editor for those cases would completely ruin the provided experience and likely run into many unanticipated problems.

Certain applications require a specific User Experience to make sense resulting in those editors being locked down to a specific implementation contributing to an Incoherent Writing UX.

Editor implementations (CKEditor, TinyMCE, AlloyEditor…) can not be configured equivalently

Some editors are still configurable through portal.properties as shown in the beginning of this article. Others, however, moved to OSGi configurations a while ago. And as you can probably guess, there are some editors that simply can not be changed.

This creates a gap between user expectations and reality. While we proclaim that editor instances can be changed, this is not true for all of them. And when it is, it sometimes doesn’t produce the expected results.

Conclusion

As briefly stated in the beginning of this post, we aim to provide a better, more coherent content-creation UX by:

• Focusing all of our efforts into a single WYSIWYG editor (CKEditor 4)

• Exploring each content-creation scenario in detail and providing the best possible UX for it

To do this, we’re already working on the following Epics:

• Reduce variability in WYSIWYG Writing Experience. To analyze our current usage of editors and simplify it to provide a better and more cohesive writing experience in DXP

• Create a CKEditor-based Balloon Editor. To create an editor based exclusively on OOTB features of CK4 that mimics AlloyEditor behaviour and functionality

• Provide simplified configuration for WYSIWYG instances. To provide new and simplified configuration mechanisms for the existing WYSIWYG instances.

We hope to complete all this work and be able to provide the best possible content-creation UX out of the box in Liferay DXP 7.3.

Please, feel free to reach out to us if you have any questions or feel you might be impacted by these changes so we can assess the situation and plan accordingly.