The first thing to realize is that user generated content doesn't need to plain and boring. While consistency is important, giving people more flexibility in formatting than you might in a content management system can result in big improvements to the readability of content.  For example, using the highlight color or table row background color functions in EditLive! is a quick and easy way to indicate that tasks in an ad-hoc task list are in progress, blocked or completed.

Going a step further and providing some good looking CSS styles for lists, tables and sections can help user's quickly make content that looks great.  For example, a section style for related links not only looks good, it helps drive consistency across the site.

Secondly, track changes can add a whole new dimension to collaboration, making it simple for people to suggest changes and review them. Think of it like an electronic highlighter that provides extra detail. By enabling track changes and actually editing the text directly, rather than just leaving a comment, the page becomes a living reflection of the decision rather than a big log discussion. When you revisit the decision in 6 months time and want a summary of the reasons behind it, you'll appreciate not having to wade through all those comments. Besides, what's the point of moving to a wiki if you just treat it like email?

Thirdly, providing pre-canned templates that users can insert via custom menu or toolbar items makes life much easier for authors to get started.  A good example is a template for draft procedures to lay out the important information like title and purpose.

Fourthly, take advantage of the new image editor in EditLive! It automatically resamples images when the user resizes them to avoid having to transfer huge images across the network. It also provides crop, rotate and flip operations to whip the image into shape and reflection and drop shadow functions to add some pizzazz.

Finally, highlight the window view of EditLive! which pops the editor out into it's own window to give the author more space to view their work. Most users don't expect this feature to exist and won't find it on it's own but once it's pointed out, dramatically improves usability and productivity.

So what exactly does PostDocument do? Just what you might expect - it posts the current editor contents to a specified URL and gives you the content the server returns. As a simple example, we'll create a custom menu item that translates the current page from English to German using Yahoo!'s babelfish service.

First we need to create the custom menu item to send the document to Yahoo! for translation:

<customMenuItem name="translate" action="PostDocument"
value="trtext##ephox##http://uk.babelfish.yahoo.com/translate_txt?lp=en_de##ephox##callback##ephox##handleTranslation"
text="Translate Into German" />

This is one of the more complex custom items we could define because the PostDocument function has a number of arguments. Here's a break down of the value element - each parameter is separated by the string "##ephox##":

Now that we've got the menu item, we just need to implement the handleTranslation JavaScript method to receive the results. Here's an example implementation that would display the translated text in a DIV on the edit page with the ID "translation":

function handleTranslation(result) {
    document.getElementById("translation").innerHTML = result;
}

This function is fairly naive since Yahoo! is actually returning a complete HTML page. It would be better to parse the HTML and only display the actual translation instead of the entire page. Other translation services may return the result in a simpler format like JSON or XML.

The PostDocument function is also available as a JavaScript method, or you can simply use the GetDocument function and submit it using the XMLHttpRequest object. Whichever way works best for you, integrating web services with the editor can be a powerful way to extend the functionality and make your authors more productive.

This article assumes you're already familiar with the version control tool you want to use and in the examples we'll use subversion. Take a look at the subversion website to learn more about it and find out how to get started.

When you first download EditLive! for IBM WCM, immediately import it into your repository without making any changes. This provides a base line so we can easily identify the changes that we make. Make sure you note the revision number as we'll need it later. You might want to create a branch or tag at this point so you can more easily refer to this revision. Then make any changes to the configuration that you need and commit your changes. At any time you can see the difference between your installer and the original Ephox supplied one by comparing the current revision with your original commit:

svn diff -r <original revision number>

When you need to upgrade EditLive! you simply unzip the new EditLive! distribution over the top of your custom installer and use the revert function to restore your changes in the modified files with the subversion revert command.

Alternatively, you could use subversion's merging capabilities to reapply the changes you made. You can do this with the svn merge command. For example:

svn merge -r <original revision number>:BASE .

Using version control is a widely recognized best practice, but it can be very confusing when you first start using it. If you're not already using a version control system for your project, this approach may not be a good fit for you. If however you're already using a version control system, storing the EditLive! for IBM WCM installer along with your other project files is an excellent way to manage changes, upgrades and keep things all in one place.

Thanks to Chris Melikian who suggested this approach.

Obviously, this isn't supported by Oracle so be careful and practice on an unimportant installation first.

It's also good to hear the upgrade has gone well and that the users are happy. Hopefully we can get the latest 6.5 upgrade into Oracle soon so they can take advantage of even more features and benefit from faster startup times.

Session Keep-Alive

To keep the session alive, we need to make sure that requests are sent back to the server at regular intervals while the user is editing. The requests could be a simple "ping" that does nothing, or it could be used to implement auto-save. We've found the best way to do this is to make the auto-save a draft, rather than automatically publishing it so that users are still in control of when changes go live. This is reasonably straight forward to implement with JavaScript timers and using XmlHttpRequest to send the request to the server.  If you're implementing autosave, you simply retrieve the document content from EditLive! with either GetDocument or GetBody and include it in the request.

The problem of course is that if the user leaves the edit page option and walks away from their browser, the AJAX requests will keep sending and the session will stay alive, even though for security we'd actually like it to time out. To solve this we need to find a way to check that the user is really still using the editor. John Vanatwerp suggested the simple but very effective solution of using a JavaScript alert dialog:

We have the alert box, which stops JS execution, appear about 10 minutes before the session expires. If the user hits OK on the alert box, the AJAXy code does a roundtrip to the server which refreshes the session timer. If they don't hit OK, the session times out as planned.

A little more complex method would be to check the IsDirty flag to see if the user has made any changes, or listen for events being fired through our advanced APIs.

Session Recovery

An alternative approach is to simply let the session expire but make it possible to login again without losing the content. One way of doing this is to allow the user to login using standard HTTP authentication, where the browser displays a dialog asking for login information, instead of using a HTML form to login. The browser will automatically resend the POST data after it logs in so the content won't be lost. You can use a HTML form for login normally and only use HTTP authentication when you're handling POST requests to have the best of both worlds.

If you stick with using a form to login all the time, you could simply include the original POST data in hidden fields so that it isn't lost and once the user logs in correctly you can save the content for them. Most login systems already do something like this to remember the original URL the user was trying to access.

Summary

Depending on your backend systems, there are a range of ways you can remove the frustration of session timeouts and let users take as long as they need to edit content. If none of the options above work for you, you could always make your sessions last longer which will at least make the problem less frequent.

Thanks to Steven Drinkwater for raising this and for all those who contributed to the discussion.