Lieven Cardoen

In my Company we develop educational software. Authors can create content in a backoffice and present them to students in different kinds of contexts.

The first and second version use the same backoffice created mainly in ASP. In spite of the fact that usability isn’t that good, it is still being used by our customers. The frontend for the first version was written in flash using Actionscript 1, the second version used Actionscript 2. In AS1 we had an swf for each type of exercise, in AS2 we had one big swf.

For the third version we decided to use Flex for backend and frontend. There have been hours of discussion about this decision in our company and even customers tend to argue about using Flex. This post is about this discussion, about why we made that choice and the consequences of this choice.

First let me state some of the requirements.

• Customers ask for interactive exercises having dragndrop, video, audio, images, connecting things, …
• An author need an easy tool to create these exercises and preview them.
• Scenarios can be created that generate all sorts of tests and these tests can be previewed.
• An intelligent player can present these tests to frontend users.
• The application may need to run offline in the future (frontend and backend)
• CD-roms must be made with the content

For the frontend we didn’t have a lot of options two years ago. Silverlight wasn’t even born yet (or maybe just), haven’t read a lot of good things about Java FX although I haven’t tested it myself, Javascript and AJAX do not seem suited for this kind of applicatoin… So Flash seemed the best choice and as of today this is still the best choice. Having an application running in the browser is a big advantage for these kind of applications. The application is loaded once into the browser which increases usability a lot, the different parts of the application can talk easily with each other, communication with the server is easy with remoting technology like WebORB or FluorineFX and interactivity like Drag and Drop, audio, video, … is a pleasure to develop, you don’t need to worry about different browsers, Linux, Mac and Windows supported and creating CD-roms is quite easy with tools like ZINC of Adobe Air. The downside is that all logic lives on the client side. First of all this means that reverse engineering the swf is not hard at all for someone who knows how to do it, even if the swf is encrypted, security needs to get more attention, programming an application is harder than programming pages so you need experienced developers, the Flash Player Plugin needs to be installed (in big companies this is often a big problem because users of a computer do not have rights to install a new plugin. The admin of the company needs to do this and often these admins are not eager to do this…) and few graphical designers have experience with Flex.

Creating the backend with .NET technology would probably be twice as fast. You can easily seperate work without affecting other parts of the project (with an application changing something often affects other parts of the application), there are a lot of .NET developers an few Flex developers, doing it in Flex still needs a server layer (WebORB with Services and some logic),… So why did we choose Flex to create our backend? Well, there are a few arguments that are important enough for this decision:

1. A lot of logic from the player can be reused in the backend, like serializers, deserialers, our framework, …
2. Creating interactive exercises with Flash is a hundred times easer than doing it with Javascript.
3. Showing a preview of the exercise can be done without having to show a popup loading an swf to show the exercise. (as we had to do in our first version).
4. Bringing it offline to Mac, Linux and Windows is a piece of cake with Adobe Air. If you would develop the backend in .NET, bringing it offline to Windows would be possible, but bringing it to Mac and Linux wouldn’t. (Even with Silverlight you would be doing the same as in Flex+ no Linux with Silverlight and not as mature yet as Flex).

It’s true that some parts like reports, access and rights management, creating scenarios, … would be a lot easier with .NET but then you would be mixing technolgy and that wouldn’t look all that nice now would it?

It’s not easy to defend such choices. For small projects backends are usually made with .NET and frontends with Flash if interactivity is needed. As a project like ours gets very big, you need to be thinking about maintenance, design patterns, different customers, budget, resources, … and then Flex doesn’t allways appear ideal… Ok, there’s no problem with different browsers, you have an application feeling in the browser, it’s  supported on Mac, Linux, Windows, but is it worth it? I find it allready difficult to explain the decision on my blog here to developers, imagine explaining it to a customer… Switching to product development in our case would be the best move according to me. The bigger a project comes, the more time it takes to add functionality. And then there’s this worry of me about how big an swf can get before having problems? Our swf is currently about 1meg big. The backend also loads a lot of stuff from the server into the memory (clientside)… Are there limitations?

I have played a little bit with silverlight in the last days and it looks promising. If it would ever get as mature as Flex, then I would certainly switch. A tool like Visual Studio is a treat to work with and having all the logic in one technology would be great. Now we have to port a lot of logic from Flex to .NET to create reports (for instance in Reporting Services), to have exports to paper from tests, …

I do not intend to start a discussion about which technology is better. For me there are customers, budget and demands and trying to meet those demands. All technologies will have their advantages and disadvantages and it’s up to the team to choose the right technology to do the job.

To the future!

Ciao!