I’ve also made a few changes to the website’s style.

1. I moved to the latest version of EditArea. Looks like it actually took a small regression in chrome, I’ll look into fixing that.
2. Smaller urls, collabedit.com/display?id=123456 becomes collabedit.com/123456. The old urls will redirect to the new one.
3. 4 spaces instead of tabs for indentation.
4. Word wrap.
5. Fixed 5 minute timeout issue.

Prior to this feature, if you accidentally wiped out your document text it was gone for good. This is no longer a problem.

Older documents won’t have any history yet, because it hasn’t been tracked until now.

1. User List – See a list of everyone who is currently viewing the document

2. Improved latency – The code no longer polls every 2 seconds to check for document changes. Instead it uses comet so it’s updated instantly.

I also fixed an issue with opera, improved the error dialog and made some changes to the underlying code.

I’ve switched to using Tornado as the underlying web server. Tornado will enable me to use comet (aka “long polling”, “server-push”, “http-streaming”, “bosh”) technology.  I haven’t taken full advantage of that yet, but I will. Tornado also has a built in templating system, authentication, database helpers and a few other nice features.

With this in mind I have decided to spend my time on something else for now. I will leave eclocking up, and I will continue to use it myself.

When I learned that google had acquired etherpad earlier this week I had mixed feelings. I’m going to miss the service it provided, but I see an opportunity for collabedit to fill the void left by etherpad. I have been looking for another side project, but hadn’t considered revisiting collabedit until now.

I recognize that collabedit lacks many of the features that make a collaborative editor like this useful. I intend to spend time over the next several months adding these features. I would appreciate any feedback from etherpad users about what features would be the most useful. For this purpose I have created a new feedback forum at http://collabedit.uservoice.com.

Congratulations to the etherpad team, you deserve all the success you’ve seen. Best of luck with Google Wave!

——————————————————————————–

With refactoring the emphasis changes. You still do upfront design, but now you don’t try to find the solution. Instead all you want is a reasonable solution. You know that as you build the solution, as you understand more about the problem, you realise that the best solution is different from the one you originally came up with. With refactoring this is not a problem, for it no longer is expensive to make the changes.

An important result of this change in emphasis is a greater movement toward simplicity of design. Before I used refactoring, I always looked for flexible solutions. With any requirement I would wonder how that requirement would change during the life of the system. Because design changes were expensive, I would look to build a design that would stand up to the changes I could foresee. The problem with building a flexible solution is that flexibility costs. Flexible solutions are more complex than simple ones. The resulting software is more difficult to maintain in general, although it is easier to flex in the direction I had in mind. Even there, however, you have to understand how to flex the design. For one or two aspects this is no big deal, but changes occur throughout the system. Building flexibility in all these places makes the overall system a lot more complex and expensive to maintain. The big frustration, of course , is that all this flexibility is not needed. Sum of it is, but it’s impossible to predict which pieces those are. To gain flexibility, you are forced to put in a lot more flexibility that you actually need.

With refactoring you approach the risks of change differently. You still think about potential changes, you still consider flexible solutions. But instead of implementing these flexible solutions, you ask yourself, “How difficult is it going to be to refactor a simple solutions into a the flexible solution?” If, as happens most of the time, the asnwer is “pretty easy,” then you just implement the simple solution.

1. The importance of a good landing page

I had hoped that people would figure out what eclocking was all about by playing with it. This wasn’t the case. My statistics from the first day were as follows:

900 people saw the timer (that's was the front page)
358 people saw the tour or used the history page

About 60% of the visitors left before they even understood what eclocking was all about. They won’t be back.

2.  Need to focus on a niche

While building eclocking, I tried to keep it as generic as possible in order to attract a broader audience. Problem is, most people didn’t see a specific scenarios where it would be useful.

I will probably need to pick either timed athletic activities  (jogging, biking) or timed billing (lawyers, contractors).  Eclocking currently isn’t the ideal solution for either.

What now?

I’ve added a more informative front page to eclocking.com. As far as choosing a niche, I’m going to give myself some time to gather information before shifting my direction.

Eclocking is my attempt to create the ideal stopwatch. Typical stopwatches have no capacity for storing, organizing or displaying your data. What’s the point of timing something if you’re not going to keep track of it?

With eclocking, once you’ve recorded a timing, you tag it and save it. Now you can create charts, filter your data, edit your data, export it, etc. This is your data, do whatever you want with it.

Your data is stored on our  servers so it travels with you. You don’t have to mess with files or programs.

It can be a little cumbersome to carry a laptop computer with you everywhere. I’ve created a mobile web version so you can use eclocking on your phone, ipod touch or other compatible device.

Please give eclocking a try and leave me some feedback. This is just the beginning. With your help and feedback we can turn eclocking into something great!