Личный опыт: некоторые проблемы яхтенных систем

Заметки об интерфейсах, с которыми я имел дело в недавнем двухнедельном переходе

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

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

Итак, истории.

(Физические) боли реализации тревог

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

Когда мы поздно вечером вышли в 20-часовой переход из Борнхольма в Грайфсвальд, где-то через полчаса на панели двигателя сработала тревога низкого заряда батареи — замигал индикатор и из зуммера пошел громкий писк. Я стоял за штурвалом, окрикнул капитана (впрочем он уже вскочил от звука), объяснил ситуацию. Он пошёл проверять электрику, а я стал искать способ подтвердить тревогу — то есть отключить звук. В терминах профсистем это называется «квитирование тревоги» (или alert acknowledgement) — в случае возникновения тревоги, система, в зависимости от её критичности, начинает активно уведомлять пользователя, но после квитирования она становится менее заметной — чтобы не отвлекать, а также чтобы в случае возникновения другой тревоги пользователь обратил на неё внимание, а не проигнорировал из-за первой. Также действие квитирования может иметь юридический смысл — пользователь взял на себя ответственность, что он в курсе тревоги и предпринимает какие-то действия по её устранению.

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

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

Где-то через час писк стал прерывающимся — видимо, батарея подзаряжалась, и считываемое значение стало прыгать вокруг порога. Я уже ушел с вахты чтобы отдохнуть перед куда более продолжительной, но эти нерегулярные изменения мешали уснуть. Я и так был зол на проектировщиков панели, а тут даже не выдержал и матами выругался в духе «они ещё и про гистерезис не в курсе!»

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

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

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

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

Обобщим принципы и проблемы из этой истории:

1. Тревога должна быть осмысленной, а способы донесения её до пользователя должны соответствовать её критичности. В данном случае тревога звучала, будто происходит что-то невообразимо плохое, привлекая к себе внимание до боли в ушах, но по факту единственный вывод от тревоги в море, в отсутствии должного сервиса и спокойной обстановки, был «просто ничего не меняй».
2. В системе должна быть возможность квитировать или, хотя бы, приглушить (mute) тревогу, чтобы уже известная проблема не отвлекала внимание (в данном случае чисто физиологически), плюс в случае возникновения других тревог пользователь не проигнорировал их или не был дезориентирован обилием раздражителей. Кстати, в авиации хватает историй, когда одна единственная тревога с непонятной причиной приводила к серьезным последствиям, а когда таких тревог было несколько и они постоянно срабатывали (и даже не так важно, противоречили они друг другу или нет) — пилоты из-за дезориентации и стресса не могли сделать простейшего базового действия для устранения проблемы и самолёт падал.
3. Гистерезис и его аналоги (по сути, любые механизмы учёта обратной связи, «памяти» системы) очень важны для того, чтобы не создавать последовательности тревог из-за одной и той же причины — и чётко дифференцировать что разные тревоги одного типа вызваны разными причинами. В реальном мире в любые показания всегда вносится шум — как на уровне считывания сигнала, так и на уровне различных реальных событий (например, судно идет по кромке коридора допустимого отклонения маршрута, и то выходит, то попадает внутрь него), и это нужно учитывать. В противном случае мы получим лишь один плюс — более дешевое решение, но плюс этот для производителя.

Без ночи ночью

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

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

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

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

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

Проблемы движения по маршруту

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

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

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

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

* * *

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