The Holidays are upon us and 2011 is nearly gone. This past year has been extremely busy and significant for Sitefinity. Before we move into 2012 I want to reflect on 2011. This post is strictly my personal opinion and, consequently, is being published to my personal blog.
I’m publishing this for Sitefinity customers who might be interested in a Telerik insiders’ perspective on this past year. Hopefully this provides some context and a glimpse into what’s coming in 2012.
Most of what you read online flows through web-based (browser-based) WYSIWYG Rich Text editors. These tools are central to every CMS and enable content authors, who might know little about HTML, to create HTML.
However, content authors are often baffled by the behavior of these tools. In fact, many characterize their Rich Text editor as the most fragile part of their CMS. This blog post is inspired by my research into this challenge.
This web page looks the way it does because of a combination of HTML and CSS. These 2 technologies are the primary languages of the web. However, very few people who publish web content know HTML & CSS. This is okay though; very few people who drive cars can build a car.
Rich Text (WYSIWYG) editors enable content authors, who know nothing about HTML, to create HTML. However, there are good & bad practices with regard to HTML & CSS. When Rich Text editors are poorly configured these tools make it easy for unsuspecting authors to accidently ruin their web site.
CKEditor comes included with a handy-dandy style selector:
Unfortunately this style selector defaults to a very small width. This small width can result in larger styles being truncated:
Thankfully this can be fixed with a couple of custom styles:
WYSIWYG Rich Text editors are central to every CMS. These tools enable content authors, who might know nothing about HTML, to create HTML content.
However, content authors frequently fear and avoid their CMS’s rich text editor. These tools are perceived as confusing, buggy & fragile. As a result, content is written off-line, using tools like MS Word, and then pasted into the CMS’s Rich Text editor. Unfortunately, this behavior creates a completely different set of challenges.
This post is devoted to reshaping this behavior. The goal is to lure content authors away from their trusty off-line tools and instead use their CMS to compose new content. Below are some recommendations for creating a more friendly web-based authoring experience.
This title will send chills up the spine of web developers & content authors everywhere. Web Developers fear the bloated markup caused by this action. Content authors fear the difficulty of mixing their favorite authoring environment with their CMS’s editor.
The problem isn’t copy & paste. The problem is WHAT is being copied & pasted.
Plain text (content without any styling) is completely safe to paste into a Rich Text editor. However, rich text content consists of 1) text and 2) styling.
This sentence has a bolded word.
In this example, my Rich Text editor added hidden markup around the word “bolded”. This markup instructs the web browser to apply special styling. If this content is copied & pasted into another program then this hidden styling is included.
And despite what you think, this isn’t what you want…
WYSIWYG Rich Text Editors (like TinyMCE, CKEditor, RadEditor, etc.) are central to how content gets into a CMS. These tools enable content authors, who know nothing about HTML, to create HTML. However, these tools are notoriously fragile, buggy and confusing to non-technical authors.
There aren’t any perfect answers to this challenge, but a helpful strategy is to disable unneeded features that are cluttering the Rich Text editor’s toolbar. This is a minor task that creates a vastly improved authoring experience.
At best, these unneeded features confuse content authors & encourage bad practices. At worst, these features will cripple the web site. Identifying (and removing) unnecessary Rich Text features creates a friendlier, safer and more predictable content authoring experience.
I’m researching this subject for an upcoming session. For this session, I wanted a screenshot showing the abominations made possible by too many Rich Text features.
Here is what I came up with…
I’m using TinyMCE, but it could’ve been almost any WYSWIYG editor. The plethora of features provided (absolute layers, emoticons, etc.) provide more than enough rope to hang yourself. It’s also fascinating that many CMS’s leave all of this stuff enabled.
It’s not surprising that non-technical content authors hate their Rich Text editors.
–
What about you? What Rich Text (WYSWIYG) features have you found to be deadliest in the hands of end-users?
Each blog post in Sitefinity can be classified using tags and/or categories.
These classifications can then be used to display a filtered list of blog posts related to a particular subject. For example, Sitefinity classifications & filters could be used to create a list a blog posts related to Technical Writing and screenshots.
The instructions below describe how to filter blog posts based on these classifications.
Each blog post in Sitefinity can be classified using tags and/or categories.
These classifications can then be used to display a filtered list of blog posts related to a particular subject. For example, Sitefinity classifications & filters could be used to create a list a blog posts related to Technical Writing and screenshots.