WIAD-2019

На конференции WIAD я в Петербурге был четвертый раз. Это - одна из площадок международного события World Information Architecture Day, которое проходит в третью субботу февраля по всему миру, более 70 площадок. Каждый год объявляется отдельная тема, и в этмо году было Design for Diversity, проектирование для многообразия. В Питере это организует сообщество UX Spb и там традиционно сильная программа (мои отчеты WIAD-2016, WIAD-2017, WIAD-2018). В этом году была площадка в Москве, но ее сделали позднее и она пересеклась с TeamLeadConf, поэтому подробностей не знаю. Как и в прошлые годы, на конференции вели запись докладов, но они пока не выложены. Следите за группой UX Spb.

Я выступал с докладом Проектирование для многообразия — конструктор и DSL вместо жесткой реализации требований, который как раз пересекается с темой конференции, в котором попробовал поговорить о балансе между реализацией "как написано в требованиях" и универсальными конструкторами, который бы обеспечивал нужную гибкость, при приемлемой сложности реализации и использования.

А теперь - про другие доклады. Наиболее интересный для меня был доклад Лары Симоновой, в комментариях к нему пару недель шло большое обсуждение. Про остальные - сильно короче.

Пост на FB Первый доклад - Шейла Шейх о структурировании функций приложения МойОфис - потому что по мере развития функций становилось все больше, и надо было обновить навигацию. В одиночку на работает, структура одного кажется нелогичным другому. Попробовали получить консолидированное представление простым образом - получили отсутствие согласия и много холиваров. Выработали метод - работа парами дает в целом качественный результат без особых холиваров. И работать лучше бумажными карточками Следующий такт - работа парами, обсуждение на карточках. И делать это должны пользователи, а не разработчики продукта, у разработчиков получается взгляд от реализации, а не от использования. Работу провели, получили еще пару уроков. Во-первых, называть категорию - в последний момент. Иначе она мешает включению новых. Во-вторых, сортировка не менее важна, чем группировка. Пользователи делали большие группы и не хотели их делать, но внутри складывали в нужном порядке, и там получаются неявные подгруппы, а слышая, как они это делают - можно и названия выделить.

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

А МойОфис, откуда был первый выступавший проходил это в прошлом году и на объектах, и тоже сейчас пришел к AirTable, об этом в их докладе было.

Пост на FB Нелли Камаева - любопытная эволюция функционала стартапа по ведению заметок.

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

Потом - управление голосом. Распознание команд и их исполнение. Оказалось, что обязательно надо отвечать, первая версия показывала распознанное на экране, но оказалось, что разговаривать хотят и не смотря на экран. Как они шутят, получилось "Сири для компаний". Прикольно, но оказалось не слишком востребовано. Все-таки люди публично не любят говорить с компьютерами на рабочие темы - слышат то все.

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

У них многое в идеях, крутые ролики, увы, анимированы дизайнером, а не являются запись экрана. Но часть уже работает, она показывала и рассказывала архитектуру. Распознавание речи - на основе google, у тех есть api.

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

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

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

Пост на FB Сотрудничество UX-дизайнера и NLU-инженера. Екатерина Юлина, Дарья Сердюк - история о том, как стартует сотрудничество, первый подход оформления пользовательского интерфейса в высокотехнологичном продукте для Natural Text Processing. В условиях ограниченного времени - построение точечных прототипов. Любопытная история постепенного взаимопонимания и получения легких решений для первых шагов. И ценно именно этим - в условиях малых ресурсов можно сделать существенные и важные шаги. Сейчас ресурсов всегда недостаточно, чтобы сделать "по полной, как положено по учебникам", и многие под этим предлогом отказываются даже сделать первый шаг - мог, все равно бесполезно. Нет, полезно, и если первый шаг делать профессионально - получается реальный эффект.

Пост на FB ИА управления проектом - Сергей Петров. Версия информационной архитектуры проекта, с контекстами, ролями, мотивацией сотрудников и многими другими составляющими. Полезна как начальный вброс, но была бы, на мой взгляд, гораздо полезнее, если бы была соотнесена с известными моделями и содержала ссылки. Потому что моделей много - OMG Essence, Archimate, включающий как расширение motivation model и многие другие. Если бы это было сделано, то дальше слушатели могли бы сознательно углубляться и детализировать.

Что ценного в докладе - это удержание одновременно идеальной картины и происходящего в реальности, наблюдение и измерение зазором между ними. Это - важный фокус, которому не так много уделяют внимания, именно в формате управления зазором, а не тотального приведения к идеальной картине.

Пост на FB Meta-IA: Информационная архитектура изменяющихся систем - Лара Симонова. У Лары есть компетенция, которая меня восхищает. Она умеет строить весьма детализированные модели больших фрагментов мира, и потом структурно представлять эти модели в своих докладах. Это резко контрастирует с принятыми идеями упрощения до единственной картинки или основной идеи, эта детализация - очень интересна. В этом докладе Лара представила конструкцию размышлений об изменчивости мира и о создании устойчивых архитектурных конструкций в изменяющемся мире. Дальше - мой краткий конспект.

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

Теперь вопрос: ИА - это скелет. Как сделать ИА, устойчивую к изменению мира. Лара рассказывала модель, как с этим работать. Модель взята из статьи, название которой я не записал, но в презентации посмотрю.

• Мир - сложный, его можно рассматривать через разные призмы/проекции. Например, через призму человека, включая культуру. Или через организационно-управленческий. Через тренды и моду, через технологии, через законы природы. Выбор призм задает контекст продукта, он - важен. Границы продукта определяются уже в выбранных проекциях. Если пропустишь призму, может получиться неустойчивая архитектура.
• В призмах есть рестрикторы - ограничение то, что надо учесть при решении. Рестриктор продукта отсекает людей от его использования.
• В мире есть слои, которые обладают разной скоростью изменения: природа - культура - регулирование - инфраструктура и технологии - экономика - мода и искусство. Изменения идут во всех слоях одновременно, но в своем темпе.
• И рестрикторы позиционированы в этих слоях, исходя из этого можно предполагать их устойчивость.

И в докладе был ретроспективный пример о том как это работает - Международная классификация болезней из книги Sorting Things Out - там это сквозной пример. Классификация возникла с 19 века для целей определения карантиров и предотвращения эпидемий. Сейчас 11 версия, меняем каждые 10 лет. 3 тома - гайд и указатель. И интересно посмотреть как раз эволюцию этой классификации за 110 лет. и увидеть там слоевые изменения.

Лара в рассказе рассмотрела рестрикторы уровня природы. (1) Изменение популяции - проявляется через изменение нормы веса и изменение уровня сахара, который квалифицирован как диабет, границы меняются. (2) Изменение агентов, мутация вирусов сказывается на болезнях и далее меняет квалификацию. В презентации разобраны другие слои и сводная таблица, и это тоже я планирую внимательно посмотреть.

А пока - огромное спасибо Ларе за доклад.

Лара Симонова Спасибо, Максим, за резюме! Единственный комментарий. Модель из статьи включает только стратификацию мира по слоям со скоростями. А призмы и рестрикторы это уже конструкты из моей головы) Статья вот: https://jods.mitpress.mit.edu/pub/issue3-brand

В комментариях к посту развернулось большое обсуждение.

Александр Турханов "Призмы" - это viewpoints из ISO42010. "Рестрикторы" - это concerns из ISO42010.

Сам доклад - это гармонизированный по ISO42010 фреймворк разработки продукта. Очень интересно методически сделана последовательность предъявления концепций, это всегда большая проблема.

Анатолий Левенчук (Anatoly Levenchuk) обрати внимание на последовательность предъявления в презентации

https://channelkit-assets.s3.amazonaws.com/uploads/attachment/file/4500/2019_IA_of%20evolving_systems.pdf

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

Анатолий Левенчук Alexander Turkhanov мы когда-то сильно рубились с urbansheep по поводу "информационной архитектуры" из раннего web (я требовал предъявить хоть какое-нибудь своё понятие в этой предметной области, не заимствованное откуда-нибудь -- а этого, понятно, не было). Поэтому у меня обычно заранее скепсис к этому предмету. Вот тут чуток подробней (в комментах и по ссылкам), хотя я там тоже в тоске говорю, что непонятно, во что людей тыкать, чтобы мозг включали -- https://ailev.livejournal.com/249643.html, и это 2004 год, 15 лет назад!

Ну и тут в комментируемой презентации: терминология довольно эзотерическая, как справедливо замечено. Начиная с того, что описано моделирование данных, а потом произвольно ввёрнуто слово "архитектура" (а не архитектурная часть результатов проектирования куда?). Насчёт "контейнера для опыта", так это прагматический поворот

Международная классификация болезней тут очень специфический объект, ибо это предмет политических разборок, нужный для определения инвалидностей (пенсии! деньги!) и лицензирования (врачебные специальности и большая фарма).

Про последовательность предъявления и предлагаемый "процесс" -- там есть довольно произвольные моменты, типа "призм" (среда, природа, человек, законы, тренды, технологии -- это явно не viewpoints, это произвольно выбранный классификатор. Viewpoints там это какие-нибудь средства для выражения concerns типа "физиология"). То есть для меня это очередной ad hoc набор удобных эвристик-классификаторов (и, конечно, любимые "матрицы" рассмотрения двойных-тройных и т.д. классификаций -- типа призмы-рестрикторы-слои), а насчёт системности я бы сильно сомневался.

Александр Турханов Анатолий Левенчук доклад должен называться "Метод создания онтологии в DDD". Его, конечно, еще доделывать, но сам заход на мой взгляд, верный. С event storming и BORO все равно проблемы, нужны новые заходы.

Анатолий Левенчук Ну да. Набор эвристик и случайных классификаторов для DDD. Типа тризовских "а теперь представьте вашу систему микроскопических размеров. А теперь -- наоборот, огромной. Не появилось ли новых идей?" )))

Максим Цепков Не, метод создания онтологий и DDD был у Лары на предыдущих конференциях, с wiad-2017 у меня даже сохранилась ссылка https://www.facebook.com/lara.simonova.the.ia/posts/1261251240609758 на ее пост, и там была интересная практическая задача сопряжения различных стандартных публичных онтологий в единую модель, при том, что создатели об этом не заботились особо.

А здесь фокус был именно на то, как делать устойчивые к изменениям в условиях развития модели.

Александр Турханов Максим Цепков устойчивость онтологии к изменениям определяется как полнотой классификатора и логики онтологии.

Возьму для примера две устойчивые онтологии PMBOK Guide и SEMAT. В одном случае объектом онтологии являются практики, в другом альфы. И в том и в другом случае классификаторы покрывают все возможные ситуации в реальной жизни, но один исходит из парадигмы фокуса на действиях, другой из парадигмы фокуса на рабочих продуктах.

Но обе онтологии построены на иерархичных полных классификаторах, отвечающих условно критериям качества пирамиды Минто ВИСИ/MECE, взаимного исключения и совместного исчерпывания.

Претензия Анатолия, как я понял, в том что (мета)-классификатор доклада критериям качества не отвечает, нет иерархичности, объекты в нем не одного типа, и он неполный, поэтому не может быть устойчивым.

Мне, повторюсь, интересен здесь заход на последовательность объяснения.

Юрий Пахомов Очень бы удивился если бы увидел как работает ИТ продукт с мировоззренческими настройками😅

Прапион Медведева Мне понравилось почти до самого конца, все слова правильные. МКБ в этом контексте немного удивила. Была уверена, что призмы и рестрикторы из стандартов.Ну и как бы ничего не мешает делать произвольную upper-ontology

Анатолий Левенчук Prapion Medvedeva как бы мешает: согласовывать своё произвольное (и заранее плохо известное всем остальным) мировоззрение с мировоззрениями всех окружающих будет сложней. Крис Партридж указывает в некоторых своих работах, что upper ontology состоит из многих взаимоувязанных посылок обычно, и кривые upper ontology с плохо совместимыми посылками обычно очень плохи в мэппинге на них других онтик и онтологий. И я бы сказал, что в рассматриваемой работе не upper ontology, а произвольно взятая эвристическая онтика: набор каких-то удобных классификаторов. Вот для чего именно удобных, это можно обсуждать.

Прапион Медведева Анатолий Левенчук это правда. Но это технические детали!)

Максим Цепков Онтики, онтологии - это все одни специалисты строго различают, а другие видят непрерывный спектр различных понятийных представлений о мире разной степени общности.

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

Ответ "через построение всеобщего полного классификатора, который учтет все будущее развитие" - не принимается, потому что такой классификатор еще никто не смог построить. Это как раз точка зрения на конструкцию НЕИЗМЕННОГО мира, восходящая, к Аристотелю или еще кому из древности, и предполагающая, что мы можем построить онтологию включающую не только прошлое и настоящее, но и все мыслимое будущее. Современный ответ - нет, не можем.

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

Александр Турханов Лара Симонова ну вот в качестве старта можно взять ту же http://15926.org это стандарт промстроя.

Александр Турханов Максим Цепков дал ISO15926 как стартовый пример.

Илья Баиметов ИА это Domain Model (as in Domain Driven Design)? Или отличается?

Максим Цепков ИА это "Информационная Архитектура". Трактовки понятия, на самом деле, разные. Один вариант - Domain Model или Domain model + онтологию предметной области (словарь понятий и связи между ними), без привязки к информационной системе.

Альтернативный вариант, возникший в раннем web как структура информации (контента), представляемой на сайте означает совокупность информации представляемой в системе для пользователей, и в случае контекстно-нагруженных систем, сайтов и приложений это может сильно отличаться от domain model.

Илья Баиметов Maxim Tsepkov ну я в данном контексте спрашивал - то есть не то, что на веб сайте. То есть все-таки доменная модель.

Пост на FB Как обеспечить доступность интерфейса. Валерия Курмак из Сбербанка увлеченно рассказала о том, как они обеспечивают доступность. Проводили специальное исследование о реальных проблемах. Неожиданно оказалось, что инвалиды хотят не обслуживаться на дому, а приходить в отделения - им важна коммуникация. Что инвалиды - разные, и им важны различные аспекты. И даже у инвалидов по зрению множество разных видов нарушений, и когда вы всерьез занимаетесь доступностью - это многообразие надо учитывать при тестировании. Фокус был не на технических решениях, а на обеспечении самого процесса, налаживании коммуникаций, объяснении разработчикам. На базовом уровни платформы обеспечивают доступность через ScreenReader, и в этом режиме телефон проговаривает все, что есть на экране. И важно, чтобы приложение нормально отрабатывало в этом режиме, а для этого нудна корректная верстка, должны быть подписаны все кнопки и так далее. И элементы экрана должны быть контрастны (не менее 4.5:1), что, правда, приходит к конфликту с представлениями дизайнеров, потребовали сделать более темный зеленый и убрать оранжевый. И если ваш набор типовых элементов обеспечивает доступность, и вы учитываете эти элементы при разработке, то это - небольшие накладные расходы, можно не рассматривать это как отдельную ветвь доработки, а включать в DoD основного потока.

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

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

Пост на FB Александр Овчаренко из Wärtsilä Digital Technology рассказывал про разные случаи, когда плохой usability приводил к реальным катастрофам с судами, самолетами и автомобилями. Проблема - поставлена, но решений не было.

И в заключении - впечатления Кирилла Улитина. Отвел вчера WIAD 2019 — СПб — 23 февраля 2019, впечатления смешанные:

• Выступать по чужой презентации (для открытия) это плохая идея, потому что раз не ты ее делал, никакой связи с презентацией нет, стоишь на сцене и видишь эти картинки как в первый раз, хоть глядел в нее весь вечер накануне. В начале, как водится, тупил и волноваться.
• Так как все открытия обычно это довольно скучно, но тем не менее они стоят в программе, и помимо формальностей, мне кажется зашло неплохо, что я вспомнил предыдущие года, свой первый WIAD, где было совершенно космическое интервью с реальным архитектором, который строит здания, у которого возникли сложности с типологией клозета и клиентом-бандитом, поприветствовал старожилов и немного потроллил IA как термин за которым каждый понимает свое.
• В этом году нас было почти в 2 раза больше чем в прошлом, пришло 120 человек!
• Идея со сбором фидбека от Yury Solonitsyn с помощью бумажной анкеты для участия в розыгрыше призов, это грандиозно, я никогда в жизни не получал так быстро тонну фидбека.
• Впечатления от сервиса introwise сложно пока оценить, хоть там и зарегилось около 45 человек, общение было вялое, к счастью в кулуарах было жарко.
• Максим Цепков (Maxim Tsepkov) вел текстовую трансляцию мероприятия, можете просмотреть его вчерашние посты, это очень здорово! Спасибо!

Спасибо Yury Solonitsyn, Сергей Кривой (Sergey Krivoy), Julia Kryuchkova, Грише за пультом, всем спикерам, участникам и компании Semrush за площадку