On the due date, you have the option of completing the task, or simply pushing the due date further out, but at least it has been brought to your attention that the task has been around for a while, and still isn’t complete.

I first became interested in the open data dialogue back in early 2009 at ChangeCamp in Toronto, which was an event aimed at re-imagining government and citizenship in the age of participation. ChangeCamp spawned ChangeEngine, a project where a group of citizens (including myself), imagined a geo-aware issue tracking system, aimed at bringing communities together to solve problems and to provoke systemic change.

As the launch of Toronto’s open data site approached, some of my colleagues at Architech Solutions and I, met with Mark Kuznicki (organizer of ChangeCamp) to discuss the possibility of building a community companion site to the city’s site. We all felt there was a need, and so DataTO was born.

The Monday following our Friday lunch marked one week to go until the city’s launch date and Mark and I met for our first planning session at the Centre for Social Innovation in Toronto. At this meeting we focused on nailing down our user roles, scoped out the feature set for the initial release and roughed out some layout concepts.

Having had a full-day meeting crop up for later in the week, I was now down to 3 days of build time. Time to get going. Given the time constraint, I decided that building the app with PHP/CodeIgniter simply wasn’t feasible, so I decided to go with Grails, a Java-powered web application framework, which I had been tinkering with for a couple weeks at the time. This decision was not taken lightly, as I would not classify myself as a Java developer, but the fact that Grails utilizes Groovy, an agile dynamic programming language for the Java platform, and that Grails is so well suited for agile development, I felt that it was the way to go.

For those of you who are not familiar with Grails, think of it as the Java equivalent to Ruby on Rails. I won’t get into Grails vs. Rails in this post, so suffice it to say they are comparable, each with pros and cons. While Grails is relatively unknown at the moment, I suspect it will gain in popularity very quickly due to it’s power, flexibility and ease of use.

Having decided on a framework, I quickly spec’ed out the app, and started the build. Since Grails makes it so easy to build object models and generate scaffolding, I had more or less completed a working wireframe by the end of the first build day. The biggest benefit to having such an easy build process is that more time is left for UI, which is clearly very important to me.

In fact, the second build day was spent largely on UI. It was clear to me at this point that some of the features we had planned on being in the initial release were not going to be ready in time. So I decided to pare back, and focus on making a select few features as solid as possible, rather than diluting my efforts, and producing a greater number of mediocre components.

Day 3 of the build came and went very quickly, and was focused on skinning the application and debugging. The week had come and gone, and one daunting task remained — deployment.

Not being a Java developer, I wasn’t familiar with the various containers, but decided to go with Tomcat based on reputation and available documentation. I installed Tomcat 6 on a MediaTemple Dedicated Virtual server behind Apache and deployed the application the night before launch. This is somewhat of a “budget” setup, but it has held up well for this proof of concept. Ideally, I’d like to migrate to Amazon AWS for the infrastructure, but that will require funding (hint, hint).

Since launch, the site has received thousands of visitors from all over the world. It currently has over 200 members, and is approaching 100 requests for datasets. It has been mentioned in numerous major publications, and was profiled on The Discovery Channel’s Daily Planet.

I was extremely reluctant to put the site out there in it’s incomplete state, as I’m somewhat of a perfectionist, and I was worried that it might be a poor reflection of what I do, but I really couldn’t be more pleased. I’ve really enjoyed this as a learning opportunity, and a chance to do something good for the community. The site still has a long way to go, but I am continuing to work on it and can’t wait to see where it goes.

To start validating zip/postal code fields, include this code somewhere after you’ve included the plugin:

jQuery.validator.addMethod("postalcode", function(postalcode, element) {
	return this.optional(element) || postalcode.match(/(^\d{5}(-\d{4})?$)|(^[ABCEGHJKLMNPRSTVXYabceghjklmnpstvxy]{1}\d{1}[A-Za-z]{1} ?\d{1}[A-Za-z]{1}\d{1})$/);
}, "Please specify a valid postal/zip code");

Now you can add postalcode to your validation rules like so:

$("#myform").validate({
	rules: {
		postalcode: {
			postalcode: true
		}
	}
});

Note: this will accept both Canadian postal codes (with or without a space) and U.S. zip codes. Enjoy!

However, it’s important to note that validation errors should only be shown at the appropriate time. Today, I was adding a new contact in Gmail and I noticed something odd when I was typing in the contact’s email address. The background of the email field immediately went bright red as soon as I had typed the first letter.

Obviously, this caused some confusion. I quickly realized that I was being notified that the field did not contain a valid email address (because I was in the middle of typing it).

The point I’m driving at here is that you shouldn’t tell your users they’ve done something wrong until they’ve actually done it. Field validation is usually best left until the user has moved on to another field or performed another action which signifies that they believe they’ve completed the field in question.

Note: One exception to this general rule of thumb, is when a user enters an invalid character in a field (eg. a letter in a phone number field). In that case, it may make sense to let them know right away.

Update: Luke Wroblewski just wrote a great article on inline validation on A List Apart. The portion on testing when to show inline validation
 bears particular relevance to this post.

Let me know what you think about Facebook Connect, and its many appications.

ASCII Characters to HTML Entities Translator

In my opinion, this emphasizes the need for an online place for all of us to network and collaborate. The fact that all these people live and work within a few kilometres of me, and that I, someone who tries to put a lot of effort into staying tuned in, didn’t know anything about them, is a pretty strong indication that we all need to start communicating.

If you’re on Twitter, start paying attention to #tsTO, I think this may be the beginning of something great.

I’ve recently started to use Things, which I’ve fallen in love with, but there’s currently no way for others to add to my list. Basecamp, and Backpack allow for shared to-do lists, but they don’t let me organize all my to-dos in one master list in the way that I want to digest them.

We have syndication for blogs (rss), calendars (ics), etc. but, as far as I know, there’s no universal format for porting to-do lists from one application to another.

WHY NOT!?

If there were, anyone could make me a to-do list, send me the subscription link, and I could pull it into the to-do list reader of my choice (Things). No more entering and re-entering to-dos.

I really don’t see it even being that complicated. This is stripped down a bit of course, but a to-do feed could look something like this:

<list title="My To-Do List">

	<item>
		<status>incomplete</status></span>
		<description>Mail out invitations</description>
	</item>
	<item>
		<status>incomplete</status>
		<description>Throw killer party</description>

	</item>
	<item>
		<status>complete</status>
		<description>Make invitations</description>
	</item>
</list>

If anyone’s interested I say we look into this further and solve our to-do list woes.

I don’t know when it disappeared, as I seem to recall using it recently, but none the less, lookupd was gone. As it turns out, lookupd was replaced with dscacheutil. So, now when you want to flush your cache simply enter dscacheutil -flushcache in terminal and Bob’s your uncle.