Browser Based WYSIWYG Editors
Lately there’s been a number of blogs from people looking for Java WYSIWYG editors that work in a browser. The latest one from Bertrand Delacretaz is enough to prompt me to speak up.
Firstly, I work for a company that develops a browser based WYSIWYG editor so I’m biased, but I’m also an expert in the field. We’re the top of the line in browser based editors and there’s really only a couple of other companies that can compare with our product. There are thousands of other products on the market that provide varying ranges of functionality, most of them are tied into a particular browser, particular platform or both. Mostly, they don’t provide a full editing experience to users or are difficult to integrate.
Here’s a few things you should look at when you are shopping around for a WYSIWYG editor:
- Platform and browser support. Do you really want to tie your application into a single browser or a single platform? How do you plan to handle the eventuality that you wind up having to support a different platform?
- Ease of integration, particularly having a similar architecture across platforms. There are a number of editors that require you to integrate them into your system in different ways depending on which browser and which OS you’re running on. Duplicate effort means more expense developing the system and a greater chance of bugs in the integration.
- Advanced editing support. Some applications just need to provide bold, italic and underline for their users and any solution will do. Most of the time though giving users more power will allow them to be more efficient and enjoy using the system more. Check how the product handles lists and tables in particular as these are the hardest parts of HTML to edit. Also look for CSS support - can you enforce a standard corporate style?
- Expandability/customizability. Can you adapt the system to do what you want? A standard feature of the better editors is the ability to create custom toolbar items or menu bar items which can callback to javascript methods, insert custom HTML or a range of other actions which allow you to develop extra functionality or better integrate the editor into your system. The best example of this is being able to replace the insert image dialog so that the user can search through the images in a CMS system.
- Ease of deployment. Users need to be able to get at the software. Look for something that deploys automatically (yes the java runtime can be automatically deployed, as can ActiveX objects and obviously JavaScript solutions) and upgrades automatically (JavaScript or Java solutions are the best at this and ActiveX is capable of it too).
- Support. It’s very rare that any of these solutions are a perfect fit straight off and you will most likely need to spend time reading the documentation and contact the company’s support team to get help to integrate it perfectly into your application. The difficulty of this will depend on how tightly you want to integrate the editor into your application, simple things like just being able to edit a standalone HTML document and save it again can be achieved straight off. More complex things like integrating your scripting language, templates, inserting images from your CMS repository and a huge range of other things can be more difficult and are entirely situation dependant. Choosing a good editor to start with will make things much easier, but you’ll most likely need some experts to point you in the right direction at some point as well.
One other thing I really want to point out (and this is where I delve into the specifics of one of our products), is that these editors shouldn’t be limited to just working in a web page. They can be embedded into a thick client application too with some really stunning results. A great example of this is Ephox’s latest product, EditLive! for XML. It provides a forms based editor XML which is pretty cool in itself, but what I’m really proud of is that the Visual Designer, which allows you to create XSLTs and XSDs for your forms, is an applet that uses the EditLive! JavaBean (our HTML editor packaged up in a form that’s easy to embed in an application). It doesn’t use any internal APIs either, it could have been completely created by someone outside of Ephox.
It’s absolutely amazing the kind of power that is available to applications that embed something like the EditLive! JavaBean - you get the ability to override any function in the editor and handle it yourself, including pre and post processing for that action, you can define your own custom tags and views to go with it (a feature we’ll be adding to our applet version soon through CSS as well), all while leveraging the hard work we’ve put in to make editing HTML easy.
Anyway, I’ll leave that there before it turns into too much of a sales pitch, but suffice it to say that the WYSIWYG editor area is as active, innovative and exciting as most of the other IT buzzwords at the moment. In most systems it’s also the part that is most used by users and the quality of your editor is often a critical factor in the perceived quality of your system. Do try to pick a good one.
April 22nd, 2004 at 10:01 pm
Thanks for your advice! This is very useful (although it means yet more choices ;-)
April 23rd, 2004 at 1:07 am
Thanks here as well, but your WebStart demo bombs out in search for a DOM implementation using Safari & Mac OS X:
java.lang.NoClassDefFoundError: org/w3c/dom/Text
at org.a.a.ah.(Unknown Source)
at org.a.a.f.(Unknown Source)
at org.a.a.n.do(Unknown Source)
at org.a.a.n.(Unknown Source)
at com.ephox.editlive.java2.c.a.(Unknown Source)
at com.ephox.editlive.java2.c.b.(Unknown Source)
at com.ephox.editlive.common.EditorCommandHandler.do(Unknown Source)
at com.ephox.editlive.common.EditorCommandHandler.if(Unknown Source)
at com.ephox.editlive.ELJBean.g(Unknown Source)
at com.ephox.editlive.ELJBean.(Unknown Source)
at WebStartDemo.(WebStartDemo.java:70)
at WebStartDemo.main(WebStartDemo.java:37)
at java.lang.reflect.Method.invoke(Native Method)
at com.sun.javaws.Launcher.executeApplication(Launcher.java:844)
at com.sun.javaws.Launcher.executeMainClass(Launcher.java:804)
at com.sun.javaws.Launcher.continueLaunch(Launcher.java:682)
at com.sun.javaws.Launcher.handleApplicationDesc(Launcher.java:397)
at com.sun.javaws.Launcher.handleLaunchFile(Launcher.java:199)
at com.sun.javaws.Launcher.run(Launcher.java:167)
at java.lang.Thread.run(Thread.java:491)
(oh: obfuscating Java binaries code is soo lame ;-)
June 23rd, 2004 at 6:44 pm
“We’re the top of the line in browser based editors and there’s really only a couple of other companies that can compare with our product.”
Are you sure? Of course, you say that, because your are one of the developers…
I think the realobjects editor is very superior to your product. With editlive, it’s easy to produce crappy xhtml, the xhtml code and “custom tag” feature of editlive is worth a loud laugh. realobjects does this much better. with their new version, you will never be able to compete, since you are basing on the crappy swing html editor stuff…
but… nice try :o)
June 23rd, 2004 at 7:27 pm
Couple of responses (greatly delayed, sorry about that):
Stephan, the WebStart demo is fixed, we needed to apply a work around for a bug in Mac OS X’s required JRE detection. Also we obfuscate the Java code as it reduces the size of the jar file significantly (package names change from com.ephox.editlive.java2.editor.images.InsertServerImageDialog to com.ephox.editlive.a.a.b.a which adds up to a pretty dramatic space saving).
Anonymous, perhaps you’d like to try the latest version of our product and the much improved custom tag support. You can now mark tags as block, inline or empty and provide your own custom view for them using the standard javax.swing.text.View class or just supply a label and icon using custom CSS attributes. With this in place you can guarantee that the resulting XHTML is at minimum well-formed. I should also note that the custom tag support in EditLive! for Java even without these new features is on par with that of FrontPage, with these new features we now have the most flexible custom tag handling I’ve seen in any editor to date.
Of course, if you really wanted validity, you might want to consider using EditLive! for XML which performs on the fly validation and has a whole swag of features designed for making sure that the resulting XML is valid.
As for the use of the “crappy swing html editor stuff”, while we’re based on that, there’s very little of it left in our product as we’ve been gradually replacing and improving sections to provide better and more reliable functionality.
Finally, regarding: “you will never be able to compete”, I should point out that Ephox is not only competing, but holds significantly more market share than RealObjects in the browser-based editor market. Which editor is better depends on what your specific needs are and will depend to some degree on personal preference, whether or not Ephox can compete with RealObjects is a definite non-argument - Ephox has been competing and winning for some time now. Ephox is the biggest supplier of cross-platform browser based editors in the world, bar none. On the windows only side I believe Ektron still has a larger market share but they have no cross-platform option at all.
I’d be happy to forward on white papers comparing EditLive! for Java with RealObject’s editor as well as a range of other popular options, or better yet drop me an email with the description of what you want from an editor and I’ll tell you how to go about it with EditLive!
June 6th, 2006 at 11:49 pm
You are the greatest.
You are the only web rich text control where I can simply paste image from clipboard.
Congratulations!
June 7th, 2006 at 9:51 am
[...] I got some nice feedback over night on an old post about WYSIWYG editors: [...]
October 29th, 2006 at 4:53 am
Hey, I’m starting a (very ambitious) e-learning website and I’ll need a browser-based editor. I came across EditLive and it seems a great fit in many ways. (Especially in that it allows users to paste from the clipboard to your app.)
I’ve got three questions:
1) Which Java version is this? The latest Java doesn’t have a great market penetration, and I’m going to need something that works for at least 90% of the users. I don’t want to force them to download huge runtimes just to edit documents online.
2) What does the editor output? XML? If people don’t have Java, I would like them to at least be able to run a tool that DISPLAYS the contents of the document, including math formulas. Do you know of any tool that can render your app’s output (at least semi-decently)?
(If not, we might just have to write our own AJAX-based equation editor and compete with yas, hehehe.)
3) What is the SUPPORT like at your company? Suppose we purchased a professional license. When our clients start complaining that the editor on our website has a bug, what are our options?
Sincerely,
Greg
October 29th, 2006 at 6:45 am
Greg,
See my reply over on http://www.symphonious.net/2006/06/07/pasting-images-into-editlive-for-java/#comments
Adrian.
November 13th, 2006 at 1:09 pm
[...] Other than that, it's a pretty good list of basic requirements for a WYSIWYG editor. I've commented before on some key things to look at when evaluating WYSIWYG editors that comes at it from a slightly more technical side. Combine the two and you have a good system out of the box that can be customized and extended to provide the best possible editing experience for users. [...]