Flash content in eLearning: one SWF vs. many?

Question

We are designing a Flash-based language course, and I am not sure which architecture we have to choose. The content won't be uploaded to the Internet, it will be used only locally.

Possible architectures:

1) A single SWF with all the data stored internally - it seems a rather clumsy and inefficient way (or it's not?).

2) To make a Flash-based interface, and to keep the data saved in a MySQL database. It presumably allows to organize the content better, avoiding self-repetitions. The problem is that the language teacher (who is not an IT specialist) will have to install additional software to handle MySQL.

3) To make a number of separate SWF files, and to make a simple HTML-file with the index.

(and some other solutions I didn't think of)

Which is the right architecture, most usable for the teacher and most elegant from the IT point of view?

Answer 1

For starters, I would vote for separating interface and data. Vend the data from the server as the Flash movie requests it. Then you don't have to load up ALL the data (not sure the size of your data, but in practice this is best and most scalable).

As for the other issue, you can create one large Flash interface or several smaller ones. The advantage of the one-interface is that it can have all the program logic in one place and only has to load all the embedded assets once. That is also the drawback, if the SWF file gets to be huge. There is no "right way" to do this. You have to weigh the options and decide which works best for you. But you can also have a "host" application that loads other movies as needed as well. If you have the time and resources, I would suggest making a proof of concept of each way (monolithic vs. distributed) and see which way will fit your needs best.

Answer 2

Do you have to use Flash? HTML is much more flexible and allows you to embed Flash files whenever you need them (such as interactions or videos). This is what I do with my courses. HTML is easier to update, doesn't require any special software, and doesn't require republishing each time you make an edit. I've written some thoughts about Flash versus HTML in e-learning if you're interested.

If you go the Flash route, I suggest either creating one 'player' SWF that loads child SWFs as needed, or use a single SWF with externalized data (database/XML files). If you can go the externalized data route, you should have a much easier time updating your course's content, because you just need to edit the database or an XML file and won't need to republish your SWF(s). This will save you a lot of time and headaches if you need to provide multiple people the ability to edit a course's content.

One really big thing to watch out for is security -- if you're serving your files locally, both HTML and Flash will run into sandboxing constraints. For instance, External Interface is disabled for local files unless you change your Flash Player security settings. For an HTML-based course, xmlhttprequest scripts will fail unless run from a server. This is not a problem if you plan to use a server on a protected intranet.