Imagine that you’re casually browsing your website and notice a typo. Now envision the steps required to fix this typo. What if you were using someone else’s computer? Would you need to install additional software? How many logins would it take? How many clicks? How much time? Could you talk your grandma through these steps?





For the past 5-years I’ve focused on Telerik’s Sitefinity CMS and during those 5 years I’ve spent an obnoxious amount of time pondering basic questions like these. Most of the content on the web isn’t put there by developers, it’s put there by end-users. They create this content using Rich Text (WYSIWYG) editors and Content Management Systems (CMS’s).

Fixing an onscreen typo probably involves leaving the current page, typing a new URL, logging in, re-navigating to the page (this time in the backend), clicking edit, fixing the typo and (finally) clicking save. If the content is “special”, then end users will literally need to email someone to get the problem fixed. The level of effort required often feels disproportionate to the trivialness of the task (fixing an onscreen typo). And I’ve painfully learned that people will simply abandon ideas if the execution cost is too high. Many of the sloppy mistakes we encounter on the web likely exist because they are too painful to fix.

As developers and interaction designers, our goal is to reduce the gaps that exist between intent and execution. Towards that end, fixing a typo on a website should take precisely 2-clicks. One click to edit, one click to save. Anything more than this, is injecting complications that have nothing to do with solving the original problem. Thankfully, the In-Line Editing feature, found in the latest release of the Kendo UI Editor, enables us to create this 2-click editing experience.

WYSIWYG is a Big Dirty Rotten Lie!

Rich Text Editors are something of a blessing and a curse in the CMS world. On one hand, these tools empower people who know nothing about HTML, to create HTML. On the other hand, the HTML created by these tools often looks like it was conjured in the 7th level of hell (aka MS Word). Developers justifiably view these tools as trojan horses and subsequently foist other punishing experiences on their end users to address the problem.





End users are equally frustrated by Rich Text Editors because they create a false (and often confusing) representation of what the final content will look like. The editing experience is frequently sandboxed (in an <iframe> ) and uses completely different styling than the final page. Or put differently, the end user is taken out of context during the authoring experience and only returned to the original context after they click publish.

When creating web content, context matters and by putting end users into a sandboxed editing environment we remove that context. It’s very common to create new content, click save and then discover the content is wrapping strangely or simply doesn’t work on the “live” page. Fixing this requires yet another round of clicking, as content authors cycle between editing, saving, viewing and then back to editing.

This is one of those workflows that has become so common that few of us pause to consider how completely awful it is. By contrast, it would be ideal if we could stay in context while creating and editing content. This would make the transition between “browsing” the web page and “editing” the web page almost seamless.

Incidentally, what I’m describing above was the original intent of the web. The web’s creator Tim Bernes-Lee always envisioned that the web would be read/writable. In fact, the first web browser, was also a web editor. However, as websites became popularized we strayed from this original vision and web “browsers” (as their name suggests) became focused on content consumption. As a result, web-based content creation often remains a suboptimal experience.

Returning the Web to Its Editable Roots

Inside the HTML5 specification is a proposal for a single parameter that would once again make the web editable while simultaneously providing a true WYSIWYG editing experience. This is accomplished by adding a simple parameter (ContentEditable) to HTML elements.

ContentEditable <div contenteditable> Edit me. </div>

The advantage of the “contenteditable” property is that content becomes editable in-line and in-context. There isn’t any <iframe> or other hacky nonsense involved which would create a false representation of the final result. Furthermore, this property is already supported in modern mainstream browsers and exceedingly easy to apply to existing HTML.





There is problem though; the default editing experience offered by web browsers is exceedingly basic. Although the content becomes editable in-line, there isn’t a toolbar to help content creators insert styling, images, etc. Furthermore, there are a limited number of event hooks developers could use to create server-side persistence of the edited content.

Each of these challenges is addressed with the latest version of the Kendo UI Editor.

Create a Better Editing Experience

Once the required Kendo UI script references are in place...

Required Kendo UI References <link href="styles/kendo.common.min.css" rel="stylesheet" /> <link href="styles/kendo.default.min.css" rel="stylesheet" /> <script src="js/jquery.min.js"></script> <script src="js/kendo.all.min.js"></script>

The only thing required to make content editable in-line is to add a “contenteditable” parameter to the <div> that surrounds the editable content. Then you just need to select the element with Kendo UI and attach the editor widget to it. The Editor widget now works in conjunction with contenteditable.

Enable Kendo UI Editor Inline <div contentEditable class="column"> <img src="../../content/web/editor/web.png" /> <h3>Web app <br />development <br />framework</h3> <p> ... </p> <script> $(".column").kendoEditor(); </script> </div>

One click toggles between editing and viewing the content and the Kendo UI Editor will automatically enrich the browser’s default editing experience.





The options contained in the toolbar are driven entirely by configuration, which enables developers to protect end users from themselves by disabling tools that might enable them to create undesirable markup (like ad-hoc CSS styles).

What You See Is What You Can Edit (WYSIWYCE)

I’ve always wanted my web editing experience to be almost casual. As I browse my website, if I see something that needs fixed, then I just fix it. And I want the act of fixing it be impulsive and reflexive, it’s done before I even realize what I’m doing. I’m delighted that Kendo UI’s Editor now has In-Line Editing capabilities and even more delighted that these features will be included in an upcoming version of Telerik’s Sitefinity CMS. Because fixing a typo shouldn’t be that hrd. :)