see what xinha is up to

Evaluating WYSIWYG editors:

wysiwyg-wishlist
wysiwyg comparison

Determine a set of editors to evaluate.

I propose these:

• Kupu (example)
  
• Xinha (example)
  
• TinyMCE (example or simple example)
  
• Dojo (example)
  
• Wikiwyg (example - double-click to edit a paragraph)
  

I don't feel like looking at FCKEdit; I think TinyMCE and Xinha offer enough diversity in that area, and something about FCKEdit just bugs me.  TinyMCE is a bit more mainstream than Xinha.

I would have left Dojo out, except it's actually tested and has a community of developers that looks more like a normal open source community.

Wikiwyg is a bit of a long shot, but has some novel/interesting features.

Determine Criteria

While I don't see any reason to do strict scoring, we should think about the things we actually want to look at, and agree on some vague sense of what's important.

Engineering:

• Is it fully open source (requirement)?
  
• Are there core developers who are responsive?
• Do they use normal development process (public repository, mailing list, bug tracker, etc)?
• Is the code clean and commented?
• Are there automated tests?
  
• Is it possible to extend without editing the core?
• Usage documentation?
• Stable releases with some frequency.
  
• Accept patches and offer commit rights and say to people outside the existing core.
  

Discussion:

Re: Stable releases with some frequency

This is not huge for us as we can be somewhat bleeding edge.  But it does show a commitment to make this a product.  Yes, this is mostly aimed at xinha, but I do get a bit of fear when I always see that you just test the nightlies.  I'm open to being convinced this is not such a bit issue. -- cholmes

That's fair.  None of these will be perfect, so ultimately we're going to just weigh the various factors.  Releases are definitely nice.  Being aware of backward compatibility is also important (and often doesn't apply to Javascript, but does here).  Putting out releases with backward compatibility problems is probably worse than releasing nightlies but being cautious about regressions.  Breaking stuff on a whim *and* not making releases is the worst case, of course.

Some projects use releases as an excuse to break things (because it doesn't have to be stable until release, or a desire to get the API "right").  I don't like this.  -- ianb

Technical requirements/goals:

• How fast does it load?  (Are they concerned about this, is there work to improve it?)
• Does it offer reasonable source editing?  (flat/minimal HTML isn't reasonable for editing)  If you upload HTML created from another source, will it mangle that HTML?
  
• Does it support advanced editing, like editing complex layouts?  (Do we care?)
• Does it offer multiple editor "profiles" -- e.g., a full mode, minimal mode, table editing, etc?
• Does it have context menus and other "clever" bits of UI?
• How visually bulky is it?  (Profiles matter here, as does the context in which it is used -- in the wiki a bulky editor is okay because that's the whole point; embedded in a smaller form it's important that the editor is light/small)
• Is it quirky?  Does it feel pleasant and predictable to use?
• Is data loss possible?  Does undo/redo work right, does the back button work, does text ever disappear?
  
• Does it support the browsers we care about?
• Does it have any features to extend its styles?  Microformats?  (Basically: light ways to extend and specialize the editor)
• Anything like Kupu's "special" features like drawers?  (We'll probably have to reimplement, but if there's something close then that helps)
• Is there a way to set it up with light/markup-based constructs?  E.g., <textarea class="wysiwyg">
• Customizable toolbar layouts?  Is it easy?
• Uploading, for pictures and attachments.  (Kupu is the only one with direct integration; others might have the framework for this kind of integration, which would help us develop the integrated features)
  

UI requirements/goals:

• Is it sluggish feeling? (Hard to fix)
  
• Arrows/enter/etc works like expected? (Hard to fix)
  
• Good keyboard shortcuts? (Not hard, not easy to fix)
  
• Existing end-user documentation? (We might have to write our own anyway if we customize it much)
  
• Internationalized? (Requires upstream coordination)
  
• Nice looking buttons? (Fixable if we get into icons)
  
• All the markup we care about is made available?  Not too much markup we don't care about?  (Fixable if the toolbar can be customized)
  

Priority

The ultimately decision will probably be based on an informal weighing of the options, as all options will have pluses and minuses.  A rough list of priorities:

• No quirks, feels good
• Ease of adding features and customizing or changing the interface
• Active and helpful development community, ideally using standard open source methodology
  

Do Evaluation

Once we figure out how and what, we must actually do the evaluation...