Introducing accounts! An account allows you to keep track of documents you’ve recently worked on. I’ll be adding more features in the near future which don’t work without an account.
I’ve also made a few changes to the website’s style.
A few changes I’ve made over the last few weeks.
You’ll notice a new “History” button on the top menu bar. This will allow you to see all previous versions of your documents, and restore an older version if you want.
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.
I just released a couple changes to collabedit.
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.
Collabedit now has sidebar chat! There are still has a few minor quirks with it. I ran into some trouble with EditArea (the javascript text editor I’m using) because it requires browser focus in order to update the text. I’ve got my eye on Codemirror and some other alternatives though.
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.
Eclocking has not gotten the reception I had hoped from the world wide web. It doesn’t solve a problem that most people care about.
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 etherpad launched in November 2008, I took notice. It was very similar to collabedit, a website that I had launched in March 2008. I quickly became a fan of etherpad and have used it for awhile now, preferring it over collabedit for most tasks. I stopped working on collabedit and moved on to other things.
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!
The following quote comes from “Refactoring” by Martin Fowler, page 67. In this section of the book, he is talking about refactoring vs trying to design everything up front.
——————————————————————————–
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.
Here’s two things I learned when I launched eclocking yesterday.
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.
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.
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.
Today it is my pleasure to introduce the world to eclocking.com.
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!