Symphonious

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

• Development of product features;
• Development of proof of concept implementations for clients.

If you like working with a wide range of technologies this would be an excellent fit for you and there are a lot of opportunities for a career in Ephox, moving into other parts of the engineering team, professional services or presales. There's also the potential for coming over to sunny Brisbane Australia1 in the future if you want to see a bit of the world. Check out the full details.

1 - and there will likely be opportunities in other places around the world over time too↩

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:

Recently, a client was having his first look at the WCM system that we were implementing [...] To him, the WYSIWYG editor was the CMS.

It's amazing how many users see things this way purely because even when they really do need the full functionality of the CMS, users still use the editor more than 90% of the time. If you're developing a CMS, the quality of the editor should be among your most important considerations because it's what you'll be judged on.

Coming back to James Robertson, I agree with most of his comments but one of the requirements struck me as a really bad idea:

• Ability to specify what window links appear in, including whether they are displayed in a new window, the size of the window, browser controls, etc. Ideally, this should be point-and-click for authors.

This may seem like a nice feature to have, and most editors provide a simple way to set the target of links, but it actually encourages users to make pages that aren't accessible. In particular WCAG Priority 2 includes the requirement that:

10.1 Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to appear and do not change the current window without informing the user. [Priority 2]

Granted, it's exceptionally common1 for this rule to be broken, but including it as a core, default requirement when looking at WYSIWYG editors seems a little off. If the client already has a site that breaks this accessibility guideline then they problem need such a feature, otherwise you should probably be steering them away from it and configuring the editor to help users create accessible content as much as possible.

Other than that, it's a pretty good list of basic requirements for a WYSIWYG editor. I've commented before on some key things to look at when evaluating WYSIWYG editors that comes at it from a slightly more technical side. Combine the two and you have a good system out of the box that can be customized and extended to provide the best possible editing experience for users.

1 - and exceptionally annoying↩

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.

The partial self training comes in by running sa-learn in a cron job to teach spam assassin that everything in that folder is spam. Any spam that SpamAssassin put there is ignored, but anything it missed and Mail.app detected is automatically used to train SpamAssassin. False positives are handled by manually fishing them out and running sa-learn –ham on my inbox to teach SpamAssassin that anything I’ve pulled out isn’t spam. Fortunately, Mail.app automatically moves messages back to the inbox when you click the “Not Junk” button.

The nicest part of it is that by having a two layer spam filter, I can switch one of them (in this case DSPAM to SpamAssassin) without being deluged by spam, because one of the filters is still well trained.

It’s all kind of neat really.

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.

It’s important to note that TDD is a design process, not a testing process. It will only test the cases that the initial developer thought of. For changing code or when the developer can’t keep all the relevant cases in their head, the tests will eliminate regressions, but by definition they won’t cover any cases the developer didn’t expect. Somewhere along the line you need someone who’s not as close to the code to really test the code and cover all the cases - not just the ones the developer thought of. Pairing helps with this, but the pair is still too close to the code. To do it properly and ensure you’re releasing a quality product, you need an actual QA process.

Regular releases in XP make traditional QA processes impossible to work with - you can’t finish all the features, throw them over the wall to QA, fix all the bugs and repeat inside a one week iteration. Instead, QA has to be an ongoing process where the QA department works alongside the development team. Straight after the planning game, QA should assist the client in writing acceptance tests that provide in-depth testing of the story requirements to ensure all the corner cases are covered. Clients often don’t think of corner cases off the top of their heads so having someone with decent QA skills will make the acceptance tests much more detailed and ensure that when the story is signed off it actually does what was needed.

As the developers work on stories, QA needs to keep an eye out for any clarifications to requirements and extra cases that the user explains to the developers while they work and make sure they are reflected in acceptance tests.

Finally, once a story is completed by the developers, QA should become an advocate for the client and test out the feature for anything that looks wrong while the client goes through and checks that it meets their requirements. This is where anything that can’t be covered by an automated test gets tested and the testing requirements documented so those tests can be run manually regularly.

During their slack time, the QA department should research ways to automate the currently manual tests, go back and run the manual tests to make sure they still pass.

The QA department might be a group of specialists or they might be the same people as in the development team - it’s the process and the allocation of time that matters more than the people. However, QA requires a distinct set of skills to development and a lot of developers aren’t much good at doing QA. If your development team doesn’t have QA skills you need to either train them up or get in QA specialists. My general inclination is that it’s best to have QA specialists who have a real passion and talent for testing software, but that your regular development team should regularly pair with them on QA work (and them with developers on non-QA work) to make sure that the team values and understands the work they do. It’s also important to avoid a divide between developers and QA - both teams are there to deliver value to the client, not to fight about whether a behavior is a bug or a feature request etc. QA and development need to be one team that works together and sits together.

One other advantage of keeping QA and development working together, is that developers fix the bugs that QA finds straight away instead of building up a big backlog that then delays the release while all those bugs are fixed and verified. Keep on top of your bug list and QA processes and you can ship top quality software in predictable timelines without the death march of bug fixing that traditionally happens at the end of projects.

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.

Having spent a heck of a lot of time working on track changes now, you'll probably hear a lot more about it and Is suspect actual tracking vs diffing is going to be a common theme.