Избранное

Позднее Ctrl + ↑

Превратить уродство в украшение: техрегламент про вид газомоторного топлива

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

В том числе на автобусах были уродские наклейки с ромбиками СПГ и КПГ:

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

В общем, все участники обсуждения думали, что эти СПГ и КПГ — элемент хвастовства экологичностью, но, в отличие от надписи «Чистый воздух», они непонятные. И мы решили их убрать. Утвердили документацию по новой экипировке. Начали оклеивать автобусы по новым стандартам. Слева — один из первых переодетых автобусов:

И тут вдруг опытный транспортник, не участвовавший в изначальном утверждении, заметил: постойте-ка, а где маркировка вида топлива? Она должна быть по техрегламенту номер такому-то!

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

Дальше я пошёл читать тот самый техрегламент:

Цвет и размеры этой наклейки должны соответствовать следующим требованиям:

​Цвет:
​Фон: зелёный
​Кайма: белая или белая светоотражающая
​Буквы: белые или белые светоотражающие

​Размеры:
​Ширина каймы: 4—6 мм
​Высота букв: ≥ 25 мм
​Толщина букв: ≥ 4 мм
​Ширина наклейки: 110—150 мм
​Высота наклейки: 80—110 мм

Слово «СПГ» должно располагаться в середине наклейки по центру.

Зелёный фон — это большая удача, ведь автобус как раз зелёный! Значит наклейки можно сделать на прозрачном фоне. Я задизайнил наклейки с нашим шрифтом:

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

Куда бы их приклеить, чтобы выглядело хорошо, да ещё и чтобы не переклеивать то, что уже успели наклеить на часть автобусов? А вот сюда, слева от гаражного номера:

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

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

К чему это я всё?

Иногда бывает, что к вашему прекрасному дизайну нужно добавить какую-то фигню: пометку 18+, логотип спонсора, номер лицензии. Чтобы не расстраиваться, попробуйте отнестись к этому элементу как к украшению. Конечно, есть минздравовский знак «Не курить», который специально задизайнили так, чтобы он уродовал всё на своём пути и спасения от этого не было, но обычно всё не так плохо.

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

По прилёте

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

А паспортный контроль проходят по прилёте. А сообщение «я дома» пишут по приезде. А в универ идут по окончании школы. Потому что это другое «по»! Оно по смыслу близко к «при» и требует такого же падежа после себя.

Кривая качества кофе

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

Сейчас мой любимый кофейный напиток — кортадо. Это двойная доза эспрессо с небольшим количеством едва взбитого молока; никакой пены. В некоторых местах ещё говорят «пикколо». В России мало кто знает слово кортадо, поэтому я говорю «флетвайт, но поменьше молока». По умолчанию говоря «кофе» я имею в виду именно это.

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

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

И только если прыгнуть выше головы по всем параметрам, появляется шанс приготовить напиток, который можно пить. Обратите внимание, здесь не идёт речь о чём-то вкусном, конечно. При 95% качества мы достигаем лишь уровня «нет срочной необходимости выплюнуть и прополоскать рот». При достижении 97,5% качества у напитка начинает появляться вкус, который вызывает интерес, и лишь после 98,8% вкус начинает приносить наслаждение.

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

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

Как-нибудь в другой раз расскажу, как искать хороший кофе.

На интерфейсном курсе: обозначение обязательных и необязательных полей

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

Это фрагмент № 118 онлайн-курса «Пользовательский интерфейс и представление информации». Записано на курсе 4 мая 2023 года.

До 6 октября идёт запись на курс, который пройдёт с 7 октября по 5 ноября.

Почитать о курсе

Программа, отзывы, запись

Классификация в голове дизайнера

Вот вам пример улучшения из Ай-ОСа 17. Кадр из видоса Брендона Бутча:

Когда создаёшь автоматизацию, раньше спрашивало, хочешь ли ты «персональную» или «домашнюю». Я дальше этого экрана никогда не проходил, потому что хрен знает, что это значит. Эплы по одним им известному принципу разделили триггеры на две категории.

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

Эта картинка отправляется в папку «Навигация» моего курса. Каждый раз, когда что-то классифицируете или делите на категории, задайте себе вопрос: а у пользователя в голове откуда эта классификация возьмётся? Она общепринятая или это только вы придумали?

Вот пример из эпловского же доклада как раз на эту тему:

Пусть надо выбрать вид транспорта. Деление на первом шаге на воздушный и наземный — понятное. А вот с топливом — засада. Если я хочу поезд, очевидно ли мне, в какой из категорий искать? Не факт, так что такое деление лучше убрать.

Заказчик вправе требовать

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

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

Вот формулировка, которая часто встречается во всяких пунктах про ответственность: «в таком-то случае Заказчик вправе требовать с Исполнителя возмещения того-то». Что это значит, зачем это писать? Я безо всякого договора вправе выйти на улицу и требовать, чтобы все прохожие сдали мне по тыще рублей. А прохожие вправе посылать меня с этим требованием подальше!

Удивительно, но большинство юристов не в состоянии написать: «В таком-то случае Исполнитель возмещает Заказчику то-то» безо всяких абстрактных прав требовать.

На интерфейсном курсе: мир пользователя

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

Это фрагмент № 115 онлайн-курса «Пользовательский интерфейс и представление информации». Записано на курсе 28 апреля 2023 года.

До 6 октября идёт запись на курс, который пройдёт с 7 октября по 5 ноября.

Почитать о курсе

Программа, отзывы, запись

Не беру лишней ответственности по договору

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

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

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

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

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

Интерфейс и поток данных

Это черновик, который я решил опубликовать.

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

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

Простой пример

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

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

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

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

Сложный пример

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

В версии, которая была до меня, да и у конкурентов, были «модули»: в одном отображались сигналы, в другом — карта города с расположением бойцов, в третьем — картотека самих охраняемых объектов с поиском, в четвёртом — какой-то журнал, куда оператор должен записывать свои действия. Снова, всё «логично», но не помогает потоку данных.

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

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

Ну и всё, исходя из этого и строим интерфейс:

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

Применимость

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

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

Доклад «Четыреста транспортных объявлений за 20 дней»

Недавно я показывал проект — информационное сопровождение Челябинской транспортной реформы. В мае рассказывал о нём на «Просмотре», и вот выложили видео:

Видно, что монтировал не я: слишком много крупного плана и не видно слайды, когда надо.

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

Ранее Ctrl + ↓