The ORB Blog

In a recent post I talked about the issues that had been picked up when we got a professional tester to test ORB. They found several edge-cases when setting up users, resources and facilities or making bookings that testing hadn’t previously picked up.

This really highlighted for us the need to validate the input not just once, but potentially three times and then to ensure that when we save the information that process itself has been successful. Let me explain:

Firstly, we’ve added limits (using the HTML INPUT tag’s maxlength attribute) to every field that accepts a text input. This should, at a browser level, prevent anyone from typing more text than the corresponding database field can hold.

You’d think that having the browser ensure that there are no problems with the data entered in these fields being too long to fit in the corresponding database fields would be enough, but it’s actually not.

So, our second addition is a check when you click on the button to save a booking or add resource, facility or user information. We validate the lengths of these fields, amongst other things, before we submit the information to the server.

But wait, there’s more! To ensure that there’s no risk of the data being tampered with between the browser and the server and so ending up too large to fit in the database fields, and just in case we’re dealing with a user who has javascript disabled (so all our validation attempts to this point won’t have run), we also validate the lengths of all data that the user has entered on the server as well. Only then do we send the data to the database.

Even now though, we’re not done. Despite taking every precaution to ensure that the data we send to the database is valid, we also check what the database tells us, to ensure that the data has been saved successfully.

This may sound like overkill, but it’s part of the process of ensuring that ORB is robust and reliable, to provide a great service to our clients.

We thought we were ready to launch, we really did. We’d tested the new ORB to death, or so we thought. Then, because we’re paranoid and because we want to ensure that ORB is as near perfect as we can make it, we asked a close friend and professional tester to take a look.

Good job we did.

You see, we’re geeks and we think like geeks. Testers tend not to be geeks and to think more like “real people” and “real people” do things that we wouldn’t even have thought of doing. Trying to create a resource with a 200 character name, creating multiple resources with the same name, creating a password that’s all spaces or hundreds of characters long. Putting data into fields through copy and paste, so bypassing the validation done as you type.

Plus, we thought it was obvious how some things work but, it turns out, it’s not as obvious as we thought.

So, to cut a long story short, we’re busy adding lots of extra checks and instructions in a few places where things might not be as obvious as we hoped.

We hope this will create a better experience for everyone.

We launched the ORB beta in January 2010, intending to run it for a two to three month period to gather feedback before doing a full launch.  Well, as ever, the best laid plans…

But although the beta has gone on much longer than we planned, we haven’t forgotten about ORB.  In fact, we have completely rebuilt ORB from the ground up.  It’s now much more robust, more scalable, more performant and more flexible, to support features we have planned in the future.

We’ve also taken the time to improve the user interface and to add some of the most requested features from our users.

You’ll see these changes roll out in time for our anniversary, when we will also introduce paid plans.

Stay tuned…