We needed to deliver a prototype on-line exam quickly. Despite their simple appearance, on-line exams can have some complex interaction modes that are annoying to deal with in a client/server model.OpenLaszlo provided an excellent framework for quickly going from idea to solution.
The Birmingham Course approached us with the idea of
placing online a mock exam for their MRCPsych course. While the time constraints were tight, we thought there was an interesting opportunity in the project, and enjoyed the enthusiasm that The Birmingham Course brought to the table.
I would have liked to do some paper prototyping, and work through the issues that might arise before starting. However, we also wanted students currently enrolled in the course to trial an on-line version of the mock exam. This left us in a bit of a pickle: can you, in one-and-one-half weeks, go from concept to implementation for an on-line examination, and get it right? (I live far enough away from Birmingham that I didn’t have the ability to take a day or two and go up there to meet with the client.)
The mock exam had no data gathering requirements, nor were there any concerns with authentication and identifying users. Therefore, some of the trickier aspects of web-based application development were not concerns. However, we still needed to deliver 133 True/False questions, and 30 multiple-choice questions in a stateful way, so students could easily “go back” and change their answers, as well as get their end-of-exam score.
While there may be AJAX gurus out there who think this would be a piece of cake, I do almost all of this development work in Scheme, and have no particular expertise in HTML/CSS/Javascript interaction on twelve different browser platforms (that’s why I run with a team). I certainly don’t have a lot of patience for developing code in an unstructured and unsupportive environment. Put another way, I think the browser makes a lousy run-time environment; I want my compiler to check for obvious problems up front, and I want my runtime environment to be rich enough that I can go about debugging a running application. Your typical AJAX app fails on these counts far too readily for me to think that any AJAX code I develop in a hurry will be reliable. (I’d like to point out that I’ve never even given AJAX enough of my time to decide if my biases and opinions are right; I’ve only read code and stories from others, and I don’t like what I see.)
Enter OpenLaszlo. It has a compiler, that tells me when I make silly mistakes. It has a rich run-time environment, which includes an interactive debugging REPL. I can create a window as easily as saying
<canvas><window>Hi there!</window></canvas>
It uses JavaScript 1.5 as it’s scripting language, and has a really sweet little constraint engine built in. The upcoming 3.1 release has some very swish enhancements on the way as well.
I was able to quickly prototype ideas for the customer, push them to the WWW, and let them interact with the application. While it is possible to do all kinds of RPC from OpenLaszlo, I chose to employ another really nice feature of the environment: SOLO application deployment. If you’re willing to give up some (not all) connectivity with remote hosts, OpenLaszlo apps can be compiled to a single, static Flash file. This means that any user with Flash 6 or better can interact with a very rich net-based app, and get a very desktop-like experience.
The end-product of a one-week mad dash can be seen online; I was quite pleased with it. I know I made some choices that were less than optimal, but the code can be refactored and improved in a future iteration of the project. I was also happy working with OpenLaszlo as a development tool—putting together GUIs was no more complex than writing a webpage, the event model and constraint system are both well-behaved and useful, and being able to deliver a static Flash document as an application means I don’t have to worry about a timeouts on client/server interactions, nor do I have to wonder if IE4/IE5/IE6/Opera/Firefox/Mozilla/Safari is going to choke on my particular choice of HTML, CSS, and Javascript idioms. If you’re some kind of “purist” who abhors Flash, then… I can’t help you. But it’s widely deployed, and much better behaved than a gaggle of browsers.
Food for thought. Point is, I liked it. And the customer loved it; the app behaved just the way they wanted. I don’t know what else I can say.