Protraktor

Эксперименты. №3 (и отчасти Protraktor UI Kit) Поскольку у меня на какое-то время пропала точка приложения моих «физических» интересов в DIY, а от новой работы мозги кипят (уже в черновике вторая часть про старт дизайна и дизайнера), решил побаловаться с подходом дизайн-систем к аппаратным органам управления — причём в срезе DIY. То есть сделать некий фреймворк из 3D-моделей и принципов для сборки более-менее эргономичных (насколько позволяют 3D-печать и прочие любительские ограничения) панелей управления для разных самоделок. Ибо то, что валяется на каком-нибудь Thingsverse — какой-то треш рукожопов, ибо антропометрию и базовые принципы унификации никто не отменял, а там о них никто не думает. В общем, начал с крутилок — «бутылочных крышек» для энкодеров и потенциометров. Ох, сколько я уже их напечатал, чтобы просто было достаточно прочно и легко, и нормально вставлялось на типовой D-вал. И сколько еще будет — неизведанная вселенная. Хочется еще как минимум добавить кнопки, джойстики. А также проработать ещё типовые модули для поверхностей пультов и стандартизированные представления меток, состояний кнопок, направлений вращения и т.п. И чтобы любой Федя, Вася или Саша, делающий самодельный синтезатор из ардуино и палок, мог собрать что-то приемлемое. Не уверен, что это самое полезное направление творческих устремлений, но травмы требуют сублимации. P.S. Осенний режим, ещё и без яхты, двигает больше обращать внимание на этот проект, опять буду его переделывать под новые реалии и мои возможности 🙈 Постараюсь быть более эджайлным — не ждать полировки и завершенности материалов, а выкладывать то что есть. Это я и про Protraktor UI Kit. Но надо кое-что переверстать. В конце концов, тот же openbridge.no не стесняется выкладывать полуготовые решения. И молодцы.

Не моя поляна сообщать вести, но, если вы ещё не в курсе, случилась какая-то фигня — Эдоби покупают Фигму. Любимый монстр перед смертью таки поглотил своего убийцу — https://www.figma.com/blog/a-new-collaboration-with-adobe/

Натолкнулся на пару книжек о визуализации информации, которые меня весьма зацепили своей фундаментальностью — и тем, что они актуальны спустя десятилетия после издания (разве это не показатель качества и глубины?). 1) Bertin, J. (1983) Semiology of Graphics: Diagrams, Networks, Maps, Esri Press — если вы знаете Тафти, то могу уверенно сказать, что Тафти — по-крайней мере в большинстве своих книжек — попсовик, плещущийся на поверхности, по сравнению с этим автором. Пожалуй, саымй глубокий труд по основам визуализации информации в истории. 2) Imhof, E. (1982) Cartographic Relief Presentation, Walterde Gruyter —это уже для любителей картографии. Такой же фундаментальный труд, как и предыдущий — но уже только про представления картографические, их создание, ошибки и визуализацию. При должных навыках эти сокровища находятся в интернетах. P.S. Добавил в список рекомендуемой литературы. Считаю его самым ценным на сайте, поэтому напоминаю о нём.

Старт дизайна и дизайнера в компании. Часть 1. Вводная Скоро, наконец, начинаю работу в новой компании фултайм, где основная задача — построить всю дизайн-историю (процессы, команду, улучшать продукты, приводить все к общему знаменателю и прочая типичная работа UX-дворника, имеющего дело с инженерными системами). Почти год бултыхался, в поисках себя и, наконец, нашел новую гавань. Что ж, многие это проходят, вот и меня коснулось. Попытки в этой компании, конечно, были и до меня, но без системного подхода. А мне это ещё и способ сделать работу над собственными ошибками — и, думаю, для вас это интересно будет почитать, ибо, как всегда, проще писать по ходу истории, чем вспоминать что там было полгода или пять лет назад. В общем, буду делиться проблемами/решениями и принципами — как я это вижу. Думаю многое полезно — даже особенно полезно для нерукоблудящих неруководящих должностей, особенно начинающим. * * * И пока самое простое. Вот вы поулчили доступы, пришли на работу, ничего не понятно. Впрочем, скорее всего вам скажут, что надо начать с такого-то продукта, ибо в нем более всего работы. Что делать? 1. Не лезть сразу целиком в продукт, отсекая всё прочее. Нужно найти ментора, который всё расскажет про проекты, неравнодушен и, желательно, поддерживал бы перемены — и у которого есть время на это (кто-то из миддл-менеджмента). Лучше о таком товарище попросить еще на этапах собеседования. Пусть ведет по всему состоянию дел, описывает проблемы, дает демо-доступы к системам, кидает ссылки на всё что было сделано недавно и пару десятков лет назад — чтобы видеть эволюцию. HR тут не подойдет, лучше кто-то с реальным опытом проектной работы с системами — продакт, лид продактов, техлид и т.п. Надо понять, какие продукты заканчивают жизнь, какие только растут, какие уже в могиле, но забыли похоронить, что приоритетно, а что нет. Также разобраться с фреймворками, что юзают для мобильных приложений, что для десктопа и т.п. — все это потом пригодится при распутывании наследия и создании плана работ. 2. Знакомиться с командами, людьми, конечно. Строить личные связи. Пытаться понять — скептики они или поддерживают ли перемены, или находятся в середине спектра и им всё равно (последних нужно избегать), кто принимает решения. Проявлять вдумчивость, стараться меньше высказывать оценок — еще ничего не понятно, чтобы хвалить или критиковать (а вдруг автор фичи — тот с кем вы сейчас говорите, и она ему нравится?). 2.1. Еще полезно найти других дизайнеров — если компания плюс-минус большая, они скорее всего есть, просто вы о них не знаете. Может в штате, может вне штата, может кто-то выполняет их функцию, творя нетленку. Всегда есть определенная ревность между старожилами и новичками, и если заранее не найти их, есть риски политики и вражды, поэтому стоит настроиться на сотрудничество как можно ранее. 3. Строить майндмеп. Голова будет перегружена от обилия источников информации, поэтому стоит всё скидывать в какую-нибудь карту или Миро-доску, особенно гипотезы и вопросы, ссылки и проч — всё, что может потом пригодиться. Тратить много времени на структурирование не стоит, пусть само в голове складывается (а сложится все равно не сразу — не нужно бежать слишком быстро), но обидно, когда спустя неделю-месяц вспоминаешь что кто-то что-то говорил, а оно пропало. В общем, разбирайтесь и старайтесь пока не вмешиваться (и это важно в первую очередь для собственной головы) — перед тем как менять территорию, нужно составить её карту. UPD: Кстати, почему не надо лезть в один продукт? Да, хочется себя быстрее проявить, но если начать сразу все силы бросать в него, то велика вероятность, что через полгода-год, когда вы дойдете до других продуктов, все своё творчество придется отменить, ибо оно не консистентно другим решениям в других продуктах. Разумеется, никогда полностью не перестрахуешься, но очевидные вещи стоит предусматривать, особенно проектируя новый дизайн-подход, распространяющийся за рамки изначального решения. Прыгая с берега в воду, нужно также думать куда и какими силами вы поплывете, когда достигнете первого буйка.

UX Design Awards тут ведут трансляцию уже какое-то время, и вполне можно подоглядывать за едой, например — https://www.youtube.com/watch?v=93W9culsy9s&ab_channel=UXDesignAwards. Вроде не только про всякие масс-маркетные глупости — сейчас было про приложение для инженеров, устанавливающих кондиционерные установки Toshiba. А теперь про МРТ от Siemens (Сименз очень круты в HMI) UPD: Реально полно профсистем от крутых команд, очень интересно поискать и поглядеть потом всё это в деталях

Про концепции. №5 Совсем свежая заметка по горячим следам, пока не остыли. Я заканчиваю потихоньку работать с текущим работодателем из-за ядерного ядрёного геморроя с финансами и напоследок меня попросили накидать как можно больше идей по развитию продукта. В общем, я стал собирать всё в одну кучу и делать общий концепт того как я вижу его — на уровне бизнес-требований, новых ролей, подхода к архитектуре UI и т.п. Но всё это понятные вещи. А вот сформулировалась по итогу мне другая мысль, почему цельные концепты важны — скажем так, добавилас ещё одна грань концептуализации. Я уже говорил, что концептуализация помогает предметно обсуждать нечто, чего еще нет. Но мы же и так можем обсуждать такие вещи. Но интересно то, что даже если наглядно визуализировать набор идей, которые уже ранее обсуждались худо бедно командой, и даже относительны понятны и, можно сказать, что уже виден лез за деревьями текущих проработок, то эти визуализации позволяют увидеть не только лес, но и даже другой лес за ним. Иными словами, если накидать даже не самое релевантное и не самое перспективное говно в кучу, то от системного эффекта (той самой эмерджентности) запустится некая химическая реакция, и в этой куче появятся конфеты новые сущности, которые окажутся намного перспективнее, чем изначальные мутные идеи и соображения. Вроде бы ничего неочевидного, но этот принцип — визулизировать сразу много всего нового в одном подходе — нужно брать на заметку, особенно если стратегия продукта завязла в текущем и есть кризис идей. Главное, не отбрасывать их из кучи слишком рано — пусть какое-то время гнилые углеродные жизненные формы полежат вместе, спрессуются, и в итоге там появится и уголь, и даже немного алмазов. * * * Ох простите, если это звучит как мусоленье, но сегодня прямо очень четко виден был этот эффект — до встречи мне казалось лишь что я просто высосал из пальца с десяток мелких или не очень релевантных идей, прибавил туда ещё свои старые, которые уже озвучивал, ну и переживал, что не внёс почти ничего интересного, но результат встречи превзошёл все ожидания и, хочется верить, этот небольшой стартап получил второе дыхание, которого хватит и на какое-то время после моего ухода.

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

Вытащу из «инспирационного» канала сюда — на первый взгляд маркетинговый, не на редкость подробный обзор решений платформы Honeywell для малой/средней авиации — https://www.youtube.com/watch?v=Ce_md5A7GYI. Вкусное начинается с 3-ей минуты. А ещё маленький момент — стилистика интерфейс, конечно, могла бы быть, мягко говоря, получше. Но вот в таких системах шрифт и стилистика кнопочек — последнее, что волнует пользователей. А UX прямо очень интересно сделан для неконвенционного, как я понимаю, оборудования.

Надо бы немного оживить проект, вернув его к историям. Поскольку у меня пара методичек в процессе — про погодные визуализации и про многоэкранные системы(а завяз я, как ни странно, на иллюстрациях, особенно в погоде), то попробую подкидывать какие-то мелкие фишки, которые всплывают в рабочей рутине (или подготовке этих опусов), достаточно компактные, чтобы не вогнать в сон и не потратить кучу времени на систематизацию. Думаю всё равно полезными будут. Под аппаратку или под задачи Итак, в большинстве случаев мы проектируем интерфейсы исходя из статистики того, что есть у пользователя — если это мобильные устройства, то мы смотрим чем пользуются условные 90-95% потребителей — и, разумеется, давно отшвыриваем какие-нибудь древние айфоны и андроиды. Если под десктоп — смотрим браузерную статистику и т.п. Это, конечно, верно и для профсистем, особенно более-менее платформенных, с большим количеством инсталляций, и которыми пользуются на рабочих компьютерах. Такой подход редко подврегается сомнениям, ибо завязан на коммерцию (т.е. широту охвата), но меж тем, у него есть и недостатки. Например, все эти попытки запихнуть в мобильный телефон полнофункциональное приложение — изначально компромиссные решения. В одних случаях (в первую очередь потребительских) это терпимо, но если система обладает большой информационной нагрузкой со сложными связями, либо если у нас много элементов управления и нужно максимально быстро переключаться с одной задачи на другую, особенно в реальном времени — то эта затея будет обладать большим количеством минусов. Иногда нам нужны большие экраны, чтобы видеть сразу больше и находить нужную кнопку немедленно. Если говорить о более специализированных системах, то в таких случаях мы можем выбирать аппаратные средства, ибо цена оборудования может быть намного меньше, чем цена всей системы, либо же сама система – это единый программно-аппаратный комплекс (ПАК), а то и часть еще большей инженерной системы (завод, судно, самолёт). В таком случае мы можем не отвлекаться на компромиссные решения по попытке упихнуть всё в мелкие, или масштабировать в разные устройства, а выбирать и контролировать аппаратные средства более свободным образом — то есть идти от задач, а не от техники. И прямо выбирать — если у нас несколько одновременно используемых режимов, то можно разбить их на несколько экранов, если нам нужны элементы интерфейса для свойств (“инспектор”) и инструментов к холсту (карте, изображению, видео) — лучше взять широкоформатный экран, а если у нас навигационная система для рек — то возьмем подобный экран и поставим в портретной ориентации в консоли, и так далее. То же самое со средствами управления — может стоит вынести некоторые органы управления в физику (джойстики, кнопки, слайдеры), а не полагаться как на данность на сенсорные экраны с их ограничениями или клавиатуру и мышку? Таких примеров вообще может быть много. Я хочу лишь сказать, что проектирование взаимодействия — это дорога в двух направлениях, стоит идти не только от инженерии к задачам, но и от задач к инженерии. Разумеется, ресурсы/бюджеты здесь (как и везде) являются определяющими, но учитывать это стоит. Опять же, очень многие вещи теперь доступны и в частных небольших проектах, благодаря относительно дешевой компонентной базе и возможностям аддитивной печати. На мой взгляд, это сильно недооцененное направление размышлений. #мысливслух#кудаглядеть

К слову, для тех кто не знает, почему у моего проекта Protraktor такое имя —вот это и есть настоящий морской протрактор, классический навигационный инструмент определения позиции на карте по пеленгам (линиям позиции) на известные объекты.