As promised, a few days ago IBM shipped the OEM edition of EditLive! It’s available to all existing WCM clients on Portal 6.1 or later from passport advantage.

Mostly for my own benefit of having an easier place to find this, it’s version 6.5.3.55 of EditLive! which is a little older than I was expecting, but still quite recent. Enterprise Edition clients (direct from Ephox) have access to the 6.6.2.6 release from early March, which includes a bunch of new features like the inline table toolbars, but my understanding is that IBM will be providing updates fairly regularly which is nice.

Congratulations to all involved in making this happen, both from Ephox and IBM. It’s been an incredibly fast turn around from the signing of the deal to a shipping product.

UPDATE: Actually, it’s more recent than that even. The download is mislabelled as 6.5.3.55 but it actually contains version 6.6.2.6 of EditLive! – the latest official release.

Sam Ruby notes that the White House feed contains a fair bit of debris:

Also noted in the process: the feed itself contains a fair amount of debris.  A sytle attribute?  A meta tag?  o:p is common in content carelessly copy/pasted from Microsoft Word.

Ah the good old o:p crud from Word.  I know a fantastic html editor they could use that would fix that up for them. Clean copy and paste from Word is probably the most popular feature in EditLive!

One of the great challenges of writing an HTML editor is discovering and smoothing over all the weird complexities in HTML. There are just some areas of HTML (and CSS) that are brain-dead stupid and you have to wonder how on earth it ever came to be like that. I suspect most of those brain-dead areas are involved with alignment or tables. This of course means that aligning tables is particularly stupid.

Let’s start with just HTML. There’s an align attribute in HTML which seems nice and straight forward <p align=”right”> will align the the paragraph content to the right. <p align=”center”> will center the paragraph content. Unfortunately this doesn’t hold true for tables.  <table align=”left”> will float the table itself left, allowing the text to wrap around the table. <table align=”right”> will do the same on the right, but <table align=”center”> will just center the table itself, without wrapping text around it.

Now add in CSS – which at least by itself is much more sensible.  <table style=”text-align: center”> has no effect on the table itself, but centers all the contents of the cells. <table style=”float: left”> floats left as does float: right. So far so good, but what if we want to center the table itself? That would be <table style=”margin-left: auto; margin-right: auto;”>  What the?

I’m sure there are good and logical reasons for all these crazy things, but anyone who’s tried to provide an align attribute in a table dialog that’s compliant with both old and new browsers and is intuitive for users has quite significant bald patches because of this.

Pangle on Twitter:

Ephox EditLive Editor will change the world. Well maybe not the world, but it will make WCM content easier to format.

I couldn’t agree more. This is of course in response to the news coming out of Lotusphere that IBM has licensed EditLive! as a standard part of their WCM offering. Ephox has been an IBM business partner for quite a few years now and has built up a lot of relationships with their technical and sales teams as well as selling EditLive! as a third party add-on to a lot of WCM clients. It’s very exciting to see this go up a step and have EditLive! as a standard part of the offering. I don’t have an exact ship date for the OEM version yet, but my understanding is that it will come as an update to Portal 6.1.

So to all the new Ephox clients who are being introduced to EditLive! as part of this agreement – welcome. I really look forward to working with IBM to get you up and running with EditLive! and seeing what it can do to improve you WCM authoring environments and resulting content. I’ve spent the last week putting together a white paper to share the experience we’ve had upgrading WCM deployments to EditLive! and a bunch of best practices for configuring EditLive! to get the most out of it.

To all our existing clients, thanks for all your support so far and  we look forward to continuing to work with you. The OEM agreement includes just the base edition of EditLive! so we’ll continue to ship the Enterprise Edition as an add-on, with some big improvements planned for both it and the base edition.  This isn’t an official source of Ephox news and I want to avoid getting any details wrong so I’ll refrain from giving details, but rest assured that everyone at Ephox is committed to making sure that we keep making all our clients happy – especially those who have supported us in the past.  If you have questions, we’ve got a page giving some information on the OEM agreement and please do contact us if you have any further questions or concerns. The white paper is probably useful for you as well.

To everyone within Ephox, congratulations on making such a fantastic editor, from engineering and product management making sure the product is great, to sales and marketing getting the word out and making enough sales to keep us in business and the admin team for letting everyone else focus on their jobs.

Now let’s get back to work and keep changing the world.

While reviewing some screen mockups for EditLive! today, it occurred to me just how limited an environment we’re forced to work in. It turns out that the default, and thus most common, size of a rich text area in IBM WCM is 740×450 (note to Ephoxians, I mistakenly quoted this as 740×360 earlier so we have slightly more vertical space than I thought).  Even in my blog’s editing interface, the editor is 718×600.

That doesn’t sound too bad until you realize that the iPhone has a screen that’s 480×320.

Now an extra couple of hundred pixels width makes a huge difference, but when you look at how much time people spend trying to strip out functions and minimize UI in iPhone apps, it’s scary to think that we aim to pack the functionality of Microsoft Word into that kind of space.

I think the only reason we manage it is by providing real drop down menus, whereas most in-browser editors just try to cram everything on to the toolbar. At least I know why UI design for EditLive! is such a challenge…