https://m.habrahabr.ru/company/jugru/blog/315806/

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

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

Задумайтесь на секунду: если мы на 97-99% уверены в успехе определённого ответа, то мы можем быть уверены и в будущем — ну, по крайней мере, в куда большей степени, чем кот Шрёдингера был уверен в своём. Следовательно, мы можем изменить весь сценарий взаимодействия с кнопкой на следующий:

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

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

С точки зрения разработчика, полный цикл выглядит следующим образом:

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

Психология, стоящая за оптимистичным UI

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

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

Практические правила

— Прежде всего убедитесь, что ваш API надёжен и возвращает предсказуемые результаты. Это чрезвычайно важно.

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

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

— Знайте время ответа своего API. Это критично. Если вы знаете, что для какого-то конкретного запроса время ответа никогда не оказывается ниже 2 секунд, то для начала займитесь работой над API. Как мы уже выяснили, оптимистичный UI работает лучше всего для времени ответа менее 2 секунд. Выход за эти пределы может привести к неожиданным результатам и большому количеству недовольных пользователей. Я предупредил.

— Оптимистический UI — это не только про нажатия на кнопки. Этот подход может быть применён к различным событиям в жизненном цикле страницы, включая её загрузку. Например,skeleton screens следуют тому же принципу: вы надеетесь, что сервер ответит успешно, и заполнит плейсхолдеры, показываемые пользователю как можно раньше.