Автор: Андрей Матюков
Если в вашей команде разработчиков электронных курсов есть разделение на методологов и верстальщиков, и не всегда между ними идеальное взаимопонимание, то не лишним будет почитать нижеприведенный текст.
Рассмотрим ситуацию, при которой методолог (он же сценарист) отвечает за создание подробного сценария, подготовку скринов (если курс имеет элементы симуляции ПО), а верстальщик, получив всё сырье и точный рецепт, «просто» должен сварить вкусное и красивое блюдо, т.е. собрать курс без лишних вопросов. Каждый должен заниматься своим делом притом, что у первого времени на свою часть работы втрое больше чем у второго.
1. Хотя бы раз вслух прочитай весь текст, который верстальщик будет «копипастить». (методологу)
Обе стороны зачастую не являются преподавателями русского языка и литературы. Разговор даже не про запятые, которые в идеале, наверно, очень малая доля людей знает, где ставить. Кроме элементарных опечаток и пропусков слов, часто фразу вообще невозможно по-русски прочитать. Изменив одно слово, в русском языке «покоробятся» все последующие окончания в предложении. А у верстальщика на исправления нет времени, у него другая задача – всё красиво расположить и заставить правильно работать. Однако, если огрехи в тексте пропустить, то редактировать курс опять же придется ему.
2. Поставь себя на место слушателя, сможет ли он по твоему сценарию интуитивно пройти весь курс от начала до конца. (методологу)
Не редки случаи, когда в различных симуляторах ПО в сценарии явно не указаны некоторые переходные моменты, без которых от одного состояния к другому не перейти. Как должна восприниматься верстальщиком фраза типа «Затем откроется такое-то окно» или что-то подобное? При четком разделении труда лучше все переходы и подсказки конкретно прописывать, чтобы и верстальщик смог реализовать задуманное, и слушатель потом не стал «тыкать» по всему экрану.
3. Избегай избыточной навигации - зачем имитировать имитацию? (методологу)
В случае с пресловутыми симуляторами ПО не всегда надо нажимать некую «Далее», чтобы перейти от одного состояния программы к другому. Иногда лучше сразу сымитировать некоторое ПО с пояснением, чем рассказывать об этой кнопке, а переходить не по ней.
4. Отвечаешь за скрины, делай их максимально пригодными для использования. (методологу)
4.1 Делай скрины по определенному блоку работы программы за один раз.
Если специализированное ПО имеет множество различных значений, подгружаемых из БД, а также дату и время, то старайтесь все скрины сделать за один подход. Иначе случается, что при рассказе о какой-то функции вдруг нелогично меняются текстовые значения или дата, которые могут сбивать с толку слушателя.
4.2 При создании скринов лучше исключить различные эффекты окон Windows.
Полупрозрачное оформление «шапок» окон отвлекают при объяснении работы программы в случае с наложением одних окон на другие. Различные закругленные углы лучше тоже избегать. Классическое оформление ОС вам в помощь, если, конечно, в курсе не объясняется дизайн «винды».
4.3 Называй рисунки латиницей - никакой Кириллицы и спецсимволов.
Тот же КурсЛаб, в частности, не видит файлы, названные иначе. Да и в принципе, это можно сказать, хороший тон – имена без русских букв, символов, да и пробелов. Чаще всего при верстке все равно приходится подрезать скрины из-за ограниченности размеров слайда, но те картинки, которые вставляются без редактирования, приходится потом еще и переименовывать.
4.4 Не искажай качество и не редактируй
Главное в этой ситуации не исказить виртуальную реальность. Симулятор ПО должен быть максимально похож на саму описываемую программу. Никаких размытостей и уменьшений не должно быть. Верстальщик сам, где нужно, сделает выкадровку, добавит эффекты. Главное, чтобы «исходник» был идеальный. Что касается отдельных окон, то их снимать надо через Alt+PrintScreen, ничего вручную не обрезая.
5. Советуйся, если верстальщик известен заранее. (методологу)
Замечательно, когда технические тонкости реализации какого-нибудь интерактива можно обсудить в процессе разработки подробного сценария. Можно также посоветоваться с другими верстальщиками, как лучше реализовать задуманное, чтобы не проектировать небылиц.
6. Лучше меньше, да лучше. (методологу)
Порой очень сложно переубедить методолога, что излишний объем материала можно безболезненно разбить на модули без потери качества подачи информации. «Что он там этот верстальщик понимает в сценариях-то?». Но совсем не хорошая история получается, когда так или иначе позднее, осознав, или по совету высшей инстанции, получается, что разбивать курс все же рациональнее. «А я о чем говорил? - напрашивается в ответ». Более короткие модули и усваиваются слушателем лучше, и разрабатывать их проще, да и отчитываться по ним. А если курс делится на несколько отдельных курсов, то и общий размер SCORM-пакета уменьшается, и курс загружается через СДО быстрее.
7. Критикуя, предлагай. (верстальщику)
Если уверен, что можешь реализовать лучше сценария, то посоветуйся сначала с его создателем. Может, никому и не нужно лучше, а сойдет и так? Оформишь вместо кадров слои, что-то объединишь или разделишь, а в итоге получится, что двойную работу сделаешь, когда любой уход в сторону с прописанного пути исключен.
8. Улови систематичность ошибок. (методологу)
Эта рекомендация в принципе касается обеих сторон, но в данном случае говорится о тех проблемах, которые описаны выше. Ситуации обговариваются, проблемы решаются, но с течением времени вновь повторяются. Фиксируйте эти грабли, чтобы в будущем не наступать на них.
9. Не бери грех на душу. (верстальщику)
Будь щепетилен при ознакомлении со сценарием, меньше будешь переделывать за другими в процессе версток. Вспомни, о чем говорили в пунктах с 1 по 9 и если что-то обнаружил из этого, заверни сценарий и верни создателю.
Лучшая команда - это методолог и верстальщик в одном лице, но так бывает далеко не всегда. Мира и взаимопонимания командам!
Комментариев нет:
Отправить комментарий