I spent some time yesterday playing around with Venus to aggregate the various Ephox related blogs. The result is current at test.symphonious.net but will either disappear or move somewhere more official depending on how we like it. I’m keen to see what people think of it. Hopefully we can encourage a few more Ephox people to make the leap into blogging.

A while back I complained that the FireFox 2.0 installer didn’t include an actual link to the Applications folder. This morning I saw that this wasn’t just a theoretical problem, nor was it just a problem for “stupid users”. One of our engineers, who is very bright and good with computers but with no real Mac OS experience, had to install FireFox 2.0 on one of our testing Macs. He dragged the FireFox icon onto the picture of the Applications folder. The lack of text made the problem even worse – he wasn’t familiar with the Applications folder icon on OS X so didn’t realize it was meant to be representative of the destination instead of being the destination in and of itself.

I installed the final version of Office 2007 this morning and when the installer finished I was actually quite impressed – it was the first Windows install I’ve done in ages that hasn’t taken the liberty to install a shortcut in my quick launch bar. Sadly, Outlook is one of the very few programs that I actually want in my quick launch bar so I went and added it myself. I thought, I’ll have to blog that – “Thumbs Up For Office 2007 Install”.

Ephox is looking for a software engineer in our San Mateo office.

Roles and Responsibilities

• Provision of advanced technical support to prospects and clients via phone and email;
• Development of solutions to both internally and externally reported bugs including the development of automated regression tests;
• Provision of professional services including custom development and product enhancements;
• Provide quality feedback to the rest of the business for the most common use cases for our products, potential new areas and feature requests and the most common problems and problem areas clients are encountering;

Other work includes

James Robertson mentions the importance of a good authoring environment in CMS solutions.

Considering that the primary purpose of a web content management system is to help staff to write and publish content, the editor has to be front-and-foremost when it comes to selecting a product. And yet, many organisations specify little more than “the CMS must provide a web-based WYSIWYG editor”.

I also found Seth Gottlieb’s comments on the subject interesting, particularly:

This weekend I switched from DSpam back to SpamAssassin because of DSpams high false positive rate and my dislike of having to review all the spam it caught constantly. While doing so, it occurred to me that the way I’ve set up my anti-spam solutions is really pretty cool. I’ve essentially set up a partially self-training system with a user-friendly interface for providing feedback via Mail’s Junk mail button.

SpamAssassin is set up to run via procmail and dump any spam into the folder that Mail.app uses for its Junk mail. Mail.app is also set to move any spam it detects into that folder so there’s a two layer spam filter in place to move everything into that one folder for review.

I’ve seen a misconception a number of times where people believe that the regular release cycles and TDD practices in XP mean that you don’t need a standard QA process – that the developers are responsible for writing perfect code, first time every time. It’s true that XP practices can significantly improve quality, both of the code and the final product, but that doesn’t excuse the team from properly testing their work.

Anthony Towns:

Writely, the web-based word processor, was kind-of interesting, but in the end didn’t work for me. The potential killer feature for me would’ve been SubEthaEdit or Gobby -like interactive collaboration, which seems like something Google ought to be able to do with their whacky AJAX techniques. Unfortunately, it seems to just be some sort of automated merge-on-commit, which does nothing for me.

I believe Writely’s attempt at real-time collaboration is a little more advanced than merge-on-commit, but as far as I know it is based around diffing instead of actual change tracking. The trouble with this is that it makes it nearly impossible to preserve the user’s intention rather than just the effects of the operation. It’s certainly easier to get a system up and running using diffing than using actual tracking of changes, but the results just don’t sync up with what users expect as much and I suspect Anthony’s experience reflects that.

I’ve been trying to get the dates in my comments feed to show up correctly with all the right time zone stuff and so on, but even though I’m pretty certain the feed is reporting the right time and time zone, NetNewsWire seems convinced that the comment was made in the future. So can someone confirm for me that the date 2006-10-25T20:28:58+10:00 refers to 8:28pm (and 58 seconds) on the 25th of October 2006 in a time zone that is +10 hours from GMT. Thus if my time zone is also +10 hours from GMT the date should mean 8:28pm local time on the 25th of October 2006.

I’m in the middle of doing platform testing for EditLive! 6.0 which involves setting up and testing a huge array of OS, browser and JVM combinations to run through and manually verify that everything is working as it should be. Normally this is hard enough to do, but at the moment it seems every tech company has either just released a new version or is about to. We’ve got FireFox 2.0, IE 7, Windows Vista beta, OS X Leopard beta, Java 6 beta, OS X Java 6 beta, Office 2007 beta and who knows what Linux and Solaris is going to do to me.

The back button has been a great challenge for a lot of modern web applications and WYSIWYG editors are certainly no exception. Way back before I can remember, someone had the fantastic idea of preserving content entered into text fields and restoring it if the user hit the back button to return to the page. Unfortunately, with the advent of WYSIWYG editors, this was generally lost because the browser reruns the JavaScript in the page again, providing no indication that the user was returning to the page. I could be wrong, and I’d love to hear of other examples, but I don’t believe there is a WYSIWYG editors available today that preserves content when the user hits the back button. I find it somewhat interesting that despite the huge amount of user angst this causes1, there doesn’t seem to be a lot of interest in solving the problem.

Since cruise control doesn’t use a bug tracker – it only provides email lists and I don’t currently have access to my email – I’ll just report this bug here and maybe someday along the way they’ll discover it and fix the problem.

Anyway, my beef is that the cruisecontrol webapp doesn’t work with lynx because it uses a ridiculous JavaScript system to trigger new builds. Now, normally I don’t use lynx as a browser because it tends to be pretty limited, but it would be nice to be able to trigger a build remotely without having to manually parse HTML files and find the URL to ping to get a build to start. At the time I was SSH’d through two machines and then using Hamachi to get access to the actual build machine so it was a little bit difficult to use a standard browser at a reasonable speed.