Это кажется очевидным, но ошибки на эту тему встречаются так часто, что надо бы написать.

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

Вот некоторые ошибки, которые мне встречались:

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

Эта мысль относится к теме «Обратная связь».

Это такой принцип в интерфейсе — называется «дай нажать».

Приведу три примера.

Группа чекбоксов с одним обязательным

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

То есть нужно, чтобы человек выбрал уведомление хотя бы одним каким-то способом, но может накликать и несколько.

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

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

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

Чекбокс и поле

В настройке комментариев в Эгее есть чекбокс «присылать по почте», которому подчинено поле адреса:

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

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

Лучше так: давать заполнить поле, даже если чекбокс выключен; включать чекбокс автоматически, как только в поле что-то вписали. В обратную сторону — аккуратнее: если чекбокс сняли, стирать адрес из поля не надо, мало ли. Пользовательские данные обладают бесконечной ценностью.

Выбор даты

Вот возможный вариант реализации выбора даты рождения в интерфейсе:

Как вы знаете, некоторых дней не существует в природе, например не бывает 31 июня. А 29 февраля в некоторые годы бывает, а в некоторые — нет.

Чтобы не дать пользователю ввести несуществующую дату, некоторые разработчики убирают из поля дня несуществующие дни. То есть если выбран месяц июнь, то дня «31» просто не будет в выпадайке. Но что, если у меня день рождения 31 августа? Я хочу ткнуть в 31, а потом выбрать август. Дай нажать!

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

Лучше так: при вводе дня, несовместимого с текущим выбранным месяцем, развыбирать месяц —

Если я выбрал 29 февраля, а выбранном году такого нет, развыбирать год.

Отчасти похожая мысль — кнопка «Купить» всегда доступна.

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

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

Ты соглашаешься, она начинает качать:

Пока она качает, ты переключаешься в основное окно программы заниматься тем, зачем её запустил:

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

А потом, когда ты её запускаешь в следующий раз, ты снова видишь вот это:

И снова соглашаешься, и оно снова начинает качать то, что уже давно скачала:

И так до бесконечности.

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

Коля Товеровский с командой единомышленников выпустил программу для Мака «Конспект». Это специальный блокнот для осмысленного ведения записей во время встреч с клиентом:

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

К сожалению, ребята не успели всё доделать и во время защиты показывали продукт так же, как Стив Джобс показывал Айфон: был заготовлен один-единственный сценарий, при котором ничего не глючило. Можете потыкать в ту версию с защиты, но полагаться на неё не стоит. Не знаю, сколько она ещё проживёт по этому адресу.

А в качестве результата «для всех» была представлена только промостраница будущего продукта:

(Ну, что делать, такой флекс. Лучше так, чем не допуститься до защиты).

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

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

Когда только начали делать, сначала все представляли какую-то страничку с четырьмя колонками, как нарисовано в книге:

Типа, пишешь где-то текст, а потом отдельные его куски как-то переносишь в одну из колонок.

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

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

Тут руководитель проекта Анна Доронина дала интервью «Кто студенту», где рассказывает о непростой истории проекта. У неё там процесс дизайна в трёх скриншотах, но на самом деле вариантов было намного больше.

С Бирманом легко: он достаточно толерантен, матом не пишет.

Помимо работы над интерфейсом, тогда же на дипломе мы зафигачили иконку (справа):

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

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

После защиты дипломов я перестал следить за судьбой проекта, и выход маковского приложения для меня для самого стал сюрпризом. Зацените тоже: «Конспект».

Сначала написал это в своём телеканале, потом решил перенести сюда.

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

Я спрашиваю, что надо сделать, чтобы подключиться. Прошу не подсказывать тех, кто говорит по-венгерски. Все говорят: «нужно поставить галочку и нажать на кнопку!».

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

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

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

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

Я говорю, мол, вместо того, чтобы вносить деньги, люди будут жать на кнопку «Подвешено 5 поездок», потому что она стоит там, где обычно стоит кнопка «Далее». Кто-то в классе соглашается, кто-то сомневается.

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

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

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

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

Вот представьте, что при улучшении интерфейса, в который тыкает сотрудник на паспортном контроле, очереди уменьшатся вдвое. Разве это не классно?

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

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

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

В классических интерфейсах курсора-пальчика не было. Элементы управления были стандартизованы и сомнений в том, как они сработают, не оставалось:

Меню в каждой программе в одном месте и ведёт себя одинаково — можно дополнительно не подсказывать. Точно так же написанное слово File в другом месте уже никто не воспримет как что-то, что можно нажать. Кнопки передают нажимаемость выпуклостью — их можно поставить где угодно, и человек поймёт. Никакой обратной связи при наведении не требовалось.

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

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

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

В одной из версий Виндоуса в тулбарах убрали выпуклость кнопок, оставили просто иконки:

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

Получается, у нас есть три варианта. Обратная связь при наведении:

1. Отсутствует — объект своим видом однозначно передаёт нажимаемость.
2. Проявляется в самом объекте (подсветка, рамка).
3. Проявляется в курсоре мыши (пальчик, балка).

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

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

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

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

В Эгее, кстати, оказалось так: у кнопок курсор — пальчик, но у чекбоксов и радиокнопок — стрелка. Получается как будто совсем уж непоследовательно: не подходит ни логика «всё, что нажимается — с пальчиком», ни логика «как в операционной системе». Но я не хочу ничего менять, как щас — лучше всего.

Ну и в связи со всем этим нужно ещё помнить, что никакого наведения нет на тач-экранах, поэтому надо рисовать элементы понятно изначально.

В квартире, в которой я жил зимой в Тель-Авиве, был такой таймер водогрейки:

Я не сразу понял, как он работает. Попробуйте додуматься.

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

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

Красные фигулины соответствуют пятнадцатиминуткам. Если фигулина включена (то есть сдвинута внутрь), то в её пятнадцатиминутку водогрейка греет воду. На фото таймер настроен греть воду с 4 до 5, с 7 до 8, с 14 до 15 и с 18 до 19. При этом включение и выключение водогрейки в нужное время происходит как-то механически. Всё же крутится, и вот, когда треугольничек оказывается на территории включенных красных фигулин, водогрейка включается. Об этом свидетельствует зажигающийся красный светодиод в ЛНУ.

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

Когда я это понял, мне в голову пришли две не очень-то связанные мысли.

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

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

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