Технологии в обучении

По мотивам данного видеоролика. Потому что его нет в рунете, и содержимое по-своему интересно.

Краткое содержание

Приблизительно следующее.

Томас Эдисон в 1922-м году предсказывал, что в будущем в обучении все книги вытяснят кинофильмы. В 1930-х предметом для революции в обучении является радио, когда один эксперт-учитель может учить много учеников одновременно. История повторилась позже с телевидением в 1950-60-х. В 1980-х никто не сомневался, что компьютеры произведут революцию в обучении и решат кучу проблем, так как они медиа, интерактивные, и могут быть любыми, какими их запрограммируешь. Даже в 1990-х многие утверждали, что CD-диски вытяснят все виды обучения (и где они?). В настоящее время многие говорят о том, что именно они произведут революцию - умные доски, планшеты, смартфоны, массовые online-курсы.

За последние 100 лет многое протерпело революцию. Но не образование.

Авторы ролика высказывают свое мнение, что у технологий не получается потому, что они не ориентированы на предмет образования как такового. Т.е. необходимо рассматривать процесс обучения (как мы работаем с информацией), а не технологии (средства представления). В поддержку этого факта имеются результаты исследований того, как эффективно работает обучение в зависимости от источника (книга, видео, интерактивное, …), и они показывают, что нет никакой существенной разницы.

В обоснование почему так происходит авторы говорят о том, что: присутствие видео не дает полноценно включиться воображению и нарисовать происходящее, также оно не заставляет инвестировать достаточно усилий для запоминания и усвоения. И иногда статические картинки работают лучше, чем анимация. И соответственно вывод о том, что важно концентрироваться на том, что происходит в голове обучающегося.

Т.е. требуется не разрабатывать новые технологии, а приспосабливать имеющиеся способы для лучшего достижения эффекта. Или, другими словами, какой перенесенный опыт человеком приводит к тому, что он обучается.

В качестве примера некоторые результаты исследований. Картинки/видео+текст работают лучше, чем просто текст. Кроме того, все отвлекающее должно быть ликвидировано. Например, сопровождающийся текст и те же слова конкурируют друг с другом, и это затрудняет понимание, и поэтому лучше оставить что-то одно.

Какие выводы делают авторы? Задачей учителя является не вдолбить информацию и потом проверить. Задачей является вдохновить, дать вызов, предоставить информацию в лучшем для понимания виде, заставить почувствовать и заволноваться, сделать ответственным за свои знания, заставить почувствовать что это важно и их работа важна. Да, учителям приходится читать лекции и принимать экзамены. Но более фундаментальным вопросом является другое.

И окончательный вывод у авторов (для меня странный) — Youtube сделает революцию в образовании. Хотя может неудивительно, т.к. авторы зарабатывают на нем.

Обсуждение

Обучение и образование относятся не только к официальным институтам (государственным, например школа) и другим неофициальным (например, семья). Их инструментарий и особенности имеют непосредственное отношение практически к любой передаче информации — будь то презентация чего-то нового, оформление документации, самоорганизация по усвоению нового, статья, и др.

Нельзя с уверенностью в общем случае сказать, что лучше, — использовать доску с мелом или компьютер, писать программы в блокноте или IDE, рисовать красивые диаграммы или сделать таблицу, просмотреть фильм или прочитать книжку, … Но с уверенностью можно сказать о других вещах — не рекомендуется на слайдах делать много букв ради того, чтобы их прочитали, картинки с примерами лучше чем просто текст, новая платформа по умолчанию не дает преимуществ (какая она бы не была современная), если бросаете вызов, то он должен быть преодолим …

А при взаимодействии с материалом не важно как он выражается, а важно как он организован, представлен и удобен для человека. Лучше выбирать для каждой задачи удобный инструмент, позволяющий как выражать, так и воспринимать свои и чужие мысли.

Удобны ли ваши API?

Написанное здесь обусловлено тем, что в последние год-два приходилось сталкиваться наверное раз пять с различными проявлениями в отношении пользователей к API и документации в целом. В данном сообщении в основном все базируется на одноименной статье Стивена Кларка, имеющейся в книге «Идеальная разработка ПО», и в е-виде содержимое на находится. Стивен провел более 10 лет работая над совершенствованием API в Microsoft'е, с 1998-го года, с такими инструментами, как Visual Studio.

Удобство API

Сплошь и рядом попадается ситуация, когда проектирование библиотек, API и т.п. происходит как есть, для себя, по каким-то высшим или подсознательным катеогриям, но без какого-либо обращения внимания на пользователей, их разнообразие и решаемые ими задачи. Так получается, что потери reengineering'a с той стороны либо совершенно не волнуют, либо списываются на глупость или неусидчивость пользователей, и более того, идут аргументы вида «а вы используете неправильно, не ходите туда и не делайте так, делайте как мы».

Цитата С. Кларка:

Меня как разработчика, который пользовался Visual Studio до присоединения к группе Visual Studio, используемые инструменты часто раздражали. Параметры компилятора было трудно найти и задать. Настройка путей к библиотекам выглядела громоздкой и неудобной. У продукта было много недостатков из области удобства использования, которые я хотел исправить при поступлении на работу в Microsoft.

Я не хочу сказать, что у меня не было трудностей с API фирмы Microsoft. Напротив, чуть ли не самые серьезные проблемы, с которыми я когда-либо сталкивался, были связаны с пониманием API библиотек MFC. Но в отличие от ситуации с инструментами, в том, что мне не удается разобраться в правильном использовании VFC, я винил только себя. Ни разу я не подумал, что проблема крылась в проектировании API.

Такая реакция на плохо спроктированные API встречается очень часто. Многие разработчики объясняют возникающие трудности своей неопытностью в обращении с API. Будь у них побольше времени, то они бы во всем разобрались. Я много раз слышал, как разработчики говорят, что им просто не хватает ума для освоения API.

Таким образом, документация и API могут быть неудобными и плохо спроектированными. Если на это не обращать внимания, то именно так и произойдет, а при более внимательном рассмотрении можно даже понять почему.

Работа с API не представляет собой работу со всем API целиком

В повседневной работе лишь немногие работают сразу со всем API. Как правило, интересы ограничиваются только той задачей, которую пытаются решить. То есть, необходимо сосредотачиваться на том, для чего предназначены API, а не на том, что оно собой представляет.

Вторым моментом является то, что все API редко кто понимает или даже пытается понять, так как это большой объем информации. Используется какой-то участок фронта для какой-то задачи в течение какого-то времени. И все. Но с другой стороны баррикад почему-то считается правильным заставлять других учить авторские предрассудки и геометрию граблей архитектуры. Зато удобно и есть кого обвинить.

Аналогичную ситуацию наблюдаю с документацией. Вместо решения конкретных задач и ориентации на пользователя пишется большой талмуд обо всем, а на все вопросы идет ответ — идите читайте нашу прозу и медитируйте над тем, что мы тут натворили. Это как если бы вы пришли на почту с вопросом, когда приходит почтальон, а в ответ вам нужно было бы изучить архитектуру того, как работает организация, кто за что отвечает, откуда берет план и график обхода с точной траекторией.

Таким образом, в редких случаях идет работа пользователя целиком со всем, что есть. А для пользователя есть задачи, которые ему нужно решать. И в круг этих задач не входит постижение некого дао.

Разные пользователи

Одним из результатов исследований было то, что пользователи разные, в том плане что они по разному работают с API и её документацией. И вписаться сразу в каждый мир и угодить всем мягко говоря, сложно.

Три типа пользователей из статьи:

Коньюктурщики (оппортунисты)

Для этой категории характерна привычка к быстрому экспериментированию, задачно-ориентированный подход и широкое использование высокоуровневых конкретных компонентов.

Прагматики

Деятельность разработчиков этой категории ориентиирована на программный код. Они пользуются инструментами, которые способствуют улучшению правильности и надежности написаного кода.

Педанты

Для педантов характерен «безопасный подход» к разработке; они считают, что для использования любой технологии необходимо сначала глубоко разобраться в ней.

Первые работают на высоком уровне (абстракции), вторые и третьи на более низком. Педанты любят гибкость примитивов (например отображение файла в память и полный контроль). Прагматики склоняются к факторизированным компонентам, т.е. агрегатные компоненты для коньюктурщиков (чтение текстового файла и работа со строкой), но с выделенными типовыми режимами работы (бинарный файл, аналогичный тому, как на диске). Соответственно, для каждых из них имеется разное представление об удобстве API.

В данном случае одно из решений — сценарно-ориентированное проектирование. Так понял, что в данном случае это когда на сооветствющем уровне абстракции готовятся API и документация для соответствующего типа пользователя.

Таким образом, пользователи разные, и что хорошо одному, может быть плохо другому, и наобормот.

Архитектура API и интерфейс пользователю

Архитектура это одно, и она не обязана быть известной пользователю. Более того, чаще всего она не помогает в решении задачи. Для пользователя намного важным является интерфейс и предоставляемая функциональность, позволяющая решать его задачи. И если описывать архитектуру, то получится много, и не для пользователя.