Protraktor

Ну а вот, кстати, почему Protraktor — это Protraktor.

Сегодня обсуждали с моим хорошим коллегой дизайн-систему Контура (Контур.Гайды) — ребята без апломба и лишнего шума стабильно и который год развивают её и делают, причём там нет каких-то адских трендовых историй, всё аккуратно и чисто, ну и весьма просто, без выпендрежей. Есть на что глядеть и мне с моими экспериментами, порой кажется я слишком наворачиваю в попытке суперуниверсальной библиотеки (все стыжусь линки обновленные выложить, но времени не хватает на доводку). В общем, кто еще не видал, думаю полезно поглядеть — 1) Описание компонентов 2) Там же перечень библиотек Figma, а если лень и хочется сразу потыкать — вот, например, компоненты и иконки 4) React UI компоненты

https://www.behance.net/gallery/25757411/TESS-Air-traffic-control-workplace — очень люблю такие концепты.

Почему я написал это? Я уже много раз наблюдал подход начинающих (и даже не очень) исследователей — как у нас, так и за рубежом (а месяц назад даже сидя на яхте участвовал в оценке скиллов интервьюера в совершенно стороннем проекте, где я немного консультировал), которые, задавая по скрипту вопросы, будто бы считают что не нужно вникать в предметку и, к тому же, даже убеждены, что уходить от скрипта в сторону абстрактных непонятных вопросов опасно, что это приводит к расфокусировке. Да, с позиций ресурсных затрат (а ещё тактических задач) может они и правы, но такие подходы «по учебникам» приводят к тому, что мусолятся совершенно локальные проблемы и улучшения, которые не продуцируют достаточной ценности продукта. И под исследователями я подразумеваю не только UX-ресечеров, но и дизайнеров, аналитиков, и даже часто видел это у собственников бизнеса. Деньги тратятся, работа кипит — а продукт никому не нужен. Увы.

(Продолжение) Приведу маленький упрощенный пример (мне сложно переносить мою морскую тематику на более массовые кейсы, поэтому будет коряво). Допустим, вы хотите сделать новый маркет-плейс в какой-то b2b области, где еще их не было. Вы чувствуете, что тут всё не очень эффективно, и даже начинаете предлагать решение, идеи. Но если поставщики относятся к этому с энтузиазмом, то другая сторона — заказчики — достаточно пофигистичны. Если их мучить распросами об их проблемах, ответы будут простые и не очень полезные. Но можно, например, сделать концепт с какой-то аналитикой — хотя это совсем далеко от текущих задач заказчиков. И показывая его (пусть там даже очень примитивные тренды и т.п.), они внезапно поймут, что старый телефонно-эксельный метод никогда не давал возможности сравнивать не только поставщиков по ценам, но еще и по аккуратности исполнения обязательств, пунктуальности, плюс механизмов планирования регулярных поставок по проформам и так далее. То есть из банальной системы “цифрового рынка”, ценность которой была недостаточной, заказчики получают возможность использовать инструмент еще и для влияния на поставщиков — «Вася, ты разгильдяй, поэтому в следующий раз или снижай цены, или мы идём к Пете». А это, наряду с основными функциями, становится уже достаточно ценным, чтобы влазить в испытания и покупки нового и непонятного продукта у стартапа. А что мы там показывали в концепте за метрики аналитики? Да бог с ними, разберемся.

Про концепции (и исследования), №4 Большинство людей не очень хорошо мыслят абстрактными понятиями — и когда обсуждается сложная и несуществующая система, ответы пользователя/заказчика могут быть туманными, потому что не вызывают каких-то ясных образов. Также высока вероятность получить пассивные отклики — на уровне «нравится/не нравится», беседа может уходит в ступор. Если обсуждается новая принципиально версия существующей системы, может быть ещё хуже. Например, если заказчик работал много лет с системой одного производителя, но теперь (например, из-за известных событий) хочет создать собственную, он будет цепляться к модели старой системы, предлагая только тактические, очевидные улучшения для поверхностных проблем. Такие же события происходят зачастую при цифровизации — вместо того, чтобы использовать возможности технологий на максимум и приходить к принципиально новым способам решения проблем, часто просто происходит «оцифровка» докомпьютерного подхода. Знаете чем концептуально отличаются цифровые морские карты от бумажных? Да почти ничем, такой же набор рамок разных масштабов с объектами внутри — цифровые копии цифр. Да, больше информации, больше всяких мета-данных (ибо очевидно), но буй на рамке карты одного масштаба и тот же (физически) буй на рамке карты другого масштаба — это разные объекты. Так вот, если не ковырять в более глубокие возможности, мы как обычно придем к «более быстрым лошадям» — это не совсем уж и шутка. Но как триггерить более глубокие дискуссии с теми, кто слишком прилип к поверхностным «слоям»? Ответ простой — таки проактивно предлагать опять же концептуально новые решения, даже если не просят. Видя буквальную картинку, заказчик или пользователь уже видит что к чему не абстрактно, а достаточно предметно, это даёт возможность не только критиковать то что он видит, но триггерит его собственные идеи — «это не то что я хочу, но давайте может вот так?» Особенно эта история критична для стартапов, которые лезут в не самые понятные (еще не сформулированные) проблемные области. Типичная ошибка — задавать узкие вопросы «а что вы делаете? а какие проблемы есть? а если вот так, то что?», и сразу по запросу делать функциональную специификацию или ставить задачу. Увы, это необходимо, но совершенно недостаточно, ибо такой реактивный подход не выводит на новые решения и идентификацию потенциальных разрывов, которые могут создавать новые ценностные характеристики продуктов — и, разумеется, желание их купить. Правильно — позадавав вопросы, во всей этой неопределенности создавать широкими мазками видение новых решений, предлагая совершенно свой подход (даже не особо боясь быть дилетантом — это уже вопрос коммуникации), и продемонстрировать заказчику. Это заискрит его мышление, что «а ведь можно и не так сделать, как всегда делали», остается только слушать и искать проблемы и потенциально новые сценарии применимости продукта. А там уже можно возвращаться в старый добрый детерминистский принцип. Работая с датчанами, мне сложно не приплести старую добрую копенгагенскую интерпретацию квантовой механики. И её очевидную применимость к UX- и бизнес-исследованиям — исследователь влияет на ответы. То есть задавая конкретные вопросы, мы будем получать конкретные ответы, и вряд ли уйдём в неизведанные новые области.

Эксперименты №3 На какое-то время выпал, разбираясь с делами, но по работе снова появился мой любимый незакрытый гештальт и крепкий орешек — визуализация погоды на карте. Несколько вечеров бился с расшифровкой грибов (GRIB-файлы, сетки данных о погоде), поскольку мои прошлые заходы еще на предыдущей работе факапились из-за попыток раскрасить синтетические данные (тот же шум Перлина), что не давало адекватной картины для оценки результата. Теперь, наконец-то, смог это сделать — первая и вторая картинки это отображения давления и силы ветра соответственно яркостью пикселя (минимальные значения — черные, максимальные — белые), а третья — примерно минута возьни в Фотошопе, используя градиентную заливку и подложку из первой попавшейся картинки с картой земли для оценки альфа-каналов (ибо не всегда есть смысл акцентировать хорошую погоду). Лёд тронулся. Хочу теперь попробовать сделать простенькую утилитку (заодно обкатывая мою недодизайн-систему), где можно на лету менять цвета погодных заливок, подложки и т.п. Уж очень часто это приходится делать, а пайплайна нормального для работы нет — обычно подбираешь градиент, шлешь прогеру, ждешь когда он натянет и сделает сборку, ну а потом оцениваешь. Еще и в данный момент погода на планете оказывается то слишком плохой, то слишком хорошей, и всё это мешает оценивать результат. И параметры разные (ветра, волны, давление, осадки) выглядят по разному и оценивать их тоже нужно по разным критериям — одной картинкой не обойтись. А уж комбинации… Плюс недавно читал экспромтом на полтора часа коллегам лекцию на эту же тему про разные подходы и нюансы визуализации заливками, сетками, изолиниями и т.п., и возникла мысль написать методичку. Раз общую книжку про профинтерфейсы так и не смог сделать, так попробую хоть узкую тему описать. А для неё тоже нужны картинки — так что, надеюсь, мотивации хватит. #лаборатория

Когда я говорю про красные палитры (интерфейсов ли или ещё чего) для ночного зрения, слушающие часто не верят или удивляются. Меж тем вот пример "здесь и сейчас" — ночую в кают-компании на яхте приятеля, и горит лампочка, чтобы из других кают можно было сходить в тот же туалет и не мешать мне. На самом деле используется для вахт — пока одни спят, другие управляют и ночью никто не мешает друг другу.

Шрифты — не очень афишируемый мною давний интерес (даже потихоньку собираю библиотеку). Вот эта статья от NNG в каком-то роде объясняет, почему я стараюсь не затрагивать эту тему. https://www.nngroup.com/articles/best-font-for-online-reading/

Ну и в мою “проф-недодизайн-систему” это вклад. Пока научился программировать отрисовку линий с привязками к характерным точкам существующих объектов. И это уже фарш. Впереди — ввод параметров линий с клавиатуры, а также использование клавиш-модификаторов для характерных углов (да, тот самый Shift). Уже накидал небольшой черновик статьи про философию работы над такими взаимодействиями и понимаю, что это скорее про методичку. Вот так скомканно, ибо очередная большая тема, которая может быть слишком нудной и нишевой. Продолжать трогать её пальцем и тыкать палкой/стилусом? Вместо очередных голосований ставьте лайки и дислайки. #лаборатория

Эксперименты. №2 Есть у меня ещё один эксперимент. Точнее, любимая мазоль — это проработка курсорных взаимодействий при работе с холстом (то есть когда мы рисуем что-то двумерное — например, маршрут на карте или дизайн в Фигме). Хотя это довольно нишевая история, я работал с ней стопяцот раз — от расстановки магазинов на схеме московского ГУМа для сенсорных навигационных киосков лет 100 назад и проработки инструментов для врачей-рентгенологов, измеряющих и обводящих разные нехорошие пятна на снимках, и до, ясен пень, отрисовки навигационных маршрутов на морских картах (эх, поленился в свое время, был бы автором патента — до сих пор считаю это одной из лучших работ, что я сделал за всё время). В общем, в рамках текущего творческого эскапизма, решил я попробовать поиграться со стилусом на моём планшете — если с тач-интерфейсами прикидки чего-то более менее точного обломались (есть тут в подписчиках один товарищ, который лучше меня бы рассказал об этом), то на стилусы еще есть надежда. Причём хочу проработать задачу черчения — опять же, присасывая это к моему контексту ползаний по яхте, когда мне постоянно приходится что-нибудь замерять и чертить, а потом, возвращаясь домой, на основе снятых замеров/чертежей готовить объекты для 3Д-печати или оценивать покупку материалов и т.п. Ползать с ноутбуком и открытым в нём Autodesk Fusion 360 не удобно. Гипотезы эти очень хочется проверить, но любая проработка таких взаимодействий требует очень сконцентрированной работы, ибо: 1) Работа с курсорами это очень быстрая и динамическая история, завязанная как на привычки, так и на выработку рефлексов. Её почти нереально тестировать без живой работы, из-за взрыва состояний и необходимости оценки вживую. Наше восприятие, в том числе “проектное” — это скорее набор статических кадров (вспомните дорогу от дома до работы — вы представите не “ролик”, а именно наборы кадров), и значит увязки переходов в динамике очень трудно представлять и оценивать заранее. 2) Проектировать работу курсоров с множеством задач нужно цельно — опять же чтобы снижать разнообразие. Фактически, это проектирование коммуникативного языка — включающего набор базовых принципов (“грамматику”), так и последующую имплементацию в конкретных паттернах для конкретных инструментов (написание “предложений”) 3) Подобные взаимодействия почти всегда завязаны либо на одновременное использование как холста, так и традиционного UI (выбор или модификацию поведения инструмента мы делаем с помощью тулбаров, контекстных меню и т.п.), либо на исползование мыши и клавиатуры (а ещё брать тот же трекпад — не мышь). Со стилусом тут добавляются комбинации из самых разных способов ввода — пальцы системой распознаются отдельно от стилуса, стилус отдельно от мыши, а еще и клавиатуру в принципе можно приспособить, чтобы доработать черновую прикидку после того, как я вылезу из узкого машинного отделения. Опять же (см. пункт 2) нет смысла делать это принципиально разными способами. Но каждый способ ввода имеет свои особенности и нужно их хорошо «разносить». 4) Всё это часто упирается в поиск компромиссного баланса между hidden logic, частотой использования того или иного инструмента (если что, самые частые — панорамирование и смена масштаба), ну и очевидность, скорость вхождения в функционал, выработку рефлексов. Плюс я периодически ненавижу Фигму и другие инструменты (привет, Миро) за их порой откровенно странные взаимодействия — например, по удалению нескольких выбранных объектов рамкой из другого выбора. Выбор простой — чтобы прорабатывать работу стилусом, надо вначале создать задел на «обычных» клавиатурно-мышево-холсто-юайных подходах. Начал делать поделку, некий примитивный аналог Компаса 2D, в котором можно рисовать простейшие чертежи как простым образом, так и с учетом привязок (snappings — от середины одной линии построить к центру окружности, а потом и еще и касательную к ней), а еще и чисто клавиатурным образом, когда нужно построить прямоугольник замеренной ширины и высоты. Разумеется, все это может комбинироваться. Хотя это отдельная тема.