Инерция в интерфейсах

Раскин подробно освещает вопросы скорости взаимодействия пользователя с компьютером, рассказывая о законах Хика и Фиттса. У автора есть несколько новых соображений по теме, и о них пойдет речь в этой статье.

На мысли натолкнуло одно небольшое, но острое изменение в дизайне iOS 5, последней на данный момент версии прошивки Айфона. По вполне логичным соображениям фирма Эппл решила поместить кнопку для перехода в свой магазин музыки прямо из музыкального проигрывателя. Решила — и поместила. И сделала это так:

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

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

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

Поскольку это ошибочное действие было выполнено по инерции, мы так и будем называть наш закон: закон инерции.

Проблема набора на клавиатуре

Закон инерции не ограничивается одним единственным примером. Он повсюду.

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

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

Одним из решений является запрет нажатий на кнопки при помощи пробела. Это снизило бы шанс выполнения непреднамеренных действий, но не избавило бы от всех проблем и привело бы к потере возможности управления с клавиатуры.

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

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

Проблема смены интерфейса

Не менее серьезным недостатком является внезапная смена элементов интерфейса.

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

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

Это один из ярчайших примеров инерции в интерфейсах. Автор не раз попадал в такую ситуацию и уверен, что он не одинок.

В качестве решения можно предложить задерживать смену кнопок на некоторое время после завершения загрузки.

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

Проблема предупреждений

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

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

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

Количественная оценка инерционности интерфейса

Можно попытаться формализовать описанные особенности и вывести методику оценки подверженности интерфейса инерции.

Очевидно, что вероятность выполнения действия по инерции определяется:

Пусть скорость печати первого пользователя составляет 360 символов в минуту, или 6 символов в секунду. Первый пользователь владеет слепым методом набора, и его реакция составляет 1 секунду.

Скорость второго пользователя примем равной 120 символам в минуту, или 2 символам в секунду. Второй пользователь не владеет слепым методом набора, и его реакция составляет 5 секунд.

Пусть опасной клавишей является пробел. Вероятность появления пробела в английском тексте составляет 0,2. То есть, первый пользователь в среднем нажмет пробел 72 раза за минуту, или 1,2 раза за секунду. Второй пользователь нажмет пробел 24 раза за минуту, или 0,4 раза за секунду.

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

Для первого пользователя:

Для второго пользователя:

Рассчитаем инерцию при задержке, равной времени реакции.

Для первого пользователя:

Для второго пользователя:

И рассчитаем инерцию для задержки, большей времени реакции в два раза.

Для первого пользователя:

Для второго пользователя:

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

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

Автору кажется разумным делать задержку такую, чтобы инерция была в интервале от -1 до 0.

Андрей Маркелов