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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вспомнил одну штуку.

Во вчерашнем совете показал интерфейс с рядом чекбоксов:

Хорошо бы упростить человеку выделение ряда чекбоксов. Если я нажал клавишу мыши над чекбоксом и повёл мышь вертикально, не отпуская клавишу, то все чекбоксы, над которыми я «проехал», должны переключиться в то же состояние.

Уточнение про то же состояние — важное. Если первым нажатием я чекбокс включил, то все, по которым я потом веду, должны включиться, а не переключиться (как было бы, если бы я их прокликал по очереди). Если у вас есть под рукой Фотошоп, посмотрите, как там работают «глазики» в панели слоёв — вот так и надо.

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

Создатели айфона изобрели новый интерфейсный элемент — индикатор листания, в простонародье «биатлон»:

До айфона такое обозначали стрелками:

Но стрелки навязчивые и предполагают прицеливание в себя. А биатлон — скромный и намекает на доступность свайпа.

Когда страниц слишком много, биатлон разрастается до неприличной длины:

Поэтому важно помнить правило 7 биатлонинок: если биатлонинок больше 7 (±2, ясное дело), то дальше показывать их нет никакого смысла и можно спокойно намекнуть на продолжение уменьшением их размера:

В первом айфоне так ещё не умели.

Конечно, число 7 взято с потолка. Реальный смысл в том, что если биатлонинки сливаются в линию и не поддаются подсчёту, то можно их и прибрать.


См. также совет о правиле семи элементов.

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

Вот завалялась картинка:

Я сначала случайно прочитал day light вместо day flight и подумал: ого, они показывают, с какой стороны будет солнце! Вот вам пример повышения информативности. Это полезно, это влияет на выбор места (обычно я в уме представляю, как полетит самолёт и где будет солнце, чтобы ни дай бог не попасть под него).

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

Что мне толку с того, что вариантов именно 26? Как это повлияет на моё желание перейти по ссылке? Меня-то интересует, есть ли там что-то подходящее. Лучше написать, что за варианты: со шнурками и без, с прорезиненной подошвой. Или показать превьюшечки.

Количество имеет смысл, например, тут:

Число позволяет мне оценить, сколько работы меня ждёт (а окружающим — умею ли я пользоваться почтой; это, конечно, не мой скриншот). Если я недавно видел 2, а теперь вижу 5, я понимаю, что пришла новая почта.

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

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

Замкнутость — это что-то вроде математически полной продуманности интерфейса, когда все случаи рассмотрены и противоречия разрулены. Может, не очень удачное слово, но пока такое. Я имею в виду, все пути в интерфейсе ведут в какие-то имеющиеся состояния внутри интерфейса.

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

Давайте вот разберём пример.

Скажем, надо сделать поле с автодополнением. Дизайнер рисует поле и показывает, как работает автодополнение:

А потом где-нибудь в описании пишет:

В поле работает автодополнение. Оно помогает ввести значение, которое ранее уже вводили. Если подходящих значений несколько, подставляет в самом поле самое часто используемое, а снизу рисует выпадайку, в которой можно выбрать из них. Достаточно, чтобы совпало хотя бы одно слово, например если уже вводили «ремонт часов», предлагает этот вариант по «ча».

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

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

Дизайнер уходит думать и возвращается с уточнением в описании:

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

А сейчас видите дыру?

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

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

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

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

А могу нажать на стрелку вниз, и получится такое:

Так ведь? А что тогда во втором случае, если нажать на стрелку вниз, будет?

Так что ли?

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

Тут дизайнер перестаёт писать описание и начинает латать дыры на лету. Говорит, «давай в этом случае сделаем, чтобы бекспейс стирал всё дописанное и возвращал исходное „ча“, и стрелка вверх тоже».

Но такой патч ничего не замыкает, а только сильнее размыкает. Теперь у нас появляется какое-то особое состояние интерфейса, когда бекспейс работает не как обычно. И надолго ли это состояние сохраняется? Например, если я введу „с“, будет ведь вот так:

И это согласно исходному описанию, безо всяких поправок — ведь сейчас уже начало введённой строки совпадает с началом единственного подходящего варианта, и выпадайка не нужна. Но посмотрите ещё раз на предыдущую картинку. Какого хрена там делала выпадайка в точно такой же на вид ситуации? И почему выпадайка пропала при вводе буквы „с“? Уже совсем трудно предсказать, что сделает бекспейс. Помнит ли он ещё, что слово «ремонт» тут «ненастоящее»?

Это не то, чтобы неразрешимые проблемы. Тут нет никакой проблемы всё аккуратно распутать. Но просто маловероятно, что дизайнер хотя бы увидел сам этот ворох вопросов, если ему показалось, что добавленная им к исходному описанию мысль всё объясняет.

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

Я на этом возьму паузу, а вам всем домашка: замкнуть этот интерфейс.

И ещё почитайте про автодополнение через выделение.