Why SnapEditor? | SnapEditor - Online HTML5 WYSIWYG Editor

Top 5 Problems that Developers have with WYSIWYG Editors

SnapEditor solves the top 5 problems that developers have with WYSIWYG editors that we learned while interviewing over two dozen developers. All five of these things were features that we believed were important and we added six more features that we were passionate about that we believe would make you love our editor even more.

1. My Editor Is Not Really WYSIWYG

The #1 problem that developers told us about is that WYSIWYG editors are "NOT What You See Is What You Get" or N-WYSIWYG. Clients complain that viewing the content in the generated page is different than viewing it in the WYSIWYG editor. This means that developers spend time explaining and supporting a component that they did not even develop.

Solution: The solution to this problem is In-Place editing. Your users edit content right on the page in which it is displayed with the correct fonts, styles and size of the display area. Another benefit of In-Place editing is that users don't have to load another page just to edit and yet another one after they finish editing. SnapEditor supports both In-Place editing and the more traditional Form editing.

Cut and Paste from Google Docs shown above into different editors below.

SnapEditor

68 characters

<h1>Hello World</h1><ul><li>Hello Stars</li><li>Hello
Moon</li></ul>

?kEditor

2657 characters - 3907% more code

<h1>
   </h1>
<h1 dir="ltr">
  <b id="internal-source-marker_0.9523176208604127" style="color: rgb(0, 0, 0); font-family: 'Times New Roman'; font-style: normal; font-variant: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; font-weight: normal; "><span style="font-size: 24px; font-family: Arial; color: rgb(0, 0, 0); background-color: transparent; font-weight: bold; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap; ">Hello World</span></b></h1>
<ul style="margin-top: 0pt; margin-bottom: 0pt; ">
  <li style="list-style-type: disc; font-size: 15px; font-family: Arial; color: rgb(0, 0, 0); background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; ">
    <b id="internal-source-marker_0.9523176208604127" style="color: rgb(0, 0, 0); font-family: 'Times New Roman'; font-style: normal; font-variant: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; font-weight: normal; "><span style="font-size: 15px; font-family: Arial; color: rgb(0, 0, 0); background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap; ">Hello Stars</span></b></li>
  <li style="list-style-type: disc; font-size: 15px; font-family: Arial; color: rgb(0, 0, 0); background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; ">
    <b id="internal-source-marker_0.9523176208604127" style="color: rgb(0, 0, 0); font-family: 'Times New Roman'; font-style: normal; font-variant: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; font-weight: normal; "><span style="font-size: 15px; font-family: Arial; color: rgb(0, 0, 0); background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap; ">Hello Moon</span></b></li>
</ul>

2. My Editor Generates Bad HTML

The #2 problem is that WYSIWYG editors generate bad HTML. Pages with a WYSIWYG editor can cause pages to render incorrectly wrecking layouts and styles. A few examples of bad HTML are unnecessarily nested tags, random APPLE-STYLE-SPAN tags and weird combinations of tags especially when content is cut and pasted from another web page or word processor.

Solution: The editor needs to have an automatic HTML cleaner that ensures that the contents of the editor follow a set of consistent rules. The user won't notice this while editing, but you'll notice it because you always get nice clean HTML back from the editor.

3. My Editor Behaves Unpredictably

The #3 problem is that WYSIWYG editors behave unpredictably. In other words, your users expect the WYSIWYG editor to work like a word processor and it doesn't. There are several hard technical reasons for this but it basically boils down to this: Every editor uses a “contentEditable” feature built into the browser but this feature has never been properly specified so every browser implements the features slightly differently.

Solution: The editor needs to have a cleaner (see #2 above) to make sure that the HTML is always in a consistent state. Without one there are so many unusual cases that it is hard to ensure predictable behavior. The Editor then needs to account for the differences in behavior between browsers. Third, the editor needs a Quality Assurance team that actively looks for unpredictable behavior. It is important that the team understands that unpredictable behavior is a bug and not just the user's problem. Finally, the editor needs a full suite of unit tests that tests for these unusual behaviors and automatically runs those tests on all supported browsers before a release.

4. My Editor Needs Better Usability

The #4 problem is that WYSIWYG editors need better usability. Usability is not easy to define but we believe there are three attributes an editor needs in order to be easy to use: (1) It needs to be familiar which means that it works the way that user’s expect based on past experience which right now means it should work like a word processor, (2) it needs to be discoverable which means that users can figure out how to do something even if they've never done it before, and (3) it needs to look simple and beautiful because research has shown that an interface that looks like it is easy to use encourages engagement and usability.

Solution: A good editor needs to be developed by a team that has a Usability and Design Philosophy that includes all three attributes of good usability and adheres to them. It also needs a team with experience in user interface design as well as a designer to execute it.

5. My Editor Makes My Page Slow

The #5 problem is that WYSIWYG editors can slow down your website. This can be because the editor is too large, it is split up into too many files or it contains code that is included with the editor but you don't use (e.g. if you don't need tables but the table code still needs to be loaded).

Solution: We're not all the way there on this one either but our Editor is currently no slower than any other full featured Editor right now. Everything in the editor is already modular and it's only a few steps away from having a version that compiles only the features that you need for your editor. We are also implementing features that allow the page to be rendered before the Editor is loaded, using CSS sprites to reduce the number of connections and other strategies from the book "High Performance Web Sites".

Top 6 Visions For The Future of Editing

In addition to the top needs we discovered during the interviews, there were several things that we felt passionate about and these make up our "No Compromise" list.

These are the features that we think you and the people who use your application will want or need and that once you start using them, there is no going back.

1. It Has to Do Both In-Place Editing and Form-Based Editing

We believe an editor designed for the future must support both In-Place editing and form-based editing. Developers should use the right tool for the job. In-Place editing is superior when WYSIWYG is important and you want to edit on the display page but a form-based editor is superior for many situations (for example for posting comments, writing a support ticket, or as part of, well, a form). If you don't have an editor that can support both, you have to implement two solutions and this sucks for you and your clients.

2. Keyboard Shortcuts for Everything

We believe there should be a keyboard shortcut for ever action in the editor. This is especially valuable for support reps that spend 8 hours in the editor responding to tickets, or power bloggers that write their stories in the editor. These people will love that they can bullet a list, or add a row in a table, or change a paragraph to a heading without touching the mouse.

3. HTML Element and Class Whitelist

We believe that a good editor gives the developer or the designer control over what HTML elements and classes are allowed in the Editor. To do this, the Editor must have an easily readable and configurable list of element/class combinations. The beauty of this is that the Editor is easy to extend with new formatting styles that are appropriate to the web page where it will be displayed with no programming. Designers will love this.

4. Superior Image Handling

We believe that users shouldn't have to think about how images work in an Editor, just like users don't have to think about how images work in a word processor. Here are some problems that we know can be fixed: (1) users have to manage the images themselves using a file manager. We believe that if the user deletes the image in the Editor, the files themselves will be deleted. (2) users have to resize their images before upload. We believe the Editor should know the maximum size of the image is the width of the Editor (or whatever you tell us it should be) and automatically resize the image. (3) When users want to change resize an image, they have to upload a new version of the image in the correct size. We believe that users should be able to drag a resize handle for the image and the server would automatically render a new version of the image in the correct size.

5. Markup Compatible

We believe a good editor supports the ability to bi-directionally convert content to a markup language like Markdown and back and do it reliably. These is important for applications that must support a text only interface (e.g. if the application must work with smartphones, email or text files).

6. Plugin API that abstracts the editor

We believe that a good editor should be easy to extend without having to know the internals of how an editor works. The API should take care of all the inconsistencies and differences between browsers. Already, everything in SnapEditor is a plugin except a core API. The API currently consists of 31 functions but we have not released it yet because we believe we need to be sure these are the right 31 functions first.