Blogs

Blogs

RICH CONTENT EDITOR STRATEGY IN DXP

An updated approach for a coherent Rich Content editing UX

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:

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.

Blogs

Thanks for the info!

A reworked editor would be quite nice.

In general, AlloyEditor works quite well for some usecases, but we often had to change something because clients required it. It was really annoying to change its behavior, add or remove items.

 

We e.g. had to remove the h1 tag since a page should only one h1 tag and editors should not be able to use it. Or another client wanted table support (a standard feature of CKEditor). Or instead of the image tag a <figure> tag should be used/inserted. And so on.

 

Long story short: When you remake the editor, make it easy to add/remove features. You won't be able to accommodate all needs OOB. But making it extensible would help me do whatever my client requires without too much ado.

 

 

This is very positive!

 

To Christoph's point "make it easy to add/remove features" ... this is crucial, but let's go beyond crucial. Let's bake it in. Let's create a fluid editor not ridged one. Consider that it is much more efficient for the vendor to make ALL features available OOTB and offer a configuration UI which checkboxes for portal admins to turn off features. It's far easier to do that than intentionally put out a product with less features and expect the community to deal with it and put the features back.

 

To that end, may I suggest configuration profiles please? Ship it with the configuration profile that Liferay deem appropriate like the application decorators "Barebone", "Content Generation", "Content Review", "Full Power User" and don't mandate that we can only choose one profile for the whole portal right?

 

Blogs may require one profile that gives priority to quotations, citations and image manipulation, web content may (should) require the Full Fat experience, threads may just need Barebone.

 

And allow the content creator to Choose which tools they need and to that end these profiles shouldn't be configuration settings at all they should be a dropdown list right there for the user to choose what editor mode suits best the task they have in-front of them.

 

In time I believe TinyMCE would have been the better choice.

I like the way Liferay decided to go with WYSIWYG Editor, so far in my career I've never had to replace default CKEditor with any other tool. The only action that always happens is extending its features with plugins or modification of existing functionality (e.g. removing h1 tag already mentioned by Christoph).

 

Currently, the only feature that is missing in current CKEditor is the possibility to define different editor configuration for different roles (a bit similar case to what Lee said). I was asked for this a few times already and usually, my client wanted very basic controls for regular editors (e.g. headers and two/three styles) and then full-featured CKEditor menu for Reviewers or Admins.

In my experience, so far, the limited editor is perfect for the new content pages. Simple html is enough there. If they need something "special", we can make a widget for that and they simply place it wherever they want. That's pretty neat.

 

But it is not so nice for Webcontent. It is too limited. I also fully agree with Krzysztof, different "kinds of editors" should see different menus. The skill levels are vastly different, in each company we have editors who are overwhelmed by many buttons. HTML? -> Panic!  And others who are perfectly able to edit the html.

 

So, long story short: Thumbs up for that request!

 

I'd like to add something:  One thing that needs a lot of love are images. It is still terribly hard to create a webcontent with images.

 

1) Please try to resize an image by dragging the corner to exactly 320px width, I dare you.

2) Extra settings for images: Border yes/no. Margin please (When I place to images next to each other, there is no gap between them. That might be what I want. Or not). Subtitles, please.  figure tag, please? And so on.  

3) Technically resize the image to that width to decrease the image size (we already talked about that at Devcon, it isn't editor specific)

 

When you look at Wordpress, the handling of images in blog articles is something they do pretty well.

It's so frustrating to see this because shouldn't we be moving away from CK at this point?

 

"When you look at Wordpress, the handling of images in blog articles is something they do pretty well." <-- It's Tiny MCE. Sorry for sounding like a broken record. Please take a look at the Demo of Tiny MCE https://www.tiny.cloud. Currently the demo has the mode switcher implemented "Classic", "Inline", "Distraction Free". That's all we need, for the user to choose which mode they want to edit in and it's right there in front of our faces.

 

 

Looking through the linked Jira stories, it looks like this work (well some of it) was pushed off to 7.4 (some indefinitely).

I'm curious though...If you guys plan on rewriting the editor, why use CKEditor 4 as your base?  Why not start with CK5?