Секрет фирмы в том чтобы «методом тыка» подобрать наиболее комфортные цвета под конкретную модель дисплея. Это может оказаться какой-нибудь темно-зеленый с оранжевым. (привет сбербанку )) или темно-голубой с опять же оранжевым.
Хотя все равно будет хреново если дисплей явно плох, но хоть как-то терпимо без сильной пятнистости
Слишком сложная система для разбора в комментарии.
Нужно понимать производственные процессы, чтобы как-то критиковать юзабилити.
Если бы вы пришли ко мне как заказчик, мы бы с ребятами засели тут на неделю — две только на разбор полетов, что, где как и для чего, вплоть до изучения толмутов по железу и инструкций техники безопасности.
Но что касается мелочей, если не повторять моменты из статьи:
* Навигацию по разделам я бы переместил наверх… но не точно. Возможно тут боковое меню подойдет, как например тут: inediapps.com/portfolio/hyterus.html
Навигацию по схемам — точно налево бы переместил, т.к. сначала выбираем схему, а потом работаем с ней (ваша компоновка подойдет больше для арабов или японцев), хотя это достаточно субъективно, я скорее стремлюсь к общепринятым компоновкам сейчас тут т.к. не знаю нюансов работы. Если UI только под мышь — то точно налево.
Верхние статусы все, вместе с лого/датой и управлением, возможно лучше выделить для них правую/левую часть по вертикали, сверху они довольно разрознено получаются. Так же хорошая практика статусы — в статусную строку помещать, но тут у вас довольно сложно, надо накидать все варианты и посмотреть как выглядит, удобно ли. (мои советы про распечатку на бумаге тут как нельзя кстати, в любом графическом редакторе можно просто подвигать все элементы и напечатать десяток листков с вариантами, попытаться поработать с ними «виртуально». там уже не надо быть дизайнером чтобы увидеть что лучше подойдет для общей компоновки панелек системы.)
+ я бы на навигацию добавил иконки.
* формат даты неудачен, особенно для таблицы сообщений.
12:30:15 28 Сентября 2019 (полный формат для РФ)
* подсветку строк в таблице сообщений я бы заменил просто на лампочки в начале, если загорится что-то красное будет видно. Слишком длинные цветовые полосы.
* в печах горит огонь (или в подогревателях), ок, но лучше дополнительно подписать что-то вроде «В работе», если все электроникой управляется, то выключенную печь вообще можно в Disabled (полупрозрачной сделать например) это даст понимание, что выключено вообще от сети, что включено, что включено и работает
* надо как-то решать вопрос валидации ввода данных. У вас много текстовых полей ввода, идеально — когда пользователь видит до валидации, в каких пределах от может ввести температуру, давление и пр. Даже инженеру-специалисту ошибиться — пара пустяков. Лучше предупреждать ошибки, чем и исправлять.
* нарисуйте сетку поверх UI, чтобы все выровнять. пример inediapps.com/portfolio/abudhabi.html (см. раздел «Гайдлайны»)
Внешний вид, конечно, мне не нравится, но хотя бы в мелочах напишу.
* уберите серый фон с мнемосхемы, у вас тексты не читаются + стандартные текстовые поля встанут получше
* Кнопки навигации визуально слишком бледные (подобные кнопки часто для Disabled состояния делаются) сделайте их, возможно, синими. Синий как нейтральный цвет — идеален. Оранжевое выделение синей кнопки встанет хорошо. Это вам даст серый для блокировки кнопок которые нельзя нажимать в данный момент.
требуется объективное доказательство: в цифрах, графиках, таймингах, и так далее.
Требуется кому?
Все показатели, что описаны ниже, как раз нужно инженеру по дизайну отдать (либо он должен вывести все необходимые параметры сам, если их нет).
Дизайн это вообще сплошная инженерия, рисовать картинки может и сын маминой подруги.
Хотя если пытаться представить графику дизайна «отсортированную цифрами», то ничего хорошего точно не получится.
Я про ключ блокировки аварийной кнопки STOP. Если его нет внутри, то блокировку нельзя отключить.
Я когда на Тех.Обслуживание в бетономешалку ползал, предпочитал данный ключ держать при себе.
одна неправильная команда, и что-нибудь или даже кто-нибудь может очень сильно пострадать.
Без тестового стенда имитирующего реальный прибор, как правило делать что-то нельзя в таких случаях.
Вообще не раз наблюдал как многие программисты делали правки прямо по живому проекту, из последнего — команда субподрядчик правили БД прямо на рабочем сервере, тестового себе не сделали, что приводило к периодическим крэшам основного сервака. Пользователи не имели доступа к БД иной раз сутки и более. Хорошо нами была предусмотрена возможность оффлайн работы для критических задач. Мои предупреждения, что компания клиента может потерять таким образом все данные или часть (бекап раз в какой-то период там все же делался) просто игнорировались.
по элементам, конечно, нужно сетку поправить, но схемы — очень хорошо представлены.
Как я и упомянул в статье — схема «под бумажный чертеж» всегда смотрится.
Функционально конечно такие UI оценивать можно только на производстве.
На первом фото узнал Telerik )
Вот, описано реальное рабочее пространство)
Компьютер можно подключить с расстояния (из другого помещения), как я понял из того что видел по конкретному случаю на софте нужно только программу резки задать, далее нужна одна кнопка пуск. На крайний случай есть целый ряд защищенных устройств в продаже.
Но то что на самом лазере должны быть кнопки это верно, в том числе и аварийный STOP с ключиком (Ключик для ТО, чтобы никто не смог включить ничего никаким способом, когда он убран, пока руки и голова внутри прибора)
А, так вот куда делись HERE maps.
У меня на нокии c WindowsPhone все еще стоят, действительно годные и шустрые карты.
Нужно будет посмотреть, как это в авто-GUI интегрировалось.
Эту проблему я описал в разделе статьи про лазер и их «компьютер на колесиках» и комментарием ниже. Подключать обычный ноут к «шкафу» — наиболее оптимальное решение в половине случаев.
Справедливости ради. На выставке присутствовало множество решений, где просто был подключен обычный ноут/планшет/пк к железу. Я думаю это оптимально для очень большого стека оборудования.
По литературе, ответил выше. Что касается примеров хороших UI, все очень субъективно. Обычно делаем целый анализ под конкретную область применения, т.к. у всех разные «специфики» и хотелки и цели. Идеального ничего нет, я привел в пример осциллографы, понимая что кто-нибудь из пользователей, кто реально использует их в работе скажет обратное в комментариях, что и произошло.
Я подумаю, пока не знаю как ответить объективно.
Пока дам ссылку на свою старую статью про проектирование одной конкретной системы умного дома, для понимания как строится UI с карандашных набросков до рабочего варианта и с улучшением до версии 2 inediapps.com/blog/smarthome.html
Хотя сегодня, спустя 5 лет я бы там много чего поменял и улучшил (сама индустрия умных домов шагнула вперед, сменилось железо и пр.)
Вот прямо ничего конкретного по промышленным UI посоветовать не могу.
Но мы с коллегой открыли для себя мир старой Советской литературы про эргономику и устройство всяческих приборных панелей.
Например вот:
Недавно вот такой список литературы обнаружил, но еще не приступал к его изучению: ссылка
Эти знания (в основном про UX) не утратили в актуальности именно в промышленных дизайнах.
Ждал этого комментария.
У меня мало опыта работы с осциллографами, но в них действительно много хороших наработок по UI/UX за полвека их эволюции.
Основная мысль статьи — что со своим GUI надо работать. Особенно с новым и хотя бы пару месяцев по 8 часов в сутки на старте производства, тогда становится более — менее понятно, что именно нужно для работы конечному пользователю, а что излишне и можно запихнуть на задний план. (с железом так же).
К сожалению, многие, кто приходят к нам за дизайном, просто просят «сделать красиво» и после чего забивают на все остальное. Хотя по уму необходимо вернуться через полгодика тестов, указать дизайнеру на ошибки и пользовательский опыт/отзывы чтобы сделать лучше. Донести это до заказчика задача сложная, для большинства прибыль на первом месте, а мы тут с вами про заботу о потребителе.
По опыту хороший софт/UI выходит где-то на версии 2.5 — 3. Делая полный редизайн цикл начинается сначала.
Любой разработчик, который не взаимодействует с конечным потребителем железа (и UI), обречен на такие отзывы как ваш. Хотя только одного вашего мнения мало, нужно собрать минимум пару десятков по одному конкретному прибору.
У меня к дизайну киосков метрополитена в Москве много замечаний, основное это:
Не нужно весь дизайн делать красным. Это ужасно. А на блеклых экранах еще и нечитаемо. Там кстати та же проблема с хреновыми экранами и томатным цветом UI, что вовсе не соответствует фирменной стилистике, как в примере из статьи.
Кнопки отмены расположены очень близко к кнопкам действия на сенсоре плохой точности, особенно при оплате банковской картой постоянно на уголок кнопок жму, чтобы случайно отмена не нажалась.
GUI очень тормозной. Такое чувство что там переполнение памяти из-за долгой работы софта где-то. Т.к. иногда попадаешь на лютые тормоза, а иногда вроде бы и норм.
Но с другой стороны для таких объемов и количества использований (нужна надежность) всё около дела. Работает же и достаточно успешно.
Про экраны в Авто да, отдельная большая тема.
Вот пример с тех же выставок, от одного крупного Японского производителя.
Огромный (для авто) экран, гиганский Gauges (ИМХО не удобный), а камере заднего вида уделили всего уголок, при этом именно изображение с камеры тяжелее всего рассматривать же. Левая часть экрана вообще не используется почти. Я уже молчу на непонятные «дизайнерские» отражения на цифрах и стрелке спидометра сбивающие с толку.
Я думаю это временно. Года через 3 станут понятны все ошибки больших экранов в авто, мода поутихнет и станут делать хорошо.
Круть! Сделайте анонс на хабре обязательно, я так понимаю это тоже уже ближе к 2020 будет, т.к. MS там что-то совсем не шевелятся с выкладкой на GitHub.
А как данные будут поступать на мобильное ПО? придется какую-то железяжку подключать?
Хотя все равно будет хреново если дисплей явно плох, но хоть как-то терпимо без сильной пятнистости
Нужно понимать производственные процессы, чтобы как-то критиковать юзабилити.
Если бы вы пришли ко мне как заказчик, мы бы с ребятами засели тут на неделю — две только на разбор полетов, что, где как и для чего, вплоть до изучения толмутов по железу и инструкций техники безопасности.
Но что касается мелочей, если не повторять моменты из статьи:
* Навигацию по разделам я бы переместил наверх… но не точно. Возможно тут боковое меню подойдет, как например тут: inediapps.com/portfolio/hyterus.html
Навигацию по схемам — точно налево бы переместил, т.к. сначала выбираем схему, а потом работаем с ней (ваша компоновка подойдет больше для арабов или японцев), хотя это достаточно субъективно, я скорее стремлюсь к общепринятым компоновкам сейчас тут т.к. не знаю нюансов работы. Если UI только под мышь — то точно налево.
Верхние статусы все, вместе с лого/датой и управлением, возможно лучше выделить для них правую/левую часть по вертикали, сверху они довольно разрознено получаются. Так же хорошая практика статусы — в статусную строку помещать, но тут у вас довольно сложно, надо накидать все варианты и посмотреть как выглядит, удобно ли. (мои советы про распечатку на бумаге тут как нельзя кстати, в любом графическом редакторе можно просто подвигать все элементы и напечатать десяток листков с вариантами, попытаться поработать с ними «виртуально». там уже не надо быть дизайнером чтобы увидеть что лучше подойдет для общей компоновки панелек системы.)
+ я бы на навигацию добавил иконки.
* формат даты неудачен, особенно для таблицы сообщений.
12:30:15 28 Сентября 2019 (полный формат для РФ)
* подсветку строк в таблице сообщений я бы заменил просто на лампочки в начале, если загорится что-то красное будет видно. Слишком длинные цветовые полосы.
* в печах горит огонь (или в подогревателях), ок, но лучше дополнительно подписать что-то вроде «В работе», если все электроникой управляется, то выключенную печь вообще можно в Disabled (полупрозрачной сделать например) это даст понимание, что выключено вообще от сети, что включено, что включено и работает
* надо как-то решать вопрос валидации ввода данных. У вас много текстовых полей ввода, идеально — когда пользователь видит до валидации, в каких пределах от может ввести температуру, давление и пр. Даже инженеру-специалисту ошибиться — пара пустяков. Лучше предупреждать ошибки, чем и исправлять.
* нарисуйте сетку поверх UI, чтобы все выровнять. пример inediapps.com/portfolio/abudhabi.html (см. раздел «Гайдлайны»)
Внешний вид, конечно, мне не нравится, но хотя бы в мелочах напишу.
* уберите серый фон с мнемосхемы, у вас тексты не читаются + стандартные текстовые поля встанут получше
* Кнопки навигации визуально слишком бледные (подобные кнопки часто для Disabled состояния делаются) сделайте их, возможно, синими. Синий как нейтральный цвет — идеален. Оранжевое выделение синей кнопки встанет хорошо. Это вам даст серый для блокировки кнопок которые нельзя нажимать в данный момент.
habr.com/ru/post/448670/#comment_20062998
Требуется кому?
Все показатели, что описаны ниже, как раз нужно инженеру по дизайну отдать (либо он должен вывести все необходимые параметры сам, если их нет).
Дизайн это вообще сплошная инженерия, рисовать картинки может и сын маминой подруги.
Хотя если пытаться представить графику дизайна «отсортированную цифрами», то ничего хорошего точно не получится.
Я когда на Тех.Обслуживание в бетономешалку ползал, предпочитал данный ключ держать при себе.
Без тестового стенда имитирующего реальный прибор, как правило делать что-то нельзя в таких случаях.
Вообще не раз наблюдал как многие программисты делали правки прямо по живому проекту, из последнего — команда субподрядчик правили БД прямо на рабочем сервере, тестового себе не сделали, что приводило к периодическим крэшам основного сервака. Пользователи не имели доступа к БД иной раз сутки и более. Хорошо нами была предусмотрена возможность оффлайн работы для критических задач. Мои предупреждения, что компания клиента может потерять таким образом все данные или часть (бекап раз в какой-то период там все же делался) просто игнорировались.
Как я и упомянул в статье — схема «под бумажный чертеж» всегда смотрится.
Функционально конечно такие UI оценивать можно только на производстве.
На первом фото узнал Telerik )
Компьютер можно подключить с расстояния (из другого помещения), как я понял из того что видел по конкретному случаю на софте нужно только программу резки задать, далее нужна одна кнопка пуск. На крайний случай есть целый ряд защищенных устройств в продаже.
Но то что на самом лазере должны быть кнопки это верно, в том числе и аварийный STOP с ключиком (Ключик для ТО, чтобы никто не смог включить ничего никаким способом, когда он убран, пока руки и голова внутри прибора)
У меня на нокии c WindowsPhone все еще стоят, действительно годные и шустрые карты.
Нужно будет посмотреть, как это в авто-GUI интегрировалось.
Я подумаю, пока не знаю как ответить объективно.
Пока дам ссылку на свою старую статью про проектирование одной конкретной системы умного дома, для понимания как строится UI с карандашных набросков до рабочего варианта и с улучшением до версии 2
inediapps.com/blog/smarthome.html
Хотя сегодня, спустя 5 лет я бы там много чего поменял и улучшил (сама индустрия умных домов шагнула вперед, сменилось железо и пр.)
Но мы с коллегой открыли для себя мир старой Советской литературы про эргономику и устройство всяческих приборных панелей.
Например вот:
Недавно вот такой список литературы обнаружил, но еще не приступал к его изучению:
ссылка
Эти знания (в основном про UX) не утратили в актуальности именно в промышленных дизайнах.
У меня мало опыта работы с осциллографами, но в них действительно много хороших наработок по UI/UX за полвека их эволюции.
Основная мысль статьи — что со своим GUI надо работать. Особенно с новым и хотя бы пару месяцев по 8 часов в сутки на старте производства, тогда становится более — менее понятно, что именно нужно для работы конечному пользователю, а что излишне и можно запихнуть на задний план. (с железом так же).
К сожалению, многие, кто приходят к нам за дизайном, просто просят «сделать красиво» и после чего забивают на все остальное. Хотя по уму необходимо вернуться через полгодика тестов, указать дизайнеру на ошибки и пользовательский опыт/отзывы чтобы сделать лучше. Донести это до заказчика задача сложная, для большинства прибыль на первом месте, а мы тут с вами про заботу о потребителе.
По опыту хороший софт/UI выходит где-то на версии 2.5 — 3. Делая полный редизайн цикл начинается сначала.
Любой разработчик, который не взаимодействует с конечным потребителем железа (и UI), обречен на такие отзывы как ваш. Хотя только одного вашего мнения мало, нужно собрать минимум пару десятков по одному конкретному прибору.
Не нужно весь дизайн делать красным. Это ужасно. А на блеклых экранах еще и нечитаемо. Там кстати та же проблема с хреновыми экранами и томатным цветом UI, что вовсе не соответствует фирменной стилистике, как в примере из статьи.
Кнопки отмены расположены очень близко к кнопкам действия на сенсоре плохой точности, особенно при оплате банковской картой постоянно на уголок кнопок жму, чтобы случайно отмена не нажалась.
GUI очень тормозной. Такое чувство что там переполнение памяти из-за долгой работы софта где-то. Т.к. иногда попадаешь на лютые тормоза, а иногда вроде бы и норм.
Но с другой стороны для таких объемов и количества использований (нужна надежность) всё около дела. Работает же и достаточно успешно.
Вот пример с тех же выставок, от одного крупного Японского производителя.
Огромный (для авто) экран, гиганский Gauges (ИМХО не удобный), а камере заднего вида уделили всего уголок, при этом именно изображение с камеры тяжелее всего рассматривать же. Левая часть экрана вообще не используется почти. Я уже молчу на непонятные «дизайнерские» отражения на цифрах и стрелке спидометра сбивающие с толку.
Я думаю это временно. Года через 3 станут понятны все ошибки больших экранов в авто, мода поутихнет и станут делать хорошо.