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?
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.