Since the very early days of my blogging, I’ve integrated a copy of EditLive! to make the editing pleasant and more powerful. For many, many years there was simply no way I could bring myself to use anything else. Lately though, Apple have been making Java applets less and less appealing while browsers have been continuously improving their content editable suport and JavaScript editors have gotten better at working around the remaining quirks and smoothing off the rough edges on the editing experience.  The final straw for me though was that the current early access release of EditLive! 8.0, which appears to include a lot of fixes for the latest OS X, breaks backwards compatibility with a number of APIs I use to integrate it into this blog.

Joyously, it looks like iOS 5 fixes the issues with contentEditable not working correctly in Mobile WebKit. A patch has landed in TinyMCE to enable the editor to work there. Great news.

Hopefully the changes to WebKit can flow through to Android as well.

Over the weekend I went to JSConf EU and every time I met someone and told them I was working on TinyMCE the conversation rapidly veered off into why contentEditable is too hard/buggy to work with and how it would be so much better if it was all built on top of canvas or just used the DOM with a custom selection API. This matched the thinking throughout the conference that it doesn’t really matter how messed up browsers are because JavaScript can be used to work around it.

Windows uses a particularly ugly format for putting HTML on the clipboard, called CF_HTML. Basically, it adds a header to the content with pretty useless information essentially declaring how many bytes in the header (and yes you have to pad the byte counts since they themselves are included in the count).

The problem between Java and Firefox is that Java always sets the ‘StartHTML’ and ‘EndHTML’ fields to -1 to indicate there is no context and Firefox will refuse to paste HTML from the clipboard if StartHTML or EndHTML is set to -1. As such, if you copy HTML from Java it will be impossible to paste into Firefox. It works perfectly with Word and IE.

The issue of P tags vs BR tags comes up very often and since my response to it has become a series of 5 articles, this post is here to provide a convenient index to point to in future.

General Primer

• Why P Tags are Your Friends
• P Tags in Word

Solutions for Specific Situations

• P Tags and Single Line Fields
• P tags and Flash
• The Email and P Myth

What Is contentEditable?

JavaScript editors are all fundamentally based on a technology called contentEditable which makes a part of the web page become editable by the user. While there is a lot of functionality that’s usually bundled under the “contentEditable” title, there are a few core parts which are essential for a browser to support correctly1{#footlink1:1278939007857.footnote}:

• Selection – allowing the user to position a text caret in the content and select various parts of it.
• Content entry and deletion – allowing the user to type basic text and to delete selected content.

Without these two key components of contentEditable it’s impossible to create a high-quality, WYSIWYG editor with JavaScript. Despite some variations in how things work, this functionality is available on all common desktop browsers and has been for quite a few years.

One of the most difficult situations to work with is when your output needs to be rendered using Flash. The HTML support in Flash is absolutely horrendous – worse even than in most email clients. Contrary to popular belief, Flash does support P tags. You will however need to ensure the text field is set to multiline. The BR tag is also only supported in multiline fields. The problem most people hit is that Flash doesn’t support the margin-top and margin-bottom attributes so you can’t get rid of the blank line between paragraphs.

One of the common reasons people want to avoid P tags in content is because the field is designed to hold just a single paragraph, so having multiple P tags inside the content would break the template layout when it’s rendered. Usually the template renders the content as something like:

<p><%= fieldContent %></p>

In that case, where the output is the only thing within the paragraph, the best solution is to leave the paragraph tags in editor content and remove them from the rendering template. That gives the editor the context it needs to work well and avoids a lot of potential problems with rendering the content. If however, you’re including some extra content in the same paragraph then the situation is more difficult, e.g. your rendering template is more like:

One thing that many people don’t realise, is that the distinction between paragraphs and line breaks isn’t unique to HTML. In fact, it’s a distinction that people have been working with quite happily for a very long time – Microsoft Word has supported the two concepts right from it’s very first version. With the more recent versions of Word, the default paragraph spacing is zero, so line breaks and paragraphs look the same, even though there is an important semantic difference. You can still see the difference if you show the non-printing characters:

A few days ago I talked about the Email and P Myth, but didn’t explain why it’s so frustrating for editor developers that people keep wanting to use BR tags instead of P tags. It’s not actually because we’re fastidious about using the correct semantic HTML, though obviously we do recommend that, it’s because a lot of concepts that user’s expect simply aren’t possible to implement sensibly if you don’t use the correct paragraph level elements.

One of the greatest frustrations for anyone who develops an HTML editor is the constant supply of people who are convinced they want to use BR tags instead of P tags. Most of these are just people who don’t want “double spacing” and they’re happy once you give them the magical CSS incantation:

p {
  margin-top: 0;
  margin-bottom: 0;
}

The other group however are people writing HTML emails who insist that P tags are completely incompatible with some email clients and cause rendering problems. At one point it seems that Yahoo! Mail really did strip them entirely but now it just applies a different default CSS styling (ironically, the magical CSS above that removes the extra spacing). So if you naively use P without specifying the padding you want, some clients will display a blank line between paragraphs, others, notably Yahoo!, will push all the lines immediately under each other. The solution is of course the opposite magical CSS incantation:

The new Ephox Enterprise TinyMCE site has now gone live, a result of our new partnership with Moxiecode, the company behind everyone’s favorite open source editor TinyMCE. I’m really excited about the potential of this partnership and have really enjoyed the opportunity to work with the Moxiecode team so far.

What We’re Adding…

We think we can bring a lot to the TinyMCE community, the things below are just where we’re starting.

Ephox EditLive! is now part of the IBM cloud offering on Amazon Web Services. EditLive! OEM edition is bundled in the cloud offering of IBM WCM. This means you can now quickly run up a new instance of IBM’s WCM system on Amazon EC2 and configure it to use EditLive! as the editor.

If you want to take advantage of the extra benefits of the Enterprise Edition (track changes, commenting, accessibility checking, image editing and more), you can install that as normal once the system is running. Currently Ephox doesn’t have per-hour pricing through Amazon but you can contact our sales team so they can discuss the options available.

From the job description:

We are seeking a Software Developer who is experienced in creating sophisticated, highly interactive, JavaScript applications. Ideally we desire someone that has experience in TinyMCE or has experience working as part of an open source project. The right person will have the ability to work remotely in a highly collaborative manner with virtual teams. I’m pretty excited about this new opening within Ephox. Lots of great stuff to come out of it hopefully, but in particular helping Ephox to start working better with Open Source communities and developing some awesome stuff with JavaScript. While TinyMCE experience is something we’re particularly keen to have “ready to go” if possible, whoever fills this role is going to become a web content editor expert in general from Tiny to CK, Dojo and of course our personal favourite EditLive!

Andrew Shebanow in Open Government and PDF:

The issue at hand is not whether governments should pick HTML or PDF. The issue at hand is whether governments are capable of publishing information at all. Show me an HTML creation tool that creates high quality, standards conformant markup from a Word document or any of the zillions of editing tools that government employees use. Now add in all the tools used by people who submit documents to the government. And all the versions of those tools released in the last 20 years. Now make sure that the HTML/XML works correctly even when the user doesn’t have the right browser or the right fonts installed. I’ve actually worked with a number of government departments who were looking to move more content online and the content conversion problem is definitely a time consuming and challenging part of the problem. That’s precisely why I wind up getting involved, since EditLive! lets you easily copy and paste content from Word documents and produce clean, compliant XHTML. It can even (optionally) strip out inline formatting and leave just the structure like headings, tables and lists.

I swear, some days you just want to reach into the screen and strangle the blogger on the other end. Jeff Atwood complains that his users commonly fail to read all the helpful hints on how to use their overly complicated, what you see isn’t what you get editor on Stack Overflow:

The ask question page is already dangerously close to cluttered with helpful tips, but apparently these helpful buttons, links, and text are all but invisible to a large segment of the user population. Sure, you could argue that Super User tends to attract less sophisticated users, but I see the exact same problem with programmers on Stack Overflow. As new users, a significant percentage of them can’t figure out how to format code, even though there’s not only a toolbar button that does it for you, but help text on the right explicitly describing how to do it manually. (Just indent 4 spaces. Spoiler alert!) So essentially, users don’t find the editor intuitive and the solution they’ve gone with up until now is to add more and more help text to try and teach the user how to use the unintuitive editor. It’s not working. The obvious solution is to escalate the arms race:

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.

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.

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.

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.

The Ephox bloggers have been way too quiet lately (myself included) so I thought I’d start an Ephox meme. What’s your 5 favorite features of any of Ephox’s products?  They might be built in or plugins that we’ve developed, maybe even features of our internal systems that make your life easier, but preferably something that our clients could get hold of (teasing people just isn’t nice).

Here’s my list:

1. Built-in Image Editor. Particularly being able to resize an image and add rounded corners and drop shadow.
2. Pop out window mode. More editing space is always good.
3. Automatically detecting URLs on the clipboard and using them as the default value in the hyperlink dialog.
4. Styles menu. Not that I use it on this blog, but having access to classes in the site style sheet make it so easy  to apply some really nice formatting with just a couple of clicks.  The styles package prototype we use internally a lot is particularly useful for this.
5. The extensible APIs. It’s so nice to be able to quickly add support for footnotes, a shiny button generator or whatever I happen to want this week. I wish more clients used this functionality to make life easier for their users – even if it was just by providing a handful of simple templates they could insert.

I tag Suneth, Damien and Brett…

I was going to write a post around accessibility and WCAG 2.0 but got annoyed once again about the EditLive! toolbar taking up two lines instead of one.  I’d already removed a whole bunch of stuff from it but it was still wrapping around by a few buttons.

It occurred to me that there are a range of functions that I had on the toolbar because I use them frequently, but that aren’t actually required because I always use the keyboard shortcut. In particular, I have no need for cut, copy, paste, undo or redo because without exception I use keyboard shortcuts. I could probably apply the same logic to strong, em and insert hyperlink as well but my toolbar fits on one line with them so they may as well stay.

Working in the world of editors there are a range of blog posts that float back up to the surface every so often, generally because they discuss an age old concern that just keeps resurfacing.  Recently a post from Moxiecode resurfaced complaining about the lack of focus on editing support in browsers. There’s been a few such posts in the past that I’ve seen and while the world of contenteditable support has definitely improved lately, it’s still one of the weakest areas of modern browsers.

From CMSWire:

Optaros has announced the launch of a new user interface framework for Alfresco. DoCASU 1.0 is an open source initiative, bringing AJAX and Rich Internet Application features to the Alfresco Enterprise CMS platform UI. Docasu “is not intended to replace the already existing Alfresco web user interface,” but rather is aimed at those who require a simpler and more user-friendly, yet highly configurable interface solution. Sounds like a sensationally good idea to me. It’s surprisingly difficult to get a team together that has the back-end skills required in terms of scalability, content management etc and the front end skills to create an intuitive UI for users. Or in graph form and Ephox specific:

Someone came up with a cool idea to add a universal edit button to make editing wikis easier. It adds a button like for RSS feeds that redirects the browser to the edit page. It’s clever but it aims way too low. If you can get browsers to add an editing button you have an opportunity to either point to an online form or a standalone application that could also edit the page. In other words, Atom Publishing Protocol auto-detection.

David Welton described a frustration he had with FireFox’s spell checker which piqued my interest:

I write most of my email (in gmail) and submit most web site content in English, however, a significant portion is also done in Italian. I leave the spell checker in English, because Italian is, in general, quite easy to spell, so that even as a native speaker, a helping hand is occasionally welcome. However, it isn’t as if I write Italian perfectly either, so the help there would be nice as well. I find it quite annoying to go change the language in the spell checker option each time, especially when, as an example, I’m responding to email and do 2 in English, one in Italian, another in English, and so on. On the face of it, identifying what language an author is using looks a lot like a natural language processing problem and thus requires a PhD and many years of research to tackle. Looking a little closer though, you begin to realize that the problem domain is dramatically reduced in this case:

Kevin Gamble pointed me towards the Sun Wiki Publisher for publishing documents to MediaWiki servers straight from OpenOffice/StarOffice. The key problem with these types of integrations is that wiki markup simply can’t handle anywhere near the same level of expressiveness as even HTML, let alone a word processor document. Hence the description mentions:

All important text attributes such as headings, hyperlinks, lists and simple tables are supported. Even images are supported as long as they have already been uploaded to the wiki site. An automatic upload of images is currently not supported.

Jeff Atwood chimes in on the age old question of HTML vs Markdown/Textile/Custom Markup/etc. Unfortunately he rules out using a WYSIWYG editor with the one line statement:

Nothing’s decided at this point, but we definitely won’t be giving users one of those friendly-but-irritating HTML GUI browser layout controls. Well sure, you wouldn’t give them a friendly-but-irritating HTML GUI browser control, but why not give them a good one? These days it takes a fair bit of effort to find a HTML editor that doesn’t handle the very basics fairly well and Jeff doesn’t seem to be looking at anything more complex than bold, italic and some hyperlinks. I think a lot of people get stuck in a real geek ego thing or remember the really early days of HTML editors and don’t actually evaluate modern editors properly and it’s a real shame.

CMSWire: Vendor Criticism of CMS Watch

In an industry whereby most of the “independent analysts” are heavily dependent on revenues from the very firms they claim to be “independent” of, it’s unusual to see truly critical research get published. So it becomes a surprise to both buyers and sellers when they read such criticism. In our reports we widely distribute the compliments and brickbats — if something is truly terrible we will tell you.

Technology is a funny thing – we spend so much time and effort trying to make things as simple and efficient as possible for our users that we sometimes lose track of the big picture and wind up making things worse. This is particularly a problem when developing components for other’s to intgrate, rather than a product that ships directly to end users. When another developer is between you and the end user a few fairly unique dynamics come into play:

 My open tabs in NetNewsWire have exploded in the last couple of days with really good articles about driving wiki adoption and generally making wiki’s work. First up Making Wikis Work is a pretty good overview of all that is wrong with wikis. It’s odd to think that a technology as young as wikis has legacy cruft but they do.

In particular, WikiWords are no longer required or a good idea, use an editor that makes creating links easy or use a simple shortcut for creating links (the square bracket notation was easy for most people to learn, but you need to provide a completely GUI alternative as well).

There’s a constant argument over whether data should be structured or unstructured in content management and knowledge management systems. The key advantage of structured data is that it’s easier to process and manage – the system can manipulate and report on the data far more accurately. The downside is that it’s more difficult and frustrating for users to be limited to the specified structure so less data tends to get captured and it can be more difficult to get adoption.

Apparently Sun has finally decided to give some love to the Swing text APIs with the addition of a removeElement method. What the linked article fails to mention is that in the particular example given, you can remove the list item with a simple document.remove(e.getStartOffset(), e.getEndOffset() - e.getStartOffset());

When you get into trouble with the swing text apis is when there are two elements that start and end at the same point – ie: a list as the only child of a table cell:

Olly Hodgson has a great article up pointing out how important it is to think about the usability of your CMS, not just the websites it creates. I’m even more impressed that he realized the editor is the key point of usability in the CMS and gave advice to go about configuring it properly.

Most people think a CMS lives or dies by it’s repository design, it’s content reuse potential or some other fancy backend feature. The reality though is that content management systems are really all about creating and editing content and that’s done with the editor. Most of the user’s time is spent using the editor and so their perception of the whole system is very much dependant on how good the editor is.

I’ve been in our San Mateo office the past week working with the sales and marketing folk which has been great, but also challenging and often frustrating. The challenge is in getting a grip on my new job as product manager, the frustrating from the initial objections we often get from clients as they try and guess what the reaction will be from their users instead of actually finding out. It’s fair enough, that’s all they have to go on but it’s frustrating to have to try and share the experiences that we’ve seen with users giving our software rave reviews. It’s also frustrating to hear negative things about software you’ve written – I always get so attached.

While most of the Ephox folk use EditLive! to edit their blog entries, there are some poor saps who are using a blog hosting service and can’t (we’ve got some interns working on a standalone blog editor with EditLive!, but that’ll take a while yet). This morning Antony learnt the value of a great editor the hard way when he copied and pasted from Microsoft Word into Typepad’s default editor:

Now I understand why so many of our users think our Microsoft Word filtering is so good…

I’ve spent most of this week working on making the start up experience for our applet better. It should look better, take longer and most importantly feel fast to the user. The first step is obviously to profile and optimize – the faster the start up time actually is, the easier it is to make it feel fast for users. There were a few things we could do to help out there, but nothing that really made a dramatic difference.

There is an awful lot of money spent on user interface research, carefully tracking what users do with an application and trying to find ways to improve based on that. It’s a shame that so much of it is wasted because the captured data is misinterpreted.

The Office 2007 Ribbon is a classic example of this, it was clear that Microsoft had real world data to back up their decisions about the Ribbon, they’d spent millions on it. Yet somehow it just didn’t seem right to me. Turns out at least Damien agrees with me. It turns out that despite the fact that usage data shows that users work in different modes, designing an interface that reflects those modes isn’t ideal.

For a couple of years now, Ephox has been very successfully using a wiki to provide communication within the company and helping to bridge the gap between our two offices on opposite sides of the pacific. Central to the success of the wiki has been the successful integration and configuration of EditLive! as the editor. It certainly helped that we have a high quality editor with lots of attention to detail but the most important aspect was the amount of attention we paid to correctly configuring the editor.

You’ve got to hand it to the Atlassian team – they are seriously clever. Wikipatterns.com launched recently to give people a place to go for advice on improving wiki adoption. The content is very useful to have in one place even if what’s there right now won’t be new to most people using wikis. It is undoubtedly useful and Lars Trieloff from the Mindquarry team has already linked to it (Mindquarry develop a soon to be opensource wiki that’s integrated with a bunch of other cool looking stuff). I’m sure other wiki vendors will be linking to it over time as well.

There were a few interesting comments on my last post. Firstly from Hen:

People are attached to their editors and not their markup. If Maven had moved from xdocs to apt-gui for their site creation, I doubt there would have been many takers. It’s true, people are very attached to their editors, but you don’t have to force them to change, it’s also not a reason to write customized mark up languages. In Maven’s case, the documentation winds up being published as HTML so that’s really the best format to use, people can use whatever editor they want to edit the HTML and it allows people to choose to use a WYSIWYG editor because they exist. This is similar to what Tim O’Brien said:

Tim O’Brien said:

I’ve been writing some APT of late, and it’s painful. Actually, on second thought almost everything that involves working with any sort of markup (no matter how lightweight) is incompatible with writing. It is difficult enough to proofread, nevermind having to constantly switch between the Wiki-esque markup of APT and then having to sit through a site generation. It’s amazing how often developers fall into the trap of changing technical details like file formats instead of actually doing the hard work to provide a simple intuitive interface. The problem is, users don’t want simpler they want simple. No matter how much you simplify a markup language, it’s still something the user has to learn and then constantly think about instead of being able to focus on what they actually want to do.

I’ve said it before, and I’ll say it again – the best syntax you can use for your wiki is HTML, or probably better XHTML. It’s a defined standard with a wide range of excellent WYSIWYG editors, it’s well known, very portable and saves you from having to write a converter to display your wiki pages.

David Van Couvering is the latest to complain about incompatible wiki syntax and he’s certainly not alone in his frustrations. People don’t want to have to learn yet another crazy wiki syntax, they want an intuitive interface that just lets them write their content. HTML provides far more flexibility than any wiki syntax, particularly around tables, which makes presenting data a lot easier.

From the Creating Passionate Users blog:

Do you know what the “comma-stupid” phrase is for your product or service? In other words, do you know what is most meaningful for your users? Because whatever that word or phrase is (i.e. the part that comes before the “, stupid!”), it should be driving everything from product development to documentation to support and marketing.

More and more I’m seeing people value the editor in a system over anything else. When Rob joined Ephox he switched to WordPress because among other things:

Robert Scoble:

I’d love to know what you think? Does any of the Office 2.0 vendors have a chance to edge in on Microsoft’s market?

Edge in – sure, it’s been happening for at least the past 5 years or more. I’ve lost count of the number of times we’ve sold EditLive! to companies who were replacing Word to make life more pleasant for users. Notably though, these aren’t situations in Word’s core target market – creating documents destined for print. Word has picked up a lot of market share in all kinds of weird and wonderful content creation scenarios that it wasn’t designed for and it’s picked up features to make it work quite well there. Despite that, these fringe areas are ripe for competitors to specialize in and provide solutions that fit better with the user’s intentions.