Поскольку среда дистанционного обучения Moodle является довольно популярной, на специализированных форумах регулярно всплывают обсуждения наиболее подходящего серверного окружения.
Moodle базируется на кросс-платформенных технологиях (LAMP), поэтому приложив время, силы и знания, можно заставить Moodle работать где угодно, от Moemo до Windows. В то же время, ни одна из платформ не является «серебрянной пулей».
Moodle — это профессиональный программный продукт Enterprise-уровня. По сложности, его можно сравнить с корпоративной ERP/CRM-системой. Разработчики сделали его дружественным к пользователю и удобным в администрировании настолько, насколько это возможно. И эта внешняя простота провоцирует дилетантский подход к внедрению: кажется, если специалист успешно справляется с установкой MS Office, администрированием сайта на Joomla или эрудирован в IT-технологиях, он без труда за час справится с установкой Moodle, а, затем, сможет вернуться к основным обязанностям.
Приведу 4 распространенных антипаттерна инсталляции Moodle:
Начинающие Windows-администраторы часто выдают за промышленное внедрение установку ознакомительного пакета на базе XAMPP для Windows. Там всё, как привыкли техники, не сталкивающиеся с серьезным серверным администрированием: готовый комплект, графический инсталлятор, работает без правки конфигурационных файлов. При такой установке из виду упускается неработоспособность множества функций, серьезные проблемы с безопасностью и производительностью, а также полная неготовность таких инсталляций и сделавших их специалистов к любым сбоям.
Первые трудности появляются уже при настройке внешнего доступа из интернет, поэтому форумы пестрят вопросами вида «почему у меня открывается ссылка 127.0.0.1/moodle, а у других — нет? Где вписать новый адрес elearning.world-school-of-everything.narod.ru, чтобы заработало?».
Чаще всего такое внедрение заканчивается разочарованием в Moodle, обвинением продукта во всех проблемах, вызванных некомпетентной установкой. Гораздо хуже, если система успеет прижиться до первого серьезного сбоя: организация потеряет не только деньги, вложенные в наполнение системы контентом, но и репутацию. Вся история обучения, выставленные оценки, информация о пройденных учениками заданиях может быть потеряны: убедить преподавателей и учеников повторить эксперимент во-второй раз будет очень непросто. Впрочем, часто достаточно привлечь квалифицированного инженера и он восстановит всю или большую часть потерянной информации.
Справедливости-ради, следует отметить, что начинающие Linux-администраторы, устанавливающие Moodle командой apt-get install moodle или копированием дистрибутива в /var/www системного веб-сервера находятся примерно там же.
Веб-мастера могут сделать обобщение, что раз Moodle написан на PHP и использует SQL-базу данных, то это — обычный CMS-движок, как Joomla, а значит, его можно по FTP закачать на хостинг за 100 рублей в месяц и нажать кнопку «установить» в интерфейсе администратора. Оставим за кадром, что даже CMS-движкам важных сайтов стоит уделить побольше внимания, компетентности и системных ресурсов. Это обобщение аналогично выводу, что рейсовый автобус — это тот же мотороллер, и его тоже можно парковать в сарае, заправлять смесью бензина и масла, эксплуатировать без обслуживания пока не сломается, а потом ремонтировать во-дворе с помощью набора отвёрток и гаечных ключей: технологии похожи, но разный масштаб, сложность системы, нагрузка и уровень ответственности.
Здесь, в лучшем случае, веб-мастер получит «белую страницу» еще на этапе установки — это сработает защита хостинг-провайдера от превышения системных лимитов. Если бы провайдеры за 100 рублей раздавали всем неограниченные ресурсы — они давно бы разорились на железе. Если ресурсов на установку хватит, пользователи «познакомятся» с защитой хостера чуть-позже: когда начнут наполнять систему материалами, возрастёт нагрузка или начнут использоваться специфичные функции, такие как импорт/экспорт курсов.
Большинство провайдеров стараются по-умолчанию установить побольше библиотек и возможностей, но для полноценного функционирования Moodle их всё-равно не хватает. Помимо медленной и нестабильной работы СДО, могут возникнуть проблемы с исполнением фоновых задач, рассылкой уведомлений, синхронизациями, сетевым взаимодействием, импортом/экспортом, проверкой текстов на орфографию, проверкой вложений на вирусы, работой с формулами, отображением «тяжелого» контента и ряд других трудностей.
Эрудиты — это самый трудный случай. Из них иногда получаются очень хорошие профессионалы, но для этого нужно много времени, терпения и, часто, несколько загубленных проектов и критических сбоев с потерей всего контента. На обсуждаемом этапе они вдохновенно убеждают руководство в целесообразности развёртывания системы на FreeBSD/Mac OSX Server/блейд-сервере/MS SQLServer/чём-угодно-еще и требуют этого от подрядчика, умело оперируя профессиональной терминологией и цитируя авторитетов. Практические же их навыки часто ограничиваются умением заказать виртуальную машину с предустановленной FreeBSD, а бьющий кодировку страниц веб-сервер или иерогливы, вместо дней недели объясняются дефектами самой Moodle, а не неумением эрудита настроить локаль под FreeBSD.
Отличить «эрудита» от эксперта очень просто: у эксперта есть больше трёх успешных внедрений на рекомендованной им технологии, больше двух полностью выполненных внедрения на других технологиях и он уже собрал и протестировал прототип инсталляции Moodle с рекомендованной им технологией.
Всё перечисленное справедливо не только для Moodle, но и для любой другой СДО, ERP/CRM-системы или профессионального интернет-магазина (Magento etc.). Не может быть «простой и лёгкой СДО» потому что сама предметная область сложна и многообразна. Лёгкая СДО в этом смысле похожа на ловушку с широким входом и узким выходом: очень скоро, любой организации станет в ней тесно и некомфортно. Смена уже внедрённого решения во много раз сложнее первоначального внедрения.
Впрочем, есть одно исключение: преподаватели-энтузиасты, внедряющие электронное обучение на общественных началах могут смело игнорировать все мои рекомендации, потому что любая работа, сделанная бесплатно и по собственной инициативе — хороша и достойна уважения. А вот руководители, принимая такой проект в качестве пилота для внедрения, должны поблагодарить и наградить создателя, а затем поручить специалистам переделать техническое решение по всем правилам.
Наша команда выбрала для себя Ubuntu Linux Server, как стабильную, легко и регулярно обновляемую и удобную в администрировании систему. Её бесплатность является немаловажным фактором, так как влияет на общую стоимость внедрения.
Очень важна присущая всем юникс-системам возможность выполнить любые работы из консоли, в том числе удаленно, по ssh, даже на медленном соединении. О небезопасности этой функции говорят только неопытные администраторы, для которых настройка полномочий, ssh-доступов, Firewall и автоблокировки по подозрительной активности в логах сродни магии.
Для нас оказалась очень полезна возможность автоматизации операций написанием скриптов и созданием deb-пакетов. Доступность в Linux бесплатных, но профессиональных инструментов мониторинга, резервного копирования и массового администрирования, систем виртуализации делает эту платформу особенно привлекательной.
Из всех операционных систем и дистрибутивов, которые я видел, Ubuntu Linux Server обладает наибольшей готовностью к развёртываю Moodle, хотя и там требуется установить и настроить десятки дополнительных пакетов. Но применение типовой платфомы позволяет всё это легко автоматизировать. А проблему недостатка на рынке специалистов, свободно ориентирующихся в Linux мы решаем очень просто: Ubuntu Linux является стандартом для всех рабочих мест наших технических специалистов. Любой разработчик, стажер или инженер техподдержки, даже если он не связан с администрированием серверов, невольно привыкает к платформе и тестирует все разработки сразу в том же окружении, что и на сервере.
У других команд специалистов вполне может быть другой опыт: масса успешных проектов на Window, FreeBSD или Max OS X Server. Даже сборщики шкафов и сантехники приносят с собой набор привычных и удобных им инструментов. Поэтому, закончить хочу пословицей: «В умелых руках и палка стреляет». И ни одна платформа не подходит для промышленного внедрения, если специалист делает это впервые.
Moodle базируется на кросс-платформенных технологиях (LAMP), поэтому приложив время, силы и знания, можно заставить Moodle работать где угодно, от Moemo до Windows. В то же время, ни одна из платформ не является «серебрянной пулей».
Moodle — это профессиональный программный продукт Enterprise-уровня. По сложности, его можно сравнить с корпоративной ERP/CRM-системой. Разработчики сделали его дружественным к пользователю и удобным в администрировании настолько, насколько это возможно. И эта внешняя простота провоцирует дилетантский подход к внедрению: кажется, если специалист успешно справляется с установкой MS Office, администрированием сайта на Joomla или эрудирован в IT-технологиях, он без труда за час справится с установкой Moodle, а, затем, сможет вернуться к основным обязанностям.
Приведу 4 распространенных антипаттерна инсталляции Moodle:
Начинающие Windows-администраторы часто выдают за промышленное внедрение установку ознакомительного пакета на базе XAMPP для Windows. Там всё, как привыкли техники, не сталкивающиеся с серьезным серверным администрированием: готовый комплект, графический инсталлятор, работает без правки конфигурационных файлов. При такой установке из виду упускается неработоспособность множества функций, серьезные проблемы с безопасностью и производительностью, а также полная неготовность таких инсталляций и сделавших их специалистов к любым сбоям.
Первые трудности появляются уже при настройке внешнего доступа из интернет, поэтому форумы пестрят вопросами вида «почему у меня открывается ссылка 127.0.0.1/moodle, а у других — нет? Где вписать новый адрес elearning.world-school-of-everything.narod.ru, чтобы заработало?».
Чаще всего такое внедрение заканчивается разочарованием в Moodle, обвинением продукта во всех проблемах, вызванных некомпетентной установкой. Гораздо хуже, если система успеет прижиться до первого серьезного сбоя: организация потеряет не только деньги, вложенные в наполнение системы контентом, но и репутацию. Вся история обучения, выставленные оценки, информация о пройденных учениками заданиях может быть потеряны: убедить преподавателей и учеников повторить эксперимент во-второй раз будет очень непросто. Впрочем, часто достаточно привлечь квалифицированного инженера и он восстановит всю или большую часть потерянной информации.
Справедливости-ради, следует отметить, что начинающие Linux-администраторы, устанавливающие Moodle командой apt-get install moodle или копированием дистрибутива в /var/www системного веб-сервера находятся примерно там же.
Веб-мастера могут сделать обобщение, что раз Moodle написан на PHP и использует SQL-базу данных, то это — обычный CMS-движок, как Joomla, а значит, его можно по FTP закачать на хостинг за 100 рублей в месяц и нажать кнопку «установить» в интерфейсе администратора. Оставим за кадром, что даже CMS-движкам важных сайтов стоит уделить побольше внимания, компетентности и системных ресурсов. Это обобщение аналогично выводу, что рейсовый автобус — это тот же мотороллер, и его тоже можно парковать в сарае, заправлять смесью бензина и масла, эксплуатировать без обслуживания пока не сломается, а потом ремонтировать во-дворе с помощью набора отвёрток и гаечных ключей: технологии похожи, но разный масштаб, сложность системы, нагрузка и уровень ответственности.
Здесь, в лучшем случае, веб-мастер получит «белую страницу» еще на этапе установки — это сработает защита хостинг-провайдера от превышения системных лимитов. Если бы провайдеры за 100 рублей раздавали всем неограниченные ресурсы — они давно бы разорились на железе. Если ресурсов на установку хватит, пользователи «познакомятся» с защитой хостера чуть-позже: когда начнут наполнять систему материалами, возрастёт нагрузка или начнут использоваться специфичные функции, такие как импорт/экспорт курсов.
Большинство провайдеров стараются по-умолчанию установить побольше библиотек и возможностей, но для полноценного функционирования Moodle их всё-равно не хватает. Помимо медленной и нестабильной работы СДО, могут возникнуть проблемы с исполнением фоновых задач, рассылкой уведомлений, синхронизациями, сетевым взаимодействием, импортом/экспортом, проверкой текстов на орфографию, проверкой вложений на вирусы, работой с формулами, отображением «тяжелого» контента и ряд других трудностей.
Эрудиты — это самый трудный случай. Из них иногда получаются очень хорошие профессионалы, но для этого нужно много времени, терпения и, часто, несколько загубленных проектов и критических сбоев с потерей всего контента. На обсуждаемом этапе они вдохновенно убеждают руководство в целесообразности развёртывания системы на FreeBSD/Mac OSX Server/блейд-сервере/MS SQLServer/чём-угодно-еще и требуют этого от подрядчика, умело оперируя профессиональной терминологией и цитируя авторитетов. Практические же их навыки часто ограничиваются умением заказать виртуальную машину с предустановленной FreeBSD, а бьющий кодировку страниц веб-сервер или иерогливы, вместо дней недели объясняются дефектами самой Moodle, а не неумением эрудита настроить локаль под FreeBSD.
Отличить «эрудита» от эксперта очень просто: у эксперта есть больше трёх успешных внедрений на рекомендованной им технологии, больше двух полностью выполненных внедрения на других технологиях и он уже собрал и протестировал прототип инсталляции Moodle с рекомендованной им технологией.
Всё перечисленное справедливо не только для Moodle, но и для любой другой СДО, ERP/CRM-системы или профессионального интернет-магазина (Magento etc.). Не может быть «простой и лёгкой СДО» потому что сама предметная область сложна и многообразна. Лёгкая СДО в этом смысле похожа на ловушку с широким входом и узким выходом: очень скоро, любой организации станет в ней тесно и некомфортно. Смена уже внедрённого решения во много раз сложнее первоначального внедрения.
Впрочем, есть одно исключение: преподаватели-энтузиасты, внедряющие электронное обучение на общественных началах могут смело игнорировать все мои рекомендации, потому что любая работа, сделанная бесплатно и по собственной инициативе — хороша и достойна уважения. А вот руководители, принимая такой проект в качестве пилота для внедрения, должны поблагодарить и наградить создателя, а затем поручить специалистам переделать техническое решение по всем правилам.
Наша команда выбрала для себя Ubuntu Linux Server, как стабильную, легко и регулярно обновляемую и удобную в администрировании систему. Её бесплатность является немаловажным фактором, так как влияет на общую стоимость внедрения.
Очень важна присущая всем юникс-системам возможность выполнить любые работы из консоли, в том числе удаленно, по ssh, даже на медленном соединении. О небезопасности этой функции говорят только неопытные администраторы, для которых настройка полномочий, ssh-доступов, Firewall и автоблокировки по подозрительной активности в логах сродни магии.
Для нас оказалась очень полезна возможность автоматизации операций написанием скриптов и созданием deb-пакетов. Доступность в Linux бесплатных, но профессиональных инструментов мониторинга, резервного копирования и массового администрирования, систем виртуализации делает эту платформу особенно привлекательной.
Из всех операционных систем и дистрибутивов, которые я видел, Ubuntu Linux Server обладает наибольшей готовностью к развёртываю Moodle, хотя и там требуется установить и настроить десятки дополнительных пакетов. Но применение типовой платфомы позволяет всё это легко автоматизировать. А проблему недостатка на рынке специалистов, свободно ориентирующихся в Linux мы решаем очень просто: Ubuntu Linux является стандартом для всех рабочих мест наших технических специалистов. Любой разработчик, стажер или инженер техподдержки, даже если он не связан с администрированием серверов, невольно привыкает к платформе и тестирует все разработки сразу в том же окружении, что и на сервере.
У других команд специалистов вполне может быть другой опыт: масса успешных проектов на Window, FreeBSD или Max OS X Server. Даже сборщики шкафов и сантехники приносят с собой набор привычных и удобных им инструментов. Поэтому, закончить хочу пословицей: «В умелых руках и палка стреляет». И ни одна платформа не подходит для промышленного внедрения, если специалист делает это впервые.
shtorman
Данные 4 антипаттерна, как вы сами и утверждаете, с легкостью применяются ко всему подряд. Тогда почему в заголовке именно Moodle? Что в нем особенного применительно к антипаттернам или что особенного в них применительно к moodle?
а как же:
Выбор серверного окружения или как не нужно ставить OCS Inventory
… или как не нужно ставить Ubuntu Linux Server
Утверждение, что «Ubuntu Linux Server обладает наибольшей готовностью к развёртываю Moodle,» — в корне не верно. Любая серверная ОС должна пройти преднастройку (безопасность, оптимизация и т.п.), а после и решение в целом необходимо проверить. А выставить Ubuntu Server в продакшн потому, что он «обладает наибольшей готовностью» — это заблуждение «начинающих Windows-администраторов».
Хм… «Наша компанда ...»
alexdjachenko
shtorman,
мы сравнивали объем преднастроек для установки Moodle и способы их автоматизации для разных платформ и пришли к такому результату. Как я писал в статье, первична проработанность настроек площадки и соответствие их требованиям системы, а не какая-то конкретная платформа. Об этом и статья.
Я пишу именно про СДО Moodle, потому что занимаюсь именно этим продуктом и вижу, как распространен дилетанский подход именно в этой сфере и как это негативно влияет на репутацию продукта.
Когда ВУЗ покупает ризограф за миллион рублей, никому не приходит в голову поручить подключение электрику. Когда автоматизируют бухгалтерию в крупном ВУЗе — никто не вызывается с предложением «я почитаю про 1С, разберусь и всё Вам поставлю». Но с дистанционным обучением этот подход очень распространён: бесплатность продукта создаёт видимость простоты и малозначительности задачи.
shtorman
alexdjachenko,
вы сравнивали, но дали только факты без анализа и информации по сравнению (условия, необходимые действия, подводные камни). Однако тема такого сравнения очень интересна и сложна (т.е. не сама установка, а какие подводные камни могут возникнуть в ходе нее, какие плюсы и минусы это даст), и вот она точно была бы полезна.
Я обратил внимание на наличие двух статей о moodle в Вашем профиле, но эта статья, на мой взгляд, не удалась.
Название не совпадает с содержанием, я ожидал увидеть как раз именно то о чем Вы написали в комментарии «сравнивали объем преднастроек для установки Moodle и способы их автоматизации для разных платформ». Может в следующей статье?
О последнем вы правы, но не до конца: если складывается такая ситуация, то скорее всего суть проблемы в следующем:
— руководство не видит ВЫГОДЫ от внедрения СДО (низкая информатизация, нет мотивации развития),
— развитие ИТ-отдела (персонала) ниже среднего, т.к. не могут обеспечить работу/оценку внедрения важного, с точки зрения профиля организации, ИТ-сервиса.
К слову, у себя мы тоже сделали ставку на moodle, но пока не взлетело по следующим причинам:
1. Низкая заинтересованность преподавателей и руководства в функционале системы (за год было 8-9 обращений, столько же курсов и тестов по ним, 6 групп по ~20 чел).
2. Не возможность бесперебойной работы самого сервиса (есть некоторые проблемы с инфраструктурой).
3. Поздно решен вопрос автоматизации ввода тестов в систему, организационные моменты по регистрации.
4. Слабое освещение функционала и возможностей самой системы отделом ИТ для преподавателей (диктуется 2ым пунктом).
5. Не привлекательный внешний вид (тоже важный пункт для вовлечения).
Moodle -была моя инициатива, на совещании поддержали преподаватели, по факту — то, что имеем. Сопровождением системы (создание тестов, регистрация пользователей) у нас занимается студент-техник (с администрированием помогает системный администратор, с методической работой — я).
Сам не считаю это (то, что не взлетело) минусом — просто затянувшийся боевой тест системы — откатали некоторые практические вещи, получили опыт малой кровью. Продолжать будем.
alexdjachenko
Я опубликовал свою статью на Мегамозге, а не на Хабре именно потому, что концентрировался не на технических деталях, а на организационных моментах. Статья ориентирована, скорее, не на исполнителя, а на его руководителя или внутреннего заказчика.
Иван, а кто был инициатором внедрения?
Описанная ситуация похожа на то, что это почти личная инициатива рядового сотрудника технического отдела. На которую не выделили ресурсов. Что-то вроде пилотного проекта.
При полноценном внедрении, в ВУЗе выбирают модель применения СДО: для дистанционного обучения, для поддержки очного обучения, для тестирования, для курсов повышения квалификации и т.п. Мотивы здесь разные, например, во ВГОСах 3-его поколения наличие СДО прописано в обязательном порядке.
Обычно, принципиальное решение принимается на уровне проректора, дальше принимается на ученом совете. На основании решения ученого совета принимается положение о дистанционном обучении, где четко прописано, в каких случаях и какие преподаватели что обязаны выкладывать в СДО, кто за это отвечает и что ему будет, если этого не произойдет.
Это автоматом решает все перечисленные Вами пункты.
Внешний вид — это компетенция технического отдела, это решается легко, быстро, но не бесплатно, поскольку профессиональные шаблоны либо стоят денег, либо их нужно делать на заказ: тратить несколько месяцев на освоение структуры стилей и формата шаблонов Moodle ради одного шаблона нецелесообразно.
shtorman
Нашел вас на moodle.org, вы в некотором роде профессионал по moodle и смежных темах, чего я не смог бы сказать о вас прочитав данную статью…
На «организационных моментах» соглашусь, но получилось весьма сумбурно (как буд-то это крик души!). И здесь может слегка перефразировать тему (дополнив по мотивам комментариев): Выбор исполнителя внедрения или как не нужно внедрять Moodle!
Вы правы, как я упомянул выше — инициатива моя — как преподавателя. По поводу ресурсов — вычислительные ресурсы выделили, и трудовые на уровне отдела ИТ- студент-техник. Исходя из перечисленного вами, наша модель — «для поддержки очного обучения, для тестирования».
Полноценного внедрения мы не провели. Как я упомянул выше — это больше похоже на пилотный проект. До этого у нас не было подобного опыта, внедрять серьезно в данный момент — опасно, слишком часты проблемы с инфраструктурой (статья в моем профиле на хабре, о ОУ). Но решая текущие проблемы, хотелось попробовать, на будущее заложить основание так сказать. Пощупали, посмотрели, сделали выводы.
То что касается внедрения — абсолютно с вами согласен, стороннее внедрение — дорогая штука. Сами с нуля и «в карьер» не осилим, поэтому начали постепенно.
Поправочка — ФГОС'ы 3-его поколения… не сыпьте соль на рану…
zv347
Используем «Мудл» в университете для тестирования (для СДО тоже, но там у меня еще нет опыта и впечатлений). Мое личное впечатление как пользователя и модератора — система переусложненная и глючная. Я вполне понял мысль автора про прямоту рук админов и отнюдь не склонен их переоценивать, но, уверен, дело тут не [только] в этом — аналогичные программы, написанные нашими программистами, оставляют намного лучшее впечатление. Скорее всего, скоро от него откажемся.
Вообще же посыл статьи напомнил историю с антеннами четвертого айфона — «вы неправильно его
ставитедержите».alexdjachenko
zv347, сложно что-то противопоставить «личному впечатлению» :) Но если Вы перечислите факты и параметры, которые Вам мешают, я постараюсь дать Вам рекомендации.
zv347
Спасибо, но я-то вряд ли что-то сделаю, я же просто пользователь. Из того, что помню — регистрируем студентов на тест, генерируются логины и пароли. На следующий день при входе у части студентов логин-пароль не подходит (или записанность на тест слетает), приходится перерегистрировать. Что касается переусложненности… опять же, в середине августа уже плохо помню, что там и как, но помню, что в «админ-панели» модератора есть кнопки с одинаковыми (или схожими до степени смешения) названиями, приводящие, тем не менее, к разным результатам. Что-то вроде «Режим редактирования» / «Редактирование» / «Администрирование — Редактирование». Стыдно, конечно, но я почти всегда долго тыкаюсь, хожу вперед-назад, пока найду, куда вбить тест или откуда вывести результаты.
shtorman
То, что вы описали, как правило, лечиться двумя шагами:
1. Методические рекомендации преподавателям и студентам (инструкции), там же на сайте без паролей.
2. Подбор и установка привлекательного и удобного шаблона.
Второй пункт мы в свое время упустили…
То, что «На следующий день при входе у части студентов логин-пароль не подходит (или записанность на тест слетает)» — это, imho, либо человеческий фактор (того, кто вносит эту информацию), либо проблемы с сетевой инфраструктурой (возможно с клиентским рабочим местом)- т.к. у нас, в этом плане -все «как часы». Не может продукт с такой областью охвата иметь такие плавающие функциональные ошибки (тут работает, тут не работает).
Но в целом alexdjachenko прав, без фактов сложно о чем-то говорить.
alexdjachenko
То что Вы описываете — классический пример недостаточного внимания к проекту со стороны вашей организации:
1. Прежде-всего, еще до начала работы, следовало проработать жизненный цикл пользователей (регистрация, подписка на курсы, смена подписок, завершение обучения и удаление). В системе есть механизмы интеграции — если в вашем ВУЗе есть уже портал студентов или любая база данных с перечнем, система может брать данные напрямую оттуда. Есть импорт студентов по спискам либо интеграция с социальными сетями (Яндекс, вКонтакте, Гугл). Есть интеграция с Майкрософтовским Office 365. Есть Электронный Деканат Всё это помогло бы избежать названных Вами ошибок ручного ввода. И уменьшить трудоемкость.
2. Никто не озаботился обучением пользователей, чтобы они не путали Режим редактирования (переход в режим контруктора курса), переход на страницу редактирования настроек курсов, и блок настроек конкретного элемента курса (страница, задание, тест), который отображается только когда Вы внутри данного элемента.
3. А меню «Администрирование» при придуманной пользовательской политике и проработанных настройках ролей вообще не должно отображаться «просто пользователю».
Именно то, о чем я и писал в статье: администратор скачал и поставил на сервер систему. Ничего не настраивал, не разрабатывали бизнес-процессы, регламенты и пользовательские регламенты. И всё это назвали «внедрение СДО», а результат списали на, якобы, недостатки системы.