А вот ещё удивительный термин наоборот. Охлаждающая жидкость в автомобиле называется антифризом. А вот незамерзайка — это вообще зимняя жидкость для мытья стёкол.

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

В то же время сходить раз в несколько лет проголосовать — ничего не стоит. А право сделать это называется «активным избирательным правом».

Это так потому, что избирать это active voice, а быть избранным — это passive voice. Логика ясная (в отличие от логики, по которой синхронное называется асинхронным), но всё равно каждый раз приходится в голове это переворачивать. Но я считаю, что раз логика тут лингвистическая, то, надо было идти дальше, и по-русски называть это действительным и страдательным избирательным правом! Другой вариант — перейти на математическую терминологию и разделить избирательное право на действительное и мнимое.

На вчерашнем семинаре интерфейсного курса разбирали элемент настройки окна:

Здесь нарушен синтаксис. Синтаксически радиокнопки — это набор однородных членов предложения, остальные члены которого даны в общей подписи. Здесь подпись «не открывается» не сочетается с общей подписью «Открывается». Формально мы как бы выбираем между вариантами: открывается влево, открывается вправо, открывается не открывается.

Чтобы исправить синтаксис, нужно все радиокнопки сделать обстоятельствами, то есть чтобы они отвечали на вопрос «как?»:

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

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

Во втором варианте последняя радиокнопка потеряла автономность. Чтобы понять, что именно «никак», приходится читать общую подпись. А вариант «не открывается» был самодостаточным.

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

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

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

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

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

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

Оправдания не имеют значения, и по идее надо сразу переходить к предложениям: что теперь делать-то? Но все мы живые люди, и иногда очень хочется объяснить, почему что-то не получилось. Если вы просто начнёте оправдываться, клиент будет думать, что решать созданную вами проблему вы не собираетесь. Поэтому нужно хотя бы сказать: «Я хочу объяснить, почему не получилось, и потом, если позволите, расскажу, как предлагаю исправить ситуацию».

Каким бы ни было ваше предложение, нужно убедиться, что клиенту оно подходит. «К завтрашнему дню уже точно будет» — это предложение, но оно звучит, как будто вы сами назначили себе новый дедлайн, не спросив мнение клиента. Мало кому такое понравится. Более нормальный вариант: «Чтобы доделать оставшееся, я бы хотел договориться взять ещё два дня». Тут клиент может либо согласиться, либо возразить, и тогда вы сможете думать дальше.

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

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

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

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

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

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

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

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

Спроектировали вы «новый флоу», а начальство вам такое: «Так а почему вы говорите, что это новый флоу? Тут ведь то же самое: выбираешь букет, указываешь адрес, оплачиваешь». Что вы на это ответите? «Да, но мы уменьшили число шагов»? Ну так а фигли сразу так и не сказали, зачем этот обмен репликами вам?

Иду на днях по переходу в Москве, вижу такое:

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

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

Но две стрелки по-прежнему противоречат друг другу. Я это называю итальянской навигацией. В Италии на дорогах я не раз встречал рядом знаки типа «Римини прямо» и «Римини направо» — можно ведь и так и так доехать! Это взрывает мозг.

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

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

Вот первая попавшаяся работа. Это главная страница, меню пицц:

Здесь сразу можно убрать мешающие ингредиенты, добавить собственные, выбрать размер и тесто. Видите ли вы проблему?

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

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

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

Иногда бывает, что в таком же контексте кнопку «Добавить в корзину» превращают в какую-то считалку типа − 1 + после добавления первой пиццы. Тут мозг окончательно взрывается. Если нажимать плюс несколько раз попеременно с изменением начинки, а потом нажать пару раз минус, невозможно даже предположить, что в итоге окажется в заказе. При этом сценарий «заказать две пиццы с курицей, но одну из них без шампиньонов» — достаточно нормальный, чтобы про него подумать.

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

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

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

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

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

Тут тоже почти исчезла:

А тут пропала цена и название:

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

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

Очевидно, что столица России — Москва, столица Франции — Париж, а столица Китая — Пекин.

Ещё есть страны, где самый известный город — это не столица. Столица Турции — не Стамбул, а Анкара. Столица Канады — не Торонто, а Оттава. Столица Бразилии — не Рио-де-Жанейро, а Бразилиа. Это неочевидные столицы, но вы всё равно в курсе.

Но есть вдвойне неочевидные столицы.

Скажем, все знают, что столица Нидерландов не Амстердам, а Гаага. Да вот только столица Нидерландов — как раз Амстердам, несмотря на то, что все органы государственной власти находятся в Гааге. Что же делает Амстердам столицей? А вот просто такая традиция, делать вид, что Амстердам — столица.

Или вот есть столица Израиля — Иерусалим. Точнее, так считает сам Израиль. А вот по мнению ООН, столица Израиля — Тель-Авив! Взрывает мозг тот факт, что у кого-то за пределами страны может быть мнение о том, где у страны столица. Понятно, что в Иерусалиме неспокойно, и многие страны держат свои посольства в Тель-Авиве, но делать вид, что он столица, довольно странно.

Кстати, ещё забавность. Столица США — не Нью-Йорк, а Вашингтон, это понятно. Но даже столица штата Нью-Йорк — не Нью-Йорк, а Олбани!

А какие вдвойне неочевидные столицы вы знаете?