Conceptual Clarity

Over the last twelve months Ephox has been working with the Extreme Programming (XP) methodology.  It's something that we are pretty committed to because at the end of the day XP's focus is on delivering more value to the client more quickly.  Hopefully that's a win win situation.  We deliver software more quickly to you and you can then give us feedback that enables us to create even better software.  

It's been a challenging shift, possibly most of all for me.  We're shifting from a fairly traditional, design up front type methodology, it was under this methodology that we begun the development of EditLive! 6.0 and the EditLive! Productivity Pack.  It wasn't without its advantages, it did enable me to more clearly communicate with clients about what was coming, but where it fell down was getting the timing right.  We blew past our initial estimates and the release was significantly late.

If we'd been following the extreme programming methodology at the time we would probably still have delivered the "finished" product at around the same time.  The key difference would have been that we would have been able to deliver more interim releases.  We would have been able to let you all see what we'd been working on and, most importantly, we would have been able to incorporate more of your feedback.  We will shortly be kicking off a new initiative called LiveWorks! to help address that, but more on that in another post.

The agility of XP doesn't come without a cost though.  If we're going to be delivering value more frequently and taking your feedback into consideration it means our roadmaps are going to get a little "fuzzier".  By leaving the roadmap somewhat "fuzzy" we can maintain the vision and direction of a release while still taking your feedback into account as we progress.  It also allows us to change direction more rapidly if that's what's valuable for you.  For instance, if accessibility suddenly becomes the "hot topic" (as it is in Europe at the moment), we can shift our release plans from track changes improvements (for example) to deliver the accessibility functionality you needed yesterday.  Well maybe we can't shift quite that fast, but you get the idea.

Sounds great right?  Well it does on paper, in practice, many of us (myself included) still love to look at larger scale plans.  I would love to have the roadmap planned out perfectly, to the finest detail, for the next two years, yet this is something XP recommends against, and with good reason, afterall all, best laid plans are often laid to waste, especially in a field that moves as swiftly as software development.  It's been a difficult move to stop myself from spending time planning all the fine little details (which inevitably shift anyway) but I've managed to restrain myself.  What I am going to focus on instead on communicating with you more clearly and continuously.  This blog is the start of that, and LiveWorks! will be live soon to give you even more of an insight.  2007 is going to be an exciting year, so stick with us, keep your feedback coming and look out for even more valuable improvements to EditLive!.

OK so the pun was bad, but I couldn't help myself.  All puns and jokes aside though, the Nintendo Wii is doing serious business.  This Christmas one of the hottest selling products is the Nintendo Wii.  I bought myself one, as did many many others.  I've never before bought a games console on its release date and in fact, with the little time I have to play games, I really prefer using my laptop.  So why my change of heart?  It's down to the Wii's outstanding product design and therein I believe there are a few lessons to be learned by product managers and development teams everywhere.

The Wii is not the most powerful next-generation games console - its graphics don't stack up against the competition, it can't play Blu-Ray discs (or DVDs for that matter) and it doesn't even have a hard-drive.  So why buy one?  Because of the innovative style of control and gameplay.  The controllers of the Wii respond to the player's movements in three dimensions instead of just the wiggle of the thumb or the press of a button.  It's a concept so simple I'm surprised that no-one thought of it before.  As a consumer it's this that I've valued over all the other features of the consoles and having now played the Wii I can tell you it's value well placed.

So as a product manager for software used by businesses what can all this possibly mean to me?  Well there are several product design concepts that the Wii exemplifies that many business can learn from:

• Vision is key.  If in doubt, have a look at the interviews with the Wii development team.  It's also key at Ephox.  We develop using an Extreme Programming (XP) methodology and for this vision is so important.  Check out James Shore's article on Vision in Agile Development if you want to know more.
• Sometimes your customers can't tell you what they want.  I imagine if Nintendo asked any gamer what they wanted in a console their answer would have been better graphics or more games.  I doubt that anyone would have said "a controller that responds to your movements in three dimensional space".  We experienced something similar with Track Changes.  Clients didn't ask for it as it wasn't something they expected of their online WYSIWYG editor, but our vision told us how valuable it is.
• Changing the balance of differentiation.  Nintendo changed the value curve.  They focused on the control mechanism and the gameplay and reduced the investment on other factors, like state-of-the-art graphics, media and hard drive technology.  This enabled them to introduce a clearly differentiated, valued product for less than the cost of the competition.  For Ephox we've had great success with integrating EditLive! into other online systems because the differentiation shifts from management and control to creating a system that people can actually use and obtain value from.
• Simple is often best.  While I am sure the Wii controllers are technically fairly complex, their beauty is in how simple they are to use.  As a very casual game-player I've never quite managed to get the hang of the XBox controller, but with the Wii I could pick it up and start playing straight away.  As any software developer would know, making simple, easy to use interfaces is very difficult, and it's definitely something I'm focused on as a product manager.

Over the last six months I have had many people ask me whether Ephox will be developing a JavaScript-based editor in the future.  This is something that we've considered in the past, but the reality of the situation at the moment is that Java enables us to do more and that means deliver more to you. 

Most of you have probably already seen the likes of FCKEditor and TinyMCE and perhaps even used one of them.  These are probably the two best offerings available based on native browser technologies.  The way that these editors work is by using JavaScript to work with an editor component embedded within the browser.  This works well for most basic editing, for example, bold, italic, underline and simple tables.  However, these tools are ultimately limited by the functionality that the browser can provide.  At the end of the day, browsers aren't built for editing, they're made for rendering.

The other advantage to the JavaScript approach is that there is no JRE install required.  However, over the last few years Sun Microsystems has done a great job with it's Java Everywhere campaign and I can't say that the issue of Java support has caused us any problems in the last year or so.

Java has freed us of the constraints of the browsers and this is why EditLive! can offer important productivity functionality like spell check-as-you-type, thesaurus, accessibility checking and syntax highlighting for source code editing.  Another great example is track changes, here's a feature I don't imagine any browser development team building in, and without Java I don't think we could have built it either.

Finally, there's a whole lot of little things that we've been able to do with EditLive! that often don't get noticed on the initial evaluation, but you're contributors will get annoyed if they're not there.  Andrew likes to refer to this as "the death of 1000 pin pricks".  These are the little things that people have just come to expect over time.  Menus for instance - without menus users will need to mouse over each toolbar icon to see what it does, or dialogs getting blocked by pop-up blockers, or the lack of double-click actions to open properties dialogs or simply the preservation of content when you accidentally hit the back button.  No single one of these is enough to cause contributors to stop using an editor, but together…well it's the death of 1000 pin pricks.

So yes, we use Java, and we will continue to do so, keeping our eye on the browser-based technologies, and re-evaluating them as they (hopefully) offer more functionality.  At the end of the day Java enables us to provide you with the most value so that's where we need to be.  What matters to us is delivering productivity to you and your users every time that they use EditLive! and that's exactly what Java enables us to do better than anything else.