Русский
Русский
English
Статистика
Реклама

Интерфейс

Из песочницы АСУДД. Разработка всей системы и интерфейса к ней

28.07.2020 14:05:45 | Автор: admin

Вступление


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

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

Про управление


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

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

Интерфейс


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

Начало реализации


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

На самом деле, это довольно распространённый подход: имеется некоторый сервер, который выдаёт сырые данные; они принимаются другим сервером, который, в свою очередь, преобразовывает их и предоставляет клиенту. Иногда бывает и вовсе конвейер, когда проходят несколько ступеней обработки, на каждом из которых может быть заинтересованный клиент. Но это так, лирическое отступление.

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

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

Общая структура и её взаимодействие


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

Всё АСУДД состоит из следующих блоков:

  • Ядро приложения
  • Универсальный драйвер оборудования(обеспечивает взаимодействие ядра с оборудованием)
  • База данных (мы использовали postgresql)
  • Сервера дорожных станций (если коротко это промышленные компьютеры, работающие на местах оборудования; обеспечивают повышенную отказоустойчивость и ещё много чего)
  • Очередь сообщений (у нас RabbitMQ), обеспечивающая взаимодействие всех блоков приложения в ЦОДе
  • Интерфейс (о нём я подробней расскажу дальше).

Конечно, был ещё дополнительный софт для наблюдение за оборудованием и специальный софт для работы с некоторыми видами оборудования (вроде Zabbix), однако я этого практически не касался, поэтому данный момент рассматривать не стану.

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

Преимущества наступили сразу же: разработка более не требовала держать в голове все существующие зависимости, а развёртывание стало предсказуемым и контролируемым. В повышении удобства этого процесса огромную роль сыграл на разработчик ядра, написавший сборщик дистрибутива и внедривший Ansible для развёртывания приложения. Сборка новой версии продукта и её развёртывание превратились в рутинную операцию, в то время как в самом начале этот процесс вполне мог занять целый день.

Но я забежал вперёд. Ansible и сборщик пакетов появится только спустя 3 года с начала разработки. А мы, пока что, только готовились к своей первой установке.

Что же из себя представлял интерфейс


Думаю, следует немного отвлечься от технической части. Но только в этом разделе.
По сути, все системы АСУДД являются SCADA (аббр. от англ. Supervisory Control And Data Acquisition диспетчерское управление и сбор данных) системами. Это некоторая условная схема (мы её называем мнемосхемой) размещения объектов и оборудования, а также возможность взаимодействовать с ней через пользовательский интерфейс.

Вот так вот выглядела наша мнемосхема:

image

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

Сам интерфейс отрисовывался на SVG: решение выглядело наиболее простым и быстрым (конечно, мы смотрели и в сторону WebGL, и разных надстроек, вроде three.js, однако получалось сложно и долго, нам же нужна была быстрая победа). Кстати, именно быстрота работы с SVG и определила выбор Chrome: он обыграл Firefox по производительности более чем в 2 раза.

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

Важной частью системы является сигнализация: дорожная и техническая. Если просто, то дорожные сигналы это то, что произошло на дороге (выпал снег, случилось ДТП итп), а вот технические это, обычно, какой-то отказ оборудования (и эти сигналы были, есть и будут всегда, потому что, как показывает наблюдение, 100% исправленного оборудования не бывает никогда).

Карточки событий это инструмент фиксирования происшествий. Упала корова на дороге и мешает движению заводится карточка событий. Суицидник решил прыгнуть с моста и был замечен диспетчером на камере карточка событий. Проще говоря, это журнал всех значимых происшествий. В нашем приложении мы уделили мало внимания данному разделу, в то время как существуют целый стандарты (вернее стандартищи, включащие в своей структуре справочников даже падения метеоритов) описания дорожных событий. Наша же карточка события была существенно скромнее, однако была довольно гибкой в настройке: мы используем JSON файлы для описания полей и их взаимодействие. Получается не так, чтобы очень просто, но вполне человекопостигаемо. Вот пример карточки события:



Несколько слов хочется сказать о камерах. Благодаря нехитрым манипуляциям с настройкой выходного потока с камеры, нам удалось без шума и пыли вывести видеопоток прямо в браузер. Не мудрствуя лукаво, мы использовали MJPEG (motion jpeg), так что нам хватило стандартного элемента IMG для отображения текущего состояния. Там, правда, в какой-то момент вылезли некоторые трудности, связанные с отображением видео, но это было не фатально. Например, вот так выглядит диалог камеры, установленной на одном из участков трассы М3:



Хочу заметить, что это довольно умная камера со множеством различных возможностей (например, мытьё и очистка стекла объектива). Всё это мы, разумеется, поддержали.

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

Опорные данные приложения


Но вернёмся к технической части. Для работы приложения требовался большой объём данных. По сути, требовались почти все данные, которыми располагало ядро, т.к. многие решения принимались на основании именно их. Очень распространённым был случай, когда приходили какие-то данные, отреагировать на которые следовало лишь через 5-10-30 минут. При этом была вероятность, что за указанный интервал времени эти данные утратят актуальность.
Так мы пришли к концепции словарей. Все данные, необходимые для принятия решения, загружались на клиент после входа пользователя в систему и поддерживались в актуальном состоянии.

То есть нам требовалась двусторонняя связь клиента с сервером. Изначально, очень просились на эту роль сокеты, однако в силу природной лени, мы остановились на уже готовом решении SSE. Да, формат был не идеальным, но покрывал функциональность на 100%.

Безусловно, была введена система контроля версии данных и периодическая пересинхронизация. Особое опасение вызывал объём словарных данных, хранимый на клиенте. Однако, проведя исследование и подсчитав предельный объём используемых данных, то даже со стократным запасом он не превышал бы 50-100 мегабайт. Кроме того, изначально закладывалась возможность оптимизации. Так что на этот риск мы пошли смело.
Вторым типом словарей была информация об оборудовании. Тут каждый объект (считай, каждый элемент оборудования) имел свою собственную структуру данных, меняющуюся по мере того, как изменялось состояние объекта. Они подгружались по тому же каналу связи, но отдельно.

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

Тут надо рассказать и о ложке дёгтя в данной бочке мёда. Дело в том, что существующие решения для отслеживания sse сообщений (по крайней мере внутри devtools), не позволяют показать всё сообщение целиком (а у нас ходили длинные json строки), что значительно усложняло отладку, так как нельзя было проверить, что за данные пришли. По этой причине, пришлось сделать дополнительную консоль отладки, отображающую все приходящие пакеты, но это не было какой-то тяжёлой работой.

Всё прочее


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

В качестве основного фреймворка, на котором работает приложения, был выбран angularjs. Кто-то может счесть данную технологию несколько устаревшей, но на момент старта проекта он очень хорошо удовлетворял поставленной задаче, а angular2 был ещё весьма сырым и рисковать не хотелось. Помимо основного фреймворка, позже, как я ни сопротивлялся (старался, по возможности, минимизировать количество используемых технологий для простоты поддержки), появились другие библиотеки: d3, lodash, printjs. Не то, чтобы они были необходимы, но с ними жизнь немного упростилась. В частности, d3 мы использовали для построения графиков (у нас была несколько нестандартная система визуализации параметров, так что ничего доступного не подошло).

Примерно с этим багажом мы вышли на приёмосдаточные испытания и даже прошли их. В последствии были ещё доработки, но они были уже из разряда косметики.

Сборка


Когда всё только начиналось, до конца не было понятно, что же из всего этого получится. В то время grunt был отличным и популярным средством сборки и он был отличной альтернативой, нежели ничего.

Не могу сказать, что это безнадёжно устаревший подход. Он долгое время исправно выполнял свою роль, до тех пор, пока не появилось достаточно много файлов, размещение, порядок подключение и взаимодействие которых требовало некоторой последовательности. Так, спустя почти 4 года использования, мы переехали на webpack.

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

Немаловажным фактором был процесс настройки CI/CD. Лично я к этому вопросу подходил, как минимум, два раза. Пробовал jenkins и bamboo. Первый мне больше знаком, так как с ним доводилось работать ранее, второй очень хорошо интегрировался в нашу экосистему (у нас использовалась вся линейка продуктов от Atlassian), однако с ним постоянно возникали сложности (в 9 случаях из 10 они упирались в права доступа и отсутствие ресурсов), которые невозможно было решать достаточно оперативно, что ставило жирный крест на использование технологии. В конечном итоге мы-таки сформировали процесс, однако до сих пор так его и не внедрили, но это уже совершенно бюрократическая история.

Компоненты как средство выживания


Кто имел дело с angularjs, тот знает, что у него есть немало своих собственных сущностей для обозначения и интеграции какой-то функциональности. Например, есть сущность service, которая, по сути, является описанием класса и возвращает объект (обычно одиночку / singleton). И когда разрабатываешь в парадигме фреймворка, поначалу охотно используешь предлагаемую функциональность.

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

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

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

Сервер отладки


Когда работаешь со сложным приложением, которое, вдобавок, требует от сервера некоторой интерактивности, то требуется, помимо статичного сервера, что-то вроде сервера разработки: специального сервера, который поставляет данные (правильные или неправильные) для эмулирования ситуаций и отладки.

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

Решение было найдено простое, как апельсин: мы взяли node.js, который запускался через nodemon (надстройка, автоматически перезапускающая скрипт при любом изменении входных файлов), подключили к нему express.js и так у нас появился свой собственный сервер отладки. Oauth авторизацию и sse реализовать было относительно просто, так что в какой-то момент у нас появился ничем не уступающий ядру аналог, снабжающий разработку управляемыми данным.

За него, разумеется, пришлось побороться с архитектором и разработчиками ядра, свято веривших в то, что отлаживаться на чём-то отличном от ядра святотатство, однако, в том раунде победа осталась за нами.

Проект vs продукт


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

Так, в результате продолжительных дебатов, интерфейс и ядро нашей АСУДД раскололись на две части: продуктовую и конфигурационную. Хотя, наверное, правильней сказать, подобная возможность оговаривалась изначально, вот только в виду сжатых сроков была отложена.

Продуктовая часть развивалась отдельно и поддерживала весь имеемый функционал: все специальные диалоги и ядерные методы. Конфигурационная (или проектная) часть содержала в себе набор файлов, на основании которых создавался файл настройки, указывающий откуда какие данные брать, как отображать то или иное оборудование.

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

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

Для начала, мы отказались от написание длинного json файла (кто правил такие знает, насколько это неудобно, да и лишняя запятая может, внезапно, поломать обратный разбор). Вместо этого стали использовать js файлы в схеме, используемой node.js (require.js). Теперь все настройки были разнесены по отдельным секциям и правились, в случае необходимости, относительно просто.

Затем, мы пересмотрели способ доставки ресурсов. Изначально, они подгружались при инициализации с сервера. Это не занимало много времени, но и нужды в этом особой не было. Теперь они начали упаковываться внутрь конфигурационного файла, разворачиваясь в память уже на сервере в момент загрузки. А так как у нас был довольно толстый канал связи и предполагалось кэширование, распухший файл конфигурации не пугал.

Потом мы занялись элементами полевого оборудования: их было решено делать автономными модулями, каждый из которых имел angularjs-обрабатываемую вставку в диалог, настройки для диалога, скрипт управления иконками и ещё много всяких мелочей. Подумав, я принял решение расширить список используемых технологий и добавил возможность применения сторонних фреймворков, например, react.js.

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

Что-то вроде выводов


На данный момент, наша АСУДД установлена как минимум на 3 объектах и, возможно, в обозримом будущем появится на четвёртом. Не так давно, мы подключили к проектам sonarqube и собрали некоторую статистику. Выяснилось, что код интерфейса примерно в 3 раза больше, чем код ядра и почти в 2 раза больше, чем код всего остального приложения. Так, незаметно для себя, я стал управляющим самого большого актива нашего направления. И это позволяет мне сделать кое-какие выводы, которые я сделал в рамках данного проекта (и вообще, и в частности):

  • Самый главный ресурс любой команды это человек; если есть рядом человек он может научиться тому, чего не знает и сделать то, что требуется сделать, даже если на это уйдёт больше времени; если же человека нет то работа не будет сделана в принципе.
  • Нет ничего хуже технического долга, потому что именно он заставляет переписывать проекты. Вчера воткнули костыль, сегодня по просьбе менеджера сделали по-быстренькому, завтра что-то сделали на скорую руку, а спустя полгода кодовая база превращается в месиво, в котором сходу не разобраться и для даже мелких изменений может потребоваться очень много времени.
  • Технологии постоянно развиваются и невозможно постоянно быть на волне, однако хорошо продуманная архитектура позволит сравнительно безболезненно не только поменять технологии, но и сделать это в короткие сроки. Отсутствие данных разработок, зачастую, приводит к смерти продукта или финансовой нецелесообразности его дальнейшей поддержки. Кстати, это актуально и для предыдущего пункта.
  • Разработка программного обеспечения это не только написания кода. Это, зачастую, путь от задумки до рабочего стола клиента. И этот путь следует продумать ещё до того, как будет написана первая строчка кода. Недаром в последнее время професси devops становится всё более и более востребованной.

Но это, как можно заметить, относится не столько к разработке АСУДД, а к разработке в принципе.

Что дальше


Конечно мы планируем дальнейшее развитие нашей АСУДД. И планы, как водится, наполеновские. Есть желание улучшить картографическую подложку, оптимизировать загрузку приложения, рассмотреть использование webGL технологий вместо SVG (и пяти лет не прошло, как мы вновь о них вспомнили) ну и, конечно, сделать автогенерируемую мнемосхему (сейчас она рисуется дизайнером). Так что планов много.
Подробнее..

Что не так с интерфейсами SCADA-систем

08.11.2020 16:19:40 | Автор: admin

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

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

Для наглядности разберем пример с торговым центром. Чтобы привлечь как можно больше посетителей, руководство ТЦ старается сделать их шоппинг максимально комфортным и, как следствие, ТЦ оборудован десятками сложных систем: свет, вентиляция, кондиционирование, теплоснабжение, водоотведение и многие другие, которые скрыты от глаз посетителей.

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

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

Пример интерфейса, собранного из готовых библиотекПример интерфейса, собранного из готовых библиотекПример интерфейса диспетчеризации теплового пунктаПример интерфейса диспетчеризации теплового пункта

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

Это моя любимаяЭто моя любимая

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

Для начала посмотрим, какие интерфейсы наши коллеги делают для умных домов:

Пример интерфейса, с сайта iridiummobileПример интерфейса, с сайта iridiummobile

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

Интерфейсы умных домов разнообразны: они могут нравиться или нет, могут устареть через пару лет или сохранять актуальность годами, быть выполненными в дизайне iOS или Android, могут быть удобными или неудобными, но вне зависимости от всего этого они прорабатываются и на них тратятся ресурсы и время.

Аналогичная ситуация и с промышленным оборудованием. Производители тратят деньги и время на разработку и улучшение своих продуктов, учитывая опыт эксплуатации.

Анализатор качества электроэнергии, фото из интернетаАнализатор качества электроэнергии, фото из интернета

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

Во-первых, на объекте всегда горят сроки. Всегда. Не бывает стройки, которая завершается вовремя или досрочно. Система диспетчеризации это последняя стадия объекта, она разрабатывается после того, как все инженерные системы прошли пусконаладочные работы.

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

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

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

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

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

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

В конце концов, сейчас у всех в руках смартфоны с современными ОС и приложениями люди давно уже привыкли к хорошим качественным интерфейсам, а мы заставляем их возвращаться в прошлое во времена Windows 98.

Немного резюмируя

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

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

Что будем делать?

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

Один из объектов 2016 года. Панель оператора станции водоподготовки. Здесь много лишних ужасных рисунков, переменные неочевидные и теряются в синей обводке, лампочки взяты как раз из стандартной библиотекиОдин из объектов 2016 года. Панель оператора станции водоподготовки. Здесь много лишних ужасных рисунков, переменные неочевидные и теряются в синей обводке, лампочки взяты как раз из стандартной библиотеки

На просторах фриланса я нашел дизайнера, чьи работы мне понравились, и мы с ним за 2 недели сделали неплохой интерфейс для панели оператора. Эта панель легла в основу всех дальнейших интерфейсов, с каждым объектом мы дорабатываем, улучшаем, но концепция сохраняется.

Панель оператора системы приточно-вытяжной вентиляции. 2017 год. 7 дюймов разрешение 800 х 480Панель оператора системы приточно-вытяжной вентиляции. 2017 год. 7 дюймов разрешение 800 х 480

Цвета подобрали из палитры material design, отрисовали заново все иконки, сделали ровные и кратные отступы, подобрали шрифт и его размер. Тогда мы еще использовали трехмерные картинки и анимацию.

Важный момент: дизайнер всю работу сделал в Photoshop, после чего мы нарезали все элементы по-отдельности и начали собирать в среде разработки для панели оператора. Это оказалось очень неудобно: некоторые элементы начинают гулять, и все отступы рушатся.

Сейчас мы уже делаем по-другому, абсолютно вся статика создается в Photoshop и подгружается единой картинкой, поверх которой отображаются все переменные и динамические объекты. Так мы можем ровно сделать верстку и снизить нагрузку на систему, так как панель будет подгружать один файл, а не десятки картинок.

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

Та же панель, но уже в актуальном дизайне, 2020г годТа же панель, но уже в актуальном дизайне, 2020г год

А вот так выглядит мнемосхема диспетчеризации. На общем плане здания расположены все инженерные системы: вентиляция административных блоков, вентиляция склада, ВРУ, установки компенсации реактивной мощности, котельная, температурное картирование, септики, энергоучет.

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

Рабочее место инженера, монитор 27 дюймов, разрешение 1920 х 1080Рабочее место инженера, монитор 27 дюймов, разрешение 1920 х 1080Развернутое окно с настройками системы вентиляцииРазвернутое окно с настройками системы вентиляции

Здесь диспетчеризация развернута на базе российского производителя К2 от МЗТА. Тумблеры и уставки сделаны штатными средствами, так как пока нет поддержки сторонней графики, пришлось максимально адаптировать их в интерфейс.

Подробнее о создании интерфейса диспетчеризации

Еще один очень значимый проект для меня мы реализовали в 2018 году это крупный ТРЦ в Московской области. На примере этого проекта поделюсь своим опытом и знаниями, надеюсь, кому-то это будет полезно.

Главное окно системы диспетчеризации вентиляцииГлавное окно системы диспетчеризации вентиляции

В ТРЦ огромное количество различных инженерных систем, про все рассказывать будет очень долго, тем более они имеют много общего, поэтому речь пойдет о 96 вентиляционных машинах, которые стоят на крыше и распределены в 15 венткамерах.

Топология

Главное окно вентиляции у нас содержит план ТРЦ, вид сверху, обозначения секций и расположенные на нем вентиляционные установки, привязанные к венткамерам и их фактическому расположению. Так как информации очень много, нам нужно вывести на главное окно только самую необходимую.

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

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

При клике на венткамеру откроется окно с расширенными параметрами установок, входящих в эту венткамеру. В этом окне можно посмотреть режимы, температуры и уставки, можно получить общую оценку работы системы.

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

Цвета и темы

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

Да и в целом темная тема проще для восприятия и меньше нагружает глаза, тем более при длительном использовании, тем более в темном помещение.

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

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

Шрифты и отступы

Тут все проще, используем GothamPro, только двух размеров: для подписей и статики 14 рх Medium, а для переменных 18 рх Bold.

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

Еще несколько окон с этого объекта.

Некоторые свежие наработки конца 2020 года.

Заключение

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

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

Подробнее..

Моя эволюция интерфейсов систем диспетчеризации

30.05.2021 20:12:29 | Автор: admin

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

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

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

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

Лонгрид!

2014

Главное окно с мнемосхемой на сенсорной панеле управления 7 дюймовГлавное окно с мнемосхемой на сенсорной панеле управления 7 дюймовОсновное меню с настройками на сенсорной панеле управления 7 дюймовОсновное меню с настройками на сенсорной панеле управления 7 дюймовОкно диспетчеризации, можно открыть на любом устройстве под управлением WindowsОкно диспетчеризации, можно открыть на любом устройстве под управлением Windows

Это индивидуальный тепловой пункт одного из павильонов ВДНХ в Москве, первый самостоятельный объект, где можно было проявить творческий подход. В помещении ИТП на шкафу управления установлена 7 дюймовая сенсорная панель для локального управления и облачная система диспетчеризации. Несмотря на то, что в этом интерфейсе довольно все криво и сыро, здесь есть много элементов и правил, которым мы придерживаемся до сих пор.

С самого первого объекта я начал применять темный интерфейс. У специализированных программ (AutoCad, Photoshop), был темно-серый интерфейс, в нем было комфортно работать долгое время и я решил придерживаться их идеологии. К тому же, помещение ИТП было без освещения и очень темным, делать яркий светлый фон на панеле просто издевательство над эксплуатацией. Хотя сейчас у нас в портфолио есть кейсы со светлой темой, все равно, на сегодняшний день предпочтение отдается именно темной.

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

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

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

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

2015

Приточно-вытяжная установка с гликолевым рекуператором. Панель оператора 10 дюймов.Приточно-вытяжная установка с гликолевым рекуператором. Панель оператора 10 дюймов.

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

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

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

2016

Станция ВЗУ коттеджного поселка. Панель оператора 10 дюймов.Станция ВЗУ коттеджного поселка. Панель оператора 10 дюймов.

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

На объектах, где есть технология, возникают проблемы в отрисовке из-за использования трехмерной графики. Одно дело показать насосы, клапан, фильтры и заслонки, другое дело показать технологическое оборудование. Найти в интернете подходящие картинки ультрафиолетовых ламп и фильтров очистки крайне сложно, не говоря уже о более сложном оборудовании: флотаторы, жироловки, обезвоживатели и так далее. Это одна из причин, почему мы отказались от 3Д в дальнейшем.

Структура меню не изменилась, изменился немного дизайн. Добавились иконки в пунктах меню. Иконки декоративные, какой-то пользы они не несут, скорее просто иконки ради иконок. Здесь они крупные, выполнены в стиле Flat, занимают прилично место на экране. В дальнейшем от иконок мы не отказывались, они стали меньше и аккуратнее и лучше вписываются в общую стилистику. Стоит применять иконки или нет в пунктах меню ответить однозначно сложно. Думаю, что так же как и с 3Д картинками, не под все пункты меню можно подобрать подходящие по стилю и смыслу иконки. Если есть возможность добавить аккуратные иконки, не уменьшая полезную площадь подписей, то лучше их добавить, они разбавят табличную структуру меню.

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

2017

Производственно-складской комплекс, МО, обзорная схема, 27 дюймовПроизводственно-складской комплекс, МО, обзорная схема, 27 дюймовПроизводственно-складской комплекс, МО, под экран планшета и ноутбукаПроизводственно-складской комплекс, МО, под экран планшета и ноутбука

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

2018

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

Основное отличие подхода к разработке этого интерфейса от предыдущих, это то, как рисуется вся статика. До этого интерфейс собирался по частям в среде разработки для панелей и в Scada системе, это очень усложняет процесс, особенно, выравнивание объектов. Здесь же вся статика делается в графическом редакторе и подгружается одной картинкой PNG на экран. Сверху накладываются только переменные и анимация. Это сразу убивает несколько зайцев: выравнивать и делать отступы можно с большой точностью, скорость загрузки страниц увеличивается, так как нужно меньше информации подгружать из памяти, уменьшается нагрузка на процессор.

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

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

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

Первое видео было с панели оператора 7 дюймов, которая установлена на дверце шкафа управления, разработка дизайна интерфейса началась с нее, дальше будут экраны с мониторов системы диспетчеризации.

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

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

Что касается главного экрана, то здесь реализован "карточный" интерфейс. Смысл его в том, чтобы структурировать информацию по системам, на каждую сделать свою карточку и разместить ее на схеме здания. Если систем много, можно разделить их по нескольким экранам, если не много, то можно все показать на одном экране и отделить разные схемы цветами. На карточке нужно отображать только самые основные параметры, которые влияют на работоспособность установки и которые можно сравнивать между собой. Для вентиляции наиболее важными параметрами являются: статус работы, наличие аварий, режим зима/лето, температура канала, помещения и обратной воды. Дополнительно стараемся отображать обороты вентилятора, процент открытия клапана и задание уставки температуры. Эти значения позволяют быстро оценить стабильность работы вентсистем и теплоснабжения установок, не переходя к схемам каждой системы отдельно. Очень удобно на одном экране сравнивать параметры работы разных систем. Если, например, наблюдается недогрев по многим системам, значит есть проблемы с теплоснабжением из котельной.

У нас есть объекты, которые имеют один этаж и там удобно все карточки систем размещать на планировке здания, привязывая к их реальному местоположению на плане. Есть объекты в 4-5 этажей, и здесь становится сложнее структурировать карточки. Можно разделить экран на 4 равных части и на каждом отобразить свой этаж с системами. Можно сделать 4 экрана, на каждом свой этаж с нанесенным на нем системами, но здесь могут быть нюансы, как правило, большая часть систем располагается на -1 этаже и на последнем или кровле, что приводит к сильному дисбалансу. Мы пробовали разные варианты, расскажу об этом чуть дальше в статье.

2019

Приточно-вытяжная установка, панель оператора 7 дюймовПриточно-вытяжная установка, панель оператора 7 дюймовМенюшка, панель 7 дюймовМенюшка, панель 7 дюймов

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

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

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

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

  1. Освобождаем интерфейс от всего лишнего, уменьшаем количество статических элементов, убираем все 3Д. Структурируем содержание по карточкам или вкладкам, оставляем больше места для динамических значение.

  2. Наводим порядок в цветах для удобства взаимодействия пользователя с интерфейсом. Оттенки темного цвета используются для фона, полей и заголовков, серым обозначаются подписи и весь текст в целом. Белый это переменные и все динамические значения. Яркий синий это цвет акцента, им обозначаются все элементы, с которыми пользователь может взаимодействовать, кнопки и уставки. И стандартные цвета: зеленый, желтый и красный, отвечают за состояние и индикацию.

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

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

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

Здесь очень удачно планировка ТЦ вписалась в разрешение Scada системы примерно 1920 х 980 рх., это позволило расположить максимум полезной информации с привязкой к физическому местоположению. Так как систем много (около 150 штук) то лучший вариант разбить их по венткамерам, где находятся щиты управления, отобразить системы как название и подкрашивать его в зависимости от состояния. Серый выведен из эксплуатации, белый стоянка, зеленая работает, желтая требует обслуживания, красный авария. Дальше архитектура строится так: при клике на венткамеру открывается табличный вид связанных систем с их основными параметрами. При клике на название системы уже откроется мнемосхема со всеми доступными параметрами и настройками.

Хотя здесь есть некоторые не доработанные моменты: кнопки сброса, индикаторы аварии, зима/лето, все равно это один из самых удачных результатов работ за все время работы. На этом объекте мы провели много дней и ночей и все это время пользовались своей же работой, и по своим субъективным ощущениям, эксплуатировать технологические системы в этом интерфейсе максимально комфортно.

2020

Приточно-вытяжная установка с увлажнением, монитор 25 дюймовПриточно-вытяжная установка с увлажнением, монитор 25 дюймовПриточно-вытяжная установка с увлажнением, монитор 25 дюймовПриточно-вытяжная установка с увлажнением, монитор 25 дюймовОбзорная схема системы диспетчеризации, медицинский центр, монитор 23 дюймаОбзорная схема системы диспетчеризации, медицинский центр, монитор 23 дюймаОбзорная схема системы диспетчеризации ТРЦ Рассвет, Москва, монитор 23 дюймаОбзорная схема системы диспетчеризации ТРЦ Рассвет, Москва, монитор 23 дюймаМнемосхема приточно-вытяжной установки.Мнемосхема приточно-вытяжной установки.

Так, ну в этом году продолжилось логическое развитие интерфейсов с некоторыми экспериментами. Расскажу по порядку.

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

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

Если вы дочитали до этого места, то скорее всего обратили внимание, что впервые появился светлый интерфейс =). Появилась очень интересная идея сделать универсальный интерфейс с темной и светлой темой и переключать его либо автоматически от времени суток, либо вручную. Реализовали эту идею так: подложки на 95 процентов прозрачные с небольшим оттенком серого, статические элементы имеют цвета не сильно контрастирующие на темном и светлом фоне, переменные имеют подобранный серый цвет, больше контрастирующий на темном и светлом фоне. По сути, мы только меняем цвет фона с белого на темно серый, а все элементы остаются без изменения. С точки зрения работы Scada системы процесс максимально простой, подмена одного фона на другой, без замены других элементов, это не перегружает процесс работы и отрисовки. У такого решения есть минус, сложно подобрать цвета одинаково правильно отображающиеся тут и там, от этого переменные немного теряются на общем фоне. Есть вариант вместе с фоном менять скриптами и цвета переменных и других элементов, но не понятно насколько это может загрузить процесс отрисовки.

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

2021

Главное окно системы диспетчеризации, логистический центр, МОГлавное окно системы диспетчеризации, логистический центр, МОМнемосхема приточно-вытяжной установкиМнемосхема приточно-вытяжной установкиЭкран работы вентустановки воздушного отопленияЭкран работы вентустановки воздушного отопленияОбзорная схема работы котельнойОбзорная схема работы котельной

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

В водяном нагревателе, как ранее уже писал нужно показать температуру обратной воды, процент открытия клапана, статус работы насоса и аварийный сигнал. Процент открытия клапан нагрева наиболее важное значение, поэтому я поместил его в центр и сделал большим шрифтом. Помимо самого значения, вокруг круглой плашки есть заполняющая его линия по кругу, она двигается по часовой стрелке и заполняет обводку круга пропорционально значению от 0 до 100. Температура обратной воды показан в круге, но уже меньшим шрифтом, и она поменяет свой цвет, если значение будет слишком низким. Если произойдет авария по термостату или по низкой температуре обратной воды, то вся обводка круга загорится красным цветом, инженеру будет понятно, что авария пришла именно с нагрева. Помимо этого добавил еще один режим "прогрев", в момент запуска вентиляции в зимнем режиме, перед пуском установки открывается клапан и прогревается до заданной температуры, в этот момент обводка плавно мерцает рыжим цветом. В стоянке в зимнем режиме обводка окрашена в белый цвет, означает, что насос работает, зимний режим включен, клапан поддерживает заданную температуру обратки. В летний период обводка становится серой и "выключается", тем самым мы понимаем, что водяной нагрев не активен.

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

С точки зрения Scada системы, мы имеем набор кадров (в нагревателе больше 100 кадров), которые меняются в зависимости от условий. Никаких GIF анимаций и наложенных слоев, отрисовка и реакция происходит мгновенно.

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

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

2022

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

Надеюсь, вы нашли в статье что-то полезное для себя. Буду рад, если оставите свою критику и комментарии, напишите, какой интерфейс больше понравился вам и почему.

Подробнее..

Кейс аналитика системы освещения в логистическом центре

17.06.2021 20:21:19 | Автор: admin

Поделюсь одним интересным кейсом, как мы сделали пилотный проект системы контроля освещением и что из этого получилось.

Клиент: крупный логистический центр в Московской Области, с которым мы работаем с 2016 года. За это время мы провели уже много работ по диспетчеризации инженерных систем, вывели в единую BMS вентиляцию, котельную, энергетику, отопление, энергоучет и много чего еще. А в этом году решили добавить еще и диспетчеризацию освещения в общую систему.

Что имеем? Установлен силовой шкаф управления освещением на 45 линий: складские ряды, коридоры, мезонин. На каждой линии установлен автомат защиты и модульный контактор. Помимо силового щита есть щит управления с ручным и автоматическим управлением. Автоматическое управление подразумевает включение и выключение линии по датчику движения, которые установлены в рядах, где двигается техника. Некоторые линии находятся в ручной режиме и постоянно включены, а некоторые, наоборот выключены. Задачу нам поставили следующую: отслеживать работу каждой линии, отслеживать залипание контакторов, оповещать о неисправностях и получать аналитику по наработке. Можно было бы полностью заменить шкафы, сделать дистанционное управление, расписание и много чего еще, но это было бы очень сильное удорожание проекта, а нас попросили именно вписаться в небольшой бюджет не меняя того, что и так работает стабильно.

Задача поставлена, начинаем реализацию. Есть несколько способов отследить работу линии освещения. Самый простой способ это использовать свободный или дополнительный контакт модульного контактора. Но конкретно в нашем случае эта схема не сработает, так как питание катушки контактора идет от общего автомата и возможна ситуация, когда на линии освещения контактор будет замкнут, а автомат выключен и питания на линии не будет. Этот способ будет работать только если питание катушки контактора идет из под автомата этого же контактора. Можно было бы поставить дополнительные контакты положения и сработки к автоматам, это даст более полную картину, но в нашем случае места в шкафу не было от слова совсем и раздвинуть автоматы для дополнительных контактов просто не было возможности. Решили пойти самым надежным путем, взять непосредственно фазу, идущую на питание линии и завести ее на контроллер. Так как у нас большая часть автоматики на объекте сделана на отечественных Контарах, то мы просто взяли модули расширения, которые воспринимают 220 вольт на входе. Это не частая опция у контроллеров, поэтому, если бы стоял другой производитель, пришлось бы ставить 45 промежуточных реле. Получился аккуратный и не большой шкаф диспетчеризации, мы повесили его рядом с силовым шкафом и обвязали все аккуратно многожильным кабелем. Расключение шкафа и отключение света согласовали заранее, а на все работы ушло около 1,5 часов.

Подключаем сигнальные линииПодключаем сигнальные линии

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

Силовой шкаф до расключенияСиловой шкаф до расключения

Дальше разрабатываем интерфейс пользователя.

Основное окно секции освещения Основное окно секции освещения

Здесь 46 линий разбитые на 2 экрана. Порядковый номер, состояние линии (включена, выключена, неисправна) и комментарий. Внизу есть оперативный график, можно посмотреть, как менялось состояние линии за последний час. Линии можно переключать, на скриншоте выбрана 16 линия.

На этом экране можно получить оперативную информацию о состоянии освещения. Есть отдельные окна трендов и настроек.

Окно с настройкамиОкно с настройками

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

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

Временные трендыВременные тренды

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

Отчет за выбранное времяОтчет за выбранное время

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

Отчет за выбранное времяОтчет за выбранное время

Вторая страница отчета выводит ту же информацию, но в виде диаграмм.

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

Подробнее..

Продуктовый дизайнер правила эксплуатации

23.09.2020 14:17:26 | Автор: admin


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

Один из видов дизайнеров достаточно нового направления продуктовый.
В статье именно о нем я и хочу поговорить.

Ударю по теории и практике.

В теории хочу разобраться кто это такой и что от него хотят.
На практике описать процесс работы этого самого дизайнера над тем самым продуктом.

Поехали!




Часть первая. Теоретическая.
Кто такой, сколько стоит и чего ожидают


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

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

Вот что говорят курсы.

Нетология обещает зарплату от 120 тыщ. рублей
UX/UI дизайнер, дизайнер продукта одна из самых востребованных digital-профессий с широкими возможностями для роста и высокой заработной платой
Она сочетает в себе аналитику и творчество, инженерный подход и нестандартность решений. Грамотная работа дизайнера увеличивает прибыль клиента и улучшает взаимодействие пользователя с продуктом.

Skillbox приманивает зарплатой от 80 тысяч.
Продуктовый дизайнер отвечает за создание и развитие продукта: от идеи до выхода на рынок.
Вы научитесь продумывать бизнес-стратегию, работать с IT-командой, проводить исследования и проектировать дизайн-системы.

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

Вообщем достаточно размыто все в описаниях.

Теперь кинем взор на hh.ru и посмотрим, чего же реально ждут работодатели от человека, именуемого продуктовый дизайнер.

Действовала я топорно и без изысков: вбила в поисковую строку Продуктовый дизайнер и выписала часто встречающиеся требования.

Хозяйке на заметку: в вакансиях уровень зарплат часто не указывают, поэтому реальную картину понять достаточно тяжело.

Но могу огорчить обещателей и ожидателей зп от 100 тыщ.
Есть, есть компании, которые хотят много, но платить за это много совсем не готовы.

Ну и погнали теперь по общим требованиям:
  • Опыт работы в дизайнерских и около того программах (Sketch, Zeplin, Figma, InVision, Adobe Photoshop и пр.);
  • Опыт работы с web, iOS и Android (потому что есть шанс, что будешь и там, и тут);
  • Разбираться в современных трендах дизайна;
  • Красиво визуализировать что дадут. А дать могут не только сложные и интересные фичи, но и баннеры, лендинги, иконки или иллюстрации. Отсюда, соответственно, вытекает знание основ композиции, типографики, и прочих таких необходимых простому дизайнеру штук;
  • Шарить в паттернах человеческого поведения. Быть в курсе того, что в мире проектирования интерфейсов твориться, что бы не только спроектировать, но и свою гипотезу выдвинуть, а чужую аргументированно задвинуть. На основе чего ты будешь выдвигать и задвигать это уже тебе либо скажут, либо сам придумаешь;
  • Быть ux-аудитором проверить то, что уже есть и исправить это в лучшую сторону, естественно;
  • Бодро отслеживать конкурентов, постоянно держа руку на пульсе;
  • Уметь общаться с пользователями. Это про проведение разного рода исследований и тестирований;
  • Уметь дизайн-систему если не создать, то руку к уже готовой приложить;
  • Где-то надо будет заняться еще и аналитикой (тут в зависимости от ситуации: либо понимать, что тебе говорит и показывает аналитик, либо быть тем самым аналитиком);
  • Грамотно писать тексты, так что местами надо будет совмещать роль и ux писателя;
  • Уметь быстрого прототипировать. Что бы идеи показать, проверить, оттащить пользователю на тест;
  • Понимать что frontend могет, а чего не могет. А так как сейчас frontend могет практически все, только дай ему время и вдохновение, то лучше понимать время, которое займет у разраба твой дизайнерский или интерфейсный креатив; Не забываем следить за качеством того, что все-таки front накреативит в итоге по твоим макетам;
    Кстати, про креатив. Этот свой креатив лучше всего совмещать с логическим мышление на одних плечах;

Ну и так, по мелочи: навыки презентации своей работы, умение аргументированно спорить с разрабами, самоорганизованность, многозадачность и пр.

Вообщем, требования достаточно обширные. Где-то больше, где-то меньше.
Надеюсь основное направление понятно.

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



На самом деле все у всех по-разному.

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

Но это лично мой опыт. Может у кого-то совсем и не так.

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

А когда ты в одном лице и швец, и жнец, и на дуде игрец, то, понятное дело, разорваться из одного большого продуктового дизайнера на кучки мелких ux и ui -дизайнерика, ux-исследовательчика, копиральщичка, художничка и аналитичка просто сил нет никаких. Кстати, времени тоже. Но тут все, опять же, зависит от времени, сложности и прочих небесных тел.

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

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

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

Потому что делать все равно надо.

Ну а как?

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



Часть вторая. Практическая.
Основана на реальных событиях.


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

И об этих светлых пятнах и будет мой рассказ.

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

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

Итак

Сбор требований с заказчика


Требования можно собирать от Product Owner, заказчика, или другого ответственного лица.

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

Требования надо собирать тщательно, не оставляя ни одного белого пятна.

По хорошему, этим должен заниматься бизнес-аналитик. Узнал, записал, принес, сделал Чмоки и махнул ручкой на прощание.

Но, имея за плечами горький опыт сломанного телефона, уверена, что этим должен заниматься продуктовый дизайнер. Ну или присутствовать при сборе требований.

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

О диктофоне, кстати, хочу сказать отдельно: если не используете его в своей работе начинайте использовать. Функция полезная до безобразия. Когда ты знаешь, что весь разговор записывается, ты можешь на нем сосредоточиться, не растеряв по пути фокус внимания, отвлекаясь на записи и прочее.

Сбор требований с пользователя


Это уже другая сторона медали.

Вот ты сейчас понял как это работает наверху, а теперь надо пойти и копнуть глубже. Копать надо в сторону тех, кто знает не только вершки, но еще и корешки.

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

Даже если делаем то, чего еще нет, все равно они каким-то образом решают эти задачи.

Потыкав палкой в обе стороны, уже имеешь более-менее внятную картинку с которой можно работать.

Еще из важного: про то, как работает и что не так, лучше узнавать ни у экспертов, а у конечных пользователей. Потому, что у экспертов может оказаться только теория или воспоминания минувших дней, а у конечных пользователей реальная практика, боль и слезы.

Почему я обращаю на это внимание? Потому что опять же шишки из практики. Собрал проблемы от экспертов, выпустился и поехал смотреть, насколько рады конечные пользователи свалившемуся на них счастью в виде решения их проблем.
И вдруг, внезапно, оказалось, что часть проблем не валидна, часть возникает не тут и не в это время, а часть вообще звучит странно и хз им бедным, что с этим делать. Короче, спасибо, решили, правда только хуже сделали.

Схема пути пользователя


Эту часть можно назвать CJM, можно еще как-то.
Ее суть состоит в том, что после полученной кучи знаний, эту кучуя нужно преобразовать в какой-то удобряемый для дальнейшей работы вид, это раз. Два решить, все ли понято, учтено и записано со слов потерпевшего верно.

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

А я брала и раскладывала весь пользовательский путь употребления какой-то функцией от точки А до Б, от Б до С и так далее.
Так как часто приходилось делать то, чего еще нет, то реальные проблемы, радости и прочее передать не могла.

Прикидывала, в теории, что там может быть, в какой момент они рискуют свернуть на темную сторону зла, пройти не по тому пути и прочее.

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

Когда весь путь чист, как слеза младенца, можно уже и к прототипу приступать.

Прототип первый: бумажный


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

Бумажки можно разложить в ряд и оценить логику и понятность будущего продукта.

На бумажках можно даже выписать какие-то моменты, которые нужно еще подумать или сразу выписывать возникающие вопросы, которые нужно будет уточнить у разработки, например.

Прототип второй: динамический


Я его делаю в Axure.

Честно, пробовала в других программах, но мне элементарно не удобно, особенно когда будет достаточно большое количество экранов.

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

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

Тестирование прототипа


Прогон по сценарию с прототипом помогает убедиться, что вы таки попали туда, куда целились. А может попали, но не туда. А может вообще не попали.

В любом случае, все правки прототип переносит легче, чем продукт, запущенный в прод.

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

Не скажу, что все проходит гладко и правильно.

Были и ограничения по времени, когда просто приходишь и показываешь итог своей работы. Типа, вот смотрите: вы просили, а мы вот чего сделали. Потом сидишь и слушаешь обратную связь.

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

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

Это точно лучше, чем ничего.

Показ прототипа разработке


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

Тадам! Финишная прямая: дизайн


Тут рассказывать особенно нечего. Садишься, открываешь программулину и начинаешь рисовать хорошо или не очень то, над чем трудился в предыдущих сериях.
Позволяет время идешь набираться визуального и прочего вдохновения на ресурсах, названия которых нельзя произносить, потому что последнее время их часто хают.

Передача в разработку


Раньше описывала сценарии в формате user story.
Звучало это примерно так:
Я, как ., хочу
Далее описывалась сама функция, действия с ней пользователем, дополнительные возможности и пр.

Оказалось, что иногда получается много и никто это читать не желает, поэтому стала лепить примечания в самом прототипе и раскладывать в miro путь уже надизайненными экранами.

Оказалось, что разработчикам так работать значительно удобней.

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



Заключение


Повторюсь, что это мое виденье и мой опыт.

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

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

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

Будет ли актуальна эта профессия в будущем или распадется, в конце-концов, на отдельных узких специалистов.
Подробнее..

Книга Хороший интерфейс невидимый интерфейс

30.10.2020 14:07:40 | Автор: admin
image Привет, Хаброжители! Сегодня мы решили поделиться бесплатной электронной книгой, где Голден Кришна заставляет нас критически взглянуть на назойливый экранный мир и демонстрирует, как можно создавать продвинутые технологии без цифровых интерфейсов. В своей умной, суровой и зачастую уморительной критической манере Голден подсказывает удивительные идеи, позволяющие выйти из плоскости экрана и при помощи всего трех принципов добиться более плодотворных инноваций. Если вы работаете в инженерной сфере или просто опасаетесь надвигающегося засилья гаджетов, эта книга будет для вас интересной и информативной. Вы сами убедитесь, что обходиться без интерфейсов можно и нужно.

2. Экранно-ориентированное мышление


Давайте напишем приложение!


Когда-то и где-то мы влюбились друг в друга.

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

Может быть, это было в 2009 году, когда со всех сторон раздавались нежные вкрадчивые призывы: Знаете, что самое потрясающее в iPhone? Если вы хотите справиться о состоянии снежного покрова в горах, для этого есть приложение!

Национальная ассоциация предприятий торговли инвентарем для зимних видов спорта утверждает, что лишь 2,6 % американцев отдыхают на горных склонах, причем в среднем всего восемь дней в году, но это неважно. Когда нежный шепоток прозвучал впервые, никто не подумал об этом. Услышав пение сирен, мы забыли обо всем остальном. Любовь и рассудок? Ну нет, это как смешать масло и уксус.

Коммерциализация продолжалась. Наш пульс ускорялся. А если вы хотите точно знать, где припарковали машину...

Не приставайте ко мне. Мы все знаем, как закончить эту фразу. Четыре запатентованных слова, которые изрядно ограничили технологическую креативность этого поколения:

Для этого есть приложение!

Забудем, что примерно 780 млн людей в мире не имеют возможности пить чистую воду или что в богатой стране США больше полумиллиона8 бездомных. Мы отмахнулись от бытовых социальных проблем и массово двинулись в сторону технологий, где перебои и инновации оказывают значительное влияние на повседневную жизнь. Мы даем миру то, в чем он больше всего нуждается: больше мобильных приложений!

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

Любовь полна терпения и доброты. Любовь можно скачать за 99 центов.

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

Приложение само по себе вовсе не гарантирует, что где-то и для кого-то оно делает что-то полезное, но тсс! мы не должны покушаться на достоинство объекта всеобщей любви. Создание приложения преподносится как благая весть о чудесах и волшебстве: написание кем-то работающего кода, который каким-то образом сумел осветить темный и страшный путь в магазины приложений Apple и Google, преподносится как благословение небес.

New York Times создала рубрику App of the Week (Приложение недели) и завела постоянную колонку App Smart Extra, где встречаются драматические заголовки вроде Метеоприложение, которое работает. Оно работает? Как бы не лопнуть от восторга!

Во время финансового кризиса New York Times назвала Bloomberg приложением недели, потому что оно показывает основные данные фондового рынка. Что? Экстраординарно!

Так и вижу пользователя сайта USA Today, наливающего себе бокал шабли и включающего диск Норы Джонс, чтобы в полной мере насладиться трогательным текстом Пять новых приложений, которые изменят вашу жизнь. Я умиляюсь уже при виде вступления: приложения, приложения,
много приложений вот что на самом деле меняет жизнь!

Или, возможно, вы думаете: Ой, да я просто включу говорящую голову по CNN и забуду про эти смартфонные страсти. Еще раз спасибо, друг мой.
Вот реальные заголовки CNN:
image

image

Словом, что бы с вами ни случилось (кончилась туалетная бумага, вы кого-то выслеживаете или вообще умерли), вы знаете Для этого есть приложение!.

Джастин Бибер. Группа One Direction. Господь Бог. Согласно Google Trends все эти запросы уступают по популярности запросу приложение (app).

image

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

Приложение для дистанционного управления моим BMW разблокирует двери автомобиля, запускает кондиционер и делает многое другое!

Таким образом компании уходят от вопроса, как сделать лучше автомобильный ключ. Большинство приложений, открывающих двери, работают одинаково, поэтому давайте в исследовательских целях проверим, так ли восхитительно работает приложение BMW на iPhone с последней версией мобильной операционной системы Apple. По словам Apple, это самая продвинутая в мире мобильная ОС. В ее самой лучшей форме.
image

image

image

image

image

image

image

image

image

image

Погодите 13 шагов? Что вообще происходит? Все начиналось с того, что я шел к своей машине. Я просто хотел открыть дверь. Это, кажется, не сложно.

image

У меня была цель, но, чтобы достичь ее, потребовался экран смартфона. Благодаря приложению на это ушла всего дюжина шагов!

Это еще страсть или уже безумие? Это и в самом деле новая веха в развитии автомобильного ключа? Подумайте и честно признайтесь: ответ нет.

Я понимаю, отказаться от своего наркотика нелегко.

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

Избавившись от графического пользовательского интерфейса, мы получим всего два шага.

1. Подойти к машине.
2. Открыть дверь.


Все промежуточное можно смело отбросить.

Звучит невероятно? Между тем за целых 10 лет до выпуска этого 13-шагового приложения, до наступления эры экранно-ориентированного мышления, такая задача была успешно решена компанией Siemens и реализована Mersedes-Benz.

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

Улучшение автомобильного ключа? Безусловно.

На это некоторые возражали мне: Ну нет, без приложения не обойтись.

А что, если я запер ключи в машине? Вот тут-то и пригодится приложение!.

Не позволяйте вашим эмоциям отключать мозг. Машина способна определить, где находятся ключи, и дверь просто не запрется, если они внутри. А багажник? Вы даже не сможете его захлопнуть, если забыли в нем ключи. Другими словами, запереть ключи в машине никак нельзя.

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

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

Этой мысли и посвящена книга:

Лучший интерфейс невидимый интерфейс.

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

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

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

Напрягите булочки.

Скачать
Подробнее..

Перевод Microsoft планирует крупное обновление пользовательского интерфейса Windows 10

31.10.2020 14:22:02 | Автор: admin

В следующем году Microsoft хочет освежить пользовательский интерфейс Windows 10.

Источник: MicrosoftИсточник: Microsoft
  • В 2021 году ожидается большое обновление пользовательского интерфейса для Windows 10;

  • Проект носит кодовое название Sun Valley;

  • Ожидаются улучшения в Проводнике, Пуске и режиме планшета.

Microsoft готовит крупное обновление ОС для Windows 10 в 2021 году, которое, по информации источников, принесет с собой значительное обновление дизайна пользовательского интерфейса Windows. Заку Баудэну (Zac Bowden) сообщили, что Microsoft планирует обновить многие элементы пользовательского интерфейса: меню Пуск, Центр уведомлений и даже Проводник с использованием современного дизайна, улучшенной анимации и новых функций.

Проект пользовательского интерфейса имеет внутреннее название "Sun Valley" (Солнечная долина), и ожидается, что будет выпущен в рамках релиза Windows 10 "Cobalt" (Кобальт), запланированного на сезон праздников 2021 года. Внутренняя документация описывает проект как "оживление" и адаптацию опыта работы на Windows к современным требованиям, чтобы соответствовать ожиданиям клиентов в мире, управляемом другими современными и легкими платформами.

За последние пару лет Windows 10 оставалась почти такой же, практически не меняясь в дизайне или наборе предоставляемых функций. Многие другие платформы на рынке претерпели полный редизайн или обновление пользовательского интерфейса за последние пять лет. И, хотя Windows 10 претерпела незначительные изменения в дизайне с введением Fluent Design, мы не видели значительного обновления или переосмысления его пользовательского интерфейса.

Над проектом "Sun Valley", по-видимому, трудится команда "Windows Devices and Experiences" под руководством директора по продуктам Пэноса Паная, возглавивший указанное подразделение еще в феврале. В мае Microsoft объявила, что компания будет реинвестировать в Windows 10 в период до 2021 года, и источники Зака сообщают, что "Sun Valley" является результатом этого реинвестирования.

Чего же ожидать?

Источник: Windows CentralИсточник: Windows Central

Еще слишком рано говорить о том, что именно будет обновлено касательно проекта "Sun Valley", но источники говорят, что следует ожидать появления нового меню "Пуск" и Центра уведомлений, вероятно, основанных на тех же функциях, что и в Windows 10X, но адаптированных для настольных компьютеров. Microsoft также работает над обновленной панелью задач, созданной с использованием обновленного кода, и улучшенным пользовательским интерфейсом для устаревшего проводника.

Что касается пользователей планшетов, Заку сообщили, что на подходе также улучшенная анимация и более плавная работа ОС. Мы уже знаем, что Microsoft перерабатывает сенсорную клавиатуру и средство выбора эмодзи, так как эти изменения уже представлены на канале "Dev" для инсайдеров. И Microsoft продолжит это "рискованное предприятие" скругления углов всего пользовательского интерфейса, включая окна приложений и другие области оболочки.

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

Обновленный дизайн будет развитием Fluent Design, а не полным редизайном ОС. Microsoft не представляет новый язык дизайна с выходом "Sun Valley", а просто пытается обновить, переориентировать текущий язык на настольные системы и более последовательно применить его во всей ОС, что в общем-то является большим подвигом для устаревшего рабочего стола Windows.

Когда выход?

Источник: Windows CentralИсточник: Windows Central

Важно подчеркнуть, что Microsoft может сократить или отложить релиз. Вероятно, что-то из запланированного не доведут до конечного продукта, поскольку такова природа разработки Windows и причина, по которой Microsoft не делает никаких анонсов заранее. Но это то, что Microsoft хочет предоставить клиентам Windows 10 в следующем году.

Microsoft надеется, что большая часть этой работы будет выполнена к концу семестра разработки Cobalt, который завершится в июне 2021 года. Затем Microsoft подпишет RTM-версию билда, отправит ее OEM-производителям и начнет тестирование в бета-канале в качестве назначенного выпуска. Само обновление не станет общедоступным до осени, а скорее всего с выходом LCU (последнее накопительное обновление) с последними функциями и исправлениями.

Если Microsoft удастся реализовать свои планы с Sun Valley, это будет крупнейшее обновление пользовательского интерфейса Windows 10, которое мы когда-либо видели до сих пор, после трех долгих лет, когда Windows 10 оставалась в стороне. Пэнос Панай хочет, чтобы люди перешли от необходимости в Windows к любви к ней. А современный, обновленный интерфейс, интуитивно понятный и ориентированный на дизайн, это отличное начало.

С Sun Valley Windows 10 по-прежнему будет знакома пользователям ПК в отличие от перехода с Windows 7 на Windows 8. Заку также сообщили, что для некоторых функций можно будет переключаться между новым и старым интерфейсом, давая пользователям возможность выбора вместо принуждения. Sun Valley стремится улучшить и модернизировать привычный интерфейс Windows, а не радикально его изменить.

Подробнее..

Из песочницы Кейс как мы на яхте бортовой компьютер заменили

02.11.2020 00:07:43 | Автор: admin
Расскажу об одном интересном кейсе, как мы меняли и модернизировали бортовые системы на частной яхте, заменили полностью бортовой компьютер, освежили интерфейс пользователя и добавили новые функции.

В мае 2018г. к нам обратился клиент с проблемой: в порту стоит яхта, вышла из строя половины автоматики, в рейс выходит, но многими системами приходится управлять в ручном режиме. Для нас такая задача была, мягко говоря, не стандартная. Мы сделали много различных систем управления и мониторинга, новые и восстанавливали старые, но в рамках зданий и производств, а тут корабль.

Спойлер: принципиальной разницы между бортовыми системами корабля и инженерными системами здания нету.

Задача показалась интересной. Контроллеры, на чем была сделана автоматика были нам более-менее знакомы, по крайней мере, было понимание как с ними работать и был необходимый софт. Порт находился недалеко от офиса, на следующий день мы съездили на яхту и провели обследование того, что вышло из строя

image
Примерно вот так она выглядит. Фото из интернета.

Яхта Итальянская, 2007 года постройки, оснащена многими инженерными системами жизнеобеспечения и комфорта пассажиров. Есть большая щитовая на нижней палубе с основными элементами управления и небольшой шкаф управления под рубкой. Там и там стоят контроллеры, отвечающие за автоматическое управление, которые связаны с бортовым компьютером. С точки зрения программиста, мы имеем 2 контроллера Wago с набором модулей расширения, которые собирают и обрабатывают данные со всех систем и передают их на верхний уровень скаду, которая установлена на встроенном ПК под управлением сильно урезанной Windows XP. Само собой, нет никаких исходников на программное обеспечение, даже не понятно вообще, что это за скада, скорее всего что-то самописное Итальянцами. Программы на контроллер тоже нет. Были некоторые электрические схемы на сами шкафы и обвязку, на Итальянском языке, местами они помогли. Вся проблема оказалась в том, что контроллер в основном шкафу приказал долго жить.

image
Слева сам контроллер, CPU, там вся логика и алгоритм. И к нему около 30 модулей расширения.

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

Самая сложная часть была подружить новую программу с существующей скадой. Скада полностью закрыта, нет даже ОРС сервера, она обменивается с контроллером по протоколу Modbus TCP/IP, и как именно она это делает не понятно. Мы использовали программу Wireshark, чтобы подслушать какие запросы и на какие адреса отправляет компьютер на контроллер, после чего симулировали ответы контроллера, чтобы узнать, как на них будет реагировать интерфейс скады. Это очень тонкая, деликатная и длительная работа, подбирать переменные, чтобы потом под них уже написать программу. Вся внешняя адресация алгоритма должна полностью совпадать со старой программой, чтобы бортовой компьютер работал точно так же, как и раньше.

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

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

К уже существующим системам яхты:

  • огни и подсветка,
  • вентиляция и кондиционирование,
  • водоснабжение и водоотведение,
  • насосы, танки с топливом и технологическими жидкостями,
  • генераторы, питание, батареи,

добавим новые:

  • освещение в каютах,
  • горн,
  • дворники,
  • люки.

Поставим новую сенсорную панель вместо старого компьютера, обновим интерфейс, добавим Русский язык и обновим программу на существующих контроллерах, чтобы у нас имелись все исходники. Мы составили КП на эти работы, договорились и в 2019 году приступили к модернизации.

Вместо компьютера мы поставили сенсорную панель Weintek MT8121XE, 12 дюймов и разрешение 1024х768. Экран резистивный, но для наших целей он подходит. Хорошая яркость и углы обзора.

image

image

image

image

image

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

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

image

image

image

image

image

image

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

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

Дополнительно мы сделали светлую тему, так как днем, при свете солнца информация с темного экрана считывалась недостаточно хорошо.

image

image

image

image

После, все это еще и продублировали на английский язык

image

image

image

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

Дополнительно поменяли цифровые анализаторы тока на генераторах, аккумуляторах и береговом питании, теперь больше параметров мы можем передавать на панель. Сама панель все эти данные может архивировать и выгружать отчеты на флешку.

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

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

В нашем портфолио это один из самых необычных и интересных кейсов, есть, о чем рассказать. Если у вас есть своя яхта и вы хотите модернизировать бортовые системы на ней, обращайтесь, с удовольствием поработаем!
Подробнее..

Recovery mode О фундаментальной несовместимости МОБА-игр с шоу-форматом

05.12.2020 00:04:30 | Автор: admin
Написание заметки мотивировано этой статьёй.

image

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

Если мы с пристрастием допросим рядового зрителя на трансляции/трибуне, то выясним, что он в основном ориентируется на комментарии комментатора и общую атмосферу зала. Однако, в целом, одиночному наблюдателю в реальном времени для восприятия доступна только макроигра! Количество и частота взаимодействий между игроками таковы, что полностью исключают возможность проследить за всеми значимыми событиями в реальном времени.

Если любезному читателю ничего не говорит словосочетание число Шеннона, разберём проблему на простом примере. На баскетбольной площадке десять человек (5х5) играют одним мячом, за которым и следят зрители.
В МОБА-играх же каждый из десяти игроков имеет при себе от 4 до 10 мячей (умения + инвентарь), которые нужно отслеживать зрителям, причём большинство из мячей имеют единственную и неповторимую форму и размер, более ни у кого другого не встречающиеся (а следовательно и отскок и т.д.). Но это ещё не всё.
В момент схватки игроки одновременно перепасовывают друг на друга эти мячи, что исключает возможность не то что описать происходящее даже для самого резвого говоруна, а просто зафиксировать все эти одновременные действия в сознании (воспринять). Потому комментаторы, как правило, вынуждены оглашать лишь некоторые действия игроков (и их последствия), показавшиеся им важными, решающими или ключевыми в то время как на деле те являются таковыми далеко не всегда.

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

Суть в том, что изначально вышеописанные игры и их контуженные дети не задумывались, не проектировались и не реализованы в качестве среды для шоу-демонстрации игрового процесса и являются развлекательными программами для непосредственных пользователей. То есть МОБА (как и RTS в целом) изначально рассчитана на развлечение одного конкретного человека, а не на полноценное наблюдение за игровым процессом группы лиц! Следовательно игра не предоставляет таких возможностей ни комментатору ни зрителю!

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

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

Сымем шляпы перед отделами маркетинга известных компаний


П.С.

В качестве эксперимента пригласите нескольких пенсионеров, не знакомых с игрой, посмотреть как есть (as is) хотя бы 5-10 минут трансляции турнира по МОБА, после чего высказаться. Для чистоты эксперимента ничего не нужно объяснять до начала обсуждения отсмотренной трансляции.

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

Как мы отказались от вкладок в интерфейсе и ускорили работу пользователей почти в 2,5 раза

03.03.2021 12:06:10 | Автор: admin
Недавно МойОфис выпустил крупное обновление 2020.03. Помимо улучшения и расширения функциональной части, в этом релизе мы кардинально изменили дизайн интерфейса редакторов. И прежде чем он стал публичным, провели исследование в специальной UX-лаборатории. Так мы выяснили, что смена внешнего вида программ приведет к существенному ускорению времени поиска пользователями нужных команд.

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

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

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

Обзор существующих решений


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

imageДля приложений Microsoft Office характерно огромное количество функций (в Office 2010 насчитали более 12 тысяч). Перегруженность интерфейса была очевидна уже в версии 97, и в следующих релизах разработчики пытались решить эту проблему разными способами в частности, динамически скрывая часть элементов в панелях и меню (это решение было признано неудачным из-за непредсказуемости поведения тулбара).

В процессе разработки 2007-й версии офиса в Microsoft сформулировали новый подход: командные меню и отдельные панели инструментов пригодны только для продуктов с относительно небольшим количеством возможностей, а для офисного пакета необходимо принципиально другое решение. В результате множества экспериментов появился ленточный интерфейс (Ribbon), который заменил собой все командное меню и панели. Именно этот интерфейс сейчас привычен всем пользователям MS Office:

image

Несмотря на то, что риббон быстро вошел в моду и стал появляться в самых разных приложениях независимо от их функциональной наполненности, в популярных альтернативах MS Office используются другие, более или менее классические решения. Редакторы Google Docs применяют традиционный подход: на панели размещено только самое востребованное, а полный набор возможностей в командном меню. При этом выбранная структура интерфейса помогает подчеркнуть легковесность продукта:

image

Открытый LibreOffice придерживается такого же подхода, только панелей здесь две и возможностей в целом больше.

image

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

image

Нельзя обойти вниманием отдельную категорию редакторов типа Notion и Coda. Они, конечно, далеко не во всем могут заменить полноценные офисные редакторы, но все же хорошо подходят для выполнения определенных задач. Сегодня они приобретают все большую популярность у значительной аудитории, а следовательно, тоже формируют у людей определенные привычки и ожидания. Эти продукты максимально фокусируются на пользовательском контенте, поэтому интерфейс в них минимален; панели инструментов могут почти отсутствовать, появляясь только по необходимости.

image

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

Первая версия панели


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

image

Структура и поведение панели основывались на трех принципах:

  • контекстность: в каждый момент времени пользователь видит на панели только те инструменты, которые применимы в текущем контексте;
  • разделение по объектам: панель структурирована с помощью вкладок, каждая из которых соответствует определенному объекту (текст, таблица, изображение и т.д.);
  • полнота: на панели представлены все инструменты форматирования, применимые в текущем контексте.

По мере накопления опыта реального использования в концепции обнаружилась фундаментальная проблема: объектная структура панели не соответствовала изначальным сценариям использования. Например, смена заливки ячейки часто ведет к смене цвета текста в этой ячейке, при том что в нашей концепции эти функции находились на разных вкладках. Это требовало от пользователей часто переключаться между вкладками и, как следствие, вызывало раздражение и снижало эффективность работы.

image

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

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

Работа над новыми концепциями


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

Имея эти данные, мы смогли сгенерировать несколько разных вариантов панели, например:

  1. Альтернативное разбиение функций по вкладкам: на одной редактирование выделенного контента, на другой общий стиль документа:
  2. Полностью контекстная панель, вызываемая щелчком правой кнопки мыши:
  3. Отказ от вкладок и объединение всех функций в одной панели:

image

Сравнив варианты, мы пришли к выводу, что третий будет наиболее привычен пользователям. Также его было проще всего запрототипировать и протестировать, поэтому мы решили развивать именно его.

Уже на ранних стадиях разработки стало понятно, что в таком варианте панели может быстро закончиться место для новых функций, а недостаточно четкая визуальная структура усложняет поиск. По этим причинам был подготовлен вариант с размещением элементов в две строки:

image

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

Панель адаптируется к ширине окна, чтобы максимально эффективно занимать доступное пространство. Также в процессе обсуждений появилась идея дать пользователю возможность самостоятельно сворачивать отдельные блоки панели, настраивая таким образом ее под себя.

Тестирование и результаты


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

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

Тестировали варианты: в одну строку, в одну строку с делением на вкладки, в две строки (на основе нефункционального прототипа) и классический риббон.

image

По ходу исследования мы снова обнаружили уже знакомые ситуации, когда люди не видели контекстные вкладки и тратили время на их поиск.

И обнаружили новую проблему напрасное переключение, когда человек зря переходил на неправильную вкладку, уже находясь на нужной.

Тестирование риббона показало, что чем больше вкладок, тем больше времени человек тратит на их перебор, если не может найти нужную кнопку.

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

По итогам исследования мы получили 23 часа видео, которые отсмотрели за несколько недель и разметили все операции по поиску функций более 1800 событий. После анализа нам удалось построить зависимость времени поиска от интерфейсного паттерна. Что интересно эта зависимость не отличалась между сравниваемыми редакторами, разница была только в количестве использований того или иного паттерна для каждого редактора. Получилось, что в случае, когда человек знал, где искать кнопку, он в среднем тратил на переключение лишние 2 секунды.

image
Из графика видно среднее время поиска кнопки: в случае, если переключение на другую вкладку не требуется (toolbar) 1.67 сек; в случае, если переключение на другую вкладку требуется (toolbar switch) 3.68 сек.

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

Разработка панели инструментов


Для претворения нашей идеи в жизнь с технической стороны мы справились со следующими подзадачами:

  1. Нужно было продумать процесс масштабирования, изменения наполнения тулбара: порядка, видимости его элементов, их свойств. Для этого мы вынесли уровни абстракции и наполнение в удобную для понимания и редактирования базу данных с web-интерфейсом (Airtable), чтобы можно было легко вносить и отслеживать изменения, наглядно видеть все нюансы отображения элементов тулбара. Во время сборки проекта, по этой базе данных мы через API стали формировать XML-файл со структурой панели для каждого редактора и поставлять его в класс-конструктор. Таким образом, коллеги из UX-отдела смогли самостоятельно править конфигурацию панели инструментов независимо от разработки, и эти корректировки стали автоматически применяться при следующей сборке продукта. Это позволило удешевить процесс внесения изменений и исключить человеческий фактор. Также такой подход позволяет формировать набор тулбаров через изменение ключа сборки, значение которого может указывать на разные базы с одинаковой структурой хороший задел, чтобы в будущем предоставить нашим конечным пользователям возможность кастомизации тулбара.
  2. Разработали алгоритм адаптации к текущей ширине окна: элементы динамически уменьшают свою ширину это позволяет сохранить структуру тулбара при уменьшении доступного места без необходимости использовать горизонтальную прокрутку.

    Вкратце, алгоритм работает так:

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


image

Заключение


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

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

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

На нашем сайте вы можете получить пробную версию МойОфис Стандартный и самостоятельно попробовать новый тулбар в работе. Мы будем рады услышать ваши отзывы и готовы обсудить их в комментариях к этой статье.

Над статьей работали UX-архитекторы Шейла Шейх и Кирилл Улитин (ulitin), а также разработчики Иван Шеров-Игнатьев и Олег Архангельский.
Подробнее..

Чем хорош сайт на Тильде? И почему не надо лезть в дорогостоящие решения

03.03.2021 20:06:54 | Автор: admin

Не часто приходится замечать решения предложенные на платформе Tilda, а зря. Почему так? Что такое вообще Tilda и для кого она?

Сразу отметим, что данный материал ни в коем случае не является рекламным, а представляет из себя анализ Тильды, как решение для бизнеса.

Если говорить коротко - это конструктор сайтов, который приобрел большую популярность в последние годы на территории России и стран СНГ в частности. Конечно, основной офер компании заключается в том, что любой новичок никогда до этого не имеющий опыта в web- разработке и в целом digital, сможет сделать для себя или своего небольшого начинания посадочную страницу. Казалось бы, причем тут вообще могут быть агентства или студии? Давайте разбираться.

Все опять исходит из профессионализма конкретных участников разработки, будь то дизайнер или маркетолог. В любом деле необходим опыт и сноровка, чтобы хорошо делать свое дело. Человек, который ни разу не работал со смыслами, не знает, что такое прототип и в целом не имеет представления, что такое дизайн, и из чего он состоит - не сможет справиться с поставленной задачей. Да, конечно Tilda предоставляет в своем ассортименте решения в виде готовых блоков из которых можно собрать небольшой MVP (минимальный жизнеспособный продукт), но вряд ли такой продукт сможет потягаться со средними сайтами в той нише для которой этот сайт предназначается. Вот именно в таких случаях на помощь приходят команды со своей экспертизой в решениях данных задач. Казалось бы, за что некоторые команды берут по 200.000 за разработку на условной бесплатной платформе?

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

По факту в более чем 50% случаев от всех задач бизнеса в медиа пространстве, ваш сайт не нуждается в том, чтобы он был разработан кодом. Не обязательно ставить такие условия где необходимо будет привлекать верстальщика или программиста. В таких проектах обычно нуждается средний или крупный бизнес, так как к тому времени у компании сформировалось представление и сложные многоуровневые задачи, которые решаются только таким же сложными решениями.

Если ваша задача начинается со слов:
Чтобы продавать или Нужна презентация - вам не нужен код.

Tilda в свою очередь тоже не является панацеей и не возведена в абсолютное значение, можно пользоваться другими решениями похожими на Тильду.

Что чаще всего приходится слышать про Тильду?
1. Тильда? - ну это как-то несерьезно для компании
Во-первых, это вполне себе компактное и быстрое решение которое позволит незатратно для компании реализовать задуманное. В среднем сайт на Тильде стоит в 2 раза дешевле чем на CMS. Пользователю абсолютно неважно на чем разработан сайт, он пришел за конкретным товаром или услугой. Имеет смысл делать упор на предложение и на сервис. Сайт это всего лишь один из инструментов в вашем бизнесе.

Во-вторых, скорее всего меня могут закидать тухлыми помидорами, но серьезная компания не будет стараться выгрызать серьезный сайт за условные 20.000 рублей. Тут 2 пути: или компания не такая серьезная, или же у директора нет понимания, что такое сайт и для чего он нужен.

2. Не, Тильда не подойдет, у нее слишком урезанный функционал
Да, вы правы, Тильда имеет большое количество ограничений, но как правило если вы обращаетесь к профессионалам то выбор данного решения будет не случайным.

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

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

Тогда скорее всего вы общаетесь с командой, которая работает только на этой платформе или же с непрофессионалом.

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

Теперь, когда мы прониклись всей серьезностью данного решения. Сформулируем реальную ситуацию и ряд задач с которыми пришлось столкнуться заказчикам.

Рассмотрим параллельно 2 ситуации, которые могут показаться разными, но по факту объединены одним и тем же.
1. Заказчик не имеет серьезного бюджет, но ему срочно необходим небольшой сайт для мероприятия, которое стартует уже в конце недели.
2. Заказчик имеет серьезный бюджет, но у него отсутствуют амбициозные задачи и в целом планы на будущий сайт. Сроки не превышают 14 дней, но для простоты понимания давайте приведем также к 7 дням.

Задача
По факту перед нами стоит задача, как сделать симпатичный MVP-проект, в срок не превышающий 7 дней.

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

День 1. Подбор референсов и обсуждение проекта
Для экономии времени и ресурсов приступаем к аналитике, но акцентируем внимание только на самых важных моментах, а именно:

  • какова будет общая концепция продукта;

  • какие есть конкуренты и что они из себя представляют;

  • Что нравится целевой аудитории;

  • что из референсов может лучше всего подойти.

Конец дня ознаменовывается обсуждением выбранных решений с заказчиками. На каждый из этапом тратим примерно по 2 часа.

День 2. Прототипирование
Так как у нас выделен только 1 день на прототип - прибегаем к быстрому решению при помощи Figma. В рамках этого сервиса есть уже готовые ui киты, другими словами блоки, которые можно компоновать в дальнейшем как угодно. Опираемся на те примеры сайтов, которые утвердили с заказчиками на предыдущем этапе и на основе их логики / структуры - переносим все это на наш прототип в Figma. В завершении идем презентовать и защищать структуру перед заказчиками.

День 3-4. Дизайн
На данном этапе делаем акцент, выделяя под него 2 суток. Так как он является самым основным в рамках работы на Тильде. Определяемся с 3 наиболее интересными и продуманными работами в данной нише, предварительно все это согласовав с заказчиками. Первый день занимает подбор и поиск будущих элементов сайта, а именно:

  • Иконки

  • Изображения

  • иные визуальные элементы, которые нельзя отнести к чему-то конкретному, но от этого они не становятся менее важными

Все должно быть объединено общей идей, сочетаться между собой, что также отсылает нас к проработке первичной логики по которой уже идет дальнейший отбор элементов. На чем первый день удачно заканчивается. Собрав бэкграунд элементов, вспоминаем о тех исходных работах, которые мы взяли, как ориентир. После чего объединяем удачные идеи этих сайтов с теми элементами, что мы нашли, находясь в свободном плавании на ресурсах для дизайнеров.

День 5. Верстка
Верстка на Тильде представляет из себя работу в zero-blockах, что значительно упрощает нашу задачу. Другими словами, если вам когда-то приходилось сталкиваться с Powerpoint/Photoshop и тд то вы без труда сможете представить сложность при работе с данным инструментом. Как правило все завязано на интуитивно понятном интерфейсе и функционале. В целом вся верстка - это своеобразный конструктор где единственное, что остается делать это переносить элементы с прототипа и двигать их в соответствии с дизайном. Но не стоит забывать, что некоторый пулл-задач не получится решить при помощи zero-blockов, что отсылает нас обратиться за помощью к верстальщику для добавления сложного элемента на сайт. Как правило такие задачи составляют менее 5% от общего числа.

День 6. Подключение домена
Одним из заключительных этапов - подключение домена. Долго не раздумывая, идем на любой из популярных хостингов-провайдеров (reg.ru,Timeweb.comи др.) Указываем DNS сервера Тильды, обновляем всю информацию и жмем подключить домен. Весь этот процесс заканчивается проставлением галочек и индексированием на новый домен. По сути основная работа на этом заканчивается. 6 и 7 день можно было бы объединить в один, но зачастую приходится долго ждать обратной связи от провайдеров, срок ожидания которых может составлять до 1 дня.

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

Для этого записываем видеоинструкции:

  • как добавлять контент;

  • Как редактировать текст и менять изображения;

  • Как пользоваться панелью администратора

Где они уже самостоятельно сможет все настроить, повторяя шаги из видео.

Вывод
Тильда - это отличный инструмент для вашего бизнеса если вы:

  • только начинаете;

  • самозанятые или у вас небольшой стартап, когда нет уверенности в бизнес-моделе;

  • когда все, что требуется от сайта - это продавать или демонстрировать портфолио.

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

Подробнее..

Перевод Как эти забавные картинки незаметно захватили сферу маркетинга

15.06.2021 12:07:46 | Автор: admin

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

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

Такой стиль иллюстраций называется корпоративный мемфис.

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

Похоже, это повсеместный тренд, от которого никуда не деться: жертвой этих причудливых картинок становятся и стартапы, и крупные технологические компании.

Как так получилось? И какое значение этот стиль имеет в сфере маркетинга?

Давайте разберемся.

Откуда название корпоративный мемфис?

Название кажется странным, но если разобраться в происхождении, то всё становится на свои места.

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

Со временем всё больше компаний начинали внедрять черты такого дизайна в собственные иллюстрации.

Получившийся в итоге стиль назвали корпоративным мемфисом.

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

В итоге теперь уже сложно различить компании по визуальному стилю взгляните сами.

Да, эти иллюстрации с разных сайтов: скриншоты из Slack, Markup и Google Покупок.Да, эти иллюстрации с разных сайтов: скриншоты из Slack, Markup и Google Покупок.

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

1. Смерть скевоморфизма

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

С тех пор, как Apple перешла на iOS 7, всё больше компаний меняют свой визуальный стиль, отдавая предпочтение простым, упрощенным изображениям. Причина банальная: мы уже привыкли к цифровым приложениям и сенсорным дисплеям, поэтому нам больше не нужна имитация аналогов из реальной жизни. Кроме того, чем проще дизайн, тем быстрее такой контент потребляется а мы пропускаем через себя огромное его количество.

Так что покойся с миром, скевоморфизм.

Современный корпоративный стиль плоский и минималистичный. Поэтому иллюстрации в маркетинговых материалах тоже должны быть такими. А что может лучше подойти к упрощенным, приятным глазу логотипам, чем красочные мультики?

Корпоративный мемфис недостающий элемент мозаики плоского фирменного стиля.

2. Взаимозаменяемые цвета

Еще одна причина взлета корпоративного мемфиса универсальность цветовой гаммы: это позволяет компаниям внедрять корпоративный стиль во все визуальные материалы. Например, вот так Ютьюб берет красный и белый из своего плоского логотипа и переносит их в иллюстрацию.

Скриншот YouTube Скриншот YouTube

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

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

3. Простой, масштабируемый дизайн

Еще один фактор популярности корпоративного мемфиса простота создания иллюстраций в этом стиле.

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

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

Мало того их даже не нужно рисовать: есть тысячи шаблонов, с помощью которых можно создавать любые иллюстрации, какие только нужно.

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

Например, Canva одна из множества платформ, предлагающих готовые элементы оформления. Среди других ресурсов FreePik, UnDraw, векторная библиотека Adobe, Humaaans и т. д.

4. Радость на лице радость в жизни?

Пожалуй, самая большая притягательность корпоративного мемфиса солнечное настроение этих иллюстраций.

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

И это работает.

Когда я вижу очередную такую иллюстрацию, я чувствую, что обо мне заботятся. Мне кажется, что всё будет хорошо. Что мир не такой сложный, как может показаться.

И что, это всё? Это и есть Корпоративный мемфис? Просто яркие цвета, культурное разнообразие и радостное настроение?

Внешность может быть обманчива

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

Ненастоящее этнокультурное разнообразие

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

Простота для ленивых

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

Бездумное счастье

Улыбающиеся лица с непропорциональными частями тела создают впечатление, будто мир проще, чем на самом деле. Компании сознательно используют это, чтобы представить себя дружелюбнее, чем они есть в реальности. И мы начинаем верить, что техногиганты делают мир лучше но нельзя забывать, что почти у всех них есть темная сторона: например, такие компании, как Google, собирают пугающее количество данных о нас.

Заключение

Корпоративный мемфис это палка о двух концах.

С одной стороны, это репрезентативный, простой и дружелюбный визуальный стиль. Создавать такие картинки может каждый что очень помогает стартапам и независимым авторам.

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

Если вы хотите использовать корпоративный мемфис для себя, я не буду вас винить: это прекрасный стиль, он всем нравится. Но спросите себя: может, есть другой, более индивидуальный и творческий подход? отражает ли этот стиль суть вашей работы? не чрезмерно ли вы упрощаете то, о чем говорите?

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


О переводчике

Alconost занимаетсялокализацией игр,приложений и сайтовна 70 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.

Мы также делаемрекламные и обучающие видеоролики для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.

Подробнее..

Категории

Последние комментарии

  • Имя: Murshin
    13.06.2024 | 14:01
    Нейросеть-это мозг вселенной.Если к ней подключиться,то можно получить все знания,накопленные Вселенной,но этому препятствуют аннуннаки.Аннуннаки нас от неё отгородили,установив в головах барьер. Подр Подробнее..
  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru