Интересное обсуждение на курсе: участник придумал интерфейс, но формулирует сценарий для него на техническом языке, а не на языке пользователя — и только из-за этого не видит, в чём проблема с интерфейсом. Предлагаю проделать мысленное упражнение и представить, что же имел в виду пользователь. 4 минуты:
Это фрагмент № 115 онлайн-курса «Пользовательский интерфейс и представление информации». Записано на курсе 28 апреля 2023 года.
До 6 октября идёт запись на курс, который пройдёт с 7 октября по 5 ноября.
Я стараюсь со всеми работать по своему договору. Но договоры у меня есть не на все случаи жизни — иногда клиенты приносят свои. Я не подписываю договор, пока не согласен с ним, даже если это «наш стандартный договор» или «обычная практика».
Одна из вещей, которые я убираю первым делом — это неадекватный уровень ответственности. Когда договор пишут юристы, они любят густо намазать всё штрафами. Например, в договоре есть пункт о том, что от моей работы клиент может как-то там пострадать, и тогда я обязуюсь возместить ущерб в полном объёме за собственный счёт. К сожалению, я не смогу взять на себя такое обязательство. Или, например, говорится, что я должен буду понести судебные расходы, если клиенту придётся из-за моей работы как-то защищаться в суде. Простите, не смогу.
Ещё часто в договоры вставляют раздел про конфиденциальность, и в нём тоже много про ответственность. Этот раздел я предпочитаю убрать целиком. В большинстве случаев это просто не нужно. Не передавайте мне конфиденциальные данные, да и всё. Понимаю, бывают случаи, когда надо, но если вы меня приглашаете прочитать лекцию в вашей компании, то зачем нам это?
У меня подход простой: я рискую репутацией, а не деньгами. Клиент сам отвечает за любые последствия использования моей работы. Поэтому я прошу не только убрать все пункты о материальной ответственности из договора, но ещё и прямо прописать, что её нет.
Наверное можно представить себе ситуацию, когда исполнитель умышленно причиняет ущерб клиенту, но в таком случае клиент со своими юристами безо всякого договора сможет добиться компенсации. Если исполнитель после встречи с клиентом спёр из его офиса холодильник, то это воровство, хотя в договоре между ними не было ни слова об уважении к частной собственности.
Поток данных — один из моих методов проектирования интерфейса. Он помогает избавиться от ненужных экранов и шагов.
С точки зрения ТРИЗа, идеальный интерфейс — это интерфейс, которого нет, но его функция выполняется. И об этой функции можно думать как о функции посредника на пути потока данных: данные текут между людьми и машинами, а интерфейс как-то в этом участвует.
Простой пример
Человек собирается в поездку и хочет узнать погоду в городе назначения. В идеале должно быть так: человек только подумал об этом, и хоп — уже знает погоду. Но пока что это недостижимо, нужен интерфейс.
Интерфейс помогает данным о запросе человека попасть в машину; данным ответа попасть к человеку. Не прозевайте: предыдущее предложение — ключевое, ведь в нём написано, зачем нам вообще этот интерфейс! Так данные на входе — это город, а на выходе — погода. Отсюда получаем интерфейс: поле ввода города, и рядом — погода в нём.
Дальше уже его улучшаем автодополнением, обновлением по мере ввода, историей; помним город или даже несколько с прошлого раза, чтобы даже не вводить. Это просто применение базовых принципов.
А как было бы неправильно? Ну, например, начать анализировать предметную область, из каких параметров складывается погода и как их сгруппировать, или там как города объединяются в страны, а страны в континенты, проектировать навигацию по этой базе. Это всё «логично», но не должно быть основой интерфейса, так как не помогает потоку данных.
Сложный пример
Я делал интерфейс «Секьюриджа», программы для мониторинга объектов пультовой охраны. В магазинах, банках, квартирах установлены сенсоры и передатчики. По городу дежурят группы быстрого реагирования — «бойцы». Оператор следит за событиями и руководит перемещением бойцов с помощью программы.
В версии, которая была до меня, да и у конкурентов, были «модули»: в одном отображались сигналы, в другом — карта города с расположением бойцов, в третьем — картотека самих охраняемых объектов с поиском, в четвёртом — какой-то журнал, куда оператор должен записывать свои действия. Снова, всё «логично», но не помогает потоку данных.
Здесь в идеале не нужен не только интерфейс, но и пользователь! Если где-то сработала сигнализация и это не ложная тревога, то ближайшие бойцы должны поехать туда безо всякого оператора, а если ложная, то хозяева должны договориться об удобном времени прихода техника, который будет знать все подробности сбоя и придёт чинить. Но пока что это недостижимо, нужен оператор, и только поэтому и нужен интерфейс.
Интерфейс должен помочь данным о сигналах с объектов пройти через оператора и дойти до бойцов в виде инструкции или хозяев и техников в виде информации. Получается, оператор должен получить какие-то данные, что-то сделать с ними, что машина сделать не может, принять решения, и отправить данные обратно в систему. Данные системы для оператора: что за сигнал, где это, как там дела с электричеством и связью, какая там ближайшая группа быстрого реагирования, кто хозяин объекта и какой его телефон, какие датчики есть на объекте и как он выглядит на плане. Оператор вникает, что произошло, инструктирует бойцов или связывается с хозяевами и техником. Данные от оператора для системы: ложная ли была тревога, были ли выявлены неполадки, требуется ли работа техников, что сделано, устранена ли проблема.
Ну и всё, исходя из этого и строим интерфейс:
Нет никакой причины оператору по крупицам собирать информацию по разным модулям и потом заносить результат в ещё один модуль «журнал». Вся информация должна сразу быть перед глазами, как и кнопки записи итогов в журнал. Оператор видит всю картину и как с кем связаться; разбирается в ситуации; здесь же жмёт на итоговую кнопку.
Применимость
Такой способ думать об интерфейсе подойдёт, когда речь о конвейерном, транзакционном взаимодействии. На этом сложно построить интерфейс Гугль-дока или программы 3д-моделирования, ведь там процесс работы слишком творческий, нелинейный. Но всё же всегда полезно думать не модулями и не «бизнес-сущностями», а сценарием и ролью интерфейса в нём.
Ещё эти идеи где-то рядом с технозависимостью. В лекции о технозависимости мы говорим о том, что технические условия не должны влиять на интерфейс, ну а тут — что и логическое устройство чего бы то ни было, организация данных, отделов в компании в общем-то тоже не должны влиять на интерфейс.
Видно, что монтировал не я: слишком много крупного плана и не видно слайды, когда надо.
А ещё во второй половине кажется, что у меня вылезли красные трусы, но на самом деле это водолазка. Вообще эта чёрная кофта не была запланирована, но на площадке был адский дубак, и в свободное от доклада время я тупо стоял перед тепловой пушкой.
Задизайнить спинку кресла в самолёте — отдельное искусство. В большинстве самолётов они фиговые: один карман для всего, неудобный столик. Но на днях мне попалась довольно клёвая.
Исходное положение. Сразу чувствуется, что много про что подумали:
Сверху есть карман для «прессы», причём из него ничего не вываливается внизу, как иногда бывает. Он достаточно просторный, чтобы в него переложить никому не нужный журнал «Аэрофлот» из нижнего кармана. Есть отдельная мини-штуковина для геджетов и отдельный столик. На крышке столика ещё и приятные пиктограммы напоминают про безопасность.
Открываем верхнюю штуку:
Тут сразу всё: и прорезиненная поверхности с несколькими уступами, чтобы можно было положить или поставить телефон или планшет под любым углом, и полноценный подстаканник. И вся эта красота — отдельно от столика. Можно есть, смотреть кино и не рисковать случайным движением опрокинуть стакан с чаем себе на штаны.
Снизу — ещё один карман:
Туда можно сунуть ноутбук, пока он не нужен. Только резинки слишком уж слабые — хочется, чтобы так не оттопыривался. Ну и там слева ещё розетка есть.
В декабре 2022 года мы с Ромой Мочаловым, Никитой Дубровиным и Ди Логвиновым выпустили нашу схему московского метро, включающую планы до 2030 года. За прошедшие месяцы и реальность, и планы слегка изменились, поэтому нашу перспективную схему пришлось подкрутить:
У будущих линий 16, 17, 18 поменялись планируемые цвета:
Появилась пересадка Бутырская — Останкино:
Запланировалась пересадка с Аэроэкспресса на D5 на станции «Домодедово», не являющейся аэропортом (обожаю):
Последние московские открытия в нашем случае потребовали «включения» большего числа линий на нашей схеме. Что-то, что раньше было строящимся, теперь стало работающим:
Недавно в Москве открылась ещё куча метро и диаметров и обновилась официальная схема. Стала вот такой:
Мне несколько человек написали узнать, что я думаю.
Что не нравится
В целом, на мой взгляд, так и не получилось красоты. Диагональ Останкино — Перово D3 справа сверху слишком навязчива, побеждает вообще всё. Не решены проблемы в районе Сити, там каша.
Внешние кольца слились в одно, особенно в районе Хорошёва. На нашей схеме мы специально нашли такую форму колец, чтобы они уходили со своей орбиты достаточно далеко друг от друга, чтобы глаз не считал их продолжением друг друга:
Ещё непонятно, что происходит с аэропортом Внуково, почему его два:
В новостях рассказали, что метро приехало прямо в аэропорт, а на схеме почему-то есть сам аэропорт, а есть отдельно от него станция метро «Аэропорт Внуково». Расстояние между ними сравнимо с расстоянием между другими станциями, никакого шаттла или хотя бы пешеходной тропинки не нарисовано.
Но психотерапевты учат: не сравнивай других с собой; сравнивай других с тем, какими они были вчера!
Что нравится
В целом, конечно, стало лучше, чем было до этого — раньше была перекособоченная хрень со страшным синим аппендиксом слева. Сейчас хоть какой-то относительный баланс достигнут.
Пересадки теперь обозначены нормально. Наконец-то внедрён принцип «Одно название — один кружок», который я использовал в своей схеме ещё в 2013 году. Посмотрите на Парк культуры, Октябрьскую, Павелецкую на новой официальной схеме:
Зачем было столько времени упираться и рисовать по два кружка там, где можно было обойтись одним? Нигде в мире так не делали, эта была чисто московская придурь.
Напомню теоретические основы обозначения пересадок на транспортных схемах. Дизайн обозначений на схеме должен помогать пассажиру соотносить объекты и их подписи; находить объекты; прокладывать маршруты. Логика же обозначения Октябрьской двумя кружками была такая: «ну, там же две разных станции, они просто называются одинаково». Если это и так (это не так), то что с того, как это связано с задачей?
Если два кружка иногда подписаны двумя раздельными словами («Серпуховская», «Добрынинская»), а иногда одним («Октябрьская»), то решительно никак невозможно догадаться, почему это происходит и что это значит. Если ты уже знаешь всё про эти станции, то такой дизайн помогает тебя почувствовать себя хорошо, но, ещё раз: дизайн обозначений на схеме должен помогать пассажиру соотносить объекты и их подписи; находить объекты; прокладывать маршруты, а не: «успокаивать знатоков московской терминологии метро, где платформу называют станцией». Когда линии проходят через один кружок и около него стоит одна подпись, ты сразу видишь пересадку и не сомневаешься в том, как она называется. Глазу, скользящему взглядом по линии, легче «пересесть» на такой станции.
Самое страшное происходило на станциях типа Третьяковской и Таганской, где трём кружкам соответствовало две подписи. На что тут был расчёт, как это вообще можно было осмыслить? В новом дизайне всё встало на свои места — стало как у меня было десять лет назад.
Ещё умер руль на Библиотеке имени Ленина. Много лет считалось очень важным обозначить, как там именно переходы устроены, что между голубой и серой веткой нет «прямого» перехода. Про это тоже в книге есть:
Пассажирам как было плевать, «прямой» переход или «непрямой», так и осталось: они просто ищут указатель к нужной линии и идут по нему. Теперь это место на схеме выглядит проще.
И не забудьте изучить нашу схему московского метро, которая и красивее официальной, и обозначения использует хорошие. Аэропорт Внуково и новые диаметры откроем на ней следующим постом.
