When I first switched to OSX I went looking for desktop blog editors. Much like Suneth just found out, the only two I considered worth using are Ecto and MarsEdit. Unfortunately, MarsEdit doesn’t have a rich text editor; it has notepad with some macros and a rich text preview.

Each to their own, but this mindset of “rich text HTML editors suck” seems to be common among people who love MarsEdit and is no doubt the reason why they all buy it. Having worked on rich text HTML editors for nearly 7 years now, I have but one thing to say.

If you hate rich text HTML editing, you haven’t used a good editor.

 

I think this review from Shawn Blanc pretty much sums up what I’m talking about:

MarsEdit’s long-time competition, ecto, offers both a HTML editor and a WYSIWYG editor. Unfortunately, when writing in ecto, you cannot switch between the two editor windows without shooting you markup in the foot. If you begin in ecto’s HTML editor and switch to the WYSIWYG, ecto turns all your hand-coded CSS-friendly tags into HTML spans, which is, to say the least, highly annoying and extremely counter-productive.

Clearly, having that happen to you would suck. I can’t do much with styles using the fairly basic wordpress.com setup but I have been annoyed at times by Ecto messing up my HTML (long time readers will remember I picked it as the best of what was available at the time).

At Ephox however, we do our best to make sure EditLive! keeps tags in the format they were loaded (after a few whitespace adjustments to make it more readable in code view). If you give us font tags, we leave them intact despite the fact that they were deprecated in HTML 4. If you give us a tag we don’t recognise, we just display a little marker to let you edit it and continue on. The only time we force span tags is when we create them to apply formatting.

And that’s just one example. We have full control over the entire HTML filtering and rendering process with substantial extensions to the basic Java capabilities. We’ve had to bend over backwards to support strange markup over the years but usually we can do it.

I’m really proud of our editing experience too, we sneak in little usability improvements whenever we find them or they’re requested via support. I’m such a big fan of the editor that a few months back, sick of using text editors to work on HTML documents in support, I spent a couple of Creative Coding Afternoons to write a very basic desktop wrapper around EditLive! and add it to the windows right click menu for HTML files. And I’m not the only one.

We dogfood EditLive! all over the place. It’s the only option when editing our wiki, which is used a lot, and ensures that we always remember to provide a good editing experience across many levels of user technical skill. Most of our blogs (including LiveWorks) use EditLive! to the produce content. Most people in the company use the editor regularly, some of them every day.

 

It’s not all good news though. I could tell you to try our demo, but there are some annoying restrictions for mac users (we can’t use command-shortcuts because Safari eats them, so you’re stuck with windows style eg CTRL-B). The editor is also less than perfect for blog editing due to difficulties with DIV tags, we’re fixing that in 6.4 but there aren’t any demo pages featuring it yet.

And to top it all off, we’re beginning to shift away from small end-user sales with what is now an industry-wide enterprise focus. So unless someone wants to do what Suneth did and use our Swing SDK to write a desktop blog editor, there’s very little chance you’ll ever see EditLive! in one.

 

Still, my point stands. Try a real HTML editor before writing them all off as useless. Although if you try it and think something is wrong, please don’t be afraid to tell us 🙂

Advertisements