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:
EditLive! ExpressΒ Edit
(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.

Busy week in support

The technical support team at Ephox is fairly small; currently there are only two of us.  This normally works out ok because our front-line team is fairly cluey and can handle a lot of cases by themselves.  It means, however, that when the other tech goes on holiday for a week I’m left doing it all by myself.

This week I worked on 43 cases, which is probably some kind of personal record.  And that doesn’t include another handful that I consulted on but weren’t actually assigned to me.

A few of them were simple follow-up emails on old cases, but most were actual technical issues with some confirmed bug reports thrown in for good measure.  One of the reasons we have a Senior developer doing support, of course, is that I just dive in and fix them myself.  I thought the bugs I’ve fixed in the last couple of days were amusing:

  • Potential deadlock with cached image downloads
  • HTML filter failed when there was a <title> tag inside the <body>
  • Infinite loop in background spell checking after removing a space followed by a single quote with track changes enabled
  • Style dropdown was only one item high with the document navigator disabled and no linked stylesheets

If you look at those last three in particular, you’ll see the sort of edge case scenarios we find our customers hitting more regularly than you’d think – and the last one was reported twice recently.  It’s an unwritten rule of customer support: any time you get a report of some weird use case that exposes a bug in the product, within a week there are other customers reporting the same thing.

I will say this however – while Ephox technical support can be a challenging job, it’s a rewarding one.  We are very proud of the quality of our support (which comes from putting developers on the team) and pretty much every week there are customers who are so happy with our support they leave comments like this:

You’ve been really helpful, and have responded quickly in all cases, IMHO – many companies are nowhere near as good as yourselves.

I have two weeks left on my support rotation, and I’m doing better than I predicted – only now am I running out of podsafe music podcasts to listen to.  It’s a bit sad to be leaving the support team, I’ll miss the wide variety of cases that come through; but we can’t leave developers on the team too long or they burn out πŸ™‚

Hamster man

I’ve been neglecting my blog this month, the looming changes to the Engineering team stressed me a little more than I’d care to admit.  But now it’s time to catch up on a post that I meant to make a week ago.

The latest in the growing line of Ephox bloggers is our engineering manager, Brett Henderson.  Brett has been with us for a couple of years now, after contracting on some J2EE work he eventually filled a much-needed role in the team.  He has a mild obsession with Hamsters, Ferrets and Squirrels (especially Scrat).

Check out his blog to see the amusing logo of a hamster in a top hat, and stay for what should be interesting discussions from an engineer who accepted our unexpected offer and his first management position πŸ™‚

Big changes at Ephox

This week marks a major reshuffling of the Ephox engineering team.  Announced by Andrew Roberts (our CEO)  the day before Easter, he has posted some of his thoughts (although hasn’t yet continued his discussion).  The long and short of it is that we’re shifting two of our senior engineers out of the engineering team and into product management in an effort to better direct our resources.

Rob, who we hired in January to bolster the level of senior experience in our team, will be moving to EditLive! product management.  This is our core business so he now has a very important role – but one that he has time to ease into with the next release or two already planned out.  He just posted the third of his monthly braindumps and notes with some irony that in a job he took to get back into programming, after only 1 month of actual coding he’s moving into a managerial role.

AJ, resident codebase god at Ephox, will now be the integrations product manager with a heavy community focus (I don’t think we’ve come up with actual titles yet).  He has talked about not only what he plans to do with the role but also concerns about his relationship with the engineering team now that he won’t be doing any core product development.  Hopefully his work will mean you hear about EditLive! in more places where you use an in-browser HTML editor.

Damien, our existing product manager, will finally be free to start preparing our Next Big Thing ™.  He has been too busy with existing products to think about what we’re doing next, which was one of the driving factors behind the idea to shift those tasks elsewhere.


These changes are going to have a huge effect on me.  I am now the developer with the most codebase knowledge; making me the go-to man for codebase questions, feature arguments and generally being an EditLive! guru.  Luckily, I started training myself for this months ago.

I can’t remember exactly when AJ announced he would be moving to England (I can’t even find a mention on his blog other than in a post about wedding photography), but I can clearly remember my reaction.  Whether Ephox starts a European office or not, there was absolutely no question that AJ would be leaving EditLive! development.  At the time I was still settling into the shoes of our other codebase guru who left to pursue game development, and realised that my goals had just shifted to not only be a codebase guru, but the codebase guru.

I immediately redoubled my efforts to steadily build codebase knowledge, and with plenty of time before AJ leaves we decided to start phasing him out of development over the course of 2007.  For a long time now I’ve been trying to solve problems on my own before asking him for help, and when I am forced to ask I take mental notes for future reference.  All this turned out to be a fantastic idea because he’s just been disconnected completely which has accelerated our plans by at least 6 months πŸ™‚

It’s going to be a huge challenge for me, but I’m absolutely ready.  I may have a different style to AJ and lack some of the tricky Java knowledge he’s picked up, but I learn fast and have very few areas of the code left to get my head around.  At least this way he’s still sitting across the room while I settle into the role instead of in another timezone πŸ˜€

Drag and Drop file support for EditLive!

Ever since we heard about improved drag & drop support in Java 1.6, the Ephox engineers have been thinking about how cool it would be to include this in EditLive! – allowing files to be dragged into the editor and their contents inserted directly into the document.  So in a Creative Coding Afternoon a few weeks ago, I implemented it.

I did it both as a proof of concept and as something that could be put up on LiveWorks – this thing is so useful the first feedback I received was “so when is this going on our internal wiki?” πŸ™‚

It’s not my first LiveWorks plugin, that distinction goes to the hyperlink tooltips; but I wasn’t involved in the LiveWorks posting of that one whereas the code and docs for this new plugin are almost 100% me.  It’s a very good example of just how extensible ELJ is with only one minor codebase change made to support inserting the contents of:

  • Images (gif, jpeg, tiff, png)
  • Text files
  • HTML files
  • MS Word Documents (only on windows)
  • .url files (Internet Explorer bookmarks)

The result is a lot of fun to play with πŸ˜€

You can drag as many files as you want, and as long as all of them are supported they will be inserted one after the other (this is really useful for images).  The whole thing is done using standard APIs for both ELJ and Java 1.6, with the support for multiple files based on the Drag & Drop Data Transfer Swing Tutorial.

Full source code is provided, and I think this is also a handy example of how to use the new TransferSupport API added in Java 1.6.  Without it, you can’t get the list of files that the user dragged until after they’ve dropped it – so there’s no way to know if any of the files in that list are supported.

As always you’ll have to download ELJ to use the plugin, but it comes with a free localhost license where you can play to your hearts content.

Jonesin’ for my Podsafe Music

We’re trying a new idea at work this week to help keep our customer support at the high quality level we are so proud of while avoiding the turnover that inevitably comes from putting really smart people on your support team.  Starting today, we are introducing a support rotation schedule that will have one of our developers on the support team at all times, and we rotate at the end of every release.  As well as avoiding support burnout, this will hopefully make sure we actually stick to the short release cycles we have planned.

I’ve known this was coming for a while, and I’ve been preparing.  My 3.5 years in support + development for our ActiveX product before switching to full-time dev on the Java Product taught me all too well that to survive, I need about 4-6hrs a day of music to listen to depending on the load.

As a result, I haven’t listened to much (if any) of my podsafe music podcasts in 3 weeks.  They’ve been sitting on my iPod, staring at me every time I search for something to listen to.  Staving off the cravings has been difficult, to the point where last week I actually stopped the podcast I was listening to and started playing regular music from my iPod – something I’ve never had to resort to at work since I discovered podcasting.  But it was all worth it, my “music podcasts” playlist is now close to 18hrs πŸ˜€

With an emphasis on pair programming for big bugfixes I’m going to say I’ll only need 4hrs/day during my time in support, and accounting for new material produced as I’m catching up this stash should last me at least 2-3 weeks.  By that time there will be new episodes of my trance podcasts to see me through and if for some reason I manage to catch up completely there is a list of music podcasts longer than my arm to choose from.

And yes, this is supposed to sound like an addiction.  If you’ve read my previous posts on the topic, that shouldn’t come as a surprise πŸ˜›