Flash-контент в электронном обучении: один SWF против многих? - PullRequest
1 голос
/ 03 апреля 2010

Мы разрабатываем языковые курсы на основе Flash, и я не уверен, какую архитектуру нам выбрать. Контент не будет загружен в Интернет, он будет использоваться только локально.

Возможные архитектуры:

1) Один SWF со всеми данными, хранящимися внутри - это кажется довольно неуклюжим и неэффективным способом (или нет?)

2) Создать интерфейс на основе Flash и сохранить данные, сохраненные в базе данных MySQL. Предположительно, это позволяет лучше организовать контент, избегая повторений. Проблема в том, что учитель языка (который не является ИТ-специалистом) должен будет установить дополнительное программное обеспечение для работы с MySQL.

3) Создать несколько отдельных SWF-файлов и создать простой HTML-файл с индексом.

(и некоторые другие решения, о которых я не думал)

Какая архитектура наиболее подходящая для учителя и наиболее элегантная с точки зрения ИТ?

Ответы [ 2 ]

0 голосов
/ 04 апреля 2010

У вас есть для использования Flash? HTML гораздо более гибок и позволяет встраивать файлы Flash в любое время, когда они вам нужны (например, при взаимодействии или видео). Это то, что я делаю со своими курсами. HTML легче обновлять, не требует специального программного обеспечения и не требует повторной публикации каждый раз, когда вы вносите изменения. Я написал несколько мыслей о Flash против HTML в электронном обучении , если вам интересно.

Если вы идете по маршруту Flash, я предлагаю либо создать один SWF-файл «игрока», который при необходимости загружает дочерние SWF-файлы, либо использовать один SWF-файл с внешними данными (база данных / файлы XML). Если вы можете пойти по пути внешних данных, вам будет намного проще обновлять содержание курса, поскольку вам просто нужно отредактировать базу данных или файл XML и не нужно будет повторно публиковать ваши SWF-файлы. Это сэкономит вам много времени и головной боли, если вам нужно будет предоставить нескольким людям возможность редактировать содержание курса.

Одна очень важная вещь, на которую стоит обратить внимание, это безопасность - если вы обслуживаете свои файлы локально, HTML и Flash будут сталкиваться с ограничениями в песочнице. Например, внешний интерфейс отключен для локальных файлов, если вы не измените настройки безопасности проигрывателя Flash Player. Для курса на основе HTML сценарии xmlhttprequest не будут работать, если они не запускаются с сервера. Это не проблема, если вы планируете использовать сервер в защищенной интрасети.

0 голосов
/ 03 апреля 2010

Для начала я бы проголосовал за разделение интерфейса и данных. Продавайте данные с сервера, как это запрашивает Flash-фильм. Тогда вам не нужно загружать ВСЕ данные (не уверен, что размер ваших данных, но на практике это лучше и масштабируемее).

Что касается другой проблемы, вы можете создать один большой интерфейс Flash или несколько меньших. Преимущество одного интерфейса состоит в том, что он может содержать всю программную логику в одном месте и загружать все встроенные ресурсы только один раз. Это также недостаток, если SWF-файл становится огромным. Нет «правильного способа» сделать это. Вы должны взвесить варианты и решить, что работает лучше для вас. Но у вас также может быть приложение для хоста, которое загружает другие фильмы по мере необходимости. Если у вас есть время и ресурсы, я бы предложил сделать обоснование концепции каждого пути (монолитный или распределенный) и посмотреть, какой путь лучше всего соответствует вашим потребностям.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...