The celebrations didn’t quite go as planned

After a busy day of merging and releasing, the release build of 6.4 popped out of our build machine around mid afternoon. I went to break out the beer only to discover that the fridge had died at some point during the day and the beer was all warm

 

If you hate rich text editors, you’re doing it wrong

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

 

Ace Attorney 4 coming soon! and other mindless ramblings

Having posted about my love of the Phoenix Wright series back in September last year, I was surprised when a few days ago I discovered that the english release of the fourth iteration (Ace Attorney: Apollo Justice) was due out in a few weeks and I hadn’t noticed.  I think the marketing for the game is only just starting to ramp up, with pointed release date announcements and a new dev blog.

I also had a nice surprise when ordering it from dvdboxoffice - my source for importing games that will take months to come out here, if they ever do - I had a birthday coupon code from last year that I’d forgotten about and gave me $2.50 off the order

 

Speaking of games that aren’t scheduled for release in Australia though (did I mention I love that DS games aren’t region locked?), the other game I’ve been keeping an eye on is Professor Layton and the Curious Village.  In the last couple of weeks Wired has had coverage of both the official trailer and this cool magazine ad showing off the quality of puzzles featured in the game.  It is due out in just over a week so I ordered that to tide me over until Apollo Justice (free shipping ftw!)

 

On a final note that could be a new entry but isn’t really worth it, this blog has been quiet because I’ve been hard at work on the next release of EditLive! and haven’t had much to talk about.  That isn’t likely to change for at least another week or two

 

Choice quote

So Suneth seems to be enjoying his visit to our US office, and it works both ways. He’s been teaching them how to handle the simple support cases and giving me less work to do! (which incidentally makes training Dylan quite a bit easier).

What caught my eye though was this quote at the end:

Working for Ephox pretty much summarizes my definition of a perfect job.

I’ve felt that way ever since… oh, around the time they started paying me for this stuff

It’s nice to know I’m not the only one, and I think this is one of the reasons our team works so well together - we all enjoy the job so much that we want to turn up in the morning

 

Welcoming another Ephox Engineer

Tomorrow  is a day I’ve been looking forward to for quite a few years.  Dylan Just, one of my best mates from uni, is starting at Ephox.  He’s not yet on Planet Ephox but I think we’re fixing that tomorrow morning

I’ve known Dylan since our first year at uni, he was living on the same residential college as me (and AJ, and 2 or 3 other people who have worked at Ephox ).  We worked really well together over the four years of our Software Engineering degree, but I took 5 years to finish after landing my job at Ephox and dropping back to 50% course load for the final two years.

That, among other things, meant that Dylan ran off and found himself a decent job when I wasn’t looking.  And basically ever since, I’ve been trying to convince him to give that up and come work with me at Ephox.  I was very happy when he finally caved and came in for an interview

It’s only a three month contract, but if he fits the team as well as I think he will I have high hopes that he’ll be offered a job at the end.  I’m probably jumping the gun a bit there but I can’t help it!  It’s going to be so much fun!

 

Progress updates make your application faster, even if it takes longer

I was highly amused by something that came through my link blog subscriptions today - Vista RTM vs SP1 file copy performance.  Although his results may be a little off due to the use of Virtual PC, I want to point out the observation he made: Vista file copy performance isn’t really that bad but it feels slow because someone decided that users only need progress updates every 10-15 seconds.  I already knew this fact from tracking my network usage in task manager but it highlights a very interesting point.

Adding per-second progress updates to SP1 may have affected the speed of file copying tasks, but even if it was a lot slower than RTM everyone will rave about how much faster it is.  This is an interesting phenomenon that I can remember we encountered early in the lifecycle of EditLive! (back before I started working on it).

At the time we didn’t have a loading progress indicator, we pretty much showed just a blank box until everything was ready.  Adding a progress bar that updated properly increased our startup time by a few seconds so there were arguments about the benefits of including it.  Eventually the progress bar advocates won, and immediately our customers gave feedback about how much better our startup was - even though we knew it was slower.

It turns out that people are always more patient with a progress bar updating constantly than some indeterminate screen where they don’t know if it will finish in 5 seconds or 5 hours.  Even if it takes longer to complete, it will feel faster and they are assured that the application hasn’t crashed.

 

EditLive! for Java, now featuring… a JavaScript editor!

For many years JavaScript editors have been a thorn in our side.  Browser vendors are constantly improving the rich text editing capability as used by all of the free editors.  We know our editor is better, and so do our clients; most of the time it’s easy to show just how much better we are during the sales process.  Last week we completed development on a new feature that we believe takes this a step further.  We’re so confident that our editor is better, we’re willing to distribute a JavaScript editor to prove it.

We don’t advertise this on the website anywhere, but I’m going to come right out and say it; we picked FCKEditor.  It’s one of the most lightweight editors around while still providing a solid experience, and it starts up a crapload faster than other JavaScript editors through use of an image array for the toolbar icons.  Most importantly though the FCKEditor source code is high quality, easy to understand and we felt it would be the easiest to maintain out of the editors we evaluated.

I’m really proud of how well this integration turned out.  Particularly the UI; if you compare the default FCKEditor interface to the default EditLive! interface you wouldn’t think it was possible to wrangle the JavaScript editor to look anything like our Java applet.  Using some creative JavaScript and CSS we not only made it look almost identical, we did it without modifying any of the core FCKEditor files.  We even created tabs to change between design and code view, something that took me a few days to get right and the result looks just like the real thing:

(click for a better look, my theme isn’t wide enough to fit the image at full size)

This integration was produced for what boils down to two basic reasons.  Some potential clients don’t want to require Java on all user machines and others are paranoid that users will freak out when the Java logo appears (I disagree, but some people really hate Java!).  Personally, I see this as a cool way to prove to the world that JavaScript editors cannot, and often will not, beat our consistent cross platform editing experience.

As an example, load up the FCKEditor demo and try this:

• Delete all the default content and type a few words
• Highlight the last word on the line and insert a hyperlink
• Click at the end of that word, hit enter and continue typing

The result will depend which browser you use - in FireFox, you wind up with the hyperlink continuing on the second line whereas Internet Explorer is a bit smarter and ends the hyperlink before starting a new paragraph.

Another example:

• double click on a word in the middle of a line
• insert a hyperlink

In FireFox, the selection model highlights the space after the word when you do this and your new hyperlink includes the space - you get this ugly line extending out from the end of your word.  IE also highlights the space after the word but is smart enough to not include the space in the new hyperlink.

Neither of these cases are an issue in EditLive!, and fixing such “minor” problems is often more effort than it’s worth in a JavaScript editor that relies on the browser to do all the heavy lifting.  I can personally vouch for this; I worked with the IE HTML editing component in EditLive! for Windows for so many years and there were numerous frustrating bugs that I just couldn’t do anything about.

The EditLive! UI is consistent and sensible on all supported platforms, and our support team is capable of fixing even minor UI bugs.  This is the advantage Java gives us; we control the entire editing component and can even fix JRE bugs by extending the Sun classes.

For basic commands you can get away with a JavaScript editor, but once you start creating complicated HTML the little things start to bite you.  It’s classic death by a thousand paper cuts; there are many more examples than the two I provided above and nobody I know at Ephox can stand using a JavaScript HTML editor anymore.  We use EditLive! on our internal wiki and so the entire company is now spoilt by using the best WYSIWYG editor in existence.

I’m going to sound like a salesman for saying this, but there are bigger advantages over JavaScript editors than the nicer editing experience.  We replicate the MS Word table insert wizard, use 100% Java dialogs so we don’t have popup blocker issues, and have no issues with custom XML tags in the middle of HTML.  Large systems often use such custom tags as template hooks; at best a JavaScript editor will hide the tag where it can be accidentally deleted and at worst it will completely corrupt it.  Oh and did I mention that we have the best in-browser Track Changes experience I know of?

I’m not trying to say the editor is perfect; there are always things we want to improve (and every time the development team is given a chance, we do).  It’s just that nothing I’ve seen (even other Java editors) holds up very well next to EditLive!.

 

For anyone wanting to try Express Edit, the website demos aren’t finished and it hasn’t actually been released yet so you’ll need to download an Early Access build.

 

The end of an era

It is with much sadness (well… not really) that Ephox has today officially moved EditLive! for Windows into End Of Live status.  This is the product that really got the company started; back before JavaScript editors existed, at a time when Internet Explorer 4 was taking over the world.

I spent my first 4 years at Ephox working on it, but eventually the value offering of the free editors started growing exponentially (mostly because more browsers offered free editor components) and our little ActiveX product, while an awesome editor, wasn’t making very many friends.

Here’s a bit of trivia - the naming history of ELW:

• Ezesite - original product back before the company was called Ephox
• EditLive! - A better product name chosen when the company name changed
• EditLive! for PC - when EditLive! for Java started to take off we didn’t want the old editor sounding like our main product
• EditLive! for Windows - because EditLive! for PC wasn’t technically correct as Macs became more popular.  It held this name for so long that we still call it ELW.
• EditLive! ActiveX SDK - when ELJ took over as primary product and inherited the “EditLive!” name, it was time to start hiding the old editor in the corner

It is a little bit sad because the first commercial product I ever worked on has now been EOL’d and in 18 months (end of 2008) it will no longer be supported.  On the other hand it’s been over two years since the last release, and later this year will mark 2 years since I migrated to ELJ development (which was the end of development activity on ELW).

In some ways we should have done this a long time ago, but we’ve been slowly migrating customers for a while and still fully supporting the product.  The biggest holdup was actually finding the time for me to write the migration documentation - which I’m quite proud of, it took many hours and dug up all the old corners of my codebase knowledge

For a bit of nostalgia, try the demo - note that lately the browser support has shrunk to IE only and it doesn’t work on Vista

 

[update] Andrew Roberts, now our CEO, pointed out that EditLive! started back in 1999 and the original name was actually Ezesite

 

The Ephox blogger list continues to grow

Thanks to the handy little technorati search I’ve been running since AJ used it to find me, I’m happy to announce another Ephox employee has started a blog - Suneth, our Support Engineer.

Up until recently, I hadn’t had much chance to work with Suneth other than the usual barrage of technical questions that new employees have.  Having spent the last 2 months working next to him on support, I’ve been very impressed with how much he’s learnt as well as how many cases he can handle in any given week.  I don’t think there’s been a single case in that time that didn’t get some kind of response the same day it was escalated to our engineering team - quite an impressive record.

I’m glad to see Suneth is enjoying his time in the Ephox Engineering team so far, and look forward to seeing what he has in mind for his blog

 

All of our developers start in support

Nick Bradbury left a comment on my previous entry saying that he believes all developers should spend time in support - it reminded me that I haven’t really posted about what happens when a developer starts at Ephox.

Aside from the fact that we have a new developer in support rotation, it’s been a long-standing policy that all developers who start with us spend at least their first month or two in support.  It not only gives them a good grounding in the more arcane features of our product as well as what our customers actually do with it, eventually we let them attempt to fix bugs on their own.

Having been a part of this process and watching others go through it, I have to say fixing bugs is by far one of the best ways to learn a legacy codebase.  Whether you dive in on your own or take an experienced guide with you, tracing through code to find a bug can give you a good grounding in how a product works.  And due to the nature of bugs, you’re most likely going to be touching a different area of the code every time you fix something so you get a wide range of experience.

The best feedback however comes when you learn the side effects of your changes.  The EditLive! codebase is getting better at instant feedback as we write more automated tests, but more than a few times either AJ or I have looked at a proposed fix, and said “nope that will break feature X because of unintended side effect Y”.  These are the powerful bits of knowledge that only come from experience, and in most cases it’s from a customer who reported that feature X broke after we changed that exact piece of code.

If you’re a developer and you’ve never been on the technical support team of your product, I pity you.  You can’t get a good feel for what customers want when you’re sitting behind your IDE listening to product managers.  Only on the front lines can you hope to understand what people want to do with your product and how you can make it better.