Правдивая ложь оптимистичных пользовательских интерфейсов

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

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

Дальнейшее чтение на SmashingMag:

• Пользователь — анонимный веб-дизайнер
• Проектирование карточных пользовательских интерфейсов
• Диалоговые интерфейсы: где мы сегодня?
  

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

Давным-давно

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

1. Пользователь нажимает кнопку.
2. Кнопка срабатывает в отключенном состоянии.
3. Вызов отправляется на сервер.
4. Ответ от сервера отправляется обратно на страницу.
5. Страница перезагружается, чтобы отразить статус ответа.

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

• Пользователь должен ждать. К настоящему времени мы знаем, что даже самая короткая задержка времени отклика сервера негативно сказывается на восприятии пользователем всего бренда, а не только данной конкретной страницы.
• Каждый раз, когда пользователь получает ответ на свое действие, он представляется довольно деструктивным образом (загружается новая страница вместо обновления существующей), что нарушает контекст задачи пользователя и может повлиять на ход его мыслей. Хотя в данном случае речь не обязательно идет о многозадачности, любое переключение мыслительного контекста неприятно. Таким образом, если действие по своей сути не предназначено для переключения контекстов (онлайн-платежи — хороший пример естественного переключения), переключение создаст недружественный тон диалога между пользователем и системой.

Хорошие не такие старые дни

Затем появился так называемый Web 2.0, предоставивший новые способы взаимодействия с веб-страницами. Их ядром были XMLHttpRequest и AJAX. Эти новые способы взаимодействия были дополнены «спиннерами»: простейшей формой индикатора прогресса, единственной целью которого было сообщить пользователю, что система занята выполнением какой-либо операции. Теперь нам не нужно было перезагружать страницу после получения ответа от сервера; вместо этого мы могли бы просто обновить часть уже отрендеренной страницы. Это сделало Интернет гораздо более динамичным, а также обеспечило более плавный и увлекательный опыт для пользователей. Типичное взаимодействие с кнопкой теперь может выглядеть так:

1. Пользователь нажимает кнопку.
2. Кнопка переходит в отключенное состояние, и на кнопке отображается какой-то счетчик, указывающий на то, что система работает.
3. Вызов отправляется на сервер.
4. Ответ от сервера отправляется обратно на страницу.
5. Визуальное состояние кнопки и страницы обновляется в соответствии со статусом ответа.

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

Этот тип взаимодействия широко используется повсеместно в цифровых медиа. Но остается одна проблема: пользователям по-прежнему приходится ждать ответа от сервера. Да, мы можем заставить наши серверы отвечать быстрее, но как бы мы ни старались ускорить инфраструктуру, пользователям все равно приходится ждать. Опять же, пользователи, мягко говоря, не любят ждать. Например, исследования показывают, что 78% потребителей испытывают негативные эмоции из-за медленных или ненадежных веб-сайтов. Более того, согласно опросу, проведенному Harris Interactive для Tealeaf, 23 % пользователей признаются, что ругались на свои телефоны, 11 % кричали на них, а целых 4 % фактически бросали свой телефон, когда сталкивались с проблемой онлайн-транзакции. Задержки — одна из таких проблем.

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

Оптимистичный интерфейс

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

op-ti-mis-tic , прил. с надеждой и уверенностью в завтрашнем дне.

Начнем с части «уверенность в завтрашнем дне».

Как вы думаете: как часто ваш сервер возвращает ошибку при каком-то действии пользователя? Например, часто ли ваш API дает сбой, когда пользователи нажимают кнопку? Или, может быть, он часто терпит неудачу, когда пользователи нажимают на ссылку? Честно говоря, я так не думаю. Конечно, это может варьироваться в зависимости от API, загрузки сервера, уровня обработки ошибок и других факторов, в которые вы, как разработчик внешнего интерфейса или специалист по UX, возможно, не захотите вмешиваться. Но до тех пор, пока API стабилен и предсказуем, а внешний интерфейс правильно сообщает о законных действиях в пользовательском интерфейсе, то количество ошибок в ответ на действия, инициированные пользователем, будет довольно низким. Я бы даже сказал, что они никогда не должны превышать 1-3%. Это означает, что в 97–99% случаев, когда пользователь нажимает кнопку на веб-сайте, ответ сервера должен быть успешным, без ошибок. Это заслуживает лучшего рассмотрения:

Подумайте об этом на мгновение: если бы мы были на 97–99 % уверены в успешной реакции, мы могли бы быть уверены в будущем этих ответов — ну, по крайней мере, гораздо более уверены в будущем, чем кот Шредингера. Мы могли бы написать совершенно новую историю о взаимодействии с кнопками:

1. Пользователь нажимает кнопку.
2. Визуальное состояние кнопки мгновенно переходит в режим успеха.

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

С точки зрения разработчика полный цикл выглядит так:

1. Пользователь нажимает кнопку.
2. Визуальное состояние кнопки мгновенно переходит в режим успеха.
3. Вызов отправляется на сервер.
4. Ответ от сервера отправляется обратно на страницу.
5. В 97–99% случаев мы знаем, что ответ будет успешным, поэтому нам не нужно беспокоить пользователя.
6. Только в случае неудачного запроса система сообщит об этом. Пока не беспокойтесь об этом — мы вернемся к этому позже в этой статье.

Давайте рассмотрим несколько примеров оптимистичных взаимодействий. Вы, вероятно, знакомы с кнопками «Нравится», которые есть в Facebook и Twitter. Давайте посмотрим на последнее.

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

Давайте посмотрим, что происходит во вкладке «Сеть» инструментов разработчика нашего браузера в этот самый момент.

На вкладке «Сеть» показано, что запрос к серверу был отправлен, но все еще выполняется. Счетчик «лайков» еще не увеличился, но с изменением цвета интерфейс четко сообщает пользователю об успехе еще до получения ответа от сервера.

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

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

Однако здесь следует отметить одну вещь. Если мы посмотрим на время отклика сервера, то увидим, что оно составляет чуть более 1 секунды . Учитывая, что модель RAIL рекомендует 100 миллисекунд как оптимальное время отклика для простого взаимодействия, обычно это слишком долго. Однако в этом случае пользователь не ощущает никакого времени ожидания из-за оптимистичного характера этого взаимодействия. Хороший! Это еще один пример психологической оптимизации производительности.

Но давайте посмотрим правде в глаза: вероятность того, что сервер вернет ошибку, составляет от 1 до 3%. Или, возможно, пользователь просто не в сети. Или, что более вероятно, сервер возвращает то, что технически является успешным ответом, но ответ содержит информацию, которая должна быть дополнительно обработана клиентом. В результате пользователь не получит индикатор отказа, но и считать ответ успешным мы тоже не можем. Чтобы понять, как поступать в таких случаях, мы должны понять, почему и как оптимистичные пользовательские интерфейсы работают в первую очередь психологически.

Психология оптимистичных интерфейсов

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

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

Оптимистичный пользовательский интерфейс имеет два основных компонента, которые заслуживают психологического анализа:

• быстрая реакция на действия пользователя;
• обработка потенциальных сбоев на сервере, в сети и в других местах.

Быстрая реакция на действия пользователя

Когда мы говорим об оптимистичном дизайне пользовательского интерфейса, мы имеем в виду оптимальное время отклика при взаимодействии человека с компьютером. И рекомендации для этого типа общения существуют еще с 1968 года. Тогда Роберт Б. Миллер опубликовал свою основополагающую статью «Время отклика в диалоговых транзакциях человека и компьютера» (PDF), в которой он определяет целых 17 различные типы ответов, которые пользователь может получить от компьютера. Один из этих типов Миллер называет «реакцией на активацию управления» — задержку между нажатием клавиши и визуальной обратной связью. Еще в 1968 году оно не должно было превышать 0,1–0,2 секунды. Да, модель RAIL не первая, кто рекомендует это — совет существует уже около 50 лет. Однако Миллер отмечает, что даже эта короткая задержка обратной связи может оказаться слишком медленной для опытных пользователей. Это означает, что в идеале пользователь должен получить подтверждение своего действия в течение 100 миллисекунд . Это входит в диапазон одного из самых быстрых бессознательных действий, которые может выполнять человеческое тело, — моргания. По этой причине 100-миллисекундный интервал обычно воспринимается как мгновенный. «Большинство людей моргают около 15 раз в минуту, а моргание длится в среднем от 100 до 150 миллисекунд», — говорит Давина Бристоу из Института неврологии Университетского колледжа Лондона, добавляя, что «это означает, что в целом мы тратим на моргание не менее 9 дней в году. ”

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

Обработка потенциального сбоя

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

Люди естественным образом организуют свою деятельность в группы, заканчивающиеся выполнением субъективно определенной цели или подцели. Иногда мы называем эти сгустки «цепочкой мыслей», «потоком мыслей» (PDF) или просто «потоком». Состояние потока характеризуется пиковым наслаждением, энергичным сосредоточением и творческой концентрацией. Во время потока пользователь полностью поглощен действием. Твит Тэмми Эвертс прекрасно иллюстрирует это:

В сети продолжительность таких сгустков активности намного короче. Давайте на мгновение вернемся к работе Роберта Б. Миллера. Типы ответов, которые он цитирует, включают:

• ответ на простой запрос указанной информации;
• ответ на сложный запрос в графическом виде;
• ответ на «Система, ты меня понимаешь?»

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

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

Пессимистичная сторона оптимистичного дизайна пользовательского интерфейса

Безусловно, самое распространенное замечание, которое я слышу, заключается в том, что оптимистичный дизайн пользовательского интерфейса — это своего рода черный шаблон — мошенничество, если хотите. То есть, используя его, мы лжем нашим пользователям о результате их взаимодействия. Юридически любой суд, вероятно, поддержал бы этот пункт. Тем не менее, я считаю эту технику предсказанием или надеждой. (Помните определение слова «оптимистичный»? Здесь мы оставляем место для «обнадеживающей» его части.) Разница между «ложью» и «прогнозированием» заключается в том, как вы обрабатываете эти 1–3% неудачных запросов. Давайте посмотрим, как оптимистичная кнопка «Мне нравится» в Твиттере ведет себя в автономном режиме.

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

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

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

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

• Любое уведомление, которое внезапно появляется на экране, переключает контекст пользователя, побуждая его проанализировать причину сбоя, причину, которая, вероятно, будет представлена ​​в сообщении об ошибке.
• Как и любое сообщение об ошибке или уведомление, это должно направлять пользователя в этом новом контексте, предоставляя полезную информацию.
• Эта полезная информация задаст еще один контекст.

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

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

Крайний пессимизм

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

Если оптимистичный пользовательский интерфейс реализован правильно и взаимодействия применяются только к тем элементам, которые никогда не ждут ответа сервера более 2 секунд, тогда пользователю придется закрыть вкладку браузера в течение этого 2-секундного окна. Это не особенно сложно с нажатием клавиши; однако, как мы видели, в 97-99% случаев запрос будет успешным, независимо от того, активна вкладка или нет (просто ответ не будет возвращен клиенту).

Таким образом, эта проблема может возникнуть только у тех 1–3%, у которых возникает ошибка сервера. Опять же, сколько из тех, кто спешит закрыть вкладку в течение 2 секунд? Если только они не участвуют в соревновании по скорости закрытия вкладок, я не думаю, что число будет значительным. Но если вы чувствуете, что это имеет отношение к вашему конкретному проекту и может иметь негативные последствия, используйте некоторые инструменты для анализа поведения пользователей; если вероятность такого сценария достаточно высока, то ограничить оптимистическое взаимодействие некритическими элементами.

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

Эмпирические правила

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

• Обязательное условие для всего, о чем мы говорили до сих пор: убедитесь, что API, на который вы полагаетесь, стабилен и дает предсказуемые результаты. Достаточно сказано.
• Интерфейс должен отлавливать потенциальные ошибки и проблемы до того , как запрос будет отправлен на сервер. А еще лучше полностью исключить все, что может привести к ошибке API. Чем проще элемент пользовательского интерфейса, тем проще будет сделать его оптимистичным.
• Применяйте оптимистичные шаблоны к простым бинарным элементам, для которых не ожидается ничего, кроме успеха или неудачи. Например, если щелчок по кнопке предполагает ответ сервера, такой как «да», «нет» или «возможно» (все из которых могут означать успех в разной степени), такая кнопка была бы лучше без оптимистичного шаблона.
• Знайте время отклика вашего API. Это очень важно. Если вы знаете, что время ответа на конкретный запрос никогда не опускается ниже 2 секунд, то, вероятно, лучше всего сначала добавить немного оптимизма по поводу вашего API. Как уже упоминалось, оптимистичный пользовательский интерфейс лучше всего работает при времени отклика сервера менее 2 секунд. Выход за рамки этого может привести к неожиданным результатам и большому количеству разочарованных пользователей. Считай себя предупрежденным.
• Оптимистичный пользовательский интерфейс — это не только клики по кнопкам. Этот подход можно применять к различным взаимодействиям и событиям в течение жизненного цикла страницы, включая загрузку страницы. Например, скелетные экраны следуют той же идее: вы прогнозируете, что сервер ответит успешно, чтобы как можно скорее заполнить заполнители, чтобы показать их пользователю.

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

Ресурсы

• «Время отклика в диалоговых транзакциях человека и компьютера» (PDF), Роберт Б. Миллер, осенняя совместная компьютерная конференция, 1968 г.
• «Представляем RAIL: ориентированная на пользователя модель производительности», Пол Айриш, Пол Льюис, Smashing Magazine, 2015 г.
• «Мобильный веб-стресс: влияние скорости сети на эмоциональное взаимодействие и восприятие бренда», Тэмми Эвертс, блог Radware, 2013 г.
• Применение потока в человеческом развитии и образовании , Михай Чиксентмихайи, 2014 г.
• «Детали мобильного дизайна: избегайте счетчика», Люк Вроблевски, 2013 г.
• «Почему производительность имеет значение, часть 2: управление восприятием», Денис Мишунов, Smashing Magazine, 2015 г.