На конференции 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.
Мне, повторюсь, интересен здесь заход на последовательность объяснения.
Вопрос, который ставился в докладе, и который на самом деле интересен - это как строить рабочую онтику, реализуемую в рамках системы так, чтобы она оказывалась относительно устойчивой в процессе развития системы вслед за изменениями мира в лице предметной области, с которой система работает.
Илья Баиметов ИА это Domain Model (as in Domain Driven Design)? Или отличается?
Пост на FB Как обеспечить доступность интерфейса. Валерия Курмак из Сбербанка увлеченно рассказала о том, как они обеспечивают доступность. Проводили специальное исследование о реальных проблемах. Неожиданно оказалось, что инвалиды хотят не обслуживаться на дому, а приходить в отделения - им важна коммуникация. Что инвалиды - разные, и им важны различные аспекты. И даже у инвалидов по зрению множество разных видов нарушений, и когда вы всерьез занимаетесь доступностью - это многообразие надо учитывать при тестировании. Фокус был не на технических решениях, а на обеспечении самого процесса, налаживании коммуникаций, объяснении разработчикам. На базовом уровни платформы обеспечивают доступность через ScreenReader, и в этом режиме телефон проговаривает все, что есть на экране. И важно, чтобы приложение нормально отрабатывало в этом режиме, а для этого нужна корректная верстка, должны быть подписаны все кнопки и так далее. И элементы экрана должны быть контрастны (не менее 4.5:1), что, правда, приходит к конфликту с представлениями дизайнеров, потребовали сделать более темный зеленый и убрать оранжевый. И если ваш набор типовых элементов обеспечивает доступность, и вы учитываете эти элементы при разработке, то это - небольшие накладные расходы, можно не рассматривать это как отдельную ветвь доработки, а включать в DoD основного потока.
Но вот тестирование доступности - это уже сложнее из-за налаживания коммуникаций. Они приняли на работу слепого тестировщика для экспертного тестирования, зовут респондентов для пользовательского тестирования, потмоу что эксперт уже слишком погружен в контекст приложения и не может выполнять роль неподготовленного пользователя. И надо, чтобы команды разработки были готовы к коммуникации с такими людьми. Об этом в докладе было много и с конкретными примерами.
Пост на FB Анна Абрамова в своем экспресс-выступлении рассказала простую карту, на которой можно работать, структурируя ответственность в проекте. Три слоя: бизнес - дизайн - реализация, визуально пирамидка. Три фокуса: текущая работа, внешняя среда (она меняется) и управление, как контуры вокруг пирамидки. И две половинки - Исполнитель и Заказчик, потмоу что у Исполнителя есть свои бизнес-цели, а у Заказчика - своя техническая среда, об этмо часто забывают. И дальше на этой карте можно не только выделять свои области и работать в них, но и проводить сопряжение по границам со смежниками, потому что типичные проблемы - с дырами ответственности или наоборот, с тем что человек видит реализацию в выполнении чужой работы, например, бизнес хочет напрямую писать требования.
Пост на FB Александр Овчаренко из Wärtsilä Digital Technology рассказывал про разные случаи, когда плохой usability приводил к реальным катастрофам с судами, самолетами и автомобилями. Проблема - поставлена, но решений не было.
И в заключении - впечатления Кирилла Улитина. Отвел вчера WIAD 2019 — СПб — 23 февраля 2019, впечатления смешанные:
Спасибо Yury Solonitsyn, Сергей Кривой (Sergey Krivoy), Julia Kryuchkova, Грише за пультом, всем спикерам, участникам и компании Semrush за площадку