А. Бородкин — лекция про основам ИА - ч. 1
1. Продукт — бизнес + клиенты + технологии. Это три потока интересов.
2. Что прорабатывать в продукте — интерфейсы + функциональность + ИА
Также — UX = UI + functions + IA
3. Успешный продукт: хороший клиентский опыт + заработать + выполнить задачи пользователя
4. Определение ИА по Бородкину — (не на примере определений) — на примере, см далее, пункт 5.
5. Пример (упрощенный): проектируем книжный интернет-магазин.
- Начинаем с ЦА: прикидываем кто есть ЦА, выявляем околоперсоны.
- Дальше собираем околоперсоны в группы (4-7 групп обычно)
- Далее по каждой группе — создаем персону. В рамках персоны: контекст, цель, что важно, что полезно, страхи.
6. Далее к каждой персоне создаем CJM (в идеале для каждой отдельной цели). При этом база CJM по вертикали:
- что хочет
- какие барьеры
- чем помогаем
- что показываем в интерфейсе / что за локация (это заход в сторону service blueprint)
Затем эти пункты приземляются на шаги по горизонтали.
7. На основе 4й строки в CJM делаем диаграмму навигации (screen-flow / location flow)
8. Как следствие: 1е определение ИА — навигационная структура цифрового продукта. Её польза: стратегическое понимание всей структуры, помощь разработке, выявление нагруженных частей UI, проработка компромиссов.
9. Ошибки с ИА: 1) на неё забивают 2) не опираются на реальных пользователей 3) делают мало сценариев 4) подменяют желания возможностями. Страховка — CJM

А. Бородкин — лекция про основам ИА - ч. 2
10. Далее — что еще есть ИА, как выражена? Например, аудит категорий в продукте (интернет магазин книг), варианты: 1) самому сделать (не очень ©) 2) закрытая карточная сортировка 3) открытая карточная сортировка. Закрытую и открытую можно (и нужно) комбинировать. 4) обратная карточная сортировка (tree test)
11. Итого, второе определение ИА — иерархия и категоризация контента для оптимизации (таксономия)
12. Ошибки в проработке таксономии: 1) позиция “нам виднее” 2) маленькая выборка 3) исследование всего однажды (а надо обновлять данные) 4) отсутствие качественных подходов, а только количественные.

А. Бородкин — лекция про основам ИА - ч. 3
13. Чем ещё выражена ИА, в чём ещё проявляется? Рассмотрим, что вообще есть в цифровом продукте, какие сущности, объекты?
14. Пример тот же, интернет-магазин книг, у нас сущности: книга, автор, издательство, жанр, etc… — и как эти сущности друг с другом связаны. Получается справочник объектов.
15. Добавляем сущности “заказ”, “клиент” и также связи между ними.
16. В итоге получаем “паутину” взаимосвязей контента, это — структура данных продукта.
17. В UI это нужно, чтобы поддерживать действия пользователя с этими сущностями.
18. Снова — это способ общения с разработчиками/архитекторами данных.
19. Итого — 3-е определение/выражение ИА == описание структуры данных и их взаимосвязь
20. Чем полезно: 1) Помощь в построении админки / управления 2) построение и проверка логики связей 3) обсуждение с разработкой 4) проще обсуждать интеграции
21. Ошибки в этом выражении ИА: 1) Пренебрежение этим рассмотрением и проработкой структуры данных 2) Невнимательное заполнение 3) НЕобщение с разработчиками 4

Заключение:
22. Грани ИА == 1) навигация 2) таксономия (категоризация контента) 3) описание связей, структуры данных + “описание того как всё связано со всем”

В. Курмак — ОШИБКИ ПРИ ПРОЕКТИРОВАНИИ ИЛИ КАКУЮ РОЛЬ В ДОСТУПНОСТИ
САЙТОВ И ПРИЛОЖЕНИЙ ИА ИГРАЕТ ДЛЯ НЕЗРЯЧИХ
1. Навигация по сайту / цифровому продукту. Зрячие ориентируются по заголовкам, незрячие — тоже, используют скринриде screenreader, он читает то, что написано и (!) подписано на экране.
2. Сначала надо понять “где я” — это глобальная навигация
3. Затем — локальная, “куда я здесь могу попасть”. Незрячий точно так же ориентируется по заголовкам, и важны уровни этих заголовков.
4. Между глобальной и локальной переключаемся по блокам / компоновке страницы, незрячий не видит этой компоновки, а ориентируется на разметку заголовков, которую понимает скринридер. В противном случае незрячий ПОЛНОСТЬЮ прослушивает всю страницу по скринридеру до нужного контента : /
5. Ошибка 1 в этой области — нарушение уровня заголовка, что визуально можно исправить для зрячего, и будет большой проблемой для незрячего. Стили и размеры заголовка СИЛЬНО влияют на ориентацию незрячих на сайте.
6. Ошибка 2 — НЕ разделять ссылку и текст явно стилем. Скринридер воспример текст как ссылку или наоборот, не прочитает пункт как ссылку!!! Надо явно выделить ссылки стилем, потому что скринридер будет понимать действие в тч и по стилю.
7. Дальше. Незрячий воспринимает странице как структуру с вложенностью и структурой. Потому важно проработать структуру страницы на абстрактном уровне с иерархией — блоки/подблоки/подподблоки/etc…
8. У скринридера есть функция skip to main content, это важно.
9. В случае с незрячими UX-редактура и UX-копирайтинг становится МАКСИМАЛЬНО АКТУАЛЬНЫМ.
10. При подписи элементов — пишите конкретно.
“Шаг 1 “= плохо. “Первый шаг: создать аккаунт” == хорошо.
11. Таблица должна быть сверстана как таблица, строки и столбцы должны иметь понятные названия. Скринридер прочитает “3я строка из 5ти”. Укажите общее кол-во строк.
12. Убирайте из видимости скринридера лишнюю информацию: например, если таблица сделана только для красоты / визуала, то “3-я строка из 5-ти” надо убрать из видимости скринридера.
13. Дальше. Стандарт WCAG. реализация на фронте должна учитывать прочтение скринридером.
14. Необходимо продумать управление контентом — жесты на мобильных, обработка кликов на десктопе.
15. Ссылка должна быть не “тут” а “перейти на госуслуги”
16. Соблюдайте единообразие навигации на всех страницах сайта, а лучше всего всего продукта / системы. Одинаковые иконки во всем продукте должны быть подписаны одинаково. Зашивайте эти вещи в дизайн-систему.
17. Дальше - видео как работают со скринридером на сайте (ссылка далее). Скринридер читает “основная область”, “область навигации”, etc. Например, кнопка [B] - назвать/прочитать buttons, какие есть кнопки.
18. Скринридер читает “кнопка без метки”.
19. Заниматься инклюзивностью — это след. шаг для дизайнеров. Приглашаем на курс Валерии (ссылка далее)
20. Блок про ИА на курсе в п.19 ведет Лара Симонова, сеньор ИА в MIRO, это круто!
21. Ещё раз, так как важно!!! Размечайте заголовки, их тип, их уровень! Структура заголовков с их стилями — основа навигации для незрячих!
22. Проверяйте как разработчики разметили заголовки!

Вопросы (часть)
23. В приложениях и на мобильных сайтах — там заголовков меньше на экране. Следите за разметкой основного заголовка на текущем экране.
24. % использования скринридера — с этим дефицит, даже нет четкого понимания статистики незрячих людей (?)
25. Арабский и другие языки - ответ ищите в тг-канале “Не исключение” (https://tttttt.me/neiskluchenie)
26. Можно ли адаптировать сложную навигацию для незрячих? Да, проектируйте вместе с разработчиком для незрячих, и тогда для зрячих UX многократно улучшится!

Ссылка на сайт в пункте 17 == https://www.pushkinmuseum.art/events/archive/2020/exhibitions/drawings/index.php? lang=ru
Курс В. Курмак в пункте 19 == https://kurmak.info/

П. Шерер — СОБИРАЕМ С НУЛЯ ИНФОРМАЦИОННУЮ АРХИТЕКТУРУ
Часть 1

1. Создадим приложение про тюленей
2. Что сегодня будет: декомпозиция, разбор продукта на свойства, свойства классифицируем, схематизируем
3. Ремарка: знание на UX-марафоне и единообразные и разнообразны, особенно про ИА, это нормально : ) Она абстрактна и её можно по-разному рассматривать.
4. Работать будем в Confluence
5. ИА не созидается с самого начала продукта. Сначала концепция и механики продукта.
6. Наш пример – приложение для отслеживания миграции тюленей в Охотском море. Мы их, тюленей, отслеживаем.
7. Что должно уметь приложение: выводить инфо о точках миграции + уметь масштабироваться для увеличения популяции
8. Этап 1 - декомпозиция. Ищем сущности: 1) тюлень с геометкой, только на сервере 2) точка (геометка), на сервере и на клиенте 3) список точек, совокупность точек, он динамический, запрашивается с клиента, на сервере не хранится 4) клиент, мобприложение, его данные и хранятся на клиенте и передаются на сервер. Чего не хватает? Не хватает стада. Что делать — привязываем точку к тюленю. Также привязываем точку к списку точек, объединяем точки в массивы. Это будут стада тюленей.
9. Но стадо — не есть отдельная сущность. Стадо есть таксономия (?), объединяет точки (тюленей) по удаленности.
10. Итого: есть сущности и есть таксономии.
11. Разбираем сущности и таксономии по свойствам. Параметры — название, код, тип данных, описание. Например, у тюленя два свойства: Внутренний ID и внешний ID. А вот точка — 7 свойств: внутрID, внешID, связанный тюлень (предыдущая сущность), связанное стадо, дата-время, широта, долгота.
12. Сущность [Список точек] — их может быть много, точка может содержать другие сущности и контент, например, фото, комментарии и тд.
13. Здесь может появиться пагинация, чтобы не грузить сразу все данные большого и тяжелого списка. Это важно когда устройства старые/слабые/медленный интернет/ограничения/etc. Кол-во в шаге загрузки называем “отступ”.
14. Таксономия “Стадо” также имеет два свойства — внутрID и внешID. Параметры те же — название, код, тип данных, описание. Динамически генерируется по запросу с клиента в каждой сессии.

П. Шерер — СОБИРАЕМ С НУЛЯ ИНФОРМАЦИОННУЮ АРХИТЕКТУРУ
Часть 2

15. Основная схема на основе предыдущих шагов (заготовка Павла). Диаграмма иерархии включения с легендой. Включение: какие свойства включены в сущность.
16. Легенда — важно. Это метамодель (способ описания модели).
17. Формат — неважен, важно отобразить структуру схемами/схемоидами, чтобы обсуждать.
18. Рассматриваем диаграмму: показаны сущности и их связи между ними. Например, сущность [Точка] имеет свойство “Связанный тюлень”, тянем линию связи в свойству “Внешний ID” у сущности [Тюлень].
19. Связывая эти свойства у сущностей, собираем диаграмму связей между сущностями и таксономиями через какие свойства.

В. Мазуревич — мастер-класс по карточной сортировке (КС)
Часть 1 - теория

1. История: Виталий готовил как-то упражнение про картосортингу и его спросили, мол, вы серьёзный человек, а нам тут разложить пасьянс предлагаете : )
2. Одна из задач ИА: организация навигации + категоризация. Например, как сделать каталог?
3. Вариантов много — страна / жанр / автор / толщина / цена / etc
4. Налицо проблемы отнесения к жанру… Как быть? Карточная сортировка. Она позволяет спросить: как организовать каталог? Как назвать категории? И тд.
5. Основная идея КС — отобрать карточки и попросить пользователей их организовать.
6. Если пользователи сами организуют карточки в группы и называют эти группы, то это — открытая КС, это для исследования, пытаемся понять как пользователи мыслят о нашем контенте.
7. Мало респондентов — качественное исследование. С обсуждением и сопутствующими вопросами. Понимаем основные причины расхождений (если они есть), подходит на старте. Стат. Значимости нет.
8. Много респондентов — количественное исследование. Имеет статистическую значимость. Позволяет оценить масштаб. Причины и нюансы не понять. Подходит для масштабных тестирований и исследований.
9. Варианты КС: 1) Открытая КС — респондент сам создаем и называет группы для карточек. Исследование, понимание как мыслят пользователи. 2) Закрытая КС — респондент кладет карточки в готовые созданные нами группы. Тестирование уже созданной структуры. 3) Обратная КС (tree test) — поиск известного объекта по группам и карточкам. Проверка каталога / навигации.
10. Рекомендации к КС: 1) реальная ЦА 2) единый концептуальный (?) набор карточек (это про соответствие признаков, чтобы не было яблоко/груша/салат) 3) карточки максимум похожи на реальные товары/объекты 4) протестируйте пункт 2 заранее, что они совместимы 5) избегайте навязывания.
11. Далее — практический тест. Будем раскидывать карточки по товарным категориям. Инструмент — Optimal Workshop.

В. Мазуревич — мастер-класс по карточной сортировке (КС)
Часть 2 - практика

12. Выбираем открытую КС. Настраиваем группы для тестирования в OW (Optimal Workshop). + смотрим всякие настройки для теста.
13. Запустили, ссылка в чате конференции. Участники подключаются. Виталий показывает как сортировать карточки в OW.
14. Вложенных групп нет, структура плоская.
15. Почувствуйте себя в роли респондента. Поехали.

В. Мазуревич — мастер-класс по карточной сортировке (КС)
Часть 3 - разбор практики и вопросы

16. Смотрим админку OW, выбираем одну из групп респондентов, с максимумом ответов. Смотрим детально ответы одного из респондентов.
17. Смотрим вкладку карточек, сводную таблицу как каждая карточка была разложена по группам.
18. Смотрим вкладку категорий, какие категории создали респонденты и что туда положили.
19. Вкладка Матрица подобия — сводная таблица, показывает как карточки рядом стоят рядом друг с другом (между какими больше всего связей по категориям), такие карточки наиболее вероятно попадают в одну группу (группа может оформится в категорию).
20. На основе этой матрицы подобия строится категориальный Mind Map
21. Зачем все это делать — разработать метрики, спланировать а/б-тесты

Вопросы (частично):
22. Порог связей в матрице подобия — он есть? Зависит от кейса, но чем больше %, тем больше связь в мозгах у пользователей.
23. Можно пересекать категории, то есть класть один объект в разные категории, например, [кухонный стол] попадет в “для кухни” и в “столы”
24 Как выбрать ответы из количественного исследования для качественного? Отсечь экстремальные значения и узнать про них качественно
25. Аналоги OW — лайфхак: использовать Trello

В завершение:
26. Факультативно: результаты тестов доступны у Виталия, запрашивайте (тг @Mazurevich)

А. Попова — ОБЪЕКТНАЯ МОДЕЛЬ В ПРОЕКТИРОВАНИИ
Часть 1

1. Зачем применять объектную модель дизайнером и проектировщикам — чтобы знать как работать с многослойной системой: разные технологии, версии, команды, релизы, изменения, функции, etc.
2. Анастасия просит всех написать “что есть ИА” в чат конференции.
3. Все представляют систему по-своему: текстом, картинками, схемами, диаграммами, последовательностями, etc.
4. Слайд с абстрактным “макро(микро?)-приближением”, отвязанное от UI, какие-то данные (на слайде сгруппированные окружности). Это абстрактное представление объектов с их свойствами, они объединены в группы.
5. Некоторые группы объектов связаны между собой линиями.
6. Следующий слайд — Zoom out, эти структуры групп объектов сложены в компоновки на экране.
7. Еще Zoom out — переходы между этими экранами, абстрактный screen flow
8. На этом уровне атомарный состав пунктов 4-5 не виден.
9. На каждом уровне zoom-а работаем с соответствующим набором элементов/объектов.
10. Далее — представление объектной модели. Вариантов много: mid map, другие разные карт.
11. Пример: пользователь. У него есть свойства: ФБ, его активность, атрибуты, сегмент (откуда он), etc.
12. У каждого свойства есть свои параметры, например у ФБ: локация, имя, пол, возраст, etc
13. Эти свойства/сущности разбираем для понимания какая будет с ними активность.
14. От этого зависит, что из этого помещать на страницу/экран.
15. Можно отобразить в виду mid map, можно в виде матрицы (с легендой). Пример легенды: объект + свойство фронт, свойство бак, действие, вложенный объект.

А. Попова — ОБЪЕКТНАЯ МОДЕЛЬ В ПРОЕКТИРОВАНИИ
Часть 2
16. Практика / тестовое задание для дизайнеров. На слайде скриншоты сервсиа подписки в мобильном банке. Задача — помочь пользователю обозревать расходы по подписке и управлять ими.
17. Строим объектную модель (ОМ) для автоплатежа, сервиса получения платежей и внешней подписки.
18. Пример: Внешняя подписка: когда внешний сервис приходит с запросом денег, которые клиент согласился отдавать.
19. Свойства этого объекта (Внешняя подписка): название, ID, статус + значение статуса, счёт списания, сумма, дата списания, периодичность, тип платежа + значение типа, контрагент (кто принимает платеж) и его реквизиты, категория.
20. Действия с “Внешняя подсписка”: включить или выключить подпсику (поменять статус).
21. Далее берем “автоплатеж” — отличается тем, что клиент сам делает платеж и настраивает его регулярность в приложении. Далее разбираются те же свойства/атрибуты, но уже для “автоплатежа”.
22. Выглядит как будто структура одинаковая, что делать?
23. Разделяем “внешняя подписка” и “входящее платежное требование”, переносим свойства из “внешней подписки” в подсистему “Входящее требование”. Отмечаем то, что фиксировано.
24. Отдельно выносится подсистема “Контрагент”, ему передаются еще свойства (из основной системы “Внешняя подписка”).
25. То есть система “Внешняя подписка” имеет подсистемы “Требование платежа” и “Контрагент”.
26. Далее подобным образом разбираем “Автоплатежа”. И очевидно, что это шаблон, в которые при заведении каждого автоплатежа указываются уже конкретные данные.
27. Добавляем действия для “Автоплатежа”: вкл/выкл, редактировать данные, удалить совсем, создать новый (на основе шаблона).
28. Теперь можно увидеть откуда данные приходят и чем отличаются объекты друг от друга.
29. Дальше пример “Счета на оплату, подписка на сервисы” — клиент сам добавляет какие счета на оплату получать и вручную оплачивать.
30. Делаем всё то же самое для третьего объекта — “Счета на оплату”. Например, у него будет другая периодичность, будет каждый раз разная сумма, но менять мы её не можем.
31. Также выделяем действия для “Счетов на оплату”.
32. Теперь видим чем (под капотом) отличаются Автоплатежи, Внешние подписки, Счета на оплату.
33. Выделяем свойства/параметры, которые можно объединить и пустить в аналитику: думать, что еще можно наблюдать/выявлять/использовать. Например, можем показывать “Сумма за подписки в месяц”, тк кажется это полезно пользователям.
34. Зная периодичность, например, можем, подсказывать когда будет платеж и какая сумма. А также всякие рекомендации.
35. Теперь понимаем, где все эти функциональные объекты могут/будут “жить” в продукте. И заодно надо ли разделить на [Подписки] и [Автоматические списания] или оставить в одном разделе [Списания и платежи]
36. Из этого упражнения можно “вытянуть” взгляд на те потоки данных, которые обеспечивают функции в продукте/системе.
37. Этот взгляд — внутренний, показывает “как работает под капотом”, это инженерная область рассмотрения, не для клиента снаружи. Но она помогает понять как научить пользователя: что ненужно от него скрыть, а что важное ему показать и когда.

М. Галушко — ИСПОЛЬЗОВАНИЕ МЕНТАЛЬНЫХ КАРТ ПРИ РАБОТЕ С ИНФОРМАЦИОННОЙ
АРХИТЕКТУРОЙ НА ПРИМЕРЕ XMIND

1. Михаил использует для работы с ИА методологию ментальных карт.
2. Что такое ментальные карты — они позволяют структурировать информацию, делая диаграммы связей. Возникают иерархии, движения от общего к частному.
3. Какие вообще бывают ПО для проработки ИА — XMind, MindManager, Aoya, Miro, MindMeister, etc
4. Ментальные карты (МК) в целом полезны для: бизнес-аудита, сбор информации (требований), установка целей, декомпозиция задач, концепция продукта на верхнем уровне, мозговые штурмы, инструмент коммуникации (когда комментируется и дополняется сама карта). Также дает понять масштаб и комплексность разрабатываемой системы.
5. Как идет работа над цифровым продуктом? 1) Бизнес-аудит, сбор инфо 2) постановка целей 3) разработка концепции 4) строим ИА, откуда далее прототипы, продукт
6. МК как инструмент коммуникации: делаем этапы, зоны ответственности, документации.
7. Михаил показывает Фреймворк в виде МК: проект делится на прототип, концепцию, бизнес-аудит, поставок задач. Эти части в свою очередь разделяются на свои внутренние потоки.
8. Вот такой вот “снимок” МК проекта и есть ИА продукта (по версии Михаила).
9. Каждому узлу в этой МК добавляются заметки/описание/инсайты/ссылки/etc
10. Далее — отслеживание процесса. Каждая ветка оснащается метками, например, кто ответственный, что именно надо сделать, и тд.
11. Преимущества МК: 1) используем как базу знаний 2) доступность формата 3) независимость от специальности и профуровня 4) это рабочий инструмент
12. Дальше — МК в ИА. Цитата Л. Розенфельда.
13. ИА возникает на этапе формирования концепции (реализации) продукта.
14. Что сделать для ИА на МК: 1) визуализация концепт-принципов 2) 3) 4) … не успел : ( …
15. Практический пример. Вводные нового проекта:
1) текущая ситуация 2) целевая аудитория 3) Обзор рынка 4) Точки принятия решений 5) Цели и задачи
16. Концепция проекта: 1) концепт-инстурменты 2) навигация 3) точки принятия решений 4) структура
17. Также в концепции проекта (?): 1) классификация контента 2) Выбор формата ИА (стандартный, например, дерево) 3) Шаблон представления контента
18. Создаем схему ИА в XMind: строим mid map. Выбираем вариант/формат представления (например, оргструктура).
19. Пример: банк, у него 1) продукты (список продуктов) 2) информация о банке (список статей/инфо) 3) личный кабинет (список функций в ЛК)
20. Развиваем дальше: выделяем намерения (интенция): получить деньги, вложить деньги, и тд. Каждую интенцию делим на функции. На одном уровне (?) с интенциями — локации типа поддержки и ЛК.
21. Далее каждую функцию/локацию декомпозируем, насыщаем метками/комментариями/требованиями
22. Обсуждаем всё это командой, коммуницируем с помощью этого “обвеса” на карте. Уже прорисовывается навигация, сценарии. ИА, выраженная такой МК — инструмент коммуникации в команде.
23. Проставляем связи активности/функций, например, после просмотра видео надо направить на страницу оформления заявки.
24. На примере Личного кабинета смотрим ближе на устройство этого набора функций.
25. Всё помечаем маркерами (для них обязательна легенда)
26. Продолжаем насыщать ИА на МК, размещая новые функции, новые требования, новые связи.
27. XMind позволяет весь этот обвес наложить на МК. Можно экспортировать (и грабить корованы).
28. Почему такой формат эффективен? — в практике Михаила не было случаев включения ИА в документацию. Это внутренний динамический инструмент коммуникаций.
29. При должной детализации все состояния, элементы и действия для создания UI представлены на низком уровне такой МК.

Ищу докладчиков на WIAD Moscow 2021.
Если вдруг это вы или знаете кто может подойти, то прошу ознакомиться с формой заявки : )
https://forms.gle/1fdL9vmJ28f7QShG6
В этот раз хочу сделать упор на оффлайновые или даже не-цифровые истории. Будет круто, если вы можете рассказать про что-то типа:
1) Навигация в городе, на дорогах, маршрутах; ментальные модели в голове у пешеходов и водителей.
2) Информационная структура / архитектура в транспорте / транспортрных хабах / аэропортах / etc
3) Информирование и/или навигация на массовых мероприятиях: навигация, план-схема местности, программа.
4) ИА в картографии / GIS-системах
5) Кейсы проработки навигации в торговых/развлекательных центрах
6) Реальные архитектурные и урбанистические проекты про ориентирование в городе/здании
7) etc / предлагайте своё!

Также я хочу делать смещение в сторону системного подхода (в понимании https://system-school.ru/ и смежных дисциплин), поэтому буду рад заявкам на темы системного мышления, ТРИЗ, СМД Щедровицкого — однако желательно, чтобы эти рассказы были про что-то близкое к информационной архитектуре, ментальным моделям, контекстам восприятия, систематизации знаний.

В целом я за насыщение продуктов и проектов ощутимым смыслом, устранение противоречий, поэтому к рассмотрению приму в том числе заявки, не связанные с перечисленными выше темами, но подразумевающие системность, структурирование, практики выявления смысла.
--------------------------------------------
ВАЖНО: подача заявки не гарантирует участие в докладчика в конференции. Когда и если ваш доклад будет принят, то мы сразу свяжемся с вами.
ТОЖЕ ВАЖНО: мероприятие бесплатное, гонорары за выступления не предусмотрены.
Заявки принимаются до 20 февраля включительно.

Ориентируйтесь на 15-30 минут включая вопросы зала (но все обсуждаемо).

Связаться со мной:
телеграм @sergej_petrov
[email protected]
https://www.facebook.com/sergejpetrov84

Ура, уже есть доклады в разработке, и они прекрасны. Анонс чуть позже, пока что выглядят так:
1) Заявка подана, доклад в стадии подготовки — сфера: лингвистика и обучение
2) Заявка подана, доклад в стадии подготовки — сфера: городская навигация

На данный момент список докладов выглядит так:
Атомизм в лингвистике
— Рустам Агамалиев, педагог

QR-остановка — разбор кейса в сфере городского транспорта
— Михаил Мартыненко — идеолог и разработчик проекта
— Надежда Новикова — аналитик и фронтенд-разработчик
Администрация муниципального образования город Краснодар, Управление инвестиций

Чуть позже я сделаю отдельные анонсы на каждую из историй.

Также ожидаю ответа/решения еще от нескольких потенциальных докладчиков. Надеюсь, что в итоге будет 3-4 выступления.

Мероприятие пройдет максимально неофициально — в Zoom, с возможностью задать вопросы мне, спикерам, друг другу, пообщаться после докладов. Регистрация туть

Пока я готовлю анонсы докладов и веду переговоры с докладчиками, самое время упомянуть инфопартнёров (на самом деле даже больше, но обо всём далее).

Школа Системного Менеджмента — не просто информационный партнёр, это образовательный узел, который сильно изменил моё видение на такие вещи как

проектирование
информационная архитектура
продукт и проект
дизайн
подход к мышлению
etc (до бесконечности могу перечислять)
Именно поэтому ссылка на Школу здесь. Я не скрываю, что хочу полностью пересмотреть взгляды на ИА, и смещать мышление всех, кто как-то участвует в WIAD и ИА-движении в сторону системного мышления по версии ШСМ.

———————

2021-й год, вероятно, переломный, и это одна из причин, почему я очень вольно подошёл к выбору / запросу докладов. Темы выступлений намеренно удалены от ИА как таковой, но всё ещё в поле UX, проектирования, мышления, формации смысла.

Всем привет! Список сформирован (но заявки все еще принимаются!)
27 февраля в Zoom. Старт в 12:00. Регистрация на timepad

0) Приветствие
— Сергей Петров, организатор WIAD Москва

1) Атомизм в лингвистике
— Рустам Агамалиев, педагог

2) QR-остановка — разбор кейса в сфере городского транспорта
— Михаил Мартыненко — идеолог и разработчик проекта
— Надежда Новикова — аналитик и фронтенд-разработчик
Администрация муниципального образования город Краснодар, Управление инвестиций

3) Звук в проектировании архитектурных и инфо-пространств
— Глеб Глонти, генеральный продюсер Kotä.Moscow

4) Джем / круглый стол / вопросы-ответы / свободное общение
— Все участники