Welcome to the blog world Brett! It’s about time. Brett’s the engineering manager at Ephox and we’ve been nagging him to blog for some time now. I’m biased, but you really should go check out the theme – apparently he’s working on a post to explain the hamster….
After the whole Andy fiasco, we’re making sure we out Brett’s new blog early and often. So who’s going to be the next Ephox blogger?
I’ve spent most of this week working on making the start up experience for our applet better. It should look better, take longer and most importantly feel fast to the user. The first step is obviously to profile and optimize – the faster the start up time actually is, the easier it is to make it feel fast for users. There were a few things we could do to help out there, but nothing that really made a dramatic difference.
As part of a restructure of the engineering team last week I was moved into a product management role, focussing on our ready-made integrations with third party products (eg: our Alfresco integration) and to be formally in charge of LiveWorks! There’s a bunch of details regarding what the new role entails that I’m still not completely clear on, but I’m sure they’ll be worked out soon enough. I expect there will still be a fair bit of technical work so I’ll still be hands on to a reasonable degree, but what I currently see the job being about is community. There are a number of aspects to this:
One of the new features in EditLive! 6.1 that we released today is a plug-in architecture that handles deployment of extensions to the editor. Plug-ins in Java apps are pretty common these days, but there aren’t all that many applets that have them so I thought it would be worth documenting some of the challenges we faced and how we overcame them.
One of the things we’ve been wanting to do for ages was automate our release process so that with the click of a button we’ve deployed a new version out to customers. Today, at least for EditLive! itself, that became a reality, with the “autodeployer” being tested out with it’s new release capabilities.
At first glance it looks like releasing a commercial product like ours would be really straight forward, but there’s a surprising amount to it. No one step is difficult, but there are a lot of different systems involved from our main web site, to our source control, build machine, release notification system, integrations, demos etc. As usual for automation projects, the biggest challenge is working out exactly what you are doing manually. Finding the right way to automate it tends to be pretty simple once you understand what you actually do.
Most issue tracking/customer relation/todo list things have a concept of resolving an issue for later or a remind me later option. The idea is that you don’t want to or can’t deal with the issue straight away, but you need to come back and review it or follow up later.
Unfortunately, it turns out that marking an issue for later tends to mean “make this disappear so I have no chance of remembering it” because the issue disappears from all the open issues lists forever. Many systems have an option to e-mail you regularly about issues that are marked as remind or later, but the e-mails are hit and miss – usually they remind you about the issue too early and you just get used to ignoring them.
There is an awful lot of money spent on user interface research, carefully tracking what users do with an application and trying to find ways to improve based on that. It’s a shame that so much of it is wasted because the captured data is misinterpreted.
The Office 2007 Ribbon is a classic example of this, it was clear that Microsoft had real world data to back up their decisions about the Ribbon, they’d spent millions on it. Yet somehow it just didn’t seem right to me. Turns out at least Damien agrees with me. It turns out that despite the fact that usage data shows that users work in different modes, designing an interface that reflects those modes isn’t ideal.
Rob posted about his second month at Ephox and it made me realize it’s been a while since I’ve taken the time to reflect on how things are going for me. Warning, lots of rambling ahead with no attempt at editing.
Towards the end of last year it had gotten too long between holidays and I was getting stressed out and generally sick of work in general. Fortunately, if you haven’t taken holidays for a long time you also have a lot to take, so I took all of January off to recuperate. Since then I’ve been working on my own for the most part with the rest of the team tied up with other projects. I must admit, I quite enjoy going off and coding stuff on my own, still doing TDD and all the other XP practices except of course pairing. It does however tend to let the odd thing slip through and we’ve seen a few issues crop up that we’ve had to fix. Fortunately, since we run the latest builds internally the problems were caught before clients saw them. I’m really not sure if a pair would have picked them up anyway, but it may have helped.
Nice article from the Chief Happiness Officer this morning on pimping your office. Most of the things listed are just over the top, but I really did like the look of Softwall. If Ephox winds up moving offices we should definitely think about using these – it’d let us have an open plan development environment with the flexibility to close off sections as needed.
For a couple of years now, Ephox has been very successfully using a wiki to provide communication within the company and helping to bridge the gap between our two offices on opposite sides of the pacific. Central to the success of the wiki has been the successful integration and configuration of EditLive! as the editor. It certainly helped that we have a high quality editor with lots of attention to detail but the most important aspect was the amount of attention we paid to correctly configuring the editor.
According to our stats, yesterday I deleted over a thousand lines of code – sounds like a productive day to me. Hopefully today I’ll find another thousand lines to delete. It’s amazing how unused methods can build up without you noticing. Eclipse will tell you about unused private methods, but not about public ones that aren’t used anymore. Most of them had unit tests even, just that the entire functionality had become unneeded. There’s probably some duplication in there as well that will let us delete more lines of code.
We’ve been struggling with ways to improve our documentation for quite a while, but we’re still finding that our documentation just isn’t good enough. The biggest frustration with the current tool is that you can’t link to a specific page on our web site so our support team has to tell people to go to the manual, click this then that then this other thing and scroll half way down the page. I think there was also a complaint that they look ugly.