Conceptual Clarity

It’s been a while since I’ve written an article about EditLive! so I thought that I’d better put one out there about what the team has been working on recently and what we are currently working on.

Since the introduction of the major new functionality of the 6.0 release we’ve been working on performance.  “Performance, but EditLive! is a Java applet!?” I hear you say.  That’s right, we’ve been finding some great new ways to get Java to stand up and perform.  And performing it is.  I now routinely experience EditLive! load times of less than 3 seconds!  That’s less than most JavaScript based editors out there (BTW that’s because of the number of HTTP requests they perform). 

In the EditLive! 6.Performance releases (that’s 6.1, 6.2 and 6.Next) we’ve incorporated a whole range of caching routines that people can take advantage of, particularly with 6.1 and 6.2.  In order to take advantage of these things you will have to make some code changes to your integrations, but they are minor and if you have any questions check out the information on LiveWorks! or get in touch with our ever-helpful support team.

As always, we’re running all these improvements on our internal systems as part of our commitment to continual testing.  The performance improvements are outstanding, of course I’m somewhat biased as the EditLive! Product Manager, so please, check out the improvements for yourself.

We’ve also incorporated the new Inline Editing functionality of EditLive! with our EditLive! for ILWCM integration and we’re getting rave reviews from those who’ve rolled it out.  In particular we’ve had a major client shift from using IBM’s JavaScript-based editor to EditLive! and they’ve cut their page load times from over 30 seconds to 3.

The engineering team has definitely pulled some rabbits out of their collective hats and they’re not done yet.  EditLive! 6.Next will contain more improvements.  At this stage I’m not going to spoil the surprise, but I think there will be many out there who appreciate it.

So check out the latest release of EditLive! and experience just how fast Java can be.  Also stay tuned for what’s coming up in the next few months, there are some exciting improvements just around the corner.

Over the last six months I have had many people ask me whether Ephox will be developing a JavaScript-based editor in the future.  This is something that we've considered in the past, but the reality of the situation at the moment is that Java enables us to do more and that means deliver more to you. 

Most of you have probably already seen the likes of FCKEditor and TinyMCE and perhaps even used one of them.  These are probably the two best offerings available based on native browser technologies.  The way that these editors work is by using JavaScript to work with an editor component embedded within the browser.  This works well for most basic editing, for example, bold, italic, underline and simple tables.  However, these tools are ultimately limited by the functionality that the browser can provide.  At the end of the day, browsers aren't built for editing, they're made for rendering.

The other advantage to the JavaScript approach is that there is no JRE install required.  However, over the last few years Sun Microsystems has done a great job with it's Java Everywhere campaign and I can't say that the issue of Java support has caused us any problems in the last year or so.

Java has freed us of the constraints of the browsers and this is why EditLive! can offer important productivity functionality like spell check-as-you-type, thesaurus, accessibility checking and syntax highlighting for source code editing.  Another great example is track changes, here's a feature I don't imagine any browser development team building in, and without Java I don't think we could have built it either.

Finally, there's a whole lot of little things that we've been able to do with EditLive! that often don't get noticed on the initial evaluation, but you're contributors will get annoyed if they're not there.  Andrew likes to refer to this as "the death of 1000 pin pricks".  These are the little things that people have just come to expect over time.  Menus for instance - without menus users will need to mouse over each toolbar icon to see what it does, or dialogs getting blocked by pop-up blockers, or the lack of double-click actions to open properties dialogs or simply the preservation of content when you accidentally hit the back button.  No single one of these is enough to cause contributors to stop using an editor, but together…well it's the death of 1000 pin pricks.

So yes, we use Java, and we will continue to do so, keeping our eye on the browser-based technologies, and re-evaluating them as they (hopefully) offer more functionality.  At the end of the day Java enables us to provide you with the most value so that's where we need to be.  What matters to us is delivering productivity to you and your users every time that they use EditLive! and that's exactly what Java enables us to do better than anything else.