Conceptual Clarity

Don't you just love analogies?  Well I hope you do because if you're about to be on the receiving end of one.  I was watching an episode of the British car show Top Gear yesterday with a segment featuring Richard Hammond attempting to drive a Formula 1 car.  Now if you're like me, or Richard Hammond as it turns out, you'd be sitting there thinking, "driving a car, even if it is a Formula 1 car, how hard can it be?"  It turns out that, the answer is "very!"

This particular situation struck me as having parallels with our development of EditLive! and web based rich text editors in general.  At the highest level EditLive! is basically a word processor for the web.  It's got most of the features that you might find in Microsoft Word or Open Office with some tweaks to make them more applicable to web documents e.g. generating standards compliant HTML for starters.

At the outset this doesn't sound difficult, after all we've had many of these features in Microsoft Word, Open Office or even the browser (when it comes to rendering) for years.  Yet that apparent ease doesn't parallel with Ephox's experience in development.  We have been, and still are, developing EditLive! in its present form for 6 years now, since I started at Ephox in fact.  However, that's nothing compared with MS Office that's been around for over 20 years!  The features that we all take for granted in Microsoft Office are (mostly) well designed and the result of the significant levels of investment that you'd expect from Microsoft.  It's when you take a much closer look at the web standards and user behaviour that you start to realize how complex the task of creating a word processor is (cue the Formula 1 analogy).

As the product manager for EditLive! I've experienced this effect for several years now when defining the specifications for EditLive!.  Whether it's a specification for track changes, how specific keys work in various situations (e.g. "Enter" or "Tab") or even down to the level of how text renders on the screen each area has a surprising amount of detail to consider and nuances to implement.  For instance, in HTML try checking out the difference between PTs, PXs and EMs for fonts and did you know that PXs can be considered a relative measurement?

At Ephox we've put a lot of investment into these little things in the past because we believe the little things are important for authors.  The fact that the tab key indents a list in some cases and in others navigates a table or adds a table row - important.  The use of the Enter key to insert a paragraph in some cases, a <br> in others and in others still a list item - important.  The ability to resize every aspect of a table inline instead of via a dialog - important.  I could go on as there are many, many more of these small items that are important to all the web content creators out there.  However, the most important thing I think you could expect from a rich text editor is that it, and the team behind it, realize the importance of all these little items.

Creating a word processor is much more difficult than it seems just like driving a Formula 1 car and the most important thing in both cases is attention to detail.  In the coming months you'll see that attention to detail coming through yet again in our latest release of EditLive!.  We've been paying attention to rendering, to font sizes, to keyboard behaviour and many other areas.  I'm confident it will be another fantastic release and if you'd like a sneak peek, just head over to LiveWorks!'s Early Access Release and check the latest in EditLive! 6.4 out for yourself.  Improvements to date have focused on CSS rendering for floats and getting sizing correct for different units and there's more to come.

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.

As the product manager for EditLive! I spend a lot of time thinking about how we can enable people to be more productive using one of the most familiar software applications - the word processor.  Certainly there are major features that can improve productivity in leaps and bounds - spell checking as you type, or track changes for instance - but, for me, making productivity gains in any piece of software is a game of clicks.

When you think about your user interface design give some thought as to how many clicks it’s taking your users to browse around the interface.  As a user a click is not just a click, it’s a series of actions.  You start by looking for the command you want, you then move the mouse and make a click, you may then have to interpret the new dialog or information presented on screen and then, finally, perform the action you wanted to perform.  The effect of adding clicks is even worse for web applications where each click can mean another HTTP request and, even in the age of AJAX, a screen refresh.  Sure, most of the time this is a process performed in less than 10 seconds or so, maybe a minute for a very slow web application - but those 10 second blocks add up and they add up fast and they add up to dollars.

For example, lets take a team of 50 knowledge workers getting paid about $30 an hour each.  As part of their daily tasks they have to add information to a wiki, to a blog and perhaps to a content management system.  To do this our hypothetical knowledge workers will be using my favourite web word processing interface; EditLive!.  Conservatively I’m going to assume that we can save each one of these people 10 minutes a day (that’s only about 60 clicks a day).  Over the course of the year this means a saving of $62,500 just through a few less clicks.

When playing the game of click minimization though you need to be careful not to confuse it with feature minimization.  Fewer clicks does not mean fewer features, it simply means making the commonly used features easier to find and use.  A great example of this is the Apple iPod.  With my iPod I can do anything from browse a photo library through to playing a song, but the most commonly used functionality is simply a button press away in the form of the play button.

When looking at EditLive!’s interface there are several of things that we do for click minimization.  For starters there is the context menu, making it easy to access the most relevant commands for a particular cursor location within two clicks (a right and then a left).  Then there’s the keyboard UI, for example, the tab key can be used to add four spaces, indent a list, outdent a list or add a table row all depending on where the cursor location is.  Finally there are the EditLive! dialogs that will not be blocked by popup blockers (saving all those clicks to allow popups) and they’re already cached by EditLive! ensuring you never have to wait for the web server to send you the dialog.

All these elements quickly add up and you can see that it doesn’t take long to reach savings of over $60,000 a year.  So, if you’re designing a user interface today or evaluating a productivity tool put some thought into how many clicks your users will have to go through because it will save you time and money.

It wasn't just the Lotus aficionados who were excited about Lotusphere this week Orlando, we had a team there as well in support of our EditLive! for IBM Workplace Web Content Management (IWWCM) integration.  Things got even more exciting for us when Mike Rhodin announced that the integration had taken out the Best in Lotusphere Showcase award (at the time of writing the Lotusphere page is yet to be updated with this news).

This is great news for the Ephox team and certainly made my day when I heard it on Tuesday (Australian time).  However, I think it's even better news for all those people out there creating content on the web, whether they are using EditLive! or a competing offering.  To me it signals realization of the importance of rich word processing applications for the web and how these applications can make the task of getting content online so much easier.

Creating compelling web content is complicated, much more so than using Microsoft Word to create a document.  The web's componentized architecture really makes it difficult for your average contributor to write content.  The web adds a whole lot more complexity - as a user I have to work with my style sheet, I need to collaborate with others, I need to upload the images I want or find them on another server…and this is just the beginning!  If I have to do this through an unfamiliar interface, if I can't run a spell checker, if I don't have a thesaurus or if I can't create a list properly then something that's already hard for me just became really difficult.  Sure blogs, wikis and content management systems make it easier today than ever before, but you still might have to explain to someone why their images are on Flickr, why ==Heading== (MediaWiki markup) is a heading, or why they can only see versions in web pages but not as tracked changes.

This is exactly where I believe WYSIWYG editors like EditLive! come to the fore and our EditLive! for IWWCM integration is one of the best examples of this.  EditLive! for IWWCM is the best of "integration at the glass".  There's a lot that has gone into the integration, though from the user's perspective using it is as simple as using Microsoft Word or Open Office.  From the instant that the user opens an item for editing, EditLive! is customizing their experience to be personalized and, most of all, pain free.  To begin, EditLive!'s interface is customized according to their role within the system and EditLive! fetches the appropriate style sheet from the server and presents it to the user in a drop down with built in styles preview.  If the user needs to insert a link or an image they simply press a button on EditLive!'s interface and can immediately browse the content repository for all available content and images they have permissions to use.  In addition to this there is EditLive!'s spell checking support, that is automatically set to the appropriate language for the user, as well as a thesaurus, comprehensive table and list support and all of EditLive!'s other rich editing support.  Finally there is track changes, working just as it does in Microsoft Word with the addition that EditLive! has already been supplied with the user's name and is logging all their changes so they can easily collaborate with their colleagues and work with the changes in the editor.

As we move into 2007 I hope that all this is a sign of things to come.  This year we want to take EditLive! to places it hasn't been to before.  Not only in new content management systems but in blogs, in wikis and in all sorts of other web content systems and in each place we take EditLive! we're going to aim to create rich, integrated user experiences.

In December we started a new initiative at Ephox called LiveWorks!.  It's something that I'm very excited about because I think it has the potential to offer a tremendous amount of value to Ephox and, more importantly, to you!

As I mentioned in an earlier post Ephox follows an Extreme Programming (XP) methodology for our development which delivers us a great amount of value internally.  Some of the benefits we get include:

• Test driven development has greatly improved product quality and code coverage
• Iterations ensure that we can deliver the most valuable features first
• We are becoming increasingly flexible with respect to changes in the market and how they reflect on the product roadmap.
• We can now release software at any time, at least internally.  

The last couple of points have been of great value internally, but there's more to releasing a software product than just developing the software.  When releasing some of the major things that need to be addressed are sales, marketing and support of a product.  Obviously these are critical aspects of releasing any product, but they do increase the time between code completion and release.  Thus, as clients, to date you may not have seen the results of our internal flexibility for roadmaps and release cycles.

LiveWorks! is about delivering this value to you.  LiveWorks! will give you an insight into what we're working on at the moment and provide useful code, integrations and plugins we've developed previously that we can release more easily on LiveWorks!.  All the integrations and plugins available on LiveWorks! come with source code and are free for you to download and use.

LiveWorks! is about hearing from you.  We've provided a community mailing list as part of LiveWorks! that myself and many of the Ephox developers are on.  If you see a project on LiveWorks! that interests you or you'd like to suggest  an integration please let the LiveWorks! community know.  If you'd like to share an integration or some code that you've found useful we'd also love to hear from you.

LiveWorks! is still evolving.  Over time we will be adding more value to LiveWorks!.  In the near future we hope to be releasing more prototype integrations and plugins.  We're also hoping to provide you with a better view of what we're planning by providing development road maps, early access releases and weekly builds so you can monitor the progress of our products and be ready to take advantage of new features.

When we first started developing the track changes functionality a year ago we only had an inkling of how useful it was going to be.  Afterall, over the years content applications have found ways around this deficit through various differencing and compare and merge engines and there was definitely a question in my mind as to how our track changes functionality would stack up against these.  Since I've been using track changes in an online editor longer than anyone else out there (all of four months) I thought I would relate my experience thus far for those wondering the same thing.

To put track changes to the test, it was deployed to both our internal wiki and the CMS for the Ephox web site.  This ensured that the functionality received some real world testing.  It took some time for people to start using it on the wiki, but with the Ephox web site the benefits were immediate.  From Australia I was able to work in collaboration with our marketing and sales departments in the USA without several long phone calls or screen sharing sessions.  Everyone could immediately see what had been changed and by whom.  Also, most importantly, changes could be seen in context and worked with immediately in the editor.  This saved hours, days if you include the time delay between the USA and Australia!

More recently I've been doing some planning on our wiki for some new product ideas and initiatives for 2007.  As part of this I've been collecting feedback from people throughout Ephox.  Previously, I would have watched our wiki's RSS feed for changes and read through document comparisons, often re-reading the complete document to see the changes and comments in context.  With track changes, this becomes significantly easier.  I can see who made changes, when and see their comments in color coded text.  Yes, we've had this in Word forever…but in a wiki?  In a wiki I've found track changes really shines!

The other "feature" of track changes that has me particularly excited is the ease of install.  I've incorporated track changes into five systems now, a wiki, a blog, our custom CMS, IBM Workplace Web Content Management and Alfresco Enterprise Content Management.  In each case installation was as easy as flicking a switch.  Once I turned on the configuration options for track changes (about 10 mins work) I was up and running, no more changes and no server-side components required.  Congratulations to our engineers!

The work is not finished yet, already I am finding things that need improvement.  For instance, I really want to be able to right click on the marker in the left margin to accept and reject changes.  Also, I really want comments, right now we are just adding these as if they were part of the document but they need to be separate.  As always I would be eager to hear from you what you would like to see with Track Changes and about your experiences with it in general.

Track changes has saved me hours, maybe even days, of my time by now, if you take that figure and multiply that those savings over a company - well to quote Keanu Reeves "WHOA" - that's some saving!  The feature has enabled me to collaborate much better via our wiki and the content management system on our web site.  Download a copy of EditLive! 6.0 to try it for yourself and within your team.  I think you may well get as much benefit out of track changes as you did from when you first deployed EditLive!.

EditLive!'s Track Changes Markup and Tooltip

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.